[Trigger] explain this insanity

[doom_sheep]

• For each (Integer A) from 1 to 15, do (Actions)
  • Loop - Actions
    • Set TempReal = (TempReal + 24.00)
    • Set QPoint[3] = (TempPoint offset by 748.00 towards TempReal degrees)
    • Unit - Create 1 sphereeffect (Level 1) for (Owner of (Constructed structure)) at QPoint[3] facing TempReal degrees
    • Hashtable - Save Handle Of(Last created unit) as (Key (SpherePart + (String((Integer A))))) of (Key hand) in Hash
    • Unit Group - Add (Last created unit) to Locusts
    • Animation - Change (Last created unit)'s animation speed to 0.00% of its original speed

this makes units in a ring around a unit for reasons. it works fine.

• For each (Integer A) from 1 to 15, do (Actions)
  • Loop - Actions
    • Unit - Kill (Load (Key (SpherePart + (String((Integer A))))) of (Key hand) in Hash)
    • Animation - Change (Load (Key (SpherePart + (String((Integer A))))) of (Key hand) in Hash)'s animation speed to 78.00% of its original speed
    • Special Effect - Create a special effect at (Position of (Load (Key (SpherePart + (String((Integer A))))) of (Key hand) in Hash)) using Abilities\Spells\Human\ThunderClap\ThunderClapCaster.mdl

this is meant to kill the units around the primary unit. it does not work. it kills one of them. one. apparently integer a from 1 to 15 became 1 to 1 somehow.

guess what, if you run it like this

Spoiler

• For each (Integer B) from 1 to 30, do (Actions)
  • Loop - Actions
    • For each (Integer A) from 1 to 15, do (Actions)
      • Loop - Actions
        • Unit - Kill (Load (Key (SpherePart + (String((Integer A))))) of (Key hand) in Hash)
        • Animation - Change (Load (Key (SpherePart + (String((Integer A))))) of (Key hand) in Hash)'s animation speed to 78.00% of its original speed
        • Special Effect - Create a special effect at (Position of (Load (Key (SpherePart + (String((Integer A))))) of (Key hand) in Hash)) using Abilities\Spells\Human\ThunderClap\ThunderClapCaster.mdl

it works for all of them. I can't explain this shit. is my machine fucking broken or something?

 

[doom_sheep]

another trigger was using "integer A" and fired every time a unit died, apparently breaking it here. I don't know how I'm meant to be coding but it's probably not like this.

 

[DracoL1ch]

GUI uses global variable so u have to try different ones in different triggers related to the same event

 

[Jampion]

By using "kill unit" every trigger with the "a unit dies" event will run, if its conditions are met. If one of the triggers uses a loop with Integer A as well, you will get problems.
The best solution to this is using local variables.
Alternatively you can use multiple global variables and make sure no loops with the same global run at the same time.

 

[_Guhun_]

Never use Integer A. It's prone to errors when other code is executing alongside it (though I guess it can be safe to use for things that are running alone, like Map Initialization)

As Jampion said, you probably have a trigger that executes when a unit dies which uses Integer A, so instead you should use shadowed global variables. You can learn about them here: Things You Should Know When Using Triggers / GUI

Also, why are you using string hashes/keys? They are prone to errors because two strings can have the same key. There should be a better way to go about it.

 

[doom_sheep]

Also, why are you using string hashes/keys?

not sure what I am meant to use instead. they seem convenient.

 

[_Guhun_]

Well, I guess it doesn't really matter since you aren't using them for the child hashtable, but why not use just Integer A instead of Key(string + String(Integer A))? If you need to store more stuff, you can always use an offset, like (10 + Integer A).

 

[HappyTauren]

If you want to use integer A/B without colliding with other triggers that do so, you can use the shadow local trick:
at the start of the trigger, add this custom script

• Custom script: local integer bj_forLoopIntegerA = 0

This will make every reference to this variable inside that trigger local. If you are using integer B, do the same thing, except with IntegerB instead of IntegerA.

 

[_Guhun_]

If you want to use integer A/B without colliding with other triggers that do so, you can use the shadow local trick:
at the start of the trigger, add this custom script local integer bj_forLoopIntegerA = 0, this will make every reference to this variable inside that trigger local. If you are using integer B, do the same thing, except with IntegerB instead of IntegerA.

I'm 90% sure that won't work, because GUI references those global variables using functions, you can see this when converting triggers to custom scripts. But maybe it will work when the map is optimized?

 

[HappyTauren]

Oh right. Fuck my answer, GUI is worse than I thought.

Actually don't use GUI, learn jass/vjass/wurst/anything that isn't GUI.

 

[_Guhun_]

Actually, this is even more reason to not use Integer A, because it's much slower, as GUI calls a function every time you want to reference Integer A and B, which is much slower than just referencing a variable, which is what is done for user-defined globals.

Actually don't use GUI, learn jass/vjass/wurst/anything that isn't GUI.

This is pretty good advice xD

 

[Chaosy]

Back in the day I always used integer a/b.
I never ran into issues personally, though I was aware of the slim possibility of them bugging.

That said, easily changed by using your own variable.

 

[HappyTauren]

The thing is, the bugs only happen if something you do in the trigger either runs another trigger directly, or causes an event that runs another trigger. In GUI this creates a ton of trouble anyways, and this integerA/B problem is just one of those.

 

[doom_sheep]

Well, I guess it doesn't really matter since you aren't using them for the child hashtable, but why not use just Integer A instead of Key(string + String(Integer A))? If you need to store more stuff, you can always use an offset, like (10 + Integer A).

I just use one hashtable for everything and differentiate the values by using strings. is that wrong somehow?

 

[_Guhun_]

I just use one hashtable for everything and differentiate the values by using strings. is that wrong somehow?

Ah, now I get it. Well, the problem is that string keys can generate the same hashfor different strings due to the algorithm used. Though that liekly isn't the cause for the issue you're having here. Also, using strings is a lot slower, since you need to convert an integer to string, add the strings together and then get the key of the resulting string. A lot of operations there. However, it doesn't really matter if the code is not executed constantly (apperently it only happens when something is constructed, so it very likely isn't).

It certainly isn't wrong if it works, because well... it works. But using different child hashtables is a much cleaner, efficient and readable solution, and you can just use the handle of the constructed structures as the child hashtable, and save each dummy unit using Integer A. But what you use is up to you.

EDIT: Of course, I can't provide a more in depth solution because I only know that small part of the code. What I'm saying is just from assuming what the code does.