GlobalVariablesUnitHasReachedWaypoint=True<Boolean[9][40][7]>
Local Variables
loopCounter = 0 <Integer>
loopCounter 2 = 0 <Integer>
loopCounter 3 = 0 <Integer>
Conditions
Actions
General - While (Conditions) are true, do (Actions)
Conditions
loopCounter < 9ActionsGeneral-While(Conditions)aretrue,do(Actions)ConditionsloopCounter2<40ActionsGeneral-While(Conditions)aretrue,do(Actions)ConditionsloopCounter3<7ActionsVariable-SetUnitHasReachedWaypoint[loopCounter][loopCounter2][loopCounter3] =FalseVariable-ModifyloopCounter3:+1Variable-ModifyloopCounter2:+1Variable-ModifyloopCounter:+1
Also what's with the colors?
Anyway, through various debugging I've tracked the problem to this trigger. What it seems to be doing is setting only one of the entries to False and the rest remain True.
Context: 9 is because there are 9 players, 40 is because there are 40 units per player, 7 is because there are 7 places that I'm tracking.
Changing the code to this makes it work for some reason:
Before each while block you need to reset the respective loopCounter to 0. Otherwise once it does the first player, loopCounter 2 will still = 40. And once it does the first unit, loopcounter 3 will still be 9.
Before each while block you need to reset the respective loopCounter to
0. Otherwise once it does the first player, loopCounter 2 will still =
40. And once it does the first unit, loopcounter 3 will still be 9.
E.g.
Set loopCounter = 0
General - While (Conditions) are true, do (Actions)
Conditions
loopCounter < 9
Actions
Set loopCounter 2 = 0
General - While (Conditions) are true, do (Actions)
Conditions
loopCounter 2 < 40
Actions
Set loopCounter 3 = 0
General - While (Conditions) are true, do (Actions)
Conditions
loopCounter 3 < 7
P.S. Why don't you just use FOR loops? Then you wouldn't have to do that
reset to 0 thing because it does it automatically.
Ok, so I'm not sure how this didn't copy, but I am resetting the loop counters outside themselves.
I use while loops because they're generally just better in terms of programming and I can also visualize them the same anyway.
Alright, so I guess them not copying was because they weren't actually there even though they were. I deleted and remade the loops exactly how they were and now it works as expected.
While loops are not "generally just better in terms of programming" than For loops. They both are and do the exact same thing. In your situation, For loops are even more appropriate, since they handle your counters' incrementation and resets, which leads to a cleaner trigger. There's literally not a single advantage to using a While loop when parsing arrays.
While loops are not "generally just better in terms of programming" than For loops. They both are and do the exact same thing. In your situation, For loops are even more appropriate, since they handle your counters' incrementation and resets, which leads to a cleaner trigger. There's literally not a single advantage to using a While loop when parsing arrays.
Actually, while loops compile to cleaner Galaxy code and should be prefered in very performance intensive situations.
In general for loops are recommended though.
Also I can't go back and add an extra condition to a 'for loop'. In general I never use for loops because of this reason, as they're restricted to an integer and nothing more.
Also I can't go back and add an extra condition to a 'for loop'. In general I never use for loops because of this reason, as they're restricted to an integer and nothing more.
You can easily add more conditions by using an if then else and the continue statement.
What is your point though? That it requires more work? That it causes
more overhead?
In general it's just nicer.
When I'm looking over my code, it stands out better to me. The conditions are indented out from the start and the actions indented out from the conditions, whereas a for loop has the conditions in the same line with only the actions indented out. When I look at it under script, it looks ridiculously better. When I want to add an additional condition, it doesn't require using an if-then statement. In terms of resources, there are two less variables being used and no need to redeclare my counter variable unless I'm using another loop with the same variable.
From my experience, for loops look cleaner and are created faster in GUI as long as they are just doing a simple counter incrementation, which, surprisingly, is pretty much the most frequent type of loop.
It's likely that your triple-nested loop is exceeding the capabilities of the editor, which would explain why the double-nested loop works and the triple does not. I'm guessing it's either the triple-nesting or the long binary causing the problem (individual triggers have a limit.) If you split your third nest off into an action definition or separate trigger, it would probably work.
It wasn't even coming close and the problem was a bug with the interface. It was showing my copy+pasted variable resets but they weren't actually in the script. When I deleted and remade them exactly how they were it worked.
Also what's with the colors?
Anyway, through various debugging I've tracked the problem to this trigger. What it seems to be doing is setting only one of the entries to False and the rest remain True.
Context: 9 is because there are 9 players, 40 is because there are 40 units per player, 7 is because there are 7 places that I'm tracking.
Changing the code to this makes it work for some reason:
Before each while block you need to reset the respective loopCounter to 0. Otherwise once it does the first player, loopCounter 2 will still = 40. And once it does the first unit, loopcounter 3 will still be 9.
E.g.
P.S. Why don't you just use FOR loops? Then you wouldn't have to do that reset to 0 thing because it does it automatically.
Ok, so I'm not sure how this didn't copy, but I am resetting the loop counters outside themselves.
I use while loops because they're generally just better in terms of programming and I can also visualize them the same anyway.
Alright, so I guess them not copying was because they weren't actually there even though they were. I deleted and remade the loops exactly how they were and now it works as expected.
While loops are not "generally just better in terms of programming" than For loops. They both are and do the exact same thing. In your situation, For loops are even more appropriate, since they handle your counters' incrementation and resets, which leads to a cleaner trigger. There's literally not a single advantage to using a While loop when parsing arrays.
Actually, while loops compile to cleaner Galaxy code and should be prefered in very performance intensive situations.
In general for loops are recommended though.
@Mille25: Go
For other code as well.
Also I can't go back and add an extra condition to a 'for loop'. In general I never use for loops because of this reason, as they're restricted to an integer and nothing more.
You can easily add more conditions by using an if then else and the continue statement.
@Mille25: Go
'easily'
That requires two additional functions as well as the condition. With a while loop I just add the condition.
@Tudentau: Go
An if then else statement is not a function, nor is continue.
Splitting hairs. The point remains the same.
@Tudentau: Go
What is your point though? That it requires more work? That it causes more overhead?
In general it's just nicer.
When I'm looking over my code, it stands out better to me. The conditions are indented out from the start and the actions indented out from the conditions, whereas a for loop has the conditions in the same line with only the actions indented out. When I look at it under script, it looks ridiculously better. When I want to add an additional condition, it doesn't require using an if-then statement. In terms of resources, there are two less variables being used and no need to redeclare my counter variable unless I'm using another loop with the same variable.
vs
From my experience, for loops look cleaner and are created faster in GUI as long as they are just doing a simple counter incrementation, which, surprisingly, is pretty much the most frequent type of loop.
Either way, it doesnt matter.
@Tudentau: Go
It's likely that your triple-nested loop is exceeding the capabilities of the editor, which would explain why the double-nested loop works and the triple does not. I'm guessing it's either the triple-nesting or the long binary causing the problem (individual triggers have a limit.) If you split your third nest off into an action definition or separate trigger, it would probably work.
Anyway, that's my armchair analysis.
@BasharTeg: Go
It wasn't even coming close and the problem was a bug with the interface. It was showing my copy+pasted variable resets but they weren't actually in the script. When I deleted and remade them exactly how they were it worked.