i've noticed when porting my games from TGF to MMF, that the build in fast loop "stop loop" function will let the entire loop resolve before terminating, while the fast loop object "stop loop" will instantly interupt a loop. Is there any way to recreate this "immediate stop" function with the built in loops, or do I have to put a flag qualifier in EVERY SINGLE ACTION to say whether a loop is dead or not....
The built-in stop loop SHOULD work. But there's always a lot of problems when porting a game from TGF to MMF.
Disclaimer: Any sarcasm in my posts will not be mentioned as that would ruin the purpose. It is assumed that the reader is intelligent enough to tell the difference between what is sarcasm and what is not.
the built in stops work in two different ways; the MMF version will wait until the current loop is finished, whereas the object will instantly terminate the loop, even if there were more events on the stack
Not sure then, maybe you could re-code it so that the loop could be terminated at the end of the loop without anything going wrong?
Disclaimer: Any sarcasm in my posts will not be mentioned as that would ruin the purpose. It is assumed that the reader is intelligent enough to tell the difference between what is sarcasm and what is not.
Yeah, defiantly try re-coding. I've never had any issues with MMF2 interrupting a loop without letting it finish. In fact, I actually have 0 experience with the object itself, because the built-in loops provide me with everything I need in regards to fast loops.
no i mean I *want* it to interupt a loop without finishing it
like a "BREAK" in c++, I don't want the compiler to parse through the rest of the loop and execute the actions. Making it run the rest of the loop is just silly, codewise. I can simulate this by adding a flag condition to *every single event*, but thats just painful and time consuming, the fast loop object is actually superior.
Originally Posted by Pixelthief no i mean I *want* it to interupt a loop without finishing it
like a "BREAK" in c++, I don't want the compiler to parse through the rest of the loop and execute the actions. Making it run the rest of the loop is just silly, codewise. I can simulate this by adding a flag condition to *every single event*, but thats just painful and time consuming, the fast loop object is actually superior.
By saying I never had problems, I meant I never had issues with it not interrupting. It's worked exactly as planned every time.
yah theres no reason why it wouldn't. I'm saying theres no way to MAKE it interupt a loop. The stop loop of the fast loop object, and the stop loop of the built in MMF, do two different things, and thus code from the two is incompatible.
by giving each fast loop an event group of its own, you can terminate a loop in its middle by simply closing the group after sending the "end loop X" command. So where you used to have:
*On loop X
+Some condition
=Stop Loop X
you change it to
*On loop X
+Some condition
=Stop Loop X
=Close Group X
Advertisement
Post Reply
