Faster Than A Fast Loop?

[Tisnart]

Excellent information you have been providing Pixelthief!
Thanx

[N64Mario]

Okay. Lets say I have 2 or 3 different conditions, that these few events I am referring to have an 'on loop "loop"' condition. The first on loop condition comes right after the start fast loop event. The next 'on loop "loop"' (same loop being called, different condition) event is located in an entirely different group that is related to some other objects.

So does that mean to make the new nested fast loop inside its own group, I would have to move all of these 'on loop' events I refer to, into this one particular group that in which is being called?

[Pixelthief]

Well, if I'm understanding what you're talking about- no. A funny and bizarre think you can do with the stack of MMF2 is to actually close the current group and open it again in the same line of code. So if you want to call one fastloop from another fastloop in a nested style, if they are not in the same hierarchy of event groups, you can have your code say:

(in group "Happy Subloop)
"On Loop: Happy"
Close Group "Happy Subloop"
Open Group "Sad Subloop"
Start Loop "Sad"
Close Group "Sad Subloop"
Open Group "Happy Subloop"

(in group "Sad Subloop)
"On Loop: Sad"
Do Stuff


But if you want to use a nested loop, you would have to make sure that the nested loop is not in the same group, or a subgroup. Because then when you close the upper level group, it wouldn't matter whether the lower level group is open or not- it wouldn't be "visible".



My personal method for doing it is to have one group per loop, and keep them "side-by-side" even when the calls are nested. So for example, in my platformer project, all the lines of code in the "Load Level" loop will invoke the loops from each other event group here:


A typical line of code looks like this:



If you just have two loops that are side by side with one line of code each and nesting each other, then in cases like that it really doesn't matter very much if you have them "group looped" apart, and you can just ignore it. Its more important for loops with loads and loads of events. For example, that "TilesX" loop just calls a "TilesY" loop thats immediately below it, which then draws the tiles at those X/Y locations- theres no reason to bother putting those two in separate groups as its one LOC each