Is there a way for event tick to fire an event once if conditions are met

I am constantly checking distance to the player from a point and I would need a way that isn’t too heavy to fire off a event once the condition is true. Problem is currently when it happens event tick will fire it alot of times, i would need to fire it once and only when the condition is met and only reset once its false again.
2)Im not sure but in unitys update function when for instance scripting an event in update that has to do with key pressing it would only perform that action once. So if i have a jump function in unitys update, it would not continuously jump as it is on update but only once. Can someone explain why that is? Why is update on c++ and unity only fired once in some events but not in bp event tick

PS: I know i could use a do once but I was wondering if there was a cleaner way to check if a condition is true in quick intervals and firing off an event based on that.

Unity update runs every frame, just like tick, I think.

If you don’t want to do something every frame, probably don’t put it on tick.

In any event, you can just put a bool there to stop tick running something, until the condition is met, then it will run.


1 Like

Yea i have a similar setup currently as your picture, though firing that event once the condition is true will be done alot of times. I was wondering if do once + reset is the only solution to do that in blueprint.

Like mentioned, in c++ or unity update you have jump or other events on tick as well but they only get fired once. I wonder why and how

If the condition is based on the player’s position, only check the condition when the player (or the point) moves; if player never moves, the condition will never change, so checking every tick is inefficient.

Once the condition is met and the event has fired, store that it was fired. You can also compare the last position with the current position: if the last position is outside the range and the current position is inside, then fire the event.

The thing is, lets say distance is less than the needed value to make the condition true, I would be storing the value every instead of once. And then I would have to do the opposite, calculating wether player is now further away and firing off an event. The main question I have is there a clean way to only make a function fire once. Or do i have to use booleans or do once to have this behaviour. Note: most is theoretical, for stuff like that I would perhaps use box triggers and timers so I don’t check all the time

Yes, but using a boolean is the most straight-forward option (and in fact, the “Do Once” actually uses two booleans).

If you don’t want to use a boolean, the question is: how would a function know if it fired without keeping track of if it fired? This is actually possible, and the solution is my second option:

This will only fire once whenever the player passes the distance “bubble”. Though, instead of storing the bool “Has Event Fired”, you store the vector “Last Position”, but that’s more reusable because you are likely going to need the last position for other things, too.

Yes, this would also work using overlap begin/end triggers. Distance is spherical, so a sphere would work.

1 Like

The programmer who invented the triggers did it precisely to avoid this solution :joy:


haha, yea i think I am currently doing stuff and just wanted to make sure I do it most clean way possible. Currently I notice Im stacking quite a bit on variables, like booleans (isFiring, HasEntered…) and just wanted to see wether there is a trick to get some things done using different ways! :smiley:

one more question, generally how much overhead is there to constantly check if a condition is true on tick? For instance i have a mechanic where a ball is following you on tick and after 2 seconds it will stop calculating Player-Ball vector for the direction and will just go towards the last calculated direction (like a homing ball which stops following after a while and just goes towards last calculated direction). The big mess is when for instance I need the movement to be on tick naturally but i also want to flag the object that after 3 seconds you should stop calculating direction and just go last.

Now thinking about it myself, should i put a function (custom event on tick) and when i want to initiate a follow i should have the custom event only enable bools (like bAllowFollow=true) and another event to delay and disable calculation? So my custom event which triggers that is only used as a flag for determining when to start. How much overhead does checking on tick constantly have? Also would be awesome if someone has any idea how to do it cleaner. I need to follow my player on tick but also have other flags and booleans that need to be enabled once…


Another option is to just use an event dispatcher. This is one of the ways they are meant for. Set up your event dispatcher, then have various parts of your project listen for it. When an event dispatcher fires, it broadcasts a message out to your entire project…it doesn’t care if anything is listening for it or not, it’s job is to just broadcast out.

Then you have a listener/bind event (or multiple bind events, in different parts of your project) that would actually do the implementation of whatever you need it to. If you set up your event dispatcher in your Game Instance (singleton), you can listen for it anywhere in your project. The event binding could also be set up in begin play. Try it out with a print string and you’ll see that even though it’s in begin play (runs once at initialization), it’ll still be called anytime your event dispatcher is triggered.

An example would be an event dispatcher called GainXP. Your UI would be listening for it so you can display how much XP you gained, but your Character would also be listening for it to actually increase your XP variable stored on your character.

The bool check method is also perfectly fine and doesn’t cost much.

Hope this helps.

“I need to follow my player on tick but also have other flags and booleans that need to be enabled once…”

You could use a Sequence node to fire multiple things in a sequence to achieve this last portion.

I usually use gates and an event that closes or opens it for those behaviors and saves me creating bools
You could add a doOnce after the gate and that the active does the reset

Lots of good suggestions already above. But the other thing to think about is this. How many of these player or polling actor checks are likely to be in the final game? If its just one, you’re overthinking this. If there’s 10-100 you’re still overthinking this. If there could be 1000-10000, then you’re doing the right thing by asking about this now ahead of time.

Overall Axis input events behave like a Tick. So often you can add a Float-Compare node + Branch check to see if the axis is above zero or is nearly equal, and then choose to perform the polling check (axis > zero indicates player input → player movement).

A Gate or DoOnce or Bool equally work fine as a test to perform the polling check only once. I like the first two options, as it means having to deal with less gameplay states / variables. Then you have to decide if there’s going to be a lot of these same / similar polling checks? If so, it might be better to initiate a Timer from the Axis event. Then just have the Timer do all these checks in one place or run once a second, or every other second, or faster if the gameplay is super quick. Often that’s enough accuracy in practice / reality.

As was hinted above, if the Timer code then needs to communicate with lots of other separate actors (to notify them), you can then use Event-Dispatchers or Interfaces. :wink:

1 Like

I agree with DomusLudus. It really sounds like you just need to make a triggerbox for this. Have it fire once on beginoverlap and you are good to go. I started out in Unity and my teacher had us putting lots of stuff on Update and FixedUpdate, but when I switched teachers and switched to Unreal I was told often to avoid putting things on Tick, so I’ve found a million ways to avoid having to use Tick. Mainly just, as people said, you don’t know how big your game is going to get and if you start putting a bunch of little things on tick now then later on you run into problems. But in this case I think it’s a really easy solution, you just create a triggerbox or trigger volume or collider that fires once on the first BeginOverlap and you are good to go.

Was thinking all these different answers may be a little confusing. So… If the OP wants a bit more background perspective then read on… As far as the best answer or most right answer is concerned, the trigger-box / collision-box / collision-volume idea probably wins as the most correct answer on a multiple choice test. However, there’s a lot more to this.

  • The big book normally recommends always using event-driven programming to drive gameplay, rather than constant polling or distance checks done on Tick (Timer may be ok it just depends on the Time interval). So just to be clear here… Event-driven programming = collision-volume / trigger-box AKA begin-overlap / end-overlap events.

  • However in practice especially during prototyping, there’s a lot more to this and quite a few gotchas you need to be aware of where this may fail, as it requires more complete setup done in advance within the level and the player. There may also be differences in coding this all in the LevelBP vs other BP’s: Triggerbox vs CollisionBox!

  • Examples of ways where this can fail… Overall, the level itself needs to be mostly finished. But what if there’s 99 levels that are all different, but only one is finished right now? What if you’re using a simple cube for the player now, but later they will be a pawn or a character? What if in the final game they’re going to be a horse / dog or an elongated spaceship, and you haven’t decided how much of the actor has to actually ‘cross the line’ in order for the event to actually trigger? What if the player may have attachments later that will change their actual collision considerably? What if some of these attachments are affected by the rotation of the camera, and so turning around may inadvertently trigger the collision in unexpected ways you didn’t account for at game time? What if you plan to use meshes underneath the player’s feet in the final game, but the volume doesn’t quite line up or match those exactly yet (large volumes, lighting and other overlapping objects in the world may make this hard to do perfectly with the skills you have right now)? Overall, the two biggest gotchas of making event-driven programming work, involve matching collision-types between the player and collision-box, and what the actual movement code looks like (whether the player moves using simulated physics / kinematic-interp’d movement / CMC).

  • Plus, what if you find out that for any of the reasons above or for others not mentioned, that the event is being triggered multiple times killing your whole gameplay, but you can’t figure out why? In that case using a DoOnce / Gate / Bool (and resetting it on a delay or timer), may still be required to avoid triggering duplicate events.

  • Summing up, there’s a good reason why Distance-Squared is used in game dev. Its faster than the default Get-Distance node, and will work between any two actors regardless of the collision setup. Polling distance makes gameplay coding easier regardless of how complex a level is… Also check out this thread as well, as it contains some interesting hints showing the variety of ways there are to go about things. So in short, there really is no absolute correct answer. It just comes down to performance and the specific needs of your particular game. Welcome to game dev… :sunglasses:

1 Like

I stay away from ticks and rely on Events for almost everything.

I’d like to remind that it’s possible to unsubscribe event handlers as well, some seem to forget this and try to make weird hacks instead of simply leaving the event party.

You can unsubscribe, like the "Clear and Invalidate Timer by Handle " call here:

1 Like

Good point. Its easy to forget that its possible to unregister events. What would be interesting to know is what’s the overhead or overall difference though. For example, what if you’re doing constant Bind / Unbind events, is there a big GC cost versus just using a Gate or something? :thinking:

Its the first time im seeing this set up, is there a documentation or guide for it? I googled and it was cascade/niagra stuff but this looks new to me.

Is this something like timer by event? Also, isn’t event tick best for accuracy? If i set timer by event on loop with a time of 0.016 it can be inaccurate at times

That’s custom node made from C++.
I always mix Blueprints with Cpp nodes.

If you see the source of Gate node you will see that the VM end up generating at least 2 UObjects just to run the node.

A delegate handle is a simple Struct, which is much less GC cost than 1 UObject.

1 Like

Not sure what your trying to do with the code. But event ticks normally are expensive the more you add to them and can get glitchy. If your trying to interact with things then I would set up a base interact actor then have a overlap trigger with the proper code to handle what your trying to do. Then create Child’s to make them differ. Another way would be to use an interface with a sphere trace. And what ever object you add the interface to will fire off your event if your trace hits it. Hope this helped.