Its a question actualy

[tw3ye]

When making a trigger
exzample:

• Wolfs Bite Copy
  • Events
    • Unit - A unit Starts the effect of an ability
  • Conditions
  • Actions
    • Set WB_caster(1) = (Casting unit)
    • Set WB_caster(2) = (Target unit of ability being cast)
• i wrote this...

the WB_caster is and unit array can i use it like this or most i create 2 variables? i got like about 50+ variables alredy and il end up with 500 till i end my map can i cut it down with this trick or is it not sugested?

 

[aki15]

When making a trigger
exzample:

• Wolfs Bite Copy
  • Events
    • Unit - A unit Starts the effect of an ability
  • Conditions
  • Actions
    • Set WB_caster(1) = (Casting unit)
    • Set WB_caster(2) = (Target unit of ability being cast)
• i wrote this...

the WB_caster is and unit array can i use it like this or most i create 2 variables? i got like about 50+ variables alredy and il end up with 500 till i end my map can i cut it down with this trick or is it not sugested?

I think it's ok using arrays ...
You should use triggering unit instead of casting.

 

[mckill2009]

you are creating 2 variables instead of 1 because of that array, you can make upto 1-60 (arrays in size 1)...

 

[ap0calypse]

the WB_caster is and unit array can i use it like this or most i create 2 variables? i got like about 50+ variables alredy and il end up with 500 till i end my map can i cut it down with this trick or is it not sugested?

Create 2 separate variables, that's better.

Arrays can hold up to 8192 (2^13) values, so that means that if you create 1 arrayed variable instead of 2 separate variables, you're actually creating 8190 variables more than the other option.
Someone here on the hive (I forgot his name) called it "shooting a fly with a bazooka", and he's completely correct about that.

50+ variables isn't that much.
You've got to live with the fact that there are and will be a lot of variables, but for your own sake: give them good names and it's not annoying at all.
For example, a knockback-system could have variables like "KBDist", "KBSpeed" etc. That will make searching for those (and other variables as well) easier.

 

[Garfield1337]

Create 2 separate variables, that's better.

Arrays can hold up to 8192 (2^13) values, so that means that if you create 1 arrayed variable instead of 2 separate variables, you're actually creating 8190 variables more than the other option.
Someone here on the hive (I forgot his name) called it "shooting a fly with a bazooka", and he's completely correct about that.

50+ variables isn't that much.
You've got to live with the fact that there are and will be a lot of variables, but for your own sake: give them good names and it's not annoying at all.
For example, a knockback-system could have variables like "KBDist", "KBSpeed" etc. That will make searching for those (and other variables as well) easier.

As far as i know,when you create an array variable,not all instances are initialized (depends how you set it,but on default,only one is) so it shouldn't matter. I could be wrong though.

 

[ap0calypse]

As far as i know,when you create an array variable,not all instances are initialized (depends how you set it,but on default,only one is) so it shouldn't matter. I could be wrong though.

Globals always have the default value initialized for all arrays (and the other value, called "Initial Value" in the variable editor, is set for all arrays up to the array size you picked in the variable editor).

Of course, when I said he creates 8192 variables I was overreacting (deliberately), but it is still a lot better to create 2 separate variables.

 

[Garfield1337]

I've probably comprehended this and this post wrongly then
And i didn't mean the Initial Value,i meant the Array Size.

 

[ap0calypse]

You can try creating a local integer and a global integer and showing their value without doing anything to them.
You'll see that the local won't show anything (as it 'doesn't contain an integer'), while the global does return 0.

WaterKnight said this (according to me):

the "size" you give in GUI is not the actual amount of fields the variable will possess but rather up to which index the members are initialized with the preset value.

I made the important part bold.
The other arrays are initialized with their default value (often null values).


Still, arrayed variables are created so they can hold up to 8192 different values, that must count for something (even if the values aren't initialized).

(I'm basing all my information on some person, whose name I still cannot remember, though)

 

[Garfield1337]

Thanks for clearing that up. I've just tested it and you were right

 

[Dr Super Good]

In response to the TC's question. Using an array is worse than 2 separate variables. Arrays in jass are actually ArrayLists which mean they dynamically expand in size which must obviously come at a cost to reading and writing to them. Separate variables should (blizzard has been known to do dumb stuff) do nothing but reserve an area of memeory for a value and when using that value you simply look up that address in memory (well vritual memory obviously). An array works along the same principles but you also precompute an addition opperation to find the correct address as the variable is nothing more than a pointer to the start of the array (element 0) but in JASS's case it also must create some management variables for the arraylist functionality (maximum size for example).

Arrays should be used only when the slot data can come from has to vary. For fixed things you should always use a single variable. An array would be player kills as you can use the player number as an index. A normal variable would be Leading player (with most kills).

I am aware that a lot of MUI GUI spells recommend the use of arrays in a static index manner but this is really a bad habbit and not what arrays are intended for.

 

[mckill2009]

but is it 'safe' or OK to make an array variable if you use them properly?, like indexing a spell or like what is stated above?...

set WB_caster(1) = unit 1
set WB_caster(2) = unit 2
AND SO ON...