Weird behaviors in nested loops, a "never" condition somehow solves it?

[Perfeks]

Hello everyone,

I might need some help here and/or some explanations. I've been working with fastloops and I've been struggling all day, because of a weird behavior from fusion 2.5. Basically, I call a loop once, that loop calls an other loop twice x times with some actions inbetween (setting variables of an object). This looks like this :

1)
- User clicks on some object
-> start loop "loop1" 1 times

[...]

2)
- On loop "loop1"
+ some condition about testing a fixed value of an item
-> Object obj1 : set alterable value X to alterable value A of obj1
-> start loop "loop2" 16 times
-> Object obj1 : set alterable value X to alterable value B of obj1
-> start loop "loop2" 16 times

[...]

Now the alterable value X of obj1 is used inside loop2 and for some reason, the second time the loop is called 16 times, the value of X isn't the alterable value B. I even tried to display everything and indeed alterable value B had the right value, whereas alterable value X still had the value of alterable value A. I can assure you that alterable value X, A and B aren't changed inside "loop2".

I struggled during a whole afternoon, trying to find where it came from. I tried to make some new events and disabled some others by inserting a "never" condition in them (like I always do to keep them as "backup" in case I'm not doing anything better). And finally, I figured out that if I copy the event n°2 (with all its actions and conditions), add a "never" condition in it, and put it right before the true one (it doesn't work if I put it after), it works! I couldn't believe it, I tried to save the app, leave, re-open it, delete that event, put it back and tested everytime. And it is true! It only works if I put that event containing a "never" condition just before.

I don't want to share my whole code, because this is a pretty consequent project. But if someone has an idea or explanation to what is happening here, I would be glad to know. Now if nobody knows, I could try to isolate this issue in an empty .mfa, but it will take some time. I just want to clarify the fact that I am pretty experienced with clickteam's products now (I've been using them for like 10 years now), I have done a lot of more complicated things with nested loops and never encountered such problem, so that's why I'm coming here.

[Perfeks]

Okay, so I was able to isolate the bug in a .mfa. It's a really short program of 8 lines of code.

To run it, just click on a red square. The value of "currentX" of "manager" is supposed to change from 111 to 999, but it doesn't. Everything is displayed on a list object on the right to follow what is happening during execution.

The first frame is the non-working one. The 4 other frames are working, but they are just ridiculous alterations of the first one (like adding an event with a "never" condition, removing a condition that is always wrong anyway ...etc). This is really absurd and it is driving me crazy!

The executable may not make much sense and may not seem of any use, because it has been reduced to its most simple form from my game by deleting a ton of content. Can someone please tell me why it's not working the way it is supposed to? I don't want any program that does the same (which is basically nothing) as this one, but I want to understand why it doesn't work, so I can rework on my actual game.

Here is the link to the executable :
http://www.mediafire.com/file/9xrrup...m/weirdBug.mfa

Thank you very much to anyone trying to help me

[Shadoku]

I've been using clickteam products for over a decade as well, and I've struggled with similar scope issues before, they can really be a pain.

What seems to be happening in this case, at least in the example you've provided, is the way fusion handles object scoping in relation to fastloops. Fusion doesn't rescope objects when returning from a loop, it (usually) inherits the scoping from the loop. This would normally mean that actions on an object would apply to all instances of that object (if the loop didn't contain any scoping conditions or actions relating to the object), or whatever instances of the object were scoped in the loop. The latter behavior is the culprit here. Fusion seems to start updating the current scope before it's decided whether an event is going to evaluate as true, so when that final event tries to scope objects with "something > 0", none exist so the only manager object in the frame is explicitly scoped out, and then control is returned to the initial event with no manager object scoped in. This is why the "never" condition in frame 4 fixes the issue, the event clears scoping, and doesn't scope out the manager like checking for "something > 0" does.

The solution is to add a final event in the loop that rescopes for the object you want to modify when returning from the loop. But you can't just add a completely empty event with no actions, as fusion doesn't seem to evaluate events with no actions (probably for efficiency's sake), so you'll need at least one action in the event; it doesn't matter what if anything it actually does.

So in the example provided, you'd need to add an event at the end that does something like

-On loop "loop2"
-Something of manager = 0
->some random action

[Perfeks]

Thank you very much for your time Shadoku!

I also figured out it was some kind of issue with scoping. I've already encountered similar problems within the same event like :
- alterable value A of "object" = 1
-> start loop "unrelated loop" 1 times
-> destroy "object"
and it would just destroy all "objects" (not only those with alterable value A = 1), because running the loop resets the scope. So, swapping these 2 actions or putting them in 2 different events resolves the issue. That made sense to me.

But you're telling me that the scope persists through different events? Is it only between the last event of a loop and the first event of the new loop? I thought the scope was reevaluated in each event depending on the conditions. What would happen if I had a scoping condition in the first event of the loop? When returning from the loop, would it use only the new scope from this condition or merge the conditions of first and last event for scoping? Do you think it should be reported as a bug?

Anyway, the most elegant solution I found so far to clear scoping is :
- on loop "loop1"
+ never
-> stop loop "loop1"

[Shadoku]

The root cause seems to be that Fusion doesn't reevaluate scope after returning from a loop, it inherits the scope of the last line in the loop. Every line in the loop itself will be evaluated and scoped normally (to the best of my knowledge at least), so the first line of a loop doesn't inherit the scoping of the parent event, and subsequent lines in the loop don't inherit the scoping of the first.

Yeah, simply not scoping anything in the last line of the loop is the easiest solution, but keep in mind you can also do scoping if you need to; for instance adding "alterable value A of object = 1" to the final event of "unrelated loop" (above of or in place of the never condition) would allow you to make your first example work without changing the order of the events.

[Perfeks]

Oh, I get it! Thank you for your knowledge. I'll have to pay attention to this issue when using loops now. It's surprising that I still learn new things after all this time.