Call same loop while it's in progress?

[2xD]

Hey.

I have some different conditions, that might activate the same loop with different parameters at the same time, while another loop of same type is still in progress:

If condition 1 -> start loop gogo with variable x=1
if condigiton 2 -> start loop gogo with variabe x=2

What will happen? Will they split and perform their action with the wanted variable or not?

Thanks.

[BartekB]

Fast Loops / For Each Loops work like this:

Game Loop (All events are checked and run from top to bottom)
e.g.
[
-Always > Do something
-Always > Run Loop ABC
-Always > Run Loop ABC
-On Loop ABC > Do loop things
-Player touches backdrop > Stop the Player
]

The following would run like this:
"Do something" would be done first
Then the "ABC" Loop will be ran, temporarily FREEZING the game loop until it is finished:
The ABC Loop will "do loop things", finish, and resume the game loop
The ABC Loop will be ran again, doing "loop things", finishing, then resuming the game loop again
Collision detection will be checked if Player touches the backdrop, if so, the player will be stopped

So in reality, you can't actually "split" a loop, it begins, does all the loop events attached to it, repeats depends if you want it to, finishes and resumes the rest of the code again. So, there is never a loop "in progress", as everything is done in-between the frame (when the frame has not been refreshed yet / end of code has been reached)

[schrodinger]

"at the same time" is something that can't actually happen
one will always perform after the other

so if conditions are laid in the way you written them above

condition 1 will trigger loop with variable x=1
and then condition 2 will trigger loop with variable x=2

but they will eventually mess up if you call a loop "inside" another loop
(meaning that x=1 won't be true when loop 2 will be finished and compiler will come back to complete loop 1)

[2xD]

Okay. But how can I realize that parallel scenario? The loops also need different inputs..

[schrodinger]

Exactly how you need it to go?

Way you described it above is fine:

event 1
>>> set var x to 1
>>> start loop "gogo"

event 2
>>> set var x to 2
>>> start loop "gogo"

they will perform one independently from the other without issues

unless inside loop "gogo" - in "onloop" conditions - you will alter var x,
that var will remain the same throughout the loop and the two loops won't interfere one with the other
(after event 1's loop will be finished, event 2's loop will start, if both conditions are true)

[2xD]

Well, my event 1 will start at the same time as event 2 (for example clicking two different keys at the same time).. Maybe via functions?

[schrodinger]

This can't be done - you can't start two actions at the exact same time,
all events will be checked and all actions will be performed top-to-bottom anyway
- but both actions result will show out in the frame

on key "2" pressed
>>> do this

on key "1" pressed
>>> do that

if user presses 1 and 2 at the same time
inside the event-flow
key 2 event will be performed
and then key 1 event will be performed

Can't think of a situation when "simultaneity" is required
since at the end of event list, when all conditions have been scrolled, 60-times per second,
the frame will be drawn with result of both conditions triggered
so both will fire "at the same time", in this sense

So if you need to react to two keypresses at same time, this is anyway correct

don't know if this answers the question - what is exactly that you need to do?

[2xD]

Oh, that's nice.

What if my Loop has other Inside-Loops? Will the game release from frozen, when all inside loops, inside actions + my main loop are done?

[schrodinger]

What if I press the other key while the game is frozen (or what if the same key again?), will it still recognize my key press?

"freezing" is just to say that a loop happens inside the very frame,
but this doesn't mean the game really "freezes"
(well, unless you start a huge loop that will perform so much stop frames from being updated at correct rate, but this doesn't seem the case I guess?)

To say more clearly,
if you game runs at 60 fps, and you have these conditions in this order:

1) always >> start loop "test"

2) flag 2 is on >> do something

3) on loop "test" >>> do this

each second, the compiler will (try its best to) scroll this list 60 times,
and draw the screen 60 times with the result of these actions

the event flow will perform as follows:

1) 3) 2)

this is what BartekB meant with "freezing": when loops are called, the compiler "stops" scrolling the list,
and instead of checking event 2), instantly jumps to event 3) - the onloop condition
Only when the onloop condition will be performed, he will return to perform event 2)

You can tell these "immediate" conditions by the fact they are "green" inside fusion
green conditions will be performed immediately when triggered, regardless of their position inside the event list

The game could actually suffer if you ask him to do too many things inside this 1/60th second and the processor is not strong enough to catch up these many tasks
this would be a noticeable "freezing", but this is directly unrelated to loops (loops can be dangerous only if you launch them a high number and ask to perform lots of actions inside onloop conditions)

Back to your question 2:
nested loops will be performed immediately as they are called from "parents"
and will be continuously performed during the same 1/60th second as explained above

>>> start loop 1

on loop 1
>>> start loop 2
>>> start loop 3

on loop 3
>>> add line hey!

on loop 2
>>> start loop 4

on loop 1
>>> add line click

on loop 4
>>> add line hello


output of this frame will be:

hello
hey!
click

and will obviously be "simultaneous" (you will see all these lines pop out together in one frame - 1/60th second)



EDIT:

talking of freezing, this will definitely freeze (crash) the app :

on event
>>> start loop 1

on loop 1
>>> start loop 1

a "catch 22"

[2xD]

Okay, I got it. Thanks for the long post