Restarting Timeline on Finished pin after brief delay. Unexpected extra delay if player colliding

Hey team, looking for help with a timeline issue. First I’ll explain how I’m using the timeline, then I’ll explain the issue.

How I use the timeline: in my game I have a moving platform blueprint, which consists of a static mesh (currently set to the default unreal Cube mesh). The mesh location is updated on a timeline, moving it from the StartLocation to the TargetLocation. The level designer can set the TargetLocation in the Details panel after dragging the blueprint into the level

On BeginPlay, I set the start location and the play rate (the level designer can control the speed of the platform), and ultimately calls a custom event Start. This checks if we have any Offset (the level designer can add an offset time so that the platform waits for a moment before beginning its timeline), and if so, calls SetTimerByEvent with Time == Offset.

After the Offset time expires, we call Play which goes into a flipflop. The flipflop A goes into a Timeline’s Play pin. The flipflop B goes into the Timeline’s Reverse pin. When the timeline finishes, we call a custom event Pause, which checks if the level designer added any Delay (to stop the platform after each cycle). This allows the player to hop on the platform when it reaches the target location, rather than it immediately returning.

All of this is working great, except for one major pitfall

The issue: When my character is riding on the platform, there is a slight unpredictable extra delay before the timeline starts again. If I have two moving platforms side by side with the same settings, if I ride one of the platforms, it quickly becomes out of sync with the other one.

Some observations:

  • The platform still travels at the same speed, the desync only happens after we reach TargetLocation. We reach TargetLocation at the same time as the other platform. The other platform starts returning to StartLocation perfectly on time, while the platform I’m riding on takes slightly longer (again with the exact same settings)
  • The platforms are perfectly in sync if I’m not standing on them
  • If there is no delay between cycles (i.e the level designer left it at 0), then there is no desync, even if I’m standing on a platform. In this case we bypass the Set Timer By Event node and we call Play right away
  • This is not affected by networking or multiplayer scenarios. The same behaviour happens for server and client, and when there is only one player
  • I’ve tried using Tick to correct the platform’s position based on GetGameTimeInSeconds It must have something to do with the extra calculations happening when the player is colliding with the platform.

The attached video more or less shows the issue. In the video, I alt+tab away from unreal to simulate low frame rate, to show how the issue is exacerbated at low frame rate

It is worth pointing out here that if there is no Delay configured between cycles, and I’m riding the platform, there is no desync at all – This supports the idea that the issue lies somewhere within the SetTimerByEvent taking a little bit longer to process

I should mention that I’ve tried using SetTimerByEvent, I’ve tried a Delay node, even another Timeline to process the between-cycles delay, and a few different approaches with Event Tick, but all approaches resulted in the exact same things as evidenced in my video above

Here’s a UEPasteBin for my blueprint: Moving Platform timeline posted by anonymous | blueprintUE | PasteBin For Unreal Engine

Incase that doesn’t work, here’s an image:

Here’s the video:

1 Like

Do you have physics enabled on the cubes?

Simulate Physics is disabled on the cube mesh in the blueprint, if that is what you mean! Thanks for taking a look :slight_smile:

I am using the mesh called Cube from Engine Content, if that helps.

1 Like

Ok, not that, then… :slight_smile:

Next step I would take is to remove the timers. I know it’s a nice idea, but it might be causing the problem. Timers a great, but the way they start is a bit strange sometimes…

So, keep the timeline, but on the finished pin, just put a delay node with the delay amount, and then back to the flip flop.

Same with the pre-delay, just a delay on begin play, then call the timeline.

I’ve actually tried using delays instead of timers, got the same results. I also tried using a second timeline instead of delays or timers, same results. Finally, I also tried using GetGameTimeInSeconds (and similar nodes) to store the time when we pause the timeline, then on tick we check if GetGameTimeInSeconds + Delay > StoredTime, but got the exact same results

It seems like no matter what I do, the Timeline takes a little extra to restart if my player is standing on the platform, exacerbated at low framerates. If there is zero delay and Play is called immediately by the Finished pin, the platforms move in unison as expected

For what it’s worth I am not married to my code, using a timeline felt like the best solution for handling my moving traps (I’ve got others like a swinging axe, rotating logs, Spike walls that open and close, squishing you if you’re under them or flinging you if you stand on the back.

Everything works great except this one pretty big issue where the character’s collision + timers or delays on Finished that restart the timeline causes a perceived desync. It is exploitable and sorta negates the usability of any of the traps that the player can overlap with. It seemed like such a straightforward solution but alas I am stuck!

1 Like

Ok, I’ve set it up, and I get the same thing. Very weird… investigating… :rofl:

Ok, it’s the delay. When the system see this

( or a timer ), it puts the code from this BP on the back burner, and comes back and finishes running it later. The amount of time before it comes back is only an approximation to the delay and is also related to how many other things the system as to handle in the meantime. In this case, it seems to decide to make the calculations to put the player on the platform before coming back.

This leads to the problem. If you get rid of the delay on the end of the TL, it works fine.

I still think there might be a way to also have the delay… will come back on that one.


Ok, change the ‘tick group’ of the timeline

Also, post physics works. It’s because of the the way the engine compensates to get the character to step on the cube. Making the TL calculations other things have happened in the engine seems to fix it.

If you continue to have problems, then a central timeline is an idea. You could have it in another actor, of the game instance etc.

This is my code, btw :slight_smile:

You are a champion, that worked! I thought I had already ruled out the tick group, but I must have been changing it on that 2nd timeline i created or something and getting false negatives.

Thanks for your help, I always see you helping in the forums and never thought I’d be the one asking the question. What a relief, cheers!

1 Like

You’re welcome :smiley:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.