So I have hexadecimal conversion working almost correctly, it works up until the 7th character, the 8th then makes 0's from thereon.
If you could check my project and get back to me on how to fix it, it would be extremely appreciated. Thanks!

The issue occurs when I encode it using my encode block then change it to hex.

Converting this value works:
10102030405060708

But encoding this value does not:
1010203040506070809

The starting 1 has no purpose other than preventing the starting 0 being cut off during decoding.

https://scratch.mit.edu/projects/144805405/

Are you trying to use it for encoding to the cloud? If so, don't bother with converting it to hexa.

P444 wrote:

Are you trying to use it for encoding to the cloud? If so, don't bother with converting it to hexa.

I am, but it's for compression reasons. Converting it via my method can save upto 80% of space on a maxed cloud variable.

GizzB wrote:

P444 wrote:

Are you trying to use it for encoding to the cloud? If so, don't bother with converting it to hexa.

I am, but it's for compression reasons. Converting it via my method can save upto 80% of space on a maxed cloud variable.

I think I have seen a similar thread earlier, hold on, lemme check.

Edit: Nvm, it was by you xD

Scratch rounds off any number bigger then a certain value (forgot exact value). You have to work around that first.

P444 wrote:

GizzB wrote:

P444 wrote:

Are you trying to use it for encoding to the cloud? If so, don't bother with converting it to hexa.

I am, but it's for compression reasons. Converting it via my method can save upto 80% of space on a maxed cloud variable.

I think I have seen a similar thread earlier, hold on, lemme check.

Edit: Nvm, it was by you xD

Scratch rounds off any number bigger then a certain value (forgot exact value). You have to work around that first.

That's not an issue, hence me compressing it… the issue it… it's not compressing it! XD

Check your encoding then. It gives me 101 for “a”, 102 for “b”, but 10102 for ab. Which should be 101102, no?

P444 wrote:

Check your encoding then. It gives me 101 for “a”, 102 for “b”, but 10102 for ab. Which should be 101102, no?

No, the starting 1 is just to prevent 0102 becoming 102 after decoding due to scratch treating it as a number.

01 = a
02 = b
03 = c
etc.

It is removed automatically during decoding.

I've just tried changing the encoded value to 6 digits, it still cuts off…

Nope, as you can see, scratch rounds of huge numbers. You can see that happen with this project https://scratch.mit.edu/projects/144832820/
After a certain point, scratch would just use x.xe+x
There is a workaround on it, but as I said earlier, do not bother converting it to hexadecimals, as it is not worth it.
Sorry it took a while to upload the project, my internet was cut off!

Edit: wrong quote…

As long as you're building the string with join and don't try to use maths functions on it you don't have to worry about Scratch treating it as a number.

deck26 wrote:

As long as you're building the string with join and don't try to use maths functions on it you don't have to worry about Scratch treating it as a number.

I have to use the maths functions, to convert to hexadecimal

Why do you want to convert it to hex? Encoding and decoding work fine without it.

duckboycool wrote:

Why do you want to convert it to hex? Encoding and decoding work fine without it.

Compression, can get 80% compression out of it for a large string… not effective for minute amounts but when I finish it and am using over 100 characters, it would be wise to considering there is a cloud variable limit

You can use one cloud variable to do the job of many, so the limit doesn't really matter. And the number limit in cloud variables is very high, so using over 100 characters shouldn't be a problem.

duckboycool wrote:

You can use one cloud variable to do the job of many, so the limit doesn't really matter. And the number limit in cloud variables is very high, so using over 100 characters shouldn't be a problem.

It's good practice to be minimalising code, I'm a programmer myself and I find it integral to keep things as small and efficient as possible… I plan on using a BIG amount in an individual data variable which WILL exceed the limit, trust me… so I need this to work

GizzB wrote:

It's good practice to be minimalising code, I'm a programmer myself and I find it integral to keep things as small and efficient as possible… I plan on using a BIG amount in an individual data variable which WILL exceed the limit, trust me… so I need this to work

Just a thought, but if you're writing your own encoder, why stop at F? As long as it didn't somehow conflict with the needs of your project, you could take your number digits right up to Z and save even more space.

Since the cloud only lets a-f.

Go into a project and set a cloud variable to 0x then a string comprised of letters A to F.

This is also case sensitive allowing for 22 different character types.

Despicable_Dad wrote:

GizzB wrote:

It's good practice to be minimalising code, I'm a programmer myself and I find it integral to keep things as small and efficient as possible… I plan on using a BIG amount in an individual data variable which WILL exceed the limit, trust me… so I need this to work

Just a thought, but if you're writing your own encoder, why stop at F? As long as it didn't somehow conflict with the needs of your project, you could take your number digits right up to Z and save even more space.

Cloud variables can't store more than F, hence the need for hexadecimal…
That's just the hexadecimal encoder, my normal encoder is the “encode” block which uses the “dictionary” variable.
Cloud variables can store base 10, base 16 and base 22 (I'm using 16 for simplicity and compression sake) whereas the normal base is 10 (0123456789). Base 16 goes 0123456789ABCDEF and Base 22 goes 0123456789abcdefABCDEF

Despicable_Dad wrote:

GizzB wrote:

It's good practice to be minimalising code, I'm a programmer myself and I find it integral to keep things as small and efficient as possible… I plan on using a BIG amount in an individual data variable which WILL exceed the limit, trust me… so I need this to work

Just a thought, but if you're writing your own encoder, why stop at F? As long as it didn't somehow conflict with the needs of your project, you could take your number digits right up to Z and save even more space.

I don't think you can store letters past F in cloud variables.

GizzB wrote:

Cloud variables can't store more than F

Ah, I didn't know that.

But this…

GizzB wrote:

whereas the normal base is 10 (0123456789). Base 16 goes 0123456789ABCDEF

lol