I've seen alot of threads talking about the maximum size of banks that use strings. But what about other variables? In particular, I'd like to know the limits on Unit Types and Integers.
Also, can I get a little more information on how to go about storing multiple variables in a single string? I'm not familiar with encrypting or managing sub-strings.
Unit types are strings and integers can be stored in strings better to save place. Strings are probably the best way to store any data in banks.
The general idea of storing everything in one string is to save space:
You convert everything to numbers and connect them together. For example you want to save the level of a hero and the items of a hero.
First you need to convert the items to numbers.
How? Easy, just give each item an ID.
For argument's sake we have 9 different items and hero levels go up to 99. Heroes have 2 item slots.
We want to save a hero with level 74 carrying the items 3 and 5.
So we need 2 digits for the hero level (since max lvl is 99, which happens to have 2 digits) and 1 digit per item slot (since we have 9 items)
Our code will be 4 digits long; you could just store:
7435
When decoding, you must make sure, the algorithm knows that the first 2 digits store the hero lvl and the other 2 store 1 item each, of course.
So, now we can store this in a bank. But why strings? We could just store it as integer.
Strings however have the advantage to be able to contain other characters than numbers. So we can use other number systems than the 10 based system. Usual choices would be the 64 system (0-9, a-z, A-Z ,+ and - or 2 other extra characters) or the 81 System (several additional special characters)
Converting "7435" into the 64 system would probably be something like "Ab+". Great, we saved some space, and we are still able to get all the saved information, we just need to re-transform it. This becomes way more significant the more information you store, of course.
This is basically, what librarys like StarCode do, you give it a huge number it should save, and it does just that, along with some other things like adding a CRC checksum (so you cannot put a random code in your bank and get level x and item y) and other encryption to obfuscate the code, so it cannot be easily modified.
Yeah...I seemed to have had a temporary lapse of reason there for a second. Good call, I completely forgot they were already strings lmao.
I understand the whole concept of combining strings, but within the editor itself, how do you pick apart a string by character? The 64 system is a great idea though, never thought of that.
We want to save a hero with level 74 carrying the items 3 and 5.
So we need 2 digits for the hero level (since max lvl is 99, which happens to have 2 digits) and 1 digit per item slot (since we have 9 items)
Our code will be 4 digits long; you could just store:
7435
When decoding, you must make sure, the algorithm knows that the first 2 digits store the hero lvl and the other 2 store 1 item each, of course.
Honestly I would use comma denominated strings for the bank saving so my variables can have a variable lengths. You have the ability to split words in a string by a common denominator.
So the way I would do it is
bank = "74,3,5"
Since my string is not a "true" number you cant really convert it to some other kind of numbering system. But I believe this offers more flexablity.
Smart people will be able to hack your bank files regardless.
Also I used to keep up on star code. And theres a couple problems with it such as. If you find a bug with it... theres not much you can do other then fix the library yourself or wait for an update. Theres also certain character limitations that you may not be able to use with a library.
That and if your using a specific library it may make it even easier for people to access the bank therefore defeating one of the purposes.
And to answer your questions the bank basically is a string from my understanding.
Honestly I would use comma denominated strings for the bank saving so my variables can have a variable lengths. You have the ability to split words in a string by a common denominator.
So the way I would do it is
bank = "74,3,5"
Since my string is not a "true" number you cant really convert it to some other kind of numbering system. But I believe this offers more flexablity.
Depends. For this example, the code becomes longer, so less information can be stored. For other examples, this might be false, however.
For wc3 this was way more significant, since save codes were limited to about 30 characters or something.
Dependant on the actual use of the system, there could be numerous improvements. For a card game, I developed a system storing cards in a savecode once. For this, I did not store the actual card id's, but I ordered the deck by id size and just stored the subtractions between following cards in order. Additionaly I used a dynamic number base system, which stored the number in an optimal system and then converted it (for example, 101 in 10 base system sucks, because it needs a 3rd digit. If we use the 11 system, this would be 2 digits only), and stored the used base as well.
Well, nvm, for sc2 the size is not THAT of an issue anymore.
Quote:
Smart people will be able to hack your bank files regardless.
True, especially with acess to your map all bank protection is basically obsolete. Maybe patch 1.2 changes this :)
Quote:
Also I used to keep up on star code. And theres a couple problems with it such as. If you find a bug with it... theres not much you can do other then fix the library yourself or wait for an update. Theres also certain character limitations that you may not be able to use with a library.
Are there any known bugs with StarCode?
Oh, and to split strings in chars: There is the function "StringSub" (probably just called Substring in the editor), which does this. It takes the input string and start+end of the substring. If you loop consecutive numbers, you will get all the characters.
Example:
StringSub("Hello",1,3)
should return "el" (if I am not mistaken ;) )
So to get all characters, you do 0,1 -> "H" 1,2 -> "e" ... you get the idea
so far iv stored like 400 ints in banks and seems to work fine. I could convert them to strings, but if it works this way why bother changing it :/. Its not like ints take lots of space.
but correct me if there is some reason why you shouldnt store 400 different values.
Also I used to keep up on star code. And theres a couple problems with it such as. If you find a bug with it... theres not much you can do other then fix the library yourself or wait for an update. Theres also certain character limitations that you may not be able to use with a library.
What bug? I only remember this strange initialization bug when you got like 20,000 vars inited or so - this bug, after extensive testing, is not directly related to Starcode but is probably a bug in Starcraft.
Also - the character limitation is for one saved string. Nothing keeps you from making a second one with the variables you can't fit into the first one. This is also a limitation imposed by Starcraft (execution limit) and not by me.
When someone discovers a bug or when some update on Starcraft breaks Starcode I intend to be there to fix it.
@Topic:
After the banks have been fixed with that huge patch size limitations aren't that much of a problem anymore. Compressing everything into strings still yields a good result (less loading time, for example) but banks can save quite a lot now.
Sooo, say I wanted to save a lot of data in one string, say there's like, 1000 boolean options, and I save it as a single 1000 character string, just using A or B to show if that boolean is true or false.
I then use a trigger that counts to 1000, loading whether or not that is A or B.
Will that save more space than saving each boolean separately with it's own key?
Can it even save a string that's 1000 characters in length?
And roughly how much space does that take up?
I can obviously shorten the length of the string to only include the ones that are true, but if the amount of trues outweigh the amount of false it suddenly becomes less efficient. hmmm
Rollback Post to RevisionRollBack
Zergling Blood : starcraft://map/1/35684
Game of Thrones : starcraft://map/1/189756
Tacticraft : starcraft://map/1/223625
To post a comment, please login or register a new account.
I've seen alot of threads talking about the maximum size of banks that use strings. But what about other variables? In particular, I'd like to know the limits on Unit Types and Integers.
Also, can I get a little more information on how to go about storing multiple variables in a single string? I'm not familiar with encrypting or managing sub-strings.
Unit types are strings and integers can be stored in strings better to save place. Strings are probably the best way to store any data in banks.
The general idea of storing everything in one string is to save space:
You convert everything to numbers and connect them together. For example you want to save the level of a hero and the items of a hero.
First you need to convert the items to numbers.
How? Easy, just give each item an ID.
For argument's sake we have 9 different items and hero levels go up to 99. Heroes have 2 item slots.
We want to save a hero with level 74 carrying the items 3 and 5.
So we need 2 digits for the hero level (since max lvl is 99, which happens to have 2 digits) and 1 digit per item slot (since we have 9 items)
Our code will be 4 digits long; you could just store:
7435
When decoding, you must make sure, the algorithm knows that the first 2 digits store the hero lvl and the other 2 store 1 item each, of course.
So, now we can store this in a bank. But why strings? We could just store it as integer.
Strings however have the advantage to be able to contain other characters than numbers. So we can use other number systems than the 10 based system. Usual choices would be the 64 system (0-9, a-z, A-Z ,+ and - or 2 other extra characters) or the 81 System (several additional special characters)
Converting "7435" into the 64 system would probably be something like "Ab+". Great, we saved some space, and we are still able to get all the saved information, we just need to re-transform it. This becomes way more significant the more information you store, of course.
This is basically, what librarys like StarCode do, you give it a huge number it should save, and it does just that, along with some other things like adding a CRC checksum (so you cannot put a random code in your bank and get level x and item y) and other encryption to obfuscate the code, so it cannot be easily modified.
@Kueken531: Go
"Unit types are strings"
Yeah...I seemed to have had a temporary lapse of reason there for a second. Good call, I completely forgot they were already strings lmao.
I understand the whole concept of combining strings, but within the editor itself, how do you pick apart a string by character? The 64 system is a great idea though, never thought of that.
@wingednosering: Go
Honestly I would use comma denominated strings for the bank saving so my variables can have a variable lengths. You have the ability to split words in a string by a common denominator.
So the way I would do it is
bank = "74,3,5"
Since my string is not a "true" number you cant really convert it to some other kind of numbering system. But I believe this offers more flexablity.
Smart people will be able to hack your bank files regardless.
Also I used to keep up on star code. And theres a couple problems with it such as. If you find a bug with it... theres not much you can do other then fix the library yourself or wait for an update. Theres also certain character limitations that you may not be able to use with a library.
That and if your using a specific library it may make it even easier for people to access the bank therefore defeating one of the purposes.
And to answer your questions the bank basically is a string from my understanding.
Depends. For this example, the code becomes longer, so less information can be stored. For other examples, this might be false, however.
For wc3 this was way more significant, since save codes were limited to about 30 characters or something.
Dependant on the actual use of the system, there could be numerous improvements. For a card game, I developed a system storing cards in a savecode once. For this, I did not store the actual card id's, but I ordered the deck by id size and just stored the subtractions between following cards in order. Additionaly I used a dynamic number base system, which stored the number in an optimal system and then converted it (for example, 101 in 10 base system sucks, because it needs a 3rd digit. If we use the 11 system, this would be 2 digits only), and stored the used base as well.
Well, nvm, for sc2 the size is not THAT of an issue anymore.
True, especially with acess to your map all bank protection is basically obsolete. Maybe patch 1.2 changes this :)
Are there any known bugs with StarCode?
Oh, and to split strings in chars: There is the function "StringSub" (probably just called Substring in the editor), which does this. It takes the input string and start+end of the substring. If you loop consecutive numbers, you will get all the characters.
Example:
StringSub("Hello",1,3)
should return "el" (if I am not mistaken ;) )
So to get all characters, you do 0,1 -> "H" 1,2 -> "e" ... you get the idea
so far iv stored like 400 ints in banks and seems to work fine. I could convert them to strings, but if it works this way why bother changing it :/. Its not like ints take lots of space.
but correct me if there is some reason why you shouldnt store 400 different values.
What bug? I only remember this strange initialization bug when you got like 20,000 vars inited or so - this bug, after extensive testing, is not directly related to Starcode but is probably a bug in Starcraft.
Also - the character limitation is for one saved string. Nothing keeps you from making a second one with the variables you can't fit into the first one. This is also a limitation imposed by Starcraft (execution limit) and not by me.
When someone discovers a bug or when some update on Starcraft breaks Starcode I intend to be there to fix it.
@Topic:
After the banks have been fixed with that huge patch size limitations aren't that much of a problem anymore. Compressing everything into strings still yields a good result (less loading time, for example) but banks can save quite a lot now.
Sooo, say I wanted to save a lot of data in one string, say there's like, 1000 boolean options, and I save it as a single 1000 character string, just using A or B to show if that boolean is true or false.
I then use a trigger that counts to 1000, loading whether or not that is A or B.
Will that save more space than saving each boolean separately with it's own key?
Can it even save a string that's 1000 characters in length?
And roughly how much space does that take up?
I can obviously shorten the length of the string to only include the ones that are true, but if the amount of trues outweigh the amount of false it suddenly becomes less efficient. hmmm