SeeGe24 wrote:

Stop saying bump!

scratchinghead wrote:

I don't see any duplication to this, so yeah, I made this guide.


What is cloud data?

Cloud data is a feature in Scratch 2 that allows for data from a project to be saved and shared online. You can use cloud data to make surveys and other projects that store numbers over time.

Who can see the data stored in cloud data?

When you interact with a project using cloud data blocks, your information can be stored along with your username, and others can view it. Each project keeps a log of who interacted with it and any data they shared.

Why is cloud data currently limited to only numbers – with no strings or lists?

The current site is limited to numbers in variables as an initial step to work out any issues with their use on the site. Scratch Team plan to roll out cloud data features incrementally. If the infrastructure is working well, they plan to add other features (cloud lists, support for strings, etc.).

If I see someone post inappropriate content using cloud data, how do I report it?

Click the “Report this” button (under on the project player) to report inappropriate content in cloud data. The report form includes a link to a log of all cloud data in that project and who left it - you may want to take look at it before sending your report. Make sure that you mention “cloud data” when you type your reason in the report.

Can I make chat rooms with cloud data?

While it is technically possible to create chat rooms with cloud data, they are not currently allowed. The Scratch Team will reconsider this policy once they have a better sense of our capability for moderating and managing reports on cloud data.

How do I add a cloud variable when I'm making a project?

When you make a variable, you can check the box that says “Cloud variable.” Any data you store will be saved on the server and visible to others.

Who can change the information in a cloud variable?
Only your project can store data in its cloud variable. If people change or remix your code, it creates a different variable in their project with the same name.

I am logged in, but I still cannot use projects with cloud data. What is going on?

You need to have become a “Scratcher” on the website to have access to cloud data. You can become a Scratcher through actively participating on the website. Check out this guide to see how to become a scratcher. https://scratch.mit.edu/discuss/topic/34888/

Is it possible to make multiplayer games with cloud data?

Multiplayer games may be difficult to create, due to network speed and synchronization issues. However, some Scratchers are coming up with creative ways to use the cloud data for turn-by-turn and other games.

How long does it take for cloud data to reach another Scratcher?

It depends. If both Scratchers have a reasonably fast Internet connection (DSL/Cable), and there are no restrictive firewalls on the computers/network, updates should be transmitted in milliseconds. However, a lot of computers have firewall software running in them, and if the firewall software blocks outgoing connections to TCP port 531 and TCP port 843, the time-lag becomes one-second. Scratch Team are currently trying to figure out ways in which they can work around this limitation.

What's the maximum amount of cloud data? And what it contains?

Currently, cloud data has been stripped down to only (up to 10) cloud variables that can contain only integers. This means that cloud variables, unlike regular variables, cannot contain letters.

What's the character limit?

A character limit of 10,240 digits per variable has also been implemented, which translates to 300.7 KB of cloud data storage per project. The Scratch Team says they want to configure the server bit-by-bit to add new features incrementally.



~Thank you for reading, if there's anything I missed, just tell me~

scratchinghead wrote:

Now, I don't know how much of it you'd want to include in the original (I've gone into probably too much detail in places), but I think some parts of it could be worth adding, in some form.

Why is cloud data currently limited to only numbers – with no strings or lists?

The current site is limited to numbers in variables as an initial step to work out any issues with their use on the site. Scratch Team plan to roll out cloud data features incrementally. If the infrastructure is working well, they plan to add other features (cloud lists, support for strings, etc.).

There's no technical reason that cloud data has only numerical values – it really doesn't need any changes to the cloud system for that – at the moment, the system is actually *preventing* non-numerical values, so it's just a case of removing that restriction.

The reason is really more to do with how easy it would then become to create chat clients. –See notes about question below for more about that…

Conversely, I think it's really, *really* difficult to see how to implement cloud lists in a way that would actually be practically useful. There's no way you would want the server to send out the whole of a list to everyone viewing the project each time someone adds/deletes/replaces/inserts just one item. But if you only send out a specific item at a time when it gets changed, the delay between one person changing it and others seeing that change would be potentially catastrophic for the syncing of cloud lists across players. (Just think what happens if one player deletes item 3 of the list, but another tries to delete item 5 of the list before they see that item 3 was deleted – what is the cloud server going to do…? It would have to somehow know that item 5 for the second player has now become item 4 of its *own* view of the list because the first player deleted item 3 *without* the second player knowing about it – and the server really has no way to know when the second player actually ‘found out’ about the deletion of item 3, so cannot tell which item the second player means by “item 5”. The only way to be sure is to send the whole list at every change – but you really don't want to be doing that all the time… :/ )

I honestly can't imagine how cloud lists could be done such that it would be reliable and efficient, given the way the majority of Scratchers would be likely to script them. And I think that's why we've never seen cloud lists, and why we're not likely to see them any time soon.


Can I make chat rooms with cloud data?

While it is technically possible to create chat rooms with cloud data, they are not currently allowed. The Scratch Team will reconsider this policy once they have a better sense of our capability for moderating and managing reports on cloud data.

Yeah… Can you imagine what would very likely happen if many Scratchers started making chat clients…? Can you see the problems that would appear as people started talking to each other on a chatting system that was moderated only by young kids…?
–Sorry, that's more of my own comment about it, and not really meant to be adding any useful info. :)


Who can change the information in a cloud variable?
Only your project can store data in its cloud variable. If people change or remix your code, it creates a different variable in their project with the same name.

This seems like a slightly odd answer (i.e. not that clear exactly what is meant). The whole point of a cloud variable is that any Scratcher running the project can change the value in the cloud. The question is asking “who”, but the answer given is in terms of “what” can change it. And even then, it's not giving any info on what the restrictions are, i.e. when the project can and cannot change a cloudvar when run by others.

I'm guessing what it needs is to say that only the project creator is able to change the cloud variable manually while the project is in editor mode (otherwise any Scratcher would be able to change it to whatever they wanted just by editing the project), and that once someone else makes a change to your cloud project then it is no longer able to change any of its values in the cloud (unless they remix, in which case it's a different project with its own cloudvars).


Is it possible to make multiplayer games with cloud data?

Multiplayer games may be difficult to create, due to network speed and synchronization issues. However, some Scratchers are coming up with creative ways to use the cloud data for turn-by-turn and other games.

Wow, where do I start with this one…?!
I think the answer is a really good summary, but it's not actually very helpful, practically. –But then to make it actually helpful does require several paragraphs, unfortunately, so not sure what to do about that.

Well, here are my thoughts, and maybe someone can ‘crystallise’ it into something more succinct… :)

First of all, I guess it depends what is meant by “multiplayer game”. That is covered a bit with the answer above referring to “turn-by-turn” games.

But most Scratchers probably think of what I'd describe as (near-)real-time multiplayer – i.e. where each player sees the movements of the other players (almost) immediately.

Such games are (at least at the moment) a practical impossibility. The main reason is to do with the way a cloud-based project ‘polls’ the cloud server about once every 1.5s for the latest cloud values. That means it's not possible for a project to receive updates to positions more frequently that that! So any other players you're watching will only get updated very ‘jerkily’, about every second or so, which is clearly no good for a real-time game!

To work around this to create ‘smooth’ player updates, you really need to store a few seconds worth of player data in a stream, and have that stored in that player's cloud variable, along with some kind of ID ‘timestamp’ for each position in the stream. Then the other players have to keep track of where they are in the stream, and work their way through it at the appropriate speed.

The delay between one person setting a cloud variable, and others seeing it, is typically one to 1.5s. Since the player interpreting the stream must have a clear (at least) 1 second of positions to work through after getting a new cloud update (otherwise they will run out before they see the next update), that means the delay is bound to be at least 2 seconds between one player moving and another seeing it.

Of course, we're all hoping the current cloud situation will change… soon…


How long does it take for cloud data to reach another Scratcher?

It depends. If both Scratchers have a reasonably fast Internet connection (DSL/Cable), and there are no restrictive firewalls on the computers/network, updates should be transmitted in milliseconds. However, a lot of computers have firewall software running in them, and if the firewall software blocks outgoing connections to TCP port 531 and TCP port 843, the time-lag becomes one-second. Scratch Team are currently trying to figure out ways in which they can work around this limitation.

Since the fast port 531 connection is now disabled, and will never return in that form (a new system is under development, based around WebSockets, I believe), the part above which mentions about the old system might as well be dropped.

Until then, that leaves the current fallback polling method, with its delay of ~1.5s between polls of the server.

See previous answer for some practical issues that causes…


What's the maximum amount of cloud data? And what it contains?

Currently, cloud data has been stripped down to only (up to 10) cloud variables that can contain only integers. This means that cloud variables, unlike regular variables, cannot contain letters.

Cloud variables can contain any *string* which the cloud server considers could be numerical – i.e. NOT just integers! That includes things like…
Floating-point values: “-036837460987.984760938706870e-8357987295” (the part within quotes)
Certain strings which have numerical values: “Infinity”, “-Infinity”, “true”, “false”
Hexadecimal (with “0x” prefix): “0x0123456789abcdefABCDEF” note that case doesn't matter, but is *remembered*!
A blank string, or even loads of spaces (it considers these to be effectively zero).
Also, leading and trailing spaces are allowed, so: “ 239872986798734968 ”

Note that the cloud server does NOT store an actual numerical value – what it stores is a *string*, so the string will not be ‘mangled’ in any way from what you set it to (i.e. leading zeros will remain, it will not turn blank/spaces into zero, it will not turn “false” into zero, etc.). But the *contents* of the string must be *considered* to be a numerical value in order for the cloud server to accept it and store.

(Also, yes, I know it's possible to circumvent the 10-cloudvar limit, but that's there for a reason, and I think it best not to draw attention to getting around it…)


What's the character limit?

A character limit of 10,240 digits per variable has also been implemented, which translates to 300.7 KB of cloud data storage per project. The Scratch Team says they want to configure the server bit-by-bit to add new features incrementally.

I guess the answer above is OK from a practical viewpoint. But the 10240 limit isn't really cloud-variable-specific, since it is applied through the “join” block. So it affects any variable if you try to set it to some expression which uses that block. (-Though it could well be that the limit was added specifically to avoid issues with having very long cloudvars?)
Again, probably best to avoid mention of the workaround for this – though I think it is relatively tedious to do, so it's not going to be something that's likely to cause widespread issues, I think…?

PLEASE NOTE…

The new cloud system is now in place, and replaces the old “fallback” cloud system.

That means some of the things written below are out of date.

The most important thing that still holds about the new system is to ensure your project does not change cloudvars too many times per second. Otherwise the cloud server can disconnect you for a while due to ‘spamming’ the connection.

How many times per second is too many…? Well, I'm not sure exactly, but I try to keep cloudvar changes in my multiplayer test project down to only ten(-ish) changes per second, and that appears to works fine. My guess would be that making 30 changes per second is too many…

Contents

1. How often to set a cloud variable
Summary: don't do it too many times per second!

2. Some things to beware of when setting a cloud variable
Summary: it can go wrong! (You often need to catch it when it does.)

3. How often to check a cloud variable's value
Summary: it doesn't matter! (But see next section for some things to avoid.)

4. Some things to beware of when checking a cloud variable's value
Summary: watch out that its value could change while using it within a loop.

5. Encoding text into a cloud value as a long string of digits
Summary: see the numerous cloud encoder/decoder projects, and cloud list projects.

6. Comparing long strings of digits
Summary: it often does not work as you expect!


Maybe there will be more points, as I think of them…

forever
do some things for this frame of the game... :: grey
set [☁ cloudvar v] to (whatever... :: grey) // Updates cloudvar many times per second, spamming cloud server
end

set [next cloud time v] to (timer)
forever
do some things for this frame of the game... :: grey
if <(timer)>(next cloud time)> then
change [next cloud time v] by (0.5) // Will only update cloud 2x per sec
set [☁ cloudvar v] to (whatever... :: grey)
end
end

set [☁ cloudvar v] to [] //  starts off empty
set [pos v] to [0]
repeat (length of (data-to-encode))
change [pos v] by (1)
find a two-digit code for (letter (pos) of (data-to-encode)) :: custom block //  for example
set [☁ cloudvar v] to (join (☁ cloudvar) (two-digit-code)) //  Very bad!! -every change gets sent to cloud server :/
end

set [temp v] to [] // construct the encoding into this variable insead
set [pos v] to [0]
repeat (length of (data-to-encode))
change [pos v] by (1)
find a two-digit code for (letter (pos) of (data-to-encode)) :: custom block //  for example
set [temp v] to (join (temp) (two-digit-code)) //  not using cloudvar, so no longer spamming cloud server
end
set [☁ cloudvar v] to (temp) //  only set cloudvar once at the end, after constructing the whole encoding

• One common reason is due to using a browser which aggressively caches the response from the cloud server. Both Internet Explorer and Edge browsers have this problem – they will *always* reset the cloud value back to what it was when you first came to the project, and it makes them effectively unusable for any cloud-enabled project (whether editing or playing). You simply have to use a different browser (such as Firefox, or Chrome, etc.)
  
  BTW, it's possible to use this ‘quirk’ to detect someone using Internet Explorer or Edge: https://scratch.mit.edu/projects/151565105/
  In fact, it's possible that someone running your cloud project with these browsers can ruin its cloud values, as the above project explains. So it's not a bad idea to actually detect this and prevent them from using the project any further (at least from doing anything that changes cloudvars).

• If you are using a sensible browser, however, then it's still possible for cloud variables to keep on reverting back to old values if the project's connection to the cloud server has timed out. This can happen if you don't use a project for an hour or so, e.g. because you're editing it. If the project does not change a cloudvar during that time, the cloud server eventually times out that project's connection, and will no longer allow any changes it sends to ‘reach’ the cloud itself. The cloudvar will simply revert back to its old value the next time the project ‘polls’ for the latest (true) cloud values (i.e. about a second later). To fix this you just need to reload the project to renew its cloud connection.

• Also, if you have a cloud-enabled project opened in more than one place as the same user (e.g. in two different tabs, or in two browsers, or two computers) then the cloud server will only accept changes to cloudvars from the *most recently opened* project. Other open instances of the same project, using the same user, will only be allowed to read the cloudvar values. That means if you are editing the instance of the project that is not the latest one you opened, then a cloudvar will revert back to its previous value right after attempting to change it.

set cloudvar to (whatever :: grey) with current value (☁ cloudvar) //  when you want to set the cloudvar
define set cloudvar to (newVal) with current value (curVal)
repeat (4) //  try four times
set [☁ cloudvar v] to (newVal) //  try setting it to the desired value
set [end time v] to ((timer)+(1.8)) //  check for 1.8 seconds after setting it
wait (0.3) secs // wait for a little bit
repeat until <not <(☁ cloudvar)=(newVal)>> //  check if its value has changed to something else
if <(timer)>(end time)> then //  all is fine - it has remained as 'newVal' for 1.8 seconds
stop [this script v] //  can finish this script now
end
wait (0.1) secs
end
if <not <(☁ cloudvar)=(curVal)>> then //  got a completely different value!
broadcast [got different cloud value v] //  probably means someone else changed it
stop [this script v] //  so get out
end
end
broadcast [failed to set cloudvar v] //  may mean bad browser, or cloud connection timed out (see text above)

set [decoded v] to [] //  start off with blank string
repeat (digit-pairs-to-decode) // or maybe repeat until it finds a specific two-digit code
set [2digits v] to (join (letter (pos) of (☁ cloudvar)) (letter ((pos)+(1)) of (☁ cloudvar))) // get 2 digits from cloudvar
set [decoded v] to (join (decoded) (letter (2digits) of (LETTERS))) //  add letter to decoded
change [pos v] by (2)
end

set [encoded v] to (☁ cloudvar) //  make a copy that we know cannot change during the loop
set [decoded v] to [] //  start off with blank string
repeat (digit-pairs-to-decode)
set [2digits v] to (join (letter (pos) of (encoded)) (letter ((pos)+(1)) of (encoded))) // get 2 digits from 'encoded'
set [decoded v] to (join (decoded) (letter (2digits) of (LETTERS))) //  add letter to decoded
change [pos v] by (2)
end

decode new cloud value (☁ cloudvar) //  send cloudvar into custom block as a parameter
define decode new cloud value (encoded)
do all the decoding in here, using (encoded) instead of (☁ cloudvar)... :: grey

if <(☁ cloudvar)=(previous value)> then //  this test may NOT do what you expect!
maybe do something here when they are equal... :: grey
else
decode new cloud value (☁ cloudvar) :: custom block
end

<[1234567890123456789000] = [1234567890123456789111]> //  Scratch says this is true!

if <(join [a](☁ cloudvar))=(join [a](previous value))> then //  ensures they are not compared numerically
maybe do something here when they are equal... :: grey
else
decode new cloud value (☁ cloudvar) :: custom block
end

EncloCreations wrote:

Basically, even thought the last movements of the opposing player will be ~1.5 seconds in the past, you would still get a mildly smooth game

DadOfMrLog wrote:

Yes, this is long – but it does also contain various scripting examples to help explain some of the points. And …

Drunken_Sailor wrote:

Why does every bump say:
“Last edited by Kaj”?

jromagnoli wrote:

Drunken_Sailor wrote:

Why does every bump say:
“Last edited by Kaj”?

Because that's part of his sig.

Drunken_Sailor wrote:

jromagnoli wrote:

Drunken_Sailor wrote:

Why does every bump say:
“Last edited by Kaj”?

Because that's part of his sig.

Oh ok.
BTW, what colour do you use for your sig?

jromagnoli wrote:

Drunken_Sailor wrote:

jromagnoli wrote:

Drunken_Sailor wrote:

Why does every bump say:
“Last edited by Kaj”?

Because that's part of his sig.

Oh ok.
BTW, what colour do you use for your sig?

probably #939393
last edited by kaj