im to lazy to summarize all this, but you should really read all posts in there, its really worth it if you are planning bigger projects that will need to store a lot of data in bank files. lets hope blizz will change smth. :)
What are the maximum and minimum values you can use for a bank integer?
You can encode a lot of information in an integer if it is allowed to be big enough.
I'm not saying that the way it works right now is okay, I'm just trying to come up with viable solutions.
What are the maximum and minimum values you can use for a bank integer? You can encode a lot of information in an integer if it is allowed to be big enough.
I'm not saying that the way it works right now is okay, I'm just trying to come up with viable solutions.
-2147483648 to 2147483648 i suppose.
edit: in gui the max seems to be 1000000000 to -1000000000, dont know if you can use bigger numbers in galaxy itself, because normally an integer can store bigger numbers.
edit2: hm... if i paste 2147483648 in it it changes to 1000000000, but i can use 1000000001, strange. dont know whats the exact limit in gui, but more then 2147483648 should not be possible.
You probably mean -2147483647, but I get your point. It's 32-bit.
And we've got 80 of them to work with, so that's 2560 bits. You can do a lot with that if you optimize.
We can store a lot of information with this. Suppose your character's attributes have a max of 256. Each one takes up only 8 bits. Each quest, assuming it has two states (complete, incomplete) takes up 1 bit. Suppose your map has 512 unique items. Each item slot takes up 9 bits.
So if we want to save 6 attributes, 20 items, and 128 quests of a character, it will only take 356 bits. And this is pretty ambitious for an ORPG (are there really going to be 128 quests and 512 items?) and we still have enough room in the bank to store seven characters and still have room for checksums and such. If someone has to have more than this, they can just swap out the XML manually.
ORPGs have to be somewhat limited anyway, since any system that allows you to trade items would also allow you to dupe them if you backed up the XML and then made a trade. If a project is so ambitious that it need more than 2560 bits to store a player's data, I think SC2 would probably be the wrong media. But that's just opinion.
Yeah, it could be implemented better. I'm just saying we can probably cope with it even if it isn't changed.
- this "80 value limit" was discovered by me and was WRONG
- that the amount of preloadable values depends on the size of each value (bigger key values = less values)
- that i have 5 character slots
- that the banks of all players are limited together, not for each person
A string with length of 90 characters per player for an 8-players game.
Granted, it's much less that we've initially expected. And you run into trouble if you want to load several heroes.
But it still beats the WC3 way of saving.
Apart from that it's really hard to get it well-encrypted since we can't even get a player's name as a string!
And I'll probably still use a save code. If I can't encrypt based on a player's name, then I'll just encrypt based on a random integer and a very small save code (just like an ID card or a code for your bank account).
I didn't read through the whole thread. Anyway, the number of digits or characters in the object being loaded shouldn't matter. A data object takes up a certain amount of memory regardless of what it contains. Storing the number "1" as a 32-bit Integer takes just as much memory as storing "2147483647" as a 32-bit Integer.
Trying to test the max number of String characters you can load is silly. Taking characters off of a String doesn't make the string take up less memory. You can load TWO STRINGS regardless of how "long" the strings are.
So the next question is, if the quoted number of 80 Integers isn't correct, then what is correct? Two strings should take up a lot more memory than 80 Integers, so is the number higher than 80 or lower?
Edit - Forget what I said about Strings, but I'm pretty sure that it should apply to Integers. It makes sense for them to segregate Strings into "long" or "short" for efficiency. What we really need to figure out is how much memory can be loaded? Not how many strings or how many integers but how much memory.
Taking characters off of a String doesn't make the string take up less memory.
..
This is irrelevent though, because like I said, the amount of memory taken up by a data object does not depend on what is contained in that object.
Bank preloading happens behind the courtains. Probably in a C script.
Strings are just char arrays. Those are generally dynamically allocated. Thus a string of length 10 will take up twice as much memory than a string of length 5. The size of a single char is always the same, but it depends on the number of chars in the array.
That's different for primitives, of course. A 32-bit int will always require 32 bit of room. But string is not a primitive.
And fact is that trying to load a 700-char string for one player does work, however loading the string for two players will not work anymore.
Quote:
this bankfile is to much for sc2 (4 entries, each entry 493 chars long[...])
What wikipedia says about strings:
Quote:
In general, there are two types of string datatypes: fixed length strings which have a fixed maximum length and which use the same amount of memory whether this maximum is reached or not, and variable length strings whose length is not arbitrarily fixed and which use varying amounts of memory depending on their actual size
You'd usually use variable lengths to save memory. Especially in an application with so many strings used.
Don't store anything that isn't a 256-bit value. Don't store redundant data.
Quests:
One byte can hold 8 quest flags: 0x10101010
Levels:
Three bytes can hold an EXP value up to 16777216 (You don't need negatives for EXP). You don't need to store both EXP and level, it would be redundant.
Skills/Talents:
Depends on how many levels they have. If they have 3 max levels each, you can store them 4 per byte: 0x 00 01 10 11 would represent 4 skills with levels 0, 1, 2 and 3 respectively.
Items:
With under 256 items you can store each item in a byte by a reference number.
Everything else:
You name it, I'll tell you how to shrink it down. It's really not that hard.
Levels: Three bytes can hold an EXP value up to 16777216 (You don't need negatives for EXP). You don't need to store both EXP and level, it would be redundant.
A good way to reduce size of things like EXP or money is to save a fraction of it.
Instead of 16777216 you just save a fifth of it (3355443) and multiply it by 5 when loading again. You'll have slight rounding errors, but who cares.
But basically rrowland hit the nail on it's head. Code compression is as important as it was with WC3 save codes.
WTF this puts my entire project in jeopardy! how the hell am i supposed to work this that small amount of space. is this 800 per bank file or 800 total? can i just have each player have their open bank file will 800 chars in each? and each player have multiple banks to increase the space?
This does appear to be bad news as is some other things, but lets remeber a few things. FIrst a foremost is a beta editor were working with, and also even if it wasn't its still an early version. I think I can speak for all of us who remeber the mind numbing limitations to things in the original staredit and worldedit? Ethier way I'm sure these limts will very much change by the time we get our hands on a retail copy of stracraft 2.
Also lets not forget just how in-depth and complicated the editor really is, lets be honest no one knows 100% everything about every aspect of the editor yet. I swear every day I check away at it I figure out something new and I belive you all can agree. We also need to remeber that becuase of this, the way we have done thigns in the past with staredit and worldedit are really not vaild anymore. I mean come on we can acutally make our own functions and action defintions, records (structures) and even full script libarys. (and even thoese who did this in wordledit through modifed versions of the editor/pure scripting can tell you it was not a full proof process)
I fully expect a lot of these size limits (file sizes and the like) to change dramaticly, it makes sense from a programmer stand point, you want to make sure things work, before you totaly stress out the system. And I think we can all agree that if these file sizes were not contained right now, battle.net 2.0 would be in worse shape then its been. I'm not trying to dismmiss anything you guys are saying, there imporant, and vaild, and you know what its a good thing to know them and find a workaround that works for us, so if it does take a while to change/fix we at least have an alternate.
The last bright spot is, release is all that much closer, a whole month and 20 days away! So if you think were busy just imagne the code guys at blizz! If its a big problem to your major project right now, work on another aspect of that project, or find a workaround, if nethier seems possible, set it aside for now and work on something smaller. But keep working and digging at the editor, and well figure it out, and if nothing else hopefully by relase blizz will fill in the gaps for us. So yeah thats my insperation speech on a very somber thread. :)
For all of you who want to know (nearly) everything about banks that is known atm:
http://www.hiveworkshop.com/forums/galaxy-editor-help-zone-647/sc2-bank-files-critics-167005/
im to lazy to summarize all this, but you should really read all posts in there, its really worth it if you are planning bigger projects that will need to store a lot of data in bank files. lets hope blizz will change smth. :)
greez
bump, it disappeared a bit quickly and i think its very important for EVERY mapper to know.
in bnet i see examples how NOT to do it everyday again ~
also i hear wrong explanations and theories everyday, like "50 values each player is ok" or smth. its much more complicated guys.
What are the maximum and minimum values you can use for a bank integer? You can encode a lot of information in an integer if it is allowed to be big enough.
I'm not saying that the way it works right now is okay, I'm just trying to come up with viable solutions.
-2147483648 to 2147483648 i suppose.
edit: in gui the max seems to be 1000000000 to -1000000000, dont know if you can use bigger numbers in galaxy itself, because normally an integer can store bigger numbers.
edit2: hm... if i paste 2147483648 in it it changes to 1000000000, but i can use 1000000001, strange. dont know whats the exact limit in gui, but more then 2147483648 should not be possible.
You probably mean -2147483647, but I get your point. It's 32-bit.
And we've got 80 of them to work with, so that's 2560 bits. You can do a lot with that if you optimize.
We can store a lot of information with this. Suppose your character's attributes have a max of 256. Each one takes up only 8 bits. Each quest, assuming it has two states (complete, incomplete) takes up 1 bit. Suppose your map has 512 unique items. Each item slot takes up 9 bits.
So if we want to save 6 attributes, 20 items, and 128 quests of a character, it will only take 356 bits. And this is pretty ambitious for an ORPG (are there really going to be 128 quests and 512 items?) and we still have enough room in the bank to store seven characters and still have room for checksums and such. If someone has to have more than this, they can just swap out the XML manually.
ORPGs have to be somewhat limited anyway, since any system that allows you to trade items would also allow you to dupe them if you backed up the XML and then made a trade. If a project is so ambitious that it need more than 2560 bits to store a player's data, I think SC2 would probably be the wrong media. But that's just opinion.
Yeah, it could be implemented better. I'm just saying we can probably cope with it even if it isn't changed.
@MasterDinadan: Go
seems like you ignored the fact that
- this "80 value limit" was discovered by me and was WRONG
- that the amount of preloadable values depends on the size of each value (bigger key values = less values)
- that i have 5 character slots
- that the banks of all players are limited together, not for each person
A string with length of 90 characters per player for an 8-players game.
Granted, it's much less that we've initially expected. And you run into trouble if you want to load several heroes.
But it still beats the WC3 way of saving.
Apart from that it's really hard to get it well-encrypted since we can't even get a player's name as a string!
And I'll probably still use a save code. If I can't encrypt based on a player's name, then I'll just encrypt based on a random integer and a very small save code (just like an ID card or a code for your bank account).
I didn't read through the whole thread. Anyway, the number of digits or characters in the object being loaded shouldn't matter. A data object takes up a certain amount of memory regardless of what it contains. Storing the number "1" as a 32-bit Integer takes just as much memory as storing "2147483647" as a 32-bit Integer.
Trying to test the max number of String characters you can load is silly. Taking characters off of a String doesn't make the string take up less memory. You can load TWO STRINGS regardless of how "long" the strings are.
So the next question is, if the quoted number of 80 Integers isn't correct, then what is correct? Two strings should take up a lot more memory than 80 Integers, so is the number higher than 80 or lower?
Edit - Forget what I said about Strings, but I'm pretty sure that it should apply to Integers. It makes sense for them to segregate Strings into "long" or "short" for efficiency. What we really need to figure out is how much memory can be loaded? Not how many strings or how many integers but how much memory.
Let me quote something from that topic:
Of course it's not 100% sure the information is valid, but the way of testing does sound reasonable to me.
Bank preloading happens behind the courtains. Probably in a C script.
Strings are just char arrays. Those are generally dynamically allocated. Thus a string of length 10 will take up twice as much memory than a string of length 5. The size of a single char is always the same, but it depends on the number of chars in the array.
That's different for primitives, of course. A 32-bit int will always require 32 bit of room. But string is not a primitive.
And fact is that trying to load a 700-char string for one player does work, however loading the string for two players will not work anymore.
What wikipedia says about strings:
You'd usually use variable lengths to save memory. Especially in an application with so many strings used.
Don't store anything that isn't a 256-bit value. Don't store redundant data.
Quests: One byte can hold 8 quest flags: 0x10101010
Levels: Three bytes can hold an EXP value up to 16777216 (You don't need negatives for EXP). You don't need to store both EXP and level, it would be redundant.
Skills/Talents: Depends on how many levels they have. If they have 3 max levels each, you can store them 4 per byte: 0x 00 01 10 11 would represent 4 skills with levels 0, 1, 2 and 3 respectively.
Items: With under 256 items you can store each item in a byte by a reference number.
Everything else: You name it, I'll tell you how to shrink it down. It's really not that hard.
A good way to reduce size of things like EXP or money is to save a fraction of it.
Instead of 16777216 you just save a fifth of it (3355443) and multiply it by 5 when loading again. You'll have slight rounding errors, but who cares.
But basically rrowland hit the nail on it's head. Code compression is as important as it was with WC3 save codes.
hm ok guys, i cant really follow you anymore.
so how do i convert my integer variables in this bytes to reduce the bank size and then reconvert it to integers when loading? :O
seems to be a lot of theory in here but how to do it?
I already told you the general idea in that other topic: http://www.hiveworkshop.com/forums/galaxy-editor-help-zone-647/sc2-bank-files-critics-167005/index5.html
A Byte is just a measurement of size. ( http://en.wikipedia.org/wiki/Byte )
WTF this puts my entire project in jeopardy! how the hell am i supposed to work this that small amount of space. is this 800 per bank file or 800 total? can i just have each player have their open bank file will 800 chars in each? and each player have multiple banks to increase the space?
In total.
No. All players together may have 800.
No. All banks loaded of all players may only have 800 size together.
Again, this has been tested by Mille25 and he got these results. It's not 100% validated since it has'nt been tested thoroughly.
Wow, Nice answers s3rious xD . All 3 the same haha.
@s3rius: Go
ugh this is bad. this is real bad.
This does appear to be bad news as is some other things, but lets remeber a few things. FIrst a foremost is a beta editor were working with, and also even if it wasn't its still an early version. I think I can speak for all of us who remeber the mind numbing limitations to things in the original staredit and worldedit? Ethier way I'm sure these limts will very much change by the time we get our hands on a retail copy of stracraft 2.
Also lets not forget just how in-depth and complicated the editor really is, lets be honest no one knows 100% everything about every aspect of the editor yet. I swear every day I check away at it I figure out something new and I belive you all can agree. We also need to remeber that becuase of this, the way we have done thigns in the past with staredit and worldedit are really not vaild anymore. I mean come on we can acutally make our own functions and action defintions, records (structures) and even full script libarys. (and even thoese who did this in wordledit through modifed versions of the editor/pure scripting can tell you it was not a full proof process)
I fully expect a lot of these size limits (file sizes and the like) to change dramaticly, it makes sense from a programmer stand point, you want to make sure things work, before you totaly stress out the system. And I think we can all agree that if these file sizes were not contained right now, battle.net 2.0 would be in worse shape then its been. I'm not trying to dismmiss anything you guys are saying, there imporant, and vaild, and you know what its a good thing to know them and find a workaround that works for us, so if it does take a while to change/fix we at least have an alternate.
The last bright spot is, release is all that much closer, a whole month and 20 days away! So if you think were busy just imagne the code guys at blizz! If its a big problem to your major project right now, work on another aspect of that project, or find a workaround, if nethier seems possible, set it aside for now and work on something smaller. But keep working and digging at the editor, and well figure it out, and if nothing else hopefully by relase blizz will fill in the gaps for us. So yeah thats my insperation speech on a very somber thread. :)
@Mille25: Go
it is -2147483648 to 2147483647. If galaxy would support the highest 32 bit value for its signed integer, then 2147483647 would be it, not 2147483648.