What was the Bug in the For loop Integer A Function?

[Map Designer]

I have seen some tutorials referencing that there is a bug in the function

• (For each Integer A from 1 to N, do:...)

could someone elaborate what is the bug? I never seen it bug with me :|

 

[IcemanBo]

Not really a bug with IntegerA per se, but something to watch out in general with loops. Have a look [GUI] - [How-to] Loop In GUI!. There's a part specified about risk.

 

[Dr Super Good]

I have seen some tutorials referencing that there is a bug in the function

If you nest two or more of them it will break because internally they use a global variable to track the state of the loop so uses of the action higher up the virtual machine stack overwrite the state of all lower down uses. This is why both a loop A and loop B are provided since those two can be nested together, as long as only 1 occurrence of both exists on the virtual machine stack at any given time. This also applies with custom loops which use a user specified global variable, however one can limit the scope of exposure of that variable allowing for more control and less risk of nesting.

Now anyone sensible can easily avoid nesting loops which share the same variable state within the same trigger. However what is much less obvious and easy to avoid is nesting occurring in other triggers the loop body might cause to run. For example using a loop A to create units at a variety of locations fed from an array will fire "A unit enters (playable map are)" triggers on every iteration of the loop. These entering unit triggers will complete first before resuming execution with the create unit loop. If this entering unit trigger then also uses loop A it will override the state of loop A causing a major bug when the trigger finishes and execution of the create unit loop resumes. This is where the custom loop action comes into play since one can assign the create unit loop a dedicated global variable and so be certain that no other triggers can interfere with the state of that variable since only the create unit loop uses it.

Of course the programmatically correct solution is to use a local variable. Local variables are unique storage that exists for each function call and last until the function returns. This makes it physically impossible for the state of such loops to interfere with each other, even if a function is recursive (calls itself). GUI does not support local variables...

 

[Map Designer]

Can I not use custom script to declare local variable and then proceed to use it in GUI?

 

[Dr Super Good]

Can I not use custom script to declare local variable and then proceed to use it in GUI?

Yes but then you might as well just write JASS, or even Lua directly.