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.

Or

2 Likes

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.

2 Likes

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

2 Likes

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…

TIA

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

2 Likes

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.

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

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.

Also forgot: you can tick an event by recursively calling that event with a delay of 0, which delays the event until the next frame. You keep calling the same event until the condition is met (which makes a while loop).


Depends on how expensive the check is. But you should only be checking the condition if the variables of the condition have actually changed. If the variables don’t change, then the condition won’t change, so constantly rechecking the condition when the variables haven’t changed is pointless and inefficient.

Simply bind event to begin play, for example, Death, Damage, Touch, Interaction, etc. Be sure to unbind it once it fires. If you unbind it once it is done, it removes clears the memory of the bind. Good practice too.

thanks, im currently using c++ mix with bps but currently I am prototyping. I hope to move the expensive checks to c++ once I am confident enough. So far this thread helped me figure some problem areas when working with bps! thanks everyone for the great contributions. Hope this thread helps other people too! :grinning: