Scoping and ForEach oddness - Do these events need to be broken up?

Hola team.

So I have a basic setup involving a few actives that are created/destroyed/updated dynamically, as follows:

Player Clicks Unit
-> Run loop UpdateInfoTray
(amongst other loops, but this is the one that's being odd, and it's executed last and doesn't involve any other moving parts previously scoped/referenced)

On Loop UpdateInfoTray:

-> Set InfoTray.Active AltVal OnScreen to 1 (Brings it onto the screen as opposed to hiding it offscreen - no problems here)
-> Set InfoTray.Active AltVal AnimationSize to 0 (Resets, ready to receive new value, is having slight issues)
-> Start Loop "SpecialTray Clear" 1 time
-> Start Loop "SpecialTray CastUpdate" X times
-> Start Loop "SpecialTray SelfUpdate" X times
-> Start Loop "SpecialTray EffectUpdate" X times (X in all these loops references a different object's alt val that's keeping track of total number of each category)
-> Run Loop ForEach SpecialTrayButton.Active "MaxID"

-----------

On Loop "SpecialTray Clear"
-> Destroy SpecialTrayButton.Active

On Loop "SpecialTray (Cast/Self/Effect)Update" (they all work the same)
-> Create SpecialTrayButton.Active
-> Set SpecialTrayButton.Active AltVal ID to (Loop Index)
-> Set SpecialTrayButton.Active AltVal Index to (value from a different object gotten via index reference, basically the button's "type"
-> Set SpecialTrayButton.Active AltVal Category to 1/2/3 (Depending on Cast/Self/Effect loop running)

ForEach SpecialTrayButton.Active "MaxID"
+ SpecialTrayButton.Active AltVal ID is GREATER THAN InfoTray.Active AltVal AnimationSize
-> Set InfoTray.Active AltVal Animation Size to SpecialTrayButton.Active AltVal ID

SO.

As I follow this through, there are two things that aren't happening that should be, and I think it's down to weird scoping ala Vol's recent (and excellent) article.

What should be happening is, if a Unit has NO Button Actives created, there should be no ID greater than 0, thus the animation value on the Tray object should remain 0. However, I suspect that scoping weirdness is keeping Buttons alive during this loop process, because the first time clicking from a Unit that has say 3, to a unit with 0, the Animation Value remains the same. If I click it again, this time with the Button actives destroyed already ie not in the same loop set, it remains at 0.

Second issue, is that during the ForEach loop, the ID picked up for the Animation Value on the tray is not always the highest ID on the button Actives. Specifically, it will pick the Highest ID from the objects in the SELF loops, ignoring any button active ID's from the CAST loops. Can't figure out why this is, and I'm guessing it has something to do with scoping again - but it doesn't seem the be the same 'legacy actives' issue from above. The reason I think that is because going from a Unit with say 6 SELF buttons to 3 works fine - If the old buttons were still in scope at this stage, surely the animation value would stay at the highest ID, which would still be 6.

So. Plan of attack? What's the glaringly simple thing I'm missing here? Appreciate the time spent reading.

So, as generally happens immediately after I hit post, I think I've figured it out. Looking at this loop:

ForEach SpecialTrayButton.Active "MaxID"
+ SpecialTrayButton.Active AltVal ID is GREATER THAN InfoTray.Active AltVal AnimationSize
-> Set InfoTray.Active AltVal Animation Size to SpecialTrayButton.Active AltVal ID

Does the Bold part of the event break scope, and only ever compare the ID AltVal of the newest created button? Since the Self category is run second, and therefore the button will always be freshest, that would explain it...

Attempted Fix #1:

Instead of having the ForEach loop include the comparison, the ForEach loop now is;

ForEach SpecialTrayButton.Active "MaxID"
-> Set InfoTray.Active AltVal TempAnimation to SpecialTrayButton.Active AltVal ID
-> Run Loop "SpecialTrayAnimationCompare"

On Loop "SpecialTrayAnimationCompare"
+ InfoTray.Active AltVal TempAnimation IS GREATER THAN InfoTray.Active AltVal AnimationSize
-> Set InfoTray.Active AltVal AnimationSize to InfoTray.Active AltVal TempAnimation
-> Set InfoTray.Active AltVal TempAnimation to 0

On Loop "SpecialTrayAnimationCompare"
+ InfoTray.Active AltVal TempAnimation IS LESS THAN InfoTray.Active AltVal AnimationSize
-> Set InfoTray.Active AltVal TempAnimation to 0

Still the same outcome, however. Hrmm. So I think maybe it is still somehow working with the old ButtonActives, rather than running the loops on the newly created set. But that doesn't explain why it works perfectly in other situations. Real noodle scratcher.

Pertinent info:

-Swapping the order of the button loops narrows down this issue. I swapped Self/Cast loops and now the MaxID return is only ever the highest of the buttons created in the cast loop, if there are any.

-If I add a simple bit of code to the ForEach loop Set Effect -> Inverted, it applies it to every button, regardless of which loop created the button.

-When I add a bit of code Add 1 to Global Value A if ID is Greater/To B if equal or lower, the global values only increase by 1 each time I click - I assumed this would increase by 1 for every button that is higher/lower or equal.

This is doing my head in haha.

Attempted Fix #2

Instead of running the ForEach loop to determine Highest ID in the core loop, I separated it by having the loop set a flag on, and then in the natural cycle of events, the flag triggers the ForEach loop, thus scoping the latest batch of Special Buttons and not just the newest created. So now it's picking up on the highest value, which is good, but the other problem still remains; When going from a high ID to a low ID (By clicking a unit with say 6 total special rules to then clicking on a unit with only 3) the high ID remains from the previous set, thus setting the Animation to exactly what it was. This doesn't happen when going from low to high, so actually hrm maybe it's event order on the comparison loop...

Holy Balls, I fixed it!

For those in the future doing a search and this comes up:

Instead of the loop being as described in the first post, there are two major changes; Firstly, instead of running a ForEach loop with an additional Greater/Less than condition, it just runs as ForEach (active, in this case Button), do X. This got rid of the scoping issue with only a certain set of the Actives being referenced. Secondly, instead of that ForEach loop bring triggered in the same core Loop set, the above Loop structure simply sets a certain Flag to On, with another condition below the Events simply being if Flag 0 is On, run the ForEach.*

*It's actually not that simple. I had to add another layer of extrapolation in that the loop sets Flag 0 on, another condition then checks for Flag 0 activation and sets Flag 1 on, toggles 0 off, and then a third event picks up Flag 1's status and runs the ForEach then. Yeah, I don't get it either.

Thanks for listening