It doesn't split anything into blocks.
In compresses all your integers into one very very big number (packaging) and then converts this big number into a new base.
I've written a library with all arithmetic operations (add, subtract, divide, multiply, modulo and exponentiate) that work with up to 100-digit numbers for this to work.
A base of 87. I know of 92 working string characters. But one is an escape character ( / ) and one is associated with tags ( < ), so I excluded them. The other 3 characters were an error on my part. I just forgot about them. They'll be in for the next version.
You can define the base by editing the alphabet. But I suggest to leave it as it is, since it's more or less the best setting.
Alright update time. Version 1.2 has one major change, the hashing is introduced:
What is hashing? How does it work?
Hashing algorithms create checksums which can be used to check whether the code has been modified or entered incorrectly.
Without hashing STARCODE would just decode the code anyway and retrieve completely screwed up numbers. This can be avoided using hashes.
STARCODE allows you to set a maxium size for the checksum (the "security level"). Especially for long codes the security level should be a little bit higher (about 3 or 4).
With a security level of 1 there is a 1/90 chance that a random code will be mistakenly acknowledged as working. With a security level of 2 this chance shrinks down to 1/8100 already. Well, that's not exactly mathematically correct, it's a little more complicated than that. But you guys will either know about it already or not really care. Suffice to say that a higher security level grants higher security.
Each level of security increases the code length by 1.
There is an example of how to use hashing in my Example map, attached to the first post of this topic.
Could you generate a set of keys based on a cipher and encrypt the thing with those keys?
Here is my precise thought-
you have your base (like base 87)
You have a cipher (like the person's account name)
For each character of the code, you do an algorithm using the current base and the cipher
For example, first base would be a base derived from the default base and the cipher and applied to character 1 of the code. The next base would be derived from the previous base and the cipher and applied to character 2, etc.
After this point, you do shuffling by putting the code into a uniform matrix + a linear matrix (anything extra after uniform is just put into the line). You go in steps of 2x2 matrices and rotate each one clockwise/counter clockwise (including the linear matrix, which would make each matrix like a 2x2 + 1 matrix). You would go column by column, row by row, so like..
Well, it's not a matter of encryption, honestly.
Even with the default encryption, deciphering it would be TREMENDOUS work as you'd not only need to figure out the right encryption key and the stored integers sizes (in correct order) and the length of the checksum, but users can even scramble the alphabet to comepletely change the outcome of all base-converted calculations.
You won't find happiness in this task unless you are a decryption specialist with a super computer.
There is only one real way to overcome this encryption: by opening the map and looking at the code itself. And in this case there's no difference between a complex encryption like yours or a lightweight encryption like mine.
It's pretty logical though.
Banks needs to be shared with all other players in the beginning. Larger banks would increase loading time way much.
And 800 chars isn't too bad actually. In Warcraft 3 there were save codes with .. at max like 30 chars. And they were annoying to write down and type in. Now we got the whole process behind the scenes and can automate it without the user noticing. AND we can store more than 20x as much information.
This Save library is awesome. I will use it for sure in my RPG.
s3rius - if i'm right we can use 4kB for all banks for all players. So with 4 players we are limited to 1kB per player and aditional to this Bank files takes a lot of space becouse how they are created: xml file:
As you can see xml tags takes a lot of space.
Aditional to it we can't create uncompresed strings larger than 100 char becouse of trigger execution time limit....
so we need to create aditional key for every 100 uncompresed chars so it takes more space for xml tags...
i think of a solution to remove one character from base coding and use it as a separator so i can store multiple 100 char stings into one big string without geting to trigger time execution limit.
That's the way to go. I forgot that these strings will be of variable length, so yea you probably will have to use one char as a delimiter. I suggest using one of the special chars like |!"ยง$%&/()=? and not an alphanumeric char.
IANA leet hax0r, but, afaik, this encryption method is solid. He's essentially using the custom key that the mapmaker chooses as the pad for the encryption. As long as your maps aren't available in an unprotected format, this should work fine.
awesome work on the library.
I'm assuming you run into problems when storing floating point numbers? Do you have a lossless system for storing them?
Do you have any accuracy info on them, or do they remain uncompressed.
awesome work on the library. I'm assuming you run into problems when storing floating point numbers? Do you have a lossless system for storing them? Do you have any accuracy info on them, or do they remain uncompressed.
There are no real floating point numbers in Galaxy. The real are just normal integers divided by 4096. So storing them loss-less is not a problem.
This is immensely useful. This should definitely be standard issue to anyone using banks.
@s3rius: Go
ah ok so your system generates the raw code first and then it splits it up into blogs whitch get converted?
@Mille25: Go
It doesn't split anything into blocks. In compresses all your integers into one very very big number (packaging) and then converts this big number into a new base.
I've written a library with all arithmetic operations (add, subtract, divide, multiply, modulo and exponentiate) that work with up to 100-digit numbers for this to work.
@s3rius: Go
Also, what base is this stored in? 64? More?
@Iggyhopper: Go
A base of 87. I know of 92 working string characters. But one is an escape character ( / ) and one is associated with tags ( < ), so I excluded them. The other 3 characters were an error on my part. I just forgot about them. They'll be in for the next version.
You can define the base by editing the alphabet. But I suggest to leave it as it is, since it's more or less the best setting.
Alright update time. Version 1.2 has one major change, the hashing is introduced:
What is hashing? How does it work?
Could you generate a set of keys based on a cipher and encrypt the thing with those keys?
Here is my precise thought-
you have your base (like base 87)
You have a cipher (like the person's account name)
For each character of the code, you do an algorithm using the current base and the cipher
For example, first base would be a base derived from the default base and the cipher and applied to character 1 of the code. The next base would be derived from the previous base and the cipher and applied to character 2, etc.
After this point, you do shuffling by putting the code into a uniform matrix + a linear matrix (anything extra after uniform is just put into the line). You go in steps of 2x2 matrices and rotate each one clockwise/counter clockwise (including the linear matrix, which would make each matrix like a 2x2 + 1 matrix). You would go column by column, row by row, so like..
column+=add;
if (column == matrixSize-1 || column == 0) { add*=-1; column+= add; row+=add2; if (row == matrixSize-1 || row == 0) { add2*=-1; row+=add; } }
@nestharus: Go
I can't really follow you there. Of what use would that be? Wouldn't it just be a overly complicated way of encryption?
thus making it extremely difficult to decrypt without increasing the code size, even with the base key ;).
Well, it's not a matter of encryption, honestly. Even with the default encryption, deciphering it would be TREMENDOUS work as you'd not only need to figure out the right encryption key and the stored integers sizes (in correct order) and the length of the checksum, but users can even scramble the alphabet to comepletely change the outcome of all base-converted calculations.
You won't find happiness in this task unless you are a decryption specialist with a super computer.
There is only one real way to overcome this encryption: by opening the map and looking at the code itself. And in this case there's no difference between a complex encryption like yours or a lightweight encryption like mine.
I'm just saying that since there is no overhead in the code size, you could just add an Encrypt function or w/e over a Convert function or something.
I guess the overall architecture would need to change a bit to promote modularity ; ).
I know with something I was working on, I just had number stacks that could have their bases converted, meaning you could really do w/e.
I was veeery dissappointed when I learned you can only store the limited and undocumented 800ish~ characters in a player's bank. :(
@Hokibukisa: Go
It's pretty logical though.
Banks needs to be shared with all other players in the beginning. Larger banks would increase loading time way much.
And 800 chars isn't too bad actually. In Warcraft 3 there were save codes with .. at max like 30 chars. And they were annoying to write down and type in. Now we got the whole process behind the scenes and can automate it without the user noticing. AND we can store more than 20x as much information.
This Save library is awesome. I will use it for sure in my RPG.
s3rius - if i'm right we can use 4kB for all banks for all players. So with 4 players we are limited to 1kB per player and aditional to this Bank files takes a lot of space becouse how they are created: xml file:
<?xml version="1.0" encoding="utf-8"?>
<Bank version="1">
<Section name="0">
<Key name="0">
<Value string="6E2I(>Z1Ekw-;.q5}vAPtM$v41'mH?wWRfuTDhr@>=tcyolzBx"/>
</Key>
</Section>
</Bank>
As you can see xml tags takes a lot of space. Aditional to it we can't create uncompresed strings larger than 100 char becouse of trigger execution time limit.... so we need to create aditional key for every 100 uncompresed chars so it takes more space for xml tags... i think of a solution to remove one character from base coding and use it as a separator so i can store multiple 100 char stings into one big string without geting to trigger time execution limit.
@Zaratulius: Go
That's the way to go. I forgot that these strings will be of variable length, so yea you probably will have to use one char as a delimiter. I suggest using one of the special chars like |!"ยง$%&/()=? and not an alphanumeric char.
I think after using this trick there will be no better way to store variables in bank files. Maybe you can add support for it in your library?
IANA leet hax0r, but, afaik, this encryption method is solid. He's essentially using the custom key that the mapmaker chooses as the pad for the encryption. As long as your maps aren't available in an unprotected format, this should work fine.
edited to say what I meant.
awesome work on the library. I'm assuming you run into problems when storing floating point numbers? Do you have a lossless system for storing them? Do you have any accuracy info on them, or do they remain uncompressed.
If you are playing the map, it IS available.
There are no real floating point numbers in Galaxy. The real are just normal integers divided by 4096. So storing them loss-less is not a problem.
oh really??? I did not know this... good to know though. Thanks for the info!