Optimising storage space when saving

[Magnogen]

Currently, "values" saves as a list of 10 booleans - perhaps they could instead be saved as a 10-bit number, (between 0 and 1024) and then unpacked to become a list again for usage?

There sure are a lot of those "values" keys in the saves, and this method could definitely store it more compactly. And with bitwise, reading and writing couldn't be simpler or faster!

Potentially, it would go from [false,false,false,false,false,false,false,false,false,false] to 0 (best case scenario), and [true,true,true,true,true,true,true,true,true,true] to 1024 (worse case scenario - less than a 12th of the size!).

Maybe there are a few other things the saves could optimise too, but I'm not sure how it works without taking a closer look... What do you think?

[Magnogen]

I've been reading the huge todey file from line 9082 onwards, and I think I might be able to do a PR to implement this kind of thing - if that's okay with you?

[TodePond]

I think it's ok - 10kb isn't very big really, and it just does JSON.stringify and JSON.parse on any data we need to keep. Any additional steps might complicate things and make future changes harder, but you're welcome to do a PR of course - I'll need to be careful around it though

[Magnogen]

Haha fair enough - I can understand why you'd want to keep it simple, given how horrendously complicated it already is. I'm curious though - why did you choose to store colours and channels as arrays of booleans, when only one index could be made true at any time? Wouldn't it be easier to use that index?

[TodePond]

Any value can be true, eg: a range of colours.

[false, false, false, true, true, true, true, true, false, false]

And the backend also supports more gappy colours, eg:

[false, false, false, true, false, true, false, true, false, false]

[Magnogen]

Ooooh of course... That didn't even cross my mind - brilliant! Thank you

[TodePond]

It's fine :)