Save/Load Minimal Codes w/ Security

[Nestharus]

So, I've been working lately on an Encoder as many of you know.

I can encode this set of data in 7 chars (norm)

Value: 1
Range: [-1000000,1000000]

Value: 500
Range: [500,1000]

Value: 100
Range: [0,100]

Value: 300
Range: [0,300]

Value: 1
Range: [0,1]

Value: 0
Range: [0,1]

Value: 7
Range: [0,16]

Value: 10
Range: [0,10]

Giving me the minimal code of FP8S6T1 using base 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ

After a check sum: 1NBD6HPOC
Scramble: 1HD27AFNB

Layered Checksum (using player hash): 27TBNALLY
Scramble: H9WKINW0

Checksum w/ Encoder Id: E0G0X14URYY
Scramble: 79ZY3NV0XDZ

So that 7 chars with just the basic code. 9 chars with basic and layered checksum (doesn't matter), but the encoder id is an additional 2 chars. Encoder id is just the struct instance that was used to generate the code (useful for backwards compatibility save/load codes, meaning if you add a few items to your map, you don't have to reset the super compact codes, you can just use an older encoder to read older codes).

So I was just wondering if anyone knew of a better way to put in the encoder or something. My current method is:

//make space for encoder id (1-8191)
//shifted (0-8190)
call bi.multiply(8191)
call bi.add(encoderId-1,0)

But that adds 2 chars ;|. That's 2 chars total for security and 2 chars total for how to decrypt, which to me is 2 too many (4 extra chars added on to the code). For all of the data encoded, this would actually be a cool save/load code: H9WK-INW0. Short and sweet ^_^.

So anyone have any ideas?

And the encryption algorithm I ran adds nothing to the code, so don't you worry over that ;p.

Am I just stuck using the encoder id, or does someone know a more elegant way of determining the version number of the code?

The code's lengths for any given version are variable, so those can't be used. The checksum can't even be retrieved without the encoder id as the checksum space allocated is different for each encoder >.>.

I'm stumped here. Without the encoder id, the map can never be updated as it would break all previous codes >.>.

How do other people store versions in their codes, like in TKoK? Or do they do it the same way, or a worse way, than my current way?

Tx ;D.

 

[Dr Super Good]

7 Characters is a bit misleading as you said your save system dynamically increases code length for big values.

Normally one uses future planning so that you allocate all the space you ever need and do not need to change code versions.

Additionally, if your code length was static (which yours may not be for big values) you can determine the length of the entered string for the version (as most likly you will have had to make the code longer).

You could try a trial and error approach to the code system by altering the hash/encoder algerthim each version so that you try multiple times (for each version supported) until it finds one which works.

The best method by far is to avoid code revisions and allocate enough space that you will never run out. If you do have to add more, you then should add enough that the code is noticably longer and thus detectibly different.

 

[Nestharus]

Well, it's all static, but the code lengths are variable ;|.

And maps like TKoK do have versions in their codes.

But hm...

Well, maybe this is a good thing, ehh

                        //make space for checksum+hashSum
                        call bi.multiply(sumMax[enc]+ps[pid]+1)
                        call bi.add(sum+ps[pid],0)
                        
                        //make space for encoder id (1-8191)
                        //shifted (0-8190)
                        call bi.multiply(8191)
                        call bi.add(enc-1,0)

I dunno though D;

I really want version control to make life easier /sad face. Just trying to interpret the code could be bad.


Maybe a code transfer system? Whenever the map is updated, people xfer their codes over to the new map?

Ehhhhhhhhhh

 

[Dr Super Good]

That is mostly how it is done, via a -load old for the next few map versions.

You could have version support as optional. As it is your code is shorter than most if you use a reasonable character set (I advise 64 character base) so if a mapper needs that functionality it can be provided.

You might also make the user remember the code version like "-load 1.1 XXXXXXXXXXXX as version numbers are far easier to remember than crazy codes (and often in the map name).

 

[Nestharus]

Dr, w/o any security, my code is 100% as small as possible given that base. I'm just using that base for testing purposes ;D. The base could be anything.

But that's a good idea Dr, that way I don't have to append the encoder to the end. They'd also only ever have to write the version # once ; ). Maybe a version # code? : O

A version # code would be 1-3 chars ^_^. They write down the code once, then in a new version, they go -load verCode code

If the verCode isn't present, it assumes latest version.