Change the maximum for the last integer you read in the "Example Usage" trigger from 17500 to 232.000.000 and the maximum for the first integer you read from 17500 to 232.000.000 the final result is 466 and not 18500.
I just tried it again with a fresh downloaded version of the example map you added in the first post.
I see. It worked for me because I was using the last slot. I'll see if that problem can be fixed.
In the end you still need to know the integer bounds, the alphabet and the encryption key. Without that this app is useless for cracking.
This isn't meant to crack anything. In fact, I am only interested in the compression aspect, so the .NET library does not contain any encryption functions. It's only meant to allow you use the Starcode compression outside of Starcraft for your own bank files. So yes, you will need to set the proper alphabet and bounds before compressing.
The problem is that my functions only work with multiplicands of max. 230,000,000. After that they overflow.
I initially did that so I could still use some integer arithmic and not have to completely rely on string arithmic. Complete string arithmic would make Starcode much slower.
So no - I won't fix that because it's technically not broken :p
If you REALLY need to store this large numbers then I suggest just dividing them by 10 before storing them, and multiplying by 10 after retrieving. You'll lose some accurcacy, but with these numbers it shouldn't really matter.
The biggest number I am storing is the credits for the player, I am shure they mind if it looses some accuracy ;) I would recommend to add this to the readme since it cost me hours to figure out it was Starcodes fault.
I will just do VAL = (VAL / 1000) + (VAL MOD 1000) and save (VAL/1000) and (VAL MOD 1000) in seperate variables.
so i've started using banks for a player ranking/ladder system
incorporated starcode because even tho i know hacking banks can be done effortlessly by people who know what they are doing. this atleast stops most people from cheating. that and when blizzard finially lock maps properly it should be fullproof. so i may aswell do it now.
anyway. i've been having some problems with data being corrupted.
i've just set the encryption alphabet back to default and it seems to be going fine.
i had changed it (i didn't touch the first set of numbers) because i read somewhere it'd help with bank security.
i've combed through my triggers a million times and can't find a reason for the corruption other than this.
Hey guys, is the encryption in Starcode working correctly? I tried to encrypt the same number using two different passwords but it resulted in the same encryption string.
Perhaps I am doing something wrong, or there is a specific password length required?
I'm pretty sure the encryption is working. Two different passwords should basically never generate the same encryption string.
You sure you didn't accidently encrypted it with the same password?
The output string is too short. The encryption works by shifting single digits according to the password.
It's not strong password protection by any means, it mainly serves obfuscation.
"60" and "Test"
"60" and "Test12342435235"
They will create the same output, because the output is 2 digits long and the first two digits of the password are the same for both tests.
"60" and "xyaaa"
"60" and "yxaaa"
That'll generate completely different output, for example.
That was the other question I had, can you change the length of the output? I might just use kyrptolib or something if i do encryption instead, I wanted to avoid people being able to swap encrypted values, which isn't really possible with your library because of the short encrypted string.
But I might just use signature anyway since they are *apparently* secure now
Use blizzards signature either way, and use star code if you need compression imo.
It depends on what your bank is for though, if it's nothing that actually effects the game, i.e personal stats, then I'm not worrying too much about encryption.
Hey, im interested in saving integer values potentially in the thousands. I was wondering just how many integers can you save in a bank file using this compression? There is probably an answer in the 135 posts but im too lazy to look through them all so i made this post.
If you've already published a map and people have used your banks (using the encryption key and order of variables in version 1 of your map) and now you want to publish version 2 of your map which contains more information in the bank, do you store that in a separate key value? So in other words for every public update you make to your map, you have to add a new key and store your new strings in a new StarCode string...is this correct? Or if you simply add integers to the end of your existing StarCode string, will that work okay without breaking old values?
You can do both.
Extending the string you already use is a bit tricky. You have to check whether the bank string is of the old or new scheme and decrypt it accordingly, then you can rewrite it in the new scheme when you save all data.
It's easier to just create a second string.
You can also think ahead and simply pre-create storage by saving integers that you don't actually use. When you need them you don't have to update anything. It's useful to know what kind of values you want to save then, though.
Sorry for the (very late) respone. I stope it still helps you or someone else :)
I had the same problem as jcraigk. What I did was use a different key for the new scheme. When loading bank data, I will first check if the player has a key from the old scheme. If so, load the data from the old key. When saving, save to new key and remove the old key.
A couple weeks after publishing the new scheme, I get rid of the old scheme loading.
There are actually some really good encryption algorithms for wc3 that you could use in this (granted you rewrite them in Galaxy or w/e). There are also some new compression techniques =).
Also, it might be smart to run this on something like a BigInt. Rather than doing math with strings, you can do it with arrays digit by digit ; ). That'll truly pack as much data as possible into the code ; P.
Furthermore, look at Encoder's tree structure. StarCode could be drastically improved by moving to a tree structure =).
And Scrambler would work on numbers like 60 with passwords that were the same towards the start ;P. It also scrambles better since it scrambles in a set of different bases.
There are still many improvements that can be made to your resource ;p.
@xorpwnz: Go
That sounds really helpfull for modifiying banks for maps that use starcode....
I see. It worked for me because I was using the last slot. I'll see if that problem can be fixed.
In the end you still need to know the integer bounds, the alphabet and the encryption key. Without that this app is useless for cracking.
This isn't meant to crack anything. In fact, I am only interested in the compression aspect, so the .NET library does not contain any encryption functions. It's only meant to allow you use the Starcode compression outside of Starcraft for your own bank files. So yes, you will need to set the proper alphabet and bounds before compressing.
Alright, got it.
The problem is that my functions only work with multiplicands of max. 230,000,000. After that they overflow.
I initially did that so I could still use some integer arithmic and not have to completely rely on string arithmic. Complete string arithmic would make Starcode much slower.
So no - I won't fix that because it's technically not broken :p
If you REALLY need to store this large numbers then I suggest just dividing them by 10 before storing them, and multiplying by 10 after retrieving. You'll lose some accurcacy, but with these numbers it shouldn't really matter.
The biggest number I am storing is the credits for the player, I am shure they mind if it looses some accuracy ;) I would recommend to add this to the readme since it cost me hours to figure out it was Starcodes fault.
I will just do VAL = (VAL / 1000) + (VAL MOD 1000) and save (VAL/1000) and (VAL MOD 1000) in seperate variables.
hm
so i've started using banks for a player ranking/ladder system
incorporated starcode because even tho i know hacking banks can be done effortlessly by people who know what they are doing. this atleast stops most people from cheating. that and when blizzard finially lock maps properly it should be fullproof. so i may aswell do it now.
anyway. i've been having some problems with data being corrupted.
i've just set the encryption alphabet back to default and it seems to be going fine.
i had changed it (i didn't touch the first set of numbers) because i read somewhere it'd help with bank security.
i've combed through my triggers a million times and can't find a reason for the corruption other than this.
where are the error messages hidden? can't find them and don't even get where in the source you use them
edit: okay found it...
Hey guys, is the encryption in Starcode working correctly? I tried to encrypt the same number using two different passwords but it resulted in the same encryption string.
Perhaps I am doing something wrong, or there is a specific password length required?
@KratsAU: Go
I'm pretty sure the encryption is working. Two different passwords should basically never generate the same encryption string.
You sure you didn't accidently encrypted it with the same password?
So the length of the password or string being encrypted doesn't matter?
Here are some tests I did, when the password is similar even if it is different, the result is the same for many of them. Am I using it correctly?
Yea kinda :D
The output string is too short. The encryption works by shifting single digits according to the password.
It's not strong password protection by any means, it mainly serves obfuscation.
"60" and "Test"
"60" and "Test12342435235"
They will create the same output, because the output is 2 digits long and the first two digits of the password are the same for both tests.
"60" and "xyaaa"
"60" and "yxaaa"
That'll generate completely different output, for example.
That was the other question I had, can you change the length of the output? I might just use kyrptolib or something if i do encryption instead, I wanted to avoid people being able to swap encrypted values, which isn't really possible with your library because of the short encrypted string.
But I might just use signature anyway since they are *apparently* secure now
@KratsAU: Go
You can't swap values inside of the output string. They're mangled together. If it's that what you mean.
what would you say is better: Use starcode or blizzards signature?
Use blizzards signature either way, and use star code if you need compression imo.
It depends on what your bank is for though, if it's nothing that actually effects the game, i.e personal stats, then I'm not worrying too much about encryption.
Hey, im interested in saving integer values potentially in the thousands. I was wondering just how many integers can you save in a bank file using this compression? There is probably an answer in the 135 posts but im too lazy to look through them all so i made this post.
If you've already published a map and people have used your banks (using the encryption key and order of variables in version 1 of your map) and now you want to publish version 2 of your map which contains more information in the bank, do you store that in a separate key value? So in other words for every public update you make to your map, you have to add a new key and store your new strings in a new StarCode string...is this correct? Or if you simply add integers to the end of your existing StarCode string, will that work okay without breaking old values?
@Kalithumos: Go
A ton. I don't know how much exactly. Integer values in the thousands isn't very much.
@jcraigk: Go
You can do both.
Extending the string you already use is a bit tricky. You have to check whether the bank string is of the old or new scheme and decrypt it accordingly, then you can rewrite it in the new scheme when you save all data.
It's easier to just create a second string.
You can also think ahead and simply pre-create storage by saving integers that you don't actually use. When you need them you don't have to update anything. It's useful to know what kind of values you want to save then, though.
Sorry for the (very late) respone. I stope it still helps you or someone else :)
I had the same problem as jcraigk. What I did was use a different key for the new scheme. When loading bank data, I will first check if the player has a key from the old scheme. If so, load the data from the old key. When saving, save to new key and remove the old key.
A couple weeks after publishing the new scheme, I get rid of the old scheme loading.
There are actually some really good encryption algorithms for wc3 that you could use in this (granted you rewrite them in Galaxy or w/e). There are also some new compression techniques =).
http://www.hiveworkshop.com/forums/jass-functions-413/snippet-scrambler-189766/ http://www.hiveworkshop.com/forums/spells-569/encoder-3-0-1-2-a-189883
Also, it might be smart to run this on something like a BigInt. Rather than doing math with strings, you can do it with arrays digit by digit ; ). That'll truly pack as much data as possible into the code ; P.
Furthermore, look at Encoder's tree structure. StarCode could be drastically improved by moving to a tree structure =).
And Scrambler would work on numbers like 60 with passwords that were the same towards the start ;P. It also scrambles better since it scrambles in a set of different bases.
There are still many improvements that can be made to your resource ;p.