[Issue] Anim_time_update innacuracy

[Cub0use]

I discovered this bug with a specific setup I use to jump ahead in an animation, but only on the first frame.

With the following in Anim Time Update, for a looping animation of 0 length:

q.anim_time+q.delta_time + (q.life_time==0 ? math.random(0,2): 0)

you might notice that the animation jumps ahead more than 2s sometimes (make sure to play it from timestamp 0, otherwise it will play like normal).

---

https://user-images.githubusercontent.com/81629481/173973416-5a086113-9613-49af-aa67-dd5ae9975229.mp4

By increasing the amount of time the animation should jump ahead, I noticed larger gaps, always further ahead than the desired number.

For instance:

q.anim_time+q.delta_time + (q.life_time==0 ? 20 : 0) jumps ahead by 30s q.anim_time+q.delta_time + (q.life_time==0 ? 60 : 0) jumps ahead by 1m30s

You can also produce a similar effect by just putting in Anim Time Update the number of seconds you wish to jump forward:

• Just 60 in Anim Time Update will jump ahead by 1m30s if you start from timestamp 0; but if you start to play the animation from a timestamp further ahead, say 30s, it will jump ahead to 1m15s instead (it lessens the jump the further the initial timestamp is).

If you start from 1m exactly or more (with 60 in Anim Time Update still), there will be no jump.

• Additionally, animations with Anim Time Update that do not include query.anim_time or query.life_time still play out, instead of staying stuck at a certain time stamp.

---

I have tested the following custom Anim Time Updates in Minecraft Bedrock, and found that they behaved differently in Blockbench.

1. q.life_time < 5 ? 1 : 3 In game, the animation is stuck for the first 5s at the 1s timestamp, then at the 3s timestamp.

Reproducing how query.life_time works in game is ambiguous though, since in game it is the time since which an entity has been loaded. In Blockbench, it is currently tied to query.anim_time, aka the time on the timeline. Furthermore, you can play other animations additively, and they will play out following the main, selected animation, even if they have different Anim Time Updates. So I don't think there is a proper way to reproduce how query.life_time behaves in game, better to stick to making it the same as query.anim_time in Blockbench.

2. q.anim_time < 5 ? 1 : 3 In game, the animation is stuck at the 1s timestamp forever, since q.anim_time starts at 0.

In Blockbench, it should also stay stuck at timestamp 1 if the initial time is below 5s. Instead, it jumps ahead to timestamp 1.5 (and not 1, because of the inaccuracy mentioned above), and then plays out until the end/indefinitely.

If you started to play the animation at timestamp 5s or further, it should instantly go back to 3s, then logically 1s. Instead, it plays out until the end/indefinitely.

3. (q.anim_time > 4) ? 0 : (q.anim_time+q.delta_time) After timestamp 4s, the animation should "reset" and go back to timestamp 0, playing in a loop (if the animation length is 0 or longer than 4s). Instead, it plays out until the end/indefinitely, no matter the initial time.

---

To sum up, there are three main issues I see with custom Anim Time Update:

• jumps at precise timestamps using logic comparing query.anim_time or query.life_time are inaccurate (too far ahead)
• Animations play out even if query.anim_time+query.delta_time or a variation is not written in.
• Animations don't seem to be able to go back at an earlier timestamp by comparing query.anim_time or query.life_time.

Blockbench 4.2.5 (Animation for Mc Bedrock models), Desktop app on W10

[JannisX11]

I'll look into these in more detail later, but this is mostly by design. Animations in Blockbench have no entity obviously, so there is no entity lifetime. So if the time in the timeline stops, or a frame does 0 progress on the timeline, then there is no chance for it to start up again.

[Cub0use]

So if the time in the timeline stops, or a frame does 0 progress on the timeline, then there is no chance for it to start up again.

I think I see what you mean. But could Blockbench continue to evaluate anim_time_update, even after it causes the timeline to stop moving forward? I guess that would kind of amount to having q.life_time, to calculate how to advance time (q.anim_time is literally the time on the timeline, a "result"; while q.life_time increases no matter what).

But the ramification is that the animation can produce different results depending on where the initial timecode is on the timeline when you press play, assuming this "pseudo" q.life_time advances from 0 the moment you press play. Which would happen in Minecraft, but not super convenient to create an animation.

What about being able to set the starting time of q.life_time in a number-field type of tool? It would then increment in real-time, no matter when you start playing the animation from on the timeline.