I notice this strange trend on anwserhub, where people proposing Tick event as ultimate solution for rapid function calling (usally rapid spawning of objects) forgetting the fact that Tick is called on each frame rendered… latterly each frame rendered, so rapid fire will depends on users frame per second.
Thru tick is good for movement and any other float-based variable changes that can be scaled with delta time (first example thats shows nodes rotating mesh didn’t do even that :p), the call rate of Tick it self can’t be scaled.
I think people are not aware that nodes can be naturly looped and that loop can be controlled with switch nodes and gates
Alternatively you can use engine’s timer mechanism, which let you create timer can call function even in infinite intervals,and you can control timer flow, thru it might be little confusing for blueprint when they place “Set Timer” node for the first time.
It’s okay to use Ticks as the trigger to fire rapidly, but you should at least take Delta Seconds into consideration somewhere along the line.
That said, it’s also possible (I think) to have faster-than-FPS firing rates, not all game functions have to be tied to the frames-per-second. In your example, if the delay time is less than the framerate, you should still get faster firing rates. At least it’ll look that way anyway. (I think)
If that was true it would apply to tick too, mouse event is on different thread (or else loop would freeze the game while you holding a button) then tick and i think engine puts spawning time to consideration in calculating delta times or else there would be serious desync issues on unstable fame ate. With tick running on 20 per second, you won’t have any physical chance to call fire function faster then that where othe event running on different thread can do that, o else oyu gonna span few based on delta time and correct there postion. But i think the best way is to use timers thru, Tick was made for to do something each frame, not each amount of time.
Yeah you definitely don’t want rapid weapon fire (and other similar things) to be frame-rate dependent but you know… tick works for prototyping/testing purposes
Sorry for resurrecting an old thread, however I felt like saying thanks to the OP for I have just used this as a starting point to create a health recovery macro for a passive skill. Works great!
I was making a GAU gun with a semi-realistic rate of fire, which is about 8000 rounds per minute. It worked properly only with Tick and calculating how many rounds should be spawned since previous tick. Timers simply couldn’t spawn objects fast enough and you have to take delta time into account to calculate proper location of each spawned round.
So I can say that choosing one or another method is not such an obvious answer.
From what I’ve gathered from various sources: Timers are a million times more efficient since you are not calling it every frame. I mean for me (I run a 144hz screen), That’s 144FPS (supposedly that’s what fraps says anyway), vice the looping timer that’s going off WHEN you tell it and HOW often. Like When you overlap something, it loops every 1 second. A lot less demand.
Very good case in-point. Not everything is running at 30 to 60 frames per second.
People use the Tick because it’s the quick-dirty solution to get something going really quick and show to people that have questions. The “politically correct” response generally does not use Tick, but some form of Timer or Delayed Loop.
I’ve been using timers to do things at intervals as it felt logical- I don’t think there is any situation where you’d want the frame rate of the consumer to dictate how often an event is called! Glad you guys confirmed that it seems to be the way to go- so many tutorials seem to go straight for the tick node to do things, so I was starting to think I was doing something wrong using timers!
Sorry to revive an old thread but I’ve done something I’m not sure is efficient or not which lets me use tick, without actually using the Tick Event.
What I did is in my event graph of my character, I created a float variable and made the tick event set it to delta seconds. So every tick I have a variable that is set to the previous tick’s DS. Then to create my loops, I use a delay node and plug in my delta second variable.
Works like a charm, but is this an efficient hack? Or is this just as bad as using tick itself?
sounds like that would be the same thing as hooking it up to tick but now you have an extra variable in there. thats fine if you use tick and dont want a lot of lines around the screen but isnt any more efficient in the background than using tick for everything. the retriggerable delay works well and you can set it to start and never stop looping from beginPlay, with a float variable connected to the delay time. which basically recreates a tick but it can be reused with different delay times (ie, rate of fire, refresh time, etc) and not just every frame
That clarification saved my skin, @DamirH . Am very grateful that you did it! <3
Besides, I’m grateful that I found this thread. As more as I was using Event Tick, more I used to feel bad. I knew it smells bad somehow, but was not sure why or acknowledged of an alternative. So, OP, thank you as well!
Also, I think Epic should consider implementing a native solution for timers like this. Probably, newbies like me would sin way less.
