killswitch for updates

William John Goodwater II 3 years ago updated by Lazlo Bonin (Lead Developer) 3 years ago 9
so I don't know if this exist or if there is a better way of handling this, but I tend to need what I call "Kill switches" for Update Events. When I need to make a Update Event go from a endless pulse of updates to a single pulse I add a If Statement with a Kill Switch Variable.

This is an example: i am receiving a update, it passes through the branch and sets the Killswitch to true meaning only one Update passes through the branch meaning anything after the code will be updated only once.

My Idea (or question if it exist already): is why cant we have a single Unity that can perform this task?
Now i know it may already exist and I may be going about this the wrong way but that's why I'm bringing this up.

Bolt Version:
Unity Version:
Scripting Backend:
.NET Version (API Compatibility Level):
Satisfaction mark by William John Goodwater II 3 years ago

Doesn't actually exist, I did this too, and it's very useful for being able to do a regular loop on update. But we have something ultimately I think is brilliant on it's way, but Lazlo is still fiddling with ideas I think. There is a potential solution for full execution without any special unit for that in some ways We'll see how it pans out, but there is potential here to go way beyond what your asking. In present why not have a macro. You don't need to do it again.

Tip, outputs are fantastic to pass data, either in a dictionary or list. You want it to be held as a reference, that's why I use lists or dictionary, instead of just a bool. Because that doesn't retain it's origins.

So pass an out from a list of dictionary with the bool . Then when you send outside of the macro, you'll be able to use that data now anywhere to manipulate it's values going on and off, that specific instance. That's the beauty of macros, you can do a lot hidden from the eye that communicates very uniquely to your needs.

Can you give an example of your Kill switch macro with Dictionary? I mean i get the idea of the Kill switch Macro on its own, but im still learning Dictionaries and have no idea what that has to do with this.

Edit: This is the Macro I came up with, I also passed a Reset switch in there Just in case i needed it for later.

a bool is a value type, not a reference type. So passing a bool only gives you a copy of the value, not a reference to the variable that holds it. Values do not retain where they come from but references maintain there value until no one references it any longer. Then it's freed from memory and no longer exists. If you get a reference to a list or dictionary (these are reference types, not value) then the bool you added to it can be referred to by talking to the holder, dictionary or list. If you change the item in the list, from outside the macro, even in separate objects, as long as it's a reference to that list or dictionary itself, the value will be changed across anywhere that holds a reference to that list. Which is not how value types work. Give me a few and I'll get you a photo worked out to demonstrate what your trying to do. How that's not too confusing and I explained it well enough.

Okay so here is an example. This is inside the macro for Update itself.

Now you can change this killswitch from anywhere in your game that gets a reference to this list, and itll update directly to this version of the update macro. And you only have to get it once. This is a terrible example because everything is close together, I wouldn't do this unless its far away or on different objects, but to show you the point of references this way. Here is what I did outside of the update. Now the update itself becomes its own killswitch. Plop down this update instead of the other.

Your way is perfectly fine! This may be overboard for most of your cases I am sure, but the premise holds that now you can manipulate this inside other macros, for like creating your own nested loops even and such. You could do it like your doing now without directly in update, that doesn't even matter. But without a reference to it, you'll need to toy with that macros own values only. you won't be able to do anything except right where your doing it in that specific parent graph. Unless you send true and false as events from somewhere else.

* EDIT : Sorry, do not put the wait for next frame. Just silly mistake. Update always happens right after start. So not necessary.

Okay i think i get your idea, yours is more useful if i need to call a specific objects kill switch from "way off in the papa patch"

but for most my cases I only need it to convert a Update code to one-off. This is mostly when I am working with a long list of stuff on an update and near the end if i don't make it a single signal, it breaks something bad.

Yup correct, I'd definitely stick with what your doing here. Mine may tend to just lend more to getting creative with exactly how things can flow but not be practical for one off blocks to execution. Now having a macro you can stop any point in execution though, Super cool.  The other way is also good to have separate units execution playing off this. Passing different lists from each unit with a bool to the next. Effectively infinite nested loops or custom conditional execution routines. Since the neighboring units now can be responsible for each others flow, start, stop, pause, ect.

Completed (Unreleased)

Version 1.4 will include a Once unit that can be reset, it sounds like this is what you might be looking for.

But also, I think you should rethink your design if you're using Update or FixedUpdate for code that should only execute once. Why not use an event in that case?

while you're right, I could use a different event, 90% of these kill/do once is at the very end of a chain and just needs a single output (or else we get updated overflow)