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