Open skeddles opened 9 months ago
Instead of all instances starting at the exact same time (how it normally works);
each instance (tile) of the animation has it's own random start time... is how it is meant to work.
Sorry if name or docs is confusing. Thanks for feedback.
okay, I see why mine doesn't work now. the problem is my tiles seem to all start within a second of each other, even though there's a frame with a long pause.
I have one frame with a big pause, then 3 really short frames. so they at most will be offset by the times of the 3 short frames, which is only 600ms.
seems to me this property should be called "TILE_ANIMATION_MODE_RANDOM_START_TILES" not start times, which I took to meant it would start anywhere within the animation's 10.6s length, which I could have used.
but at the very least, the docs should explain that this picks a random start TILE not a random start TIME.
unfortunately it seems this feature wont work for my game.
It does apply a random time offset so it isn't a matter of random frames though
then why do all my tiles animations above start within 1 second of each other?
Because the random offset is limited to one second? It's not a frame offset, this is a possible improvement but currently that's how it works
How would what I said be incompatible with that? And how would it be compatible with it being an offset of frames?
okay, I see why mine doesn't work now. the problem is my tiles seem to all start within a second of each other, even though there's a frame with a long pause.
I have one frame with a big pause, then 3 really short frames. so they at most will be offset by the times of the 3 short frames, which is only 600ms.
seems to me this property should be called "TILE_ANIMATION_MODE_RANDOM_START_TILES" not start times, which I took to meant it would start anywhere within the animation's 10.6s length, which I could have used.
but at the very least, the docs should explain that this picks a random start TILE not a random start TIME.
unfortunately it seems this feature wont work for my game.
I've mentioned it should work timewise when it was being added (in https://github.com/godotengine/godot/pull/77257#discussion_r1199581275), to me the current behavior is absolutely a bug in the implementation. The random_animation_offset
passed to draw_tile
method is in 0.0
..1.0
range and it's used as is when passed to the RenderingServer but it should be instead scaled according to the calculated duration of the animation. Seems we overlooked this while reviewing. This needs to be fixed (I've opened https://github.com/godotengine/godot/pull/86210).
Because the random offset is limited to one second? It's not a frame offset, this is a possible improvement but currently that's how it works
How would what I said be incompatible with that? And how would it be compatible with it being an offset of frames?
oh... that's a weird way to randomize them...
I agree @kleonc that it seems like it should be based on the animation's length
Except for the oversight how is it weird?
As someone who has also run into this, it makes certain intermittent tile animations (like @skeddles above with the water waves) impossible to configure correctly. Limiting it to a second just doesn't consider the wide world of random offsets we might want that have a larger period.
It's being fixed, see the issue linked above 🙂
Once CI checks will finish in https://github.com/godotengine/godot/pull/86210 anyone feel free to test it by downloading the artifact (how-to).
@kleonc the way you currently have it the animation is sitting on the last frame while it waits for the offset to expire. Usually when you animate something, the FIRST frame is the point of rest. If you picture an animated character sprite, it would be like having him stop with his foot hovering over the ground. Or with the water, stopping with the ripple still in the water.
How do you mean it waits? It loops and doesn't hold on the end
Please add a note on the PR about it, preferably with some samples of what's wrong, video for example
@kleonc the way you currently have it the animation is sitting on the last frame while it waits for the offset to expire. Usually when you animate something, the FIRST frame is the point of rest. If you picture an animated character sprite, it would be like having him stop with his foot hovering over the ground. Or with the water, stopping with the ripple still in the water.
@dannflor What do you mean by "currently"? Some specific released version or https://github.com/godotengine/godot/pull/86210 or something else? Also are you referring to some specific behavior you're experiencing in some specific use case / setup of yours? Please be more specific. (I also don't understand what do you mean by this "waiting".)
Sorry for the confusion, I checked out the artifact but my tile timings were just misconfigured. I had the last frame extending for multiple seconds for some reason and thought that was because of your change. It's working perfectly 👍
Your Godot version: 4.2 Issue description:
im trying to figure out how the new "random start times" feature works for timemaps, since it's behaving strangely for me. i tried to look on the docs to find an explination of how it works and it says this:
TILE_ANIMATION_MODE_RANDOM_START_TIMES -Tile animations start at random times, looking varied.
which doesnt really tell me anything.
what does this actually do?
URL to the documentation page (if already existing): https://docs.godotengine.org/en/stable/classes/class_tilesetatlassource.html#enumerations