Hello! I love working with cloud variables, but most of the time they get a little weird and mess up or what I like to call it, corrupted. Let's say you have a 600 character jumble of level data that you would like to upload for all to see. An encoder would have to encode it into numbers, so that would make 1,200 more characters in the cloud variable. What if the project gets front paged? Tons of users would want to upload their levels. If 50 users upload a level, that would make 60,000 characters in one cloud variable! This is where it gets out of hand. The loading function stops working and the game freezes from counting up too much without stopping in a “run without screen refresh” function. I just need to know how long one cloud variable can go.

EDIT: the information below is not really correct - the 10240 limit is only imposed by the “join” block, so it is possible to create much longer cloudvars if you set its value without using that…

The limit is not to do with cloud variables - the cloud server enforces no particular limit (though it would take longer to transfer huge lengths, of cousre). Rather, there is a general 10240 character limit on any variable (which includes cloud vars). This was added to Scratch about a couple of months ago.

That means if you end up over-running 10240 characters while encoding, you have to catch that (before it happens!) and move on to the next cloud var.

Since there are max. 10 cloud vars allowed in a project, that means you have an absolute total limit of 102400 characters in the cloud for a project…

MCAnimator3D wrote:

Hello! I love working with cloud variables, but most of the time they get a little weird and mess up or what I like to call it, corrupted. Let's say you have a 600 character jumble of level data that you would like to upload for all to see. An encoder would have to encode it into numbers, so that would make 1,200 more characters in the cloud variable. What if the project gets front paged? Tons of users would want to upload their levels. If 50 users upload a level, that would make 60,000 characters in one cloud variable! This is where it gets out of hand. The loading function stops working and the game freezes from counting up too much without stopping in a “run without screen refresh” function. I just need to know how long one cloud variable can go.

then admin must be active to convert from cloud to standard in project (like me at Claver sctatch project)(set cloud data to (null), but first add this “pages” to project)

I used some simple math to determine that the CLOUD VARIABLE LIMIT SHOULD BE RAISED!!!! First, there are about 115,000,000 projects. But you can consider that, say, 10% of projects do not have access to cloud variables use them. Then you can consider that the projects that DO use cloud variables probably only use 1 and are only ,on average, 3 digits plus (maybe to encode the username) about 18 digits which is 21 total. One digit is 1 byte, so multiply 103,500,000 by 21 and you get…
2,173,500,000!?!?!?
That's less than 2.174 GB!
So let's raise the limit to the number of cloud variables you can have!

when green flag clicked
set [cloud variable limit v] to (500)

Coolmath2046 wrote:

I used some simple math to determine that the CLOUD VARIABLE LIMIT SHOULD BE RAISED!!!! First, there are about 90,000,000 projects. But you can consider that only a small fraction, say 10%, of projects that have access to cloud variables use them. Then you can consider that the projects that DO use cloud variables probably only use 1 and are only ,on average, 3 digits plus (maybe to encode the username) about 18 digits which is 21 total. One digit is 3.32192809489 bytes, so multiply 9,000,000 by 21 and multiply the answer by 3.32192808489 and you get…
627,844,410!?!?!?
That's less than 628 MB!
So let's raise the limit to the number of cloud variables you can have!

when green flag clicked
change [cloud variable limit v] by (99999)

Yes.

Signal boost 1000000000000000%

Coolmath2046 wrote:

I used some simple math to determine that the CLOUD VARIABLE LIMIT SHOULD BE RAISED!!!! First, there are about 90,000,000 projects. But you can consider that only a small fraction, say 10%, of projects that have access to cloud variables use them. Then you can consider that the projects that DO use cloud variables probably only use 1 and are only ,on average, 3 digits plus (maybe to encode the username) about 18 digits which is 21 total. One digit is 3.32192809489 bytes, so multiply 9,000,000 by 21 and multiply the answer by 3.32192808489 and you get…
627,844,410!?!?!?
That's less than 628 MB!
So let's raise the limit to the number of cloud variables you can have!

when green flag clicked
change [cloud variable limit v] by (99999)

You are forgetting that cloud variables have to be updated over the internet, so it's the bandwidth of the servers that limits them, not the memory capacity of the servers. The more cloud variables you allow, then the more slowly the Scratch website will react to our projects and people will complain about lagging.

Also, the cloud servers don't just keep the most recent value. All previous changes are kept (for quite some time, at least), as well as who set it to that value, so that it's possible to check up on what happened to it over time.

Limit? What limit? Use lists.

TheLogFather wrote:

= = = = = = = = = =
EDIT: the information below is not really correct - the 10240 limit is only imposed by the “join” block, so it is possible to create much longer cloudvars if you set its value without using that…
= = = = = = = = = =

The limit is not to do with cloud variables - the cloud server enforces no particular limit (though it would take longer to transfer huge lengths, of cousre). Rather, there is a general 10240 character limit on any variable (which includes cloud vars). This was added to Scratch about a couple of months ago.

That means if you end up over-running 10240 characters while encoding, you have to catch that (before it happens!) and move on to the next cloud var.

Since there are max. 10 cloud vars allowed in a project, that means you have an absolute total limit of 102400 characters in the cloud for a project…

I just checked Scratch Town by @griffpatch. The length of Cloud List is 224336. How is this possible if the limit is 10240 per cloud variable?

flutehamster wrote:

Limit? What limit? Use lists.

Cloud lists don't exist yet…

So the best is to either switch vars or wait for cloud lists!

Nathan98765 wrote:

TheLogFather wrote:

= = = = = = = = = =
EDIT: the information below is not really correct - the 10240 limit is only imposed by the “join” block, so it is possible to create much longer cloudvars if you set its value without using that…
= = = = = = = = = =

The limit is not to do with cloud variables - the cloud server enforces no particular limit (though it would take longer to transfer huge lengths, of cousre). Rather, there is a general 10240 character limit on any variable (which includes cloud vars). This was added to Scratch about a couple of months ago.

That means if you end up over-running 10240 characters while encoding, you have to catch that (before it happens!) and move on to the next cloud var.

Since there are max. 10 cloud vars allowed in a project, that means you have an absolute total limit of 102400 characters in the cloud for a project…

I just checked Scratch Town by @griffpatch. The length of Cloud List is 224336. How is this possible if the limit is 10240 per cloud variable?

MathlyCat wrote:

flutehamster wrote:

Limit? What limit? Use lists.

Cloud lists don't exist yet…

So the best is to either switch vars or wait for cloud lists!

If you set a cloud var to a list, there is no limit.

set [CLOUDvar v] to (list :: list)

Nathan98765 wrote:

TheLogFather wrote:

= = = = = = = = = =
EDIT: the information below is not really correct - the 10240 limit is only imposed by the “join” block, so it is possible to create much longer cloudvars if you set its value without using that…
= = = = = = = = = =

……

Since there are max. 10 cloud vars allowed in a project, that means you have an absolute total limit of 102400 characters in the cloud for a project…

I just checked Scratch Town by @griffpatch. The length of Cloud List is 224336. How is this possible if the limit is 10240 per cloud variable?

Hmmm… maybe I should've written that ‘disclaimer’ at the top with [big] rather than [small]…

EDIT: Oh, that's better!

he hacked it. He knows how to change the code

Nathan98765 wrote:

TheLogFather wrote:

= = = = = = = = = =
EDIT: the information below is not really correct - the 10240 limit is only imposed by the “join” block, so it is possible to create much longer cloudvars if you set its value without using that…
= = = = = = = = = =

The limit is not to do with cloud variables - the cloud server enforces no particular limit (though it would take longer to transfer huge lengths, of cousre). Rather, there is a general 10240 character limit on any variable (which includes cloud vars). This was added to Scratch about a couple of months ago.

That means if you end up over-running 10240 characters while encoding, you have to catch that (before it happens!) and move on to the next cloud var.

Since there are max. 10 cloud vars allowed in a project, that means you have an absolute total limit of 102400 characters in the cloud for a project…

I just checked Scratch Town by @griffpatch. The length of Cloud List is 224336. How is this possible if the limit is 10240 per cloud variable?

MathlyCat wrote:

flutehamster wrote:

Limit? What limit? Use lists.

Cloud lists don't exist yet…

So the best is to either switch vars or wait for cloud lists!

Cloud list DOES exist- well, you can't add cloud list to a project, but you can create it using encoding and decoding. Here is a cloud list that I made: https://scratch.mit.edu/projects/104723681/

TheLogFather wrote:

EDIT: the information below is not really correct - the 10240 limit is only imposed by the “join” block, so it is possible to create much longer cloudvars if you set its value without using that…

The limit is not to do with cloud variables - the cloud server enforces no particular limit (though it would take longer to transfer huge lengths, of cousre). Rather, there is a general 10240 character limit on any variable (which includes cloud vars). This was added to Scratch about a couple of months ago.

That means if you end up over-running 10240 characters while encoding, you have to catch that (before it happens!) and move on to the next cloud var.

Since there are max. 10 cloud vars allowed in a project, that means you have an absolute total limit of 102400 characters in the cloud for a project…

Is it true that using multiple join variables will decrease the limit? I use a multiple in my project and it never wants to save cloud data that is longer than 128 digits.

Informinity wrote:

Is it true that using multiple join variables will decrease the limit? I use a multiple in my project and it never wants to save cloud data that is longer than 128 digits.

Your problem is not the cloud variable limit since 10240 characters is 10240 digits.

Kind of a necro everybody.

It's a necro party!

Let's all dress up as mummies.

I think it is possible to add a normal list to a cloud variable, so in very long cloud lists i think the game decode to a list, add to it, and encode it.

[Encode the list]

Informinity wrote:

Is it true that using multiple join variables will decrease the limit? I use a multiple in my project and it never wants to save cloud data that is longer than 128 digits.

I would guess that you're seeing a problem because you're assuming the cloudvar is numerical at some point, and using a mathematical operator on it.

Note that if you want to compare two long variables (or expressions) using the equals or greater/less than operators, you must ensure that you force Scratch to treat them as strings, rather than numerically. If you have numerical expressions on both sides of such an operator (e.g. if the expressions contain only digits, as may be the case for your cloudvars), then you need to join a non-digit onto them (same one either side, obviously) so that Scratch will compare them as strings rather than numerically.