Is there a max number of variables?

[guhubner]

Is there a max number of variables?

Is there a way to increase this limit??? I didn't know this until the number of variables arrive to +- 20 variables with [8000] array each.

 

[YoshiRyu]

Is there a max number of variables?

yep, at least your computer's RAM (infinite doesn't exist in computers), i don't know if the game fix a lower limit than that (it's not impossible)

but anyway, the more your map use RAM, the more warcraft lag, and the memory is already big enough to allow hudge lags which make the game unplayable, i don't see any valid reason to want the game to lag more than that.

 

[SFilip]

Number of variables is nothing you need to worry about.
First of all every map has to start with around 100 variables defined in common.j and blizzard.j.
Furthermore one variable takes only a couple of bytes of memory - you would need around 100000 to make a couple of MB difference when it comes to memory use. Just make sure there are no memory leaks and you're fine.
Also array size doesn't really matter - the max possible is always 8191. The number you specify is just the initial amount.

 

[YoshiRyu]

Furthermore one variable takes only a couple of bytes of memory

Wrong
it's different for each kind of variable
integers probably take 2 bytes
pointers (i.e. any handle variables) probably take 2 bytes too (but the pointed object like units take much more space)
booleans probably take 1 byte
strings probably take 2 bytes + 1 byte/caracter + 1 byte
of course, nothing is sure, because warcraft is released without technical doc

The number you specify is just the initial amount.

in fact, the number you specify is usefull for initialisation values
sample: integer array[4] with default value 1
you start the game with an array which is set to 1 for the 0,1,2,3 index
you can use also the greater index, but their initial values are unknown

the max possible is always 8191

2^13? strange max value, i wonder why...

 

[SFilip]

> integers probably take 2 bytes
4 as they can go up until 2^31-1 after which they wrap around and are set to -2^31.

> pointers (i.e. any handle variables) probably take 2 bytes too
4 bytes in a 32-bit operating system, always.
But handles aren't exactly pointers, they are a form of a list and take 4 bytes regardless of the system.
Furthermore handles will take more memory when created as they are actually structures, dynamically allocated space. However I seriously doubt this can go beyond 100 bytes or so for any handle type in warcraft.

> booleans probably take 1 byte
Again, 4 bytes. Warcraft treats them as the LONGBOOL variable from some reason. It is possible for a boolean to hold any integer variable thanks to H2I-like functions which is one way to prove this.

> strings probably take 2 bytes + 1 byte/caracter + 1 byte
This is a bit blurry. The way warcraft allocates memory is a bit different as it uses a form of a list. You're probably right though, but it's 4 bytes again instead of 2.

> of course, nothing is sure
Everything above is 101% certain except for the strings as there are accurate ways of proving it.

> strange max value
If you're talking about the fact it's 8191 then...I guess it was supposed to be 8192 - that's a constant defined in common.j. But because of a blizzard bug using the last index causes crashes when a map is saved and then loaded according to Vexorian. This is why people take 8191 as the actual size.

 

[Eleandor]

I thought the array reason was because the variable has 8192 arrayslots (2^13). Since 0 is used, it goes from 0 to 8191...

 

[Dr Super Good]

8191 dont you mean because 1 is array index 0 and thus it is 1 less than you said.

 

[SFilip]

You're right, but that's a different thing.
Lets begin with how it's supposed to be - array size 8192. That's indexes from 0 to 8191, the size is still 8192.
But due to a bug using the last index (8191) causes a saved game to crash on load according to some tests Vexorian performed. So the index 8191 can't be used, 8190 becomes the last index meaning that the maximum possible array size is 8191 (0..8190).

 

[YoshiRyu]

> integers probably take 2 bytes

I was starting from the fact you look sure that variables take 2 bytes

4 bytes in a 32-bit operating system, always.

Warcraft is not an operating system, JASS is not c++, integer are not int
Warcraft could easily use 2-bytes pointer in a virtual memory using it as a gap from a memorised true memory index
PS: real "int" are not always in 4 bytes, there is old OSs with 2-bytes int

> of course, nothing is sure
Everything above is 101% certain

if you have the JASS tech doc, please give it to us
never assume that something "must be like usually"
that's a bad idea

> strange max value

It's a strange value because 2^13 is a wast of bits, that's not logical
(for the missing last index, maybe the JASS array use the same way than string to detect the end of the array, they're not fixly sized, like strings)

 

[Eleandor]

You're right, but that's a different thing.
Lets begin with how it's supposed to be - array size 8192. That's indexes from 0 to 8191, the size is still 8192.
But due to a bug using the last index (8191) causes a saved game to crash on load according to some tests Vexorian performed. So the index 8191 can't be used, 8190 becomes the last index meaning that the maximum possible array size is 8191 (0..8190).

ok, that sounds correct... but I understood you said there was a bug at array index 8192, which technically doesn't exist...

whatever

 

[SFilip]

> you look sure that variables take 2 bytes
Eh...what?

> Warcraft is not an operating system
Operating system is what Warcraft is working under. Unless it's completely written in assembly (which is not the case) it has to rely on its functionality.

> JASS is not c++
Warcraft was written in C++. That's not really relevant though.

> Warcraft could easily use 2-bytes pointer in a virtual memory
There is no such thing as a 2-bytes pointer in a 32-bit operating system.
Furthermore...the first handle is 0x100000. The maximum possible 16bit (2-byte) integer is 2^16 (0x10000) which is 16 times less. There is no possible way it can be 2-byte.

> real "int" are not always in 4 bytes, there is old OSs with 2-bytes int
Yes, this is why I said 32-bit operating system.

> if you have the JASS tech doc
Nope, but the second best thing, grimoire source code, can be downloaded freely.

> never assume that something "must be like usually"
I never did. Nothing I said is a mere assumption, everything is based on facts. To be specific - I made a couple of custom natives using japi - they always need to take a 32-bit integer value for all types. Furthermore it can easily be proven using H2I and similar return bug functions.

 

[YoshiRyu]

> you looked sure that variables take 2 bytes
Eh...what?

Furthermore one variable takes only a couple of bytes of memory

(sorry for the mistake, that didn't help to understand ^^')

Operating system is what Warcraft is working under. Unless it's completely written in assembly (which is not the case) it has to rely on its functionality.

No no no, you can easily, in any program, ask the system a part of the memory, store it's adress somewhere, and use 2-byte pointers to find a precise point of the memory from the initial adress.
That's exactly like the arrays, if you have an array of less than 256 index, of course it have a 4-bytes initial adress, but then, you can use char for the indexes, and perform the true memory adresse of the item you wish by (initial adress + char index)

// many syntax shortcuts, don't care
void* vmem;
------------------------------------------------
vmem = (void*)malloc(256);
------------------------------------------------
char vmalloc(char nb_bytes) {
  char vptr;
  // search free space in vmem
  return vptr;
}
void* vget(char index) {
  return vmem+index;
}
void vset(char index, char nb_bytes, void* value) {
  memcpy(vmem+index, value);
}

since jass is a script language, you can't know what is really performed when you write "local handle myhandle", it may allocate a true memory pointer, a relative vmem one, or event an array's item.

you've checked that integer can store 4-bytes values
you can do the same with handle if you wish to check their size, but that's probably 4-bytes too

anyway, that's a pain in the *** to not have this doc
i really want to know if condition are fully checked or dynamicly...
(because of my bad english, a sample to explain :
if (unitvar!=null and GetUnitUserData(unitvar)>0) then ...
do or don't?)

anyway, that's subject is very interresting
you seem to have studie really hard the JASS specifications