Increasing variable array size

[Rahko]

Is there a way increase a variable's array size in a trigger?

I have to save each cast ability (or it's targets and whatelse) to variable every time the ability is cast. So is there a way to increase array size on the go, because I can't know how many times the ability is cast during the game and it feels a bit stupid to put the array size to like 99 just for sure.

It can't take up much memory to have excess, empty arrays, but it still just feels a little clumsy.

Here's an example of one my ability triggers:

• ab Polymorph
  • Events
    • Unit - A unit Begins casting an ability
  • Conditions
    • (Ability being cast) Equal to Polymorph
  • Actions
    • Set PolymorphDur[PolymorphCount] = 0
    • Set PolymorphTarget[PolymorphCount] = (Target unit of ability being cast)
    • Wait 1.00 seconds
    • [Increase array size here?]
    • Set PolymorphCount = (PolymorphCount + 1)

Now I have to have the array size for PolymorphDur and PolymorphTarget to very high, like 99, because I must be able to refer each single target, the ability was cast on, later. But if I could increase the array size, it would as a whole feel more like professional way to do it. Or does the array size even matter that much I should care about it?

 

[~El]

You don't need to resize arrays in WC3. They will automatically resize internally as you add more elements to them, in increments of powers of two, as far as I know. The upper limit is 32768 elements per array.

 

[Rahko]

Oh, I didn't know that. Thanks!

 

[Dr Super Good]

There is a constant for maximum array size. In case of future expansion/change it is recommended to use this constant rather than a hard coded value.

JASS_MAX_ARRAY_SIZE

It is currently defined as follows...

constant integer JASS_MAX_ARRAY_SIZE=32768

I have to save each cast ability (or it's targets and whatelse) to variable every time the ability is cast. So is there a way to increase array size on the go, because I can't know how many times the ability is cast during the game and it feels a bit stupid to put the array size to like 99 just for sure.

Now I have to have the array size for PolymorphDur and PolymorphTarget to very high, like 99, because I must be able to refer each single target, the ability was cast on, later. But if I could increase the array size, it would as a whole feel more like professional way to do it. Or does the array size even matter that much I should care about it?

If you just want an instance stored for some amount of time, eg the duration of the ability, then I suggest using an indexing system which will recycle array indices.

If you want to store every single cast of an ability, permanently, then be aware that one could possibly consider this as a leak. If you need a cast history you might want a queue structure of sorts that tracks the last finite number of casts.

 

[Rahko]

Yes, you are right, they do actually leak, since I don't need to reference to them once the duration is over. But I was indeed planning to recycle the arrays, tough I haven't thought up the exact system yet (shouldn't be hard).

 

[Dr Super Good]

But I was indeed planning to recycle the arrays, tough I haven't thought up the exact system yet (shouldn't be hard).

No need to reinvent the wheel. Look up standard GUI indexing approaches or if writing JASS you can use vJASS structs.

The basic approach is to make a "free" list which is basically a linked list of free indices from the array. When allocating an instance you first try to get a index from the free list, only allocating a new clear index if the free list is empty. When you free an instance you add it to the free list, usually appending it to the start of a single linked list. The linked list is formed by using an index member of the instance (can be any integer member of the instance to save array declarations) to reference other free instances with a variable containing the index of the top of the list.

There is another approach which is useful if you do not need instance indexes to be constant throughout the life of an instance. In such a case allocated instances are appended to the end of the instance list while freed instances get overwritten member by member with the instance at the end of the instance list. The instance count is the length of the instance list which is always continuous.

 

[Rahko]

Well, now that you mentioned it, I looked up one GUI indexing system, and turns out my system is basically just the same. Just need to make few tweaks to the end (Or not even few tweaks, just one action where I set a variable back to zero xP)