Topic Information

Cloud Variables Limited to 128 Characters Now? by MCAnimator3D in Advanced Topics

Posts: 459

1: MCAnimator3D wrote at 10:15:32 PM 12/2/20182990806
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.
2: novice27b wrote at 11:50:23 AM 13/2/20182991209
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.
3: dude341 wrote at 8:03:09 PM 13/2/20182991583
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.
4: asivi wrote at 9:28:07 PM 13/2/20182991729
I'd say it is currently working.
5: frodewin wrote at 9:31:35 PM 13/2/20182991738
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*
6: awesome-llama wrote at 8:05:39 AM 14/2/20182992066
That is not good. Such a shame. So many projects rely on large cloud data strings, and now they cannot save.
7: TheGamer- wrote at 5:56:16 PM 14/2/20182992488
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.
8: TheLogFather wrote at 6:23:20 PM 14/2/20182992519

>>> 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…



9: TheLogFather wrote at 6:47:39 PM 14/2/20182992540
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…



10: TheGamer- wrote at 6:49:01 PM 14/2/20182992542

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.
11: jokebookservice1 wrote at 10:21:06 PM 14/2/20182992748
Perhaps cloud variables supporting text (in the future) could make up for this restriction, at least a little?
12: GreenScripter wrote at 12:52:09 AM 15/2/20182992878
I wonder how many projects this just broke. Any high score lists, just about anything other than a basic click to up the number.
13: DatOneLefty wrote at 2:10:22 AM 15/2/20182992928

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.
14: TheGamer- wrote at 11:28:52 AM 15/2/20182993125

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.
15: jokebookservice1 wrote at 12:55:05 PM 15/2/20182993204
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..
16: TheGamer- wrote at 1:02:53 PM 15/2/20182993215

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…
17: jokebookservice1 wrote at 1:19:33 PM 15/2/20182993231
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.
18: TheLogFather wrote at 1:38:22 PM 15/2/20182993240
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…)

19: jokebookservice1 wrote at 1:50:20 PM 15/2/20182993253
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
20: jokebookservice1 wrote at 2:41:25 PM 15/2/20182993281

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.