what is TILE_ANIMATION_MODE_RANDOM_START_TIMES

[skeddles]

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

[AThousandShips]

See also:

• Add TileSetAtlasSource::TileAnimationMode options and allow to shuffle tile animations godot#77257

CC @rakkarage

[rakkarage]

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.

[skeddles]

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.

[AThousandShips]

It does apply a random time offset so it isn't a matter of random frames though

[skeddles]

then why do all my tiles animations above start within 1 second of each other?

[AThousandShips]

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?

[kleonc]

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 godotengine/godot#77257 (comment)), 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 godotengine/godot#86210).

[skeddles]

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

[AThousandShips]

Except for the oversight how is it weird?

[dannflor]

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.

[AThousandShips]

It's being fixed, see the issue linked above 🙂

[kleonc]

Once CI checks will finish in godotengine/godot#86210 anyone feel free to test it by downloading the artifact (how-to).

[dannflor]

@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.

[AThousandShips]

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]

@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 godotengine/godot#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".)

[dannflor]

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 👍

[tetrapod00]

I'm going to close this, because it seems like the current documentation is adequate to describe the current behavior. IMO nothing more needs to be specified here:

Tile animations start at random times, looking varied.

The linked PR, godotengine/godot#86210, has also been merged, so I think this issue is resolved. If you disagree, feel free to leave a comment to reopen (ideally with a suggestion for a wording improvement).