Timeline ticks faster than Tick

Here is the setup I have which results in Timeline ticking 3 times faster than Tick;

Timeline is set to AutoPlay and Loop. However, if I set the Timeline length to 0.01 or check “Use Last Keyframe?” to true, Timeline will tick 3 times faster than Tick, no matter the framerate. Here it is;

Counter 2 is 190 (Tick) and Counter 1 is 570 (Timeline). At this point I thought that maybe Timeline ticks on my Maximum framerate rather than my Fixed framerate, which is 60. So I set it to go up as much as it can. I can reach 120 FPS and Timeline still ticks 3 times faster than Tick.

This felt weird to me because people confidently responded here that you can’t tick faster than Tick;

Can someone enlighten me, what’s going on here? Is it something wrong with my setup? Or is Timeline legitemately ticking 3 times a frame?

Did the tick default on this actor is 0?

Sorry? I didn’t quite get what you mean.

on actor defaults there is a field where you set the tick value, just a small check, is it value set to 0?

Oh, I see what you mean. Yes it is set to 0 and Tick ticks every frame no doubt. Because in another test I’ve made I set it to stop after 3 seconds, and the Tick count was around 170, which is correct, because I have 60 fps fix and a small fps drop at the very beginning (40fps to 60), which is the error between 170 and 180.

I just tested this code and in 4.17 and everything works as expected. Either the version has actually a bug, or you changed something else. Things that come up in my mind: Timeline Tick Interval, Actor Tick Interval, Time Dilation.

This is a fresh new project. Timeline Tick and Actor Tick are not touched. Global and custom time dilation are both 1.

While testing the code, did you set the Timeline to Use Last Keyframe? or set the Timeline length to 0.01?

Here is the problem, the Tick event works as intended, meaning it actually correctly ticks every frame. So how could I make Timeline tick faster than my framerate by changing the Timeline Tick or Actor Tick?

I will provide more useful screenshots with proper Game Time when I get the chance.

Sorry, I forgot to change the Timeline and you are right. Going to values around 0.01, the Timeline is ticking 3 times faster than the actor Tick. I’m not quite sure how to solve your problem though, to make a timeline tick faster than the actual actor :expressionless:

Its not necessarily a bad thing since you can make it update as fast as tick by not checking Use Last Keyframe?

I’m not sure what you mean - I experienced this triple tick issue on a timeline which didn’t have the Use Last Keyframe option ticked.

The problem is caused by the code which executes when the timeline exceeds the timeline length (or the last keyframe time), if the timeline has been set to loop. When this happens, it first sets the playback position to the end (to make sure any events are fired) which causes the first update execution, then it sets the playback position to the start which causes the second update execution, and then it continues as normal, setting the playback position to the point in the timeline where the time has wrapped around to, causing the third update execution. These all execute on the same frame - you can test this by printing the current game time to the screen.

Only the third update should be triggered, really. If one wanted to have an event trigger on the timeline end/beginning, they could do so with custom events. I noticed this because I’m currently doing some performance optimisations, and noticed that this looked like a bit of a waste.

Hope this helps! Shame that Epic didn’t get around to fixing this in the year since you first reported this issue.

Thanks,
Nick

When looping, the timeline component will execute the Update 3 times. I have submitted a pull request here to address this.

Oh wow, I really haven’t dug into it since I posted this and only looked at empty Timelines to check the issue, since nobody responded.
For me, a completely empty timeline with “Use Last Keyframe” unticked but set to loop will update only as fast as the tick.
But an empty timeline with “Use Last Keyframe” ticked will update three times more than tick.

I didn’t really think of any other scenarios, thanks for looking deeper into this!

I’m currently on version 4.19.2 and I can confirm the 3x tick speed on the timeline.
However I use it as a hack to be able to get a little more precision on an float value update during counting of the time passed between Http req → res. I simply did a float increment by deltaT / 3 as it seems the update speed of the timeline is 3x event tick. As far as I could find this was the only way from blueprints to count faster than the event tick (please correct me if I’m wrong, cause I’m not particularly happy with this hacky way of putting the counter together).

My pull request has been merged in, and the fix is available in 4.21.

You could essentially recreate the previous functionality by having a for loop in your update logic - the timeline component would previously update 3x when crossing over the end of the timeline if set up to loop, but it wouldn’t distribute those 3 updates over the frame. For all intents and purposes, you’d just be doing the logic 3 times, hence the bug. Of course you could do some more advanced stuff with delta time during these 3 updates, in order to step some simulation like a physics engine might do, but I think this is probably not the best use of a timeline component for that use case.

If you really wanted to have some logic execute more than once in a single frame in a more distributed manner, you could have multiple timeline components, and change their tick group so that they execute at different parts of the overall frame tick. However, for the case of wanting to track the time between a HTTP request and response, it may be better to just record the time of the request, and add a callback for your response in which you can record the time then calculate a duration from the two times (if this is what you want to do).

Hope this helps!

Thanks for the reply and the update on version 4.21.
Those are some great suggestions, I can’t believe I didn’t think of simply recording times! I will definitely check out the time method using the UTCNow function and milliseconds, and do some comparisons. Rigging up timelines in this way was somewhat of a desperate measure I came up with in the moment and once you’re inside a frame of mind it becomes hard to think outside it…

Anyway thanks a lot, this was very helpful.