Time Discrepancy between Delay, Timer, and Timeline

Hello everyone,

I’ve been puzzled by discovering that Delay (time = 1), Set timer by event (time = 1) and Timeline (length = 1) all give different results to me.

The exact time those 3 time management methods “trigger” seem to differ slightly.

I’ve created a simple Uasset actor to drop into the world, that will print the trigger times to the screen using the “Now” node. You’ll find it here :…cy.uasset/file

Is it a known, normal behaviour? It’s probably nothing but I must say it kinda shook my trust in these nodes since now I’m left wondering which one is “more correct” and if I should avoid at all cost “mixing” them (like launching a 1 second timeline and planning a Timer trigger midway to do something else).

Capture d’écran 2.png

Thanks for your opinion :slight_smile:

This is probably as intended, i do not know exactly how all of those methods count time, but:

timer by event is meant to be most precise, it is basically triggered event directly from engine (from C++ level), and blueprints process it when triggered. Not sure if those are improved, but having many of them made my code really easy to crash (broken link or lost reference to trigger was major pita).
delay, is processed every frame together with all blueprints, this stuff may be delayed, or not triggered in equal intervals.
never played with timelines really, i prefer interpto and slightly improved event tick

@DehoEdeba since you’re testing time differences, have also testing in a development build?

It’s not surprising that Timelines are off from the other two, they seem to have more under the hood. As @Nawrot states, timers are once again the most reliable way to perform delays. And I’ll add that they are the most flexible. I also remember reading another forum post about how timelines use timers (assuming that meant under the hood).

I’d also time it using GameTimeInSeconds.

These timed nodes aren’t meant to be totally accurate, it’s just a best attempt taking into account frame rate and cpu load.

Thanks for your ideas everyone, I appreciate it :smiley:

I didn’t know that Timers were fragile like you say. I’ll be careful not to abuse them.
I’ve started using timelines more and more though, since they’re such a comfortable way of lerping values without resorting to the tick event. I don’t think I could go back ^^

Ok I’ve been trying to time the triggers using GameTimeInSeconds and if anything it makes things more readable. I didn’t think the problem could come from the Now node.
Unfortunately it doesn’t really change the situation. What’s infuriating is that it keeps changing: I have streaks where Delay = Timer with a premature Timeline but then I try a few minutes later and now Delay = Timeline and the Timer is off. So weird.

Indeed timelines seem to be more often than not the “outlier”. What’s funny is that it consistently triggers slightly BEFORE one second when the other two methods only ever trigger AFTER one second.

Anyway I’m just splitting hair here I suppose, uncovering an irrelevant engine or CPU limitation. We’re talking very small time differences here, after all. If I think too much about it it bothers me a lot, so I guess I should simply stop thinking about it.
I suppose time is just a social construct ^^

You probably never need such precise timing for a game project. Excessive and fast timing may have quite big hit on performance, and that is how i know those timers and event tick differences.
I tried to optimize android game with 200-400 actors that needed update (spawning visible mesh, collision and physics body when they in range).

First attempt to do it during event tick was disaster, ate all cpu instantly.
Then i tried timers it was even worse, too easy to destroy actor and leave timer unhandled.

Then back to event tick, but this time i updated only 1/4th of them per tick. And that was best solution. Bit more experimenting and game looked ok up to updating 1/4th every half second.

So you probably do not need those timers to be precise and update in exact frame you need, most people will not notice difference.

Deltasecs may be a factor as its included in Timelines but not Delays / Timers iirc. But you’re over-thinking things a bit as this is game dev. Its more VFX smoke and mirrors, than exact science.:wink: In general, its more important to have things happen in sync (in the right order). But if you need precise timings then try posting in one of the Arduino threads, as that’s where timing is more crucial maybe. You can probably sync things using game-time anyway as opposed to anything else. Overall, I wonder what’s the craziest thing Unreal Engine has ever been connected into anyway? :stuck_out_tongue: Probably not anything involving cutting / assembly / industrial robots.:smiley: