Hey all,
I'm about to embark on creating a lot of trigger-based upgrades.
These upgrades will be chosen via dialogs.
The first part of my question is, how should I store each players chosen upgrades. There's going to be quite a few.
Having global integer arrays for every upgrade relating back to the player seems like the straight-forward method, but is there a better way?
Let's say there's around 100 upgrades per player with max 8 players. Does it even matter, maybe these numbers are too small to effect performance?
And no these aren't going to be put into banks afterwards lol
The available script code is 4 to 10 times bigger compared to 1.4.4. So it's unlikely that you run out of space fast.
Only if you run out of space, you should think about using other, slower storage methods.
I suggest trying out user types data. Since the data is one time use, just read them into local variables with your function that's displaying your upgrades. Once the function completes its run, the locals will clear and you won't have a useless global sitting in your memory
My map is very script intensive, but I have no idea how close I am to pushing the limits. Probably and hopefully far away.
Are there any known limits for script size or general rules of thumb on things not to surpass?
My map is very script intensive, but I have no idea how close I am to pushing the limits. Probably and hopefully far away.
Are there any known limits for script size or general rules of thumb on things not to surpass?
Pre-patch, the script limit was 2 MB in various "places", like raw script file size, memory space used by variables at runtime etc. Usually, this was plenty to work with, and if you didn't waste a whole lot of space, you would rarely hit the limit.
Now, it is 4-10 times higher, stated by Blizzard, but I don't know the exact specifics, like if this affects all applications of the limit, or when it is actually 4 times and when 10 times.
€ Previously, on a blank map, the memory limit for variables caused issues at around 500k variables. Just tried it again right now, and for a global array, it caps at exactly 519,400 members, one more, and it won't compile (where did that 4-10 times go? o_0 - Also this was pretty inconsistent, half of the time, it compiled just fine, then it started complaining about script size limit again without any change to the code at all).
However, the exact number depends on the map and can be affected by other trigger stuff and even data or units placed on the map.
Quote:
I'm not sure what user types data is? Is there a tutorial for it by chance?
And can the triggers read from it once it has been set?
User Types are a new data type, which is essentially just an array, which you can fill in the data editor. You can define each user type, if it is modifiable by trigger; you can check, modify and reset them to default, if you choose to do so, otherwise they are read-only. Pretty straightforward.
They seem to have connections to various other data types we don't know much about yet, but just for storing and reading information, this is not important.
1) If you're not using level-based upgrades, then I suggest using an array of booleans or a simple string variable for each player. If you use the string approach, use substrings to manipulate the data as needed. The string method is also good for if your upgrade levels don't exceed 9. EDIT: Although if you're feeling adventurous, you could use alphabetic letters to represent higher values.
2) Use User Types. If you mess around in that for a few minutes, you'll understand it easily. As I understand it, User Types will occupy data space, not script space.
I'm not sure if I'm understanding User Types correctly. Is it similar to custom values that allow more types than just fixed? Can it be modified for units on individual bases or does it have a static "global" value? Or do I have to stick to the messy variables with huge arrays?
User types are nothing more than extra-messy variables with potentially huge arrays :D. Also, if you just need a few hundreds of upgrades per player, there is absolutely no problem in running a boolean or integer array, probably organized in a record.
Hey all,
I'm about to embark on creating a lot of trigger-based upgrades.
These upgrades will be chosen via dialogs.
The first part of my question is, how should I store each players chosen upgrades. There's going to be quite a few.
Having global integer arrays for every upgrade relating back to the player seems like the straight-forward method, but is there a better way?
Let's say there's around 100 upgrades per player with max 8 players. Does it even matter, maybe these numbers are too small to effect performance?
And no these aren't going to be put into banks afterwards lol
Thanks all
Just use integer arrays.
The available script code is 4 to 10 times bigger compared to 1.4.4. So it's unlikely that you run out of space fast.
Only if you run out of space, you should think about using other, slower storage methods.
I suggest trying out user types data. Since the data is one time use, just read them into local variables with your function that's displaying your upgrades. Once the function completes its run, the locals will clear and you won't have a useless global sitting in your memory
@Ahli634: Go
My map is very script intensive, but I have no idea how close I am to pushing the limits. Probably and hopefully far away.
Are there any known limits for script size or general rules of thumb on things not to surpass?
@FuzzYD: Go
I'm not sure what user types data is? Is there a tutorial for it by chance?
And can the triggers read from it once it has been set?
Pre-patch, the script limit was 2 MB in various "places", like raw script file size, memory space used by variables at runtime etc. Usually, this was plenty to work with, and if you didn't waste a whole lot of space, you would rarely hit the limit.
Now, it is 4-10 times higher, stated by Blizzard, but I don't know the exact specifics, like if this affects all applications of the limit, or when it is actually 4 times and when 10 times.
€ Previously, on a blank map, the memory limit for variables caused issues at around 500k variables. Just tried it again right now, and for a global array, it caps at exactly 519,400 members, one more, and it won't compile (where did that 4-10 times go? o_0 - Also this was pretty inconsistent, half of the time, it compiled just fine, then it started complaining about script size limit again without any change to the code at all).
However, the exact number depends on the map and can be affected by other trigger stuff and even data or units placed on the map.
User Types are a new data type, which is essentially just an array, which you can fill in the data editor. You can define each user type, if it is modifiable by trigger; you can check, modify and reset them to default, if you choose to do so, otherwise they are read-only. Pretty straightforward.
They seem to have connections to various other data types we don't know much about yet, but just for storing and reading information, this is not important.
2 methods come to mind:
1) If you're not using level-based upgrades, then I suggest using an array of booleans or a simple string variable for each player. If you use the string approach, use substrings to manipulate the data as needed. The string method is also good for if your upgrade levels don't exceed 9. EDIT: Although if you're feeling adventurous, you could use alphabetic letters to represent higher values.
2) Use User Types. If you mess around in that for a few minutes, you'll understand it easily. As I understand it, User Types will occupy data space, not script space.
I'm not sure if I'm understanding User Types correctly. Is it similar to custom values that allow more types than just fixed? Can it be modified for units on individual bases or does it have a static "global" value? Or do I have to stick to the messy variables with huge arrays?
User types are nothing more than extra-messy variables with potentially huge arrays :D. Also, if you just need a few hundreds of upgrades per player, there is absolutely no problem in running a boolean or integer array, probably organized in a record.
@DieHappy1234: Go
http://www.sc2mapster.com/forums/development/data/40511-new-data-types-in-patch-1-5/?post=20