Aye, but using strings is just as good as int arrays. It's slower but it wouldn't change the end result, would it? And strings were convenient because the thing was made with banks in mind. You'd immediately have a usable string output. I thought that was pretty neat :P
I would've made things differently if I had all the neat things of vJass at my disposal.
I made this a year ago when I was still young and wild ~ and I don't think I'll rewrite it completely, as the need for it is much smaller by now.
Still, I appreciate the criticism and the links. I haven't looked at the Wc3 scene for a long time now and I love it that there's still so much stuff being made after so many years.
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 :)
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.
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 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.
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.
I just tried with 1,000,000,000 and it loaded fine.
Did you make sure to define all maximum values correctly?
How many of these (ridiculously high) values are you saving? Maybe it's the amount rather than the maximum.
Instead you can also store an index with each string.
So infront of all the information of your units, you store a number between 1 and 20, and increase this number everytime you write a new code.
Then, when loading, you can check whether the numbers are unique or whether somebody tinkered around with it.
Or you can use a different encryption key for every code, this way you can easily spot dublications are they're exactly the same string, which doesn't happen with different keys.
Well, the problem is that Starcraft maps run on a somewhat slow engine. There's nothing anyone can do about that. At some point your computer just needs too much time to write or read the save codes.
What you can do to reduce the weight on each computer is to add a small Wait command inbetween each decompression:
This is how your trigger should look, I guess. Adding a small wait makes the engine "take a breath" before continuing so it doesn't give up as quickly.
However, at some point the sheer number of units you're trying to save will make the engine reach it's limit in only a single run. At this point you have to split it up further. As I wrote in the readme, I suggest save strings that don't become greater than 100 charaters.
It is true that Starcode lost one of it's feats since Banks now don't have such a horrid limit anymore.
But it's still encrypting nicely (and less used space surely isn't too bad too) so it does bug me immensely that it doesn't work correctly sometimes.
Right, the division-by-zero bug is caused by faulty variable initialisation. That can be fixed (although should never happen in the first place).
However, there are even more severe problems. The variable arrays somehow influence the result of mathematical calculations!
Changing the default value of one of the arrays will change the result of some of these functions.
In addition at least one wrapper function magically stops working.
This is impossible since the struct and all variables have absolutely no connection to this. That can mean only one thing,
These aren't bugs caused by Starcode - they are caused by Galaxy itself or the underlying C script.
Right now my best advice is to change the variable arrays to prevent that from happening.
I see what you mean, this is indeed strange. The system should never ever divide by zero unless given bad input, which isn't the case here.
My best guess till now is that the sheer number of initializations (20000 variable sets) of the record is too much too handle. It seems to neglect Starcode's variable init then.
I'll look into it in full detail tomorrow.
@nestharus: Go
Aye, but using strings is just as good as int arrays. It's slower but it wouldn't change the end result, would it? And strings were convenient because the thing was made with banks in mind. You'd immediately have a usable string output. I thought that was pretty neat :P
I would've made things differently if I had all the neat things of vJass at my disposal.
I made this a year ago when I was still young and wild ~ and I don't think I'll rewrite it completely, as the need for it is much smaller by now.
Still, I appreciate the criticism and the links. I haven't looked at the Wc3 scene for a long time now and I love it that there's still so much stuff being made after so many years.
@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 :)
@KratsAU: Go
You can't swap values inside of the output string. They're mangled together. If it's that what you mean.
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.
@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?
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.
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.
I just tried with 1,000,000,000 and it loaded fine.
Did you make sure to define all maximum values correctly?
How many of these (ridiculously high) values are you saving? Maybe it's the amount rather than the maximum.
@jaminv: Go
Instead you can also store an index with each string.
So infront of all the information of your units, you store a number between 1 and 20, and increase this number everytime you write a new code.
Then, when loading, you can check whether the numbers are unique or whether somebody tinkered around with it.
Or you can use a different encryption key for every code, this way you can easily spot dublications are they're exactly the same string, which doesn't happen with different keys.
@jaminv: Go
Well, the problem is that Starcraft maps run on a somewhat slow engine. There's nothing anyone can do about that. At some point your computer just needs too much time to write or read the save codes.
What you can do to reduce the weight on each computer is to add a small Wait command inbetween each decompression:
This is how your trigger should look, I guess. Adding a small wait makes the engine "take a breath" before continuing so it doesn't give up as quickly.
However, at some point the sheer number of units you're trying to save will make the engine reach it's limit in only a single run. At this point you have to split it up further. As I wrote in the readme, I suggest save strings that don't become greater than 100 charaters.
@ikillforeyou: Go
Yes, definitely update to 1.4 (get it from the first post in the topic)! You probably fell victim to the Encryption bug which I fixed in 1.3 or 1.4.
It is true that Starcode lost one of it's feats since Banks now don't have such a horrid limit anymore.
But it's still encrypting nicely (and less used space surely isn't too bad too) so it does bug me immensely that it doesn't work correctly sometimes.
Right, the division-by-zero bug is caused by faulty variable initialisation. That can be fixed (although should never happen in the first place).
However, there are even more severe problems. The variable arrays somehow influence the result of mathematical calculations!
Changing the default value of one of the arrays will change the result of some of these functions.
In addition at least one wrapper function magically stops working.
This is impossible since the struct and all variables have absolutely no connection to this. That can mean only one thing,
These aren't bugs caused by Starcode - they are caused by Galaxy itself or the underlying C script.
Right now my best advice is to change the variable arrays to prevent that from happening.
@Mille25: Go
I see what you mean, this is indeed strange. The system should never ever divide by zero unless given bad input, which isn't the case here.
My best guess till now is that the sheer number of initializations (20000 variable sets) of the record is too much too handle. It seems to neglect Starcode's variable init then.
I'll look into it in full detail tomorrow.
@EarendilSphere: Go
Text is a formatted String. Images can be in Texts, but Texts are no images.