Instantiation Timer Loop

[abstract cove]

Hi I'm trying to have one object instantiate for a brief duration of 10 seconds, pause and then instantiate another object for 10 seconds and have it in a loop. This is what I have so far. Does anyone have a solution?

[thorn flax]

Use custom event.

Once a cooldown node is triggered with 10 seconds - connect completed to "trigger custom event"

And then add this custom event to the start of the cooldown node.

And whatever you want to happen every 10 seconds, you put it in between cooldown and trigger custom event

Custom Event >> [ coolDown] >> Instantiate >> Trigger Custom Event

And the loop goes on

[abstract cove]

I'll give it a shot and let you know the results. Thanks a lot dude!

[abstract cove]

Does it automatically put it in a loop? Or will I need a unit for that?

[thorn flax]

Unit? Uhm if the trigger event is triggered on cooldown complete, then it will re-initiate the cooldown forever.

Unless you add a IF before cooldown - in between custom event and cooldown

And then, you would only need the first flow to trigger that cooldown

[abstract cove]

Okay so I implemented it but it seems to be instantiating the first item while instantiating the second item periodically rather than pausing instantiation for the first item for 10 seconds and then instantiating the second one. Here's what I put

[regal wasp]

Yeah dont use update for that. Timers are not great for everything. Give coroutines a try, much easier to control

You can have a wait node inside a while loop

@thorn flax Can UVS use InvokeRepeating?

Thats a super simple way to do timer stuff if you are still learning to program

But a custom recursive event is good idea. If you insist on using timer node

[thorn flax]

Ive seen others do that - not sure the differences. I only used custom events and such methods.

[abstract cove]

What do you mean by coroutines? What exactly are they?

[abstract cove]

The last time I tried a while loop, my game crashed

[regal wasp]

idk how much you know already so I'll just waffle

loops like for & while and recursive methods are prime suspects for your game freezing. But you use these whenever you want to repeat something. They usually come with controls that let you limit how much they loop. while is a tad more unruly compared to for.

While loops don't inherently crash your app, they will if you don't give them any way to exit. If it freezes it means the condition you provided never becomes false. So it loops infinitely and hogs up all your computer's resources in a single cycle until your app crashes.

while (1 == 1) will crash your app, because there is never a situation where 1 doesn't equal 1.

The rule is to always make sure your while loop has a way to exit.

for loops are a bit friendlier, you tell them from the very beginning exactly how many times you want them to run, rather than infinite. For instance, spawn 5 enemies. for is good for that.

you can generally use while and for interchangeably, you adjust your approach accordingly.

as for coroutines, I'll show you an example. They are a bit strange to learn in C# at first, but thankfully they make more beginner-sense in VisualScripting

First, just to clarify, this is how Litoid was suggesting you can do it using Timer

that will log "Done" every 5 seconds. Start triggers it the first time, after that the custom event just keeps waiting 5 seconds then calling itself forever

here is a coroutine version of the exact same thing

you'll see almost no difference, except that the Custom Event node has to be set to Coroutine. Wait nodes won't work unless the event that's running them is set to that.

as you're just learning, you'll probably have more fun with the Timer node, as it automatically lets you sample ticks, elapsed time, time remaining and % etc.

to get those values from a coroutine you need to add a little elbow grease. Coroutines can offer more control, but that's not always the case

But unlike the timer node, which basically creates a new subroutine each time its run, you cant run them so easily in a loop, that's why recursion as in the above example works better.

Coroutines on the other hand work more in tandem with loops. Unlike in a regular procedure, where a while loop tries to resolve all within a single cycle, in a coroutine you can stall the loop so it doesn't proceed until some time later when you allow it to based on a set of rules. So for more advanced use-cases, it's handier than timer.

it depends on the situation, but there, you have 3 ways to make a repeating timer

[thorn flax]

Coroutine = co - routine.

Means once a node (or event) triggers, something happens in a separate timeline from main one.

The code can continue to execute on its own timeline. But the timer behind the coroutine is running on background.

This helps for example when you need time-based nodes like "wait for X seconds" or "run at end of this frame" or "run on next frame".

And yet you can use nodes like timer or cooldown without needing a coroutine.

This coroutine are set in event-type nodes like: onUpdate, Custom Event, on collision enter, on trigger exit, etc.

You click those nodes, and in node settings you mark checkbox to activate it.

[regal wasp]

I took a look at InvokeRepeating but it's not a good option for UVS, makes sense in C# cos you provide a delegate name but that's not a super compatible approach for UVS

[fast rapids]

is there an actual difference with using a float variable that goes down per time.deltatime and then stop if at 0

[regal wasp]

You can do update timers that way if u want. I usually wouldnt because I try to avoid Update on principle. If you prefer, it's fine.

[thorn flax]

I did a test, 1000 operations doing the same. Different methods.

And cooldown node always win. Better performance than doing that. Variable - delta Time until 0.

Its somewhere in the posts

[fast rapids]

how is your update timer set up, is it set with a condition at the begining and at the end

[regal wasp]

I'm assuming Cooldown node runs an async thread

coroutines simulate that effect but without actually starting a separate thread

I don't really worry about the performance side of this, more the maintenance side. Update versions of this tend to be messier. It's nice when code reads like a story.

I will still take a coroutine over Update because you can choose when to start and stop them without requiring a check each frame, or without having to maintain additional states.

[abstract cove]

I can't thank y'all enough man. I tested out what you told me. Positive results! Thanks again!

[fast rapids]

if i could implement coroutine then i guess i would, if you are able to use them, but i managed to do everything i needed as timer with update so the only thing that matters for me is performance

[regal wasp]

Yeh. End of day, use whatever works.

[fast rapids]

is it better for performance though? it may be important for me at some point

[regal wasp]

Probably go by Litoid's tests, they seem to have concluded that Timers nodes win. I wouldn't worry about performance without definite reason though, not when it comes to trivial matters like this.

Only if you're working on an RTS with hundreds or thousands of units processing things each frame or low-latency onilne gaming etc etc.

but if you are doing so 300-400 processes as one-offs every now and then, egh, wouldn't worry at all, even a phone from 2009 will be fine with that.

[fast rapids]

i might have to make a game with 1000s of unit maybe

[regal wasp]

💀

if so, yes, cut performance costs wherever possible, but it also depends how often they update

1000s now and then is still ok, depending what they are doing exactly

[fast rapids]

well honestly ill be using unode

[regal wasp]

Either either, the approach to problem solving is same

[fast rapids]

okay