I noticed that my Pokedex project that I made to transfer image data and stuff over the cloud stopped working. I started to test it more and realized that setting cloud variables to letters externally stopped working (which isn't too bad), but what's really concerning is that now cloud variables only save if the length is 128 or less.

Setting the cloud variable to “01020304050607080910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364” (which is 128 characters long) works and shows up in the cloud data records, but adding a “1” in front (129 characters): “101020304050607080910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364” doesn't save to the cloud server.

What I'm guessing they're adjusting cloud variables for 3.0, but I hope it doesn't stay like this.

That's a shame, it seems like they're really cracking down on “unintended” uses of cloud data. You can still work-around this by using multiple variables, or just setting the same variable multiple times.

This will ruin any cloud data project that needs to store a lot of data (e.g projects with 10 cloud variables to split all types of data across).
Hoping this is a bug. I'll ask Paddle2See.

I can confirm that cloud variables don't save to the cloud if they are longer than 128 digits. I tested with this project: https://scratch.mit.edu/projects/203898565/

But why? There are so many requests on new features in the forum and some of these requests make a lot of sense. Instead a new limit is implemented to make Scratch less useful *cries heavy tears*

That is not good. Such a shame. So many projects rely on large cloud data strings, and now they cannot save.

I really hope this is an accidental side effect of an update, but I can confirm that the limit does seem to be in place, my machine learning project is no longer updating the training data - https://scratch.mit.edu/cloudmonitor/186394410/ .

I've asked speakvisually and thisandagain about it, so hopefully one of them will reply soon.

novice27b wrote:

That's a shame, it seems like they're really cracking down on “unintended” uses of cloud data. You can still work-around this by using multiple variables, or just setting the same variable multiple times.

Those work arounds don't really work if you're dealing with a lot of data though (relatively that is), the project I linked above would need hundreds of cloud vars just to store the data for a single trained bot.

>>> Oops, nope, what I wrote below is wrong!! <<<

–


Don't panic! –The cloud variables are working just as before.

The only change is that the cloud log doesn't report changes for cloudvars when >128 characters.

You can check that it's all still working fine here: https://scratch.mit.edu/projects/24934494

As you can see, the length of the cloudvar is still more than fifty thousand digits…

OK, nope, I'm wrong.

Looks like the value of the long cloudvar in the cloud was just staying stuck at the same (long) value, since it wasn't getting updated in the cloud, only in the project.

Hmmmph!!!

That's a real nuisance…

TheLogFather wrote:

OK, nope, I'm wrong.

Looks like the value of the long cloudvar in the cloud was just staying stuck at the same (long) value, since it wasn't getting updated in the cloud, only in the project.

Hmmmph!!!

That's a real nuisance…

Yup, downloading old values seem fine, it's just updating new ones.

Perhaps cloud variables supporting text (in the future) could make up for this restriction, at least a little?

I wonder how many projects this just broke. Any high score lists, just about anything other than a basic click to up the number.

jokebookservice1 wrote:

Perhaps cloud variables supporting text (in the future) could make up for this restriction, at least a little?

that will be one fun compression algorithm to write.

jokebookservice1 wrote:

Perhaps cloud variables supporting text (in the future) could make up for this restriction, at least a little?

Not very much at all. Even if all printable characters according to python are allowed (minus a few hidden ones, eg \n), then we only have 94 characters: 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!"#$%&\'()*+,-./:;<=>?@^_\`{|}~ . This means that in 128 characters we have 94^128 different combinations = ~3.633835478324481e+252 . This is roughly the same as if we were allowed 252 characters of 0-9 (10^252 = ~1e+252) , or 210 characters of hex (16^210 = ~7.33155940312959e+252), or 188 characters of case-preserved hex (22^188 = ~2.3739086043651e+252).


Which is about equivalent to 840 characters in binary (2^840 = ~7.33155940312959e+252), or about 105 bytes.

That's not all printable characters… that's all printable ASCII characters…

EDIT: And I do believe that chr() and ord() should support the rest of unicode too..

jokebookservice1 wrote:

That's not all printable characters… that's all printable ASCII characters…

Ah I see what you mean now, so according to this we would have ~1.89mb.

DatOneLefty wrote:

that will be one fun compression algorithm to write.

I see what you mean…

It would be wonderful if Scratch had the ability to convert to and from a Unicode codepoint; because that would make the filesize of the compressor much smaller.

Note that using unicode doesn't really change how many bytes end up getting used to store data.

So if the constraint is that cloud values can only be 128 *bytes* long (and we don't know yet how this constraint is applied) then using unicode will not give any worthwhile increase in how much data can be stored in cloudvar…

It all depends how the cloud server is counting things – is it counting the length of the string using a method that understands unicode, or is it counting actual bytes (or a string-length method that doesn't know unicode, so ends up effectively equivalent to bytes)?

Since the Scratch player version has not changed (still on v459.1) since this length constraint has appeared, it would seem it is getting applied at the server end. (Interestingly, though, the github version is now on 460, but without any changes to the available code – so something has been going on…)

Scratch Cloud Vars *can* store text right now (you just have to set it externally); so we can test right now. I'll go test…

EDIT ^^^ The above is wrong!

Apparently you can no longer store text in cloud variables

Vlaros wrote:

jokebookservice1 wrote:

Scratch Cloud Vars *can* store text right now (you just have to set it externally); so we can test right now. I'll go test…

EDIT ^^^ The above is wrong!

Apparently you can no longer store text in cloud variables

It's a bit worse than that… It seems you can no longer store hex (even prefacing with 0x). https://scratch.mit.edu/projects/204260416/. Unless I've messed up somewhere in the code

I can reproduce your issue.