Hello.

Recently, I've been having difficulties getting a constantly updating cloud-list to pick up on more than one Scratcher viewing the project at a time.

For those who don't know what a cloud list is, see this.

I would like to have professional help on this one. This is something that goes beyond what Scratch can normally do. The project I'm having the problems with is my Cloud List Lobby, which, hypothetically, should transmit encoded cloud data between two or more Scratchers currently viewing the project. The result is a Lobby, that holds the usernames of all the Scratchers viewing the project at the same time. It's like a cloud list that keeps a tab on everyone who has viewed, but instead shows who is viewing. I've provided detailed description of two theoretical scripts in this post. Sadly, I've found out that cloud data can only update to the first user that changes it, so making this Lobby will either be impossible, or maybe the Scratch Team can change the way cloud data works to receive information from all Scratchers using it.

If this cloud lobby is successful, it will revolutionize the way we use Scratch…

Warm Regards from PZ7.

I've found cloud vars are pretty difficult to use robustly between users. Take a look at my ping test project for my attempts…

Cloud vars seem to be fine if you're only reading them - they update after not much more than a second of being changed by someone else.

But if you start to set one yourself then the updates of *all* other cloud vars becomes far less reliable, unfortunately.
With the ping test I found I had to drop back to more than a second gap between setting a cloud var, otherwise you often don't see changes to *any* other cloud vars.

Even then the update time appears to ‘drop off a cliff’ - something like two or three seconds before you see another cloud var has changed.
It means if you try to implement some kind of mutex locking (to prevent two players updating something at the same time), you have to set your lock value and check it again several times over about three seconds to be sure you really have it to yourself. And then you finally get to make the change you originally wanted (and it's another two or three secs before someone else sees that change…)

Not much hope for real-time multiplayer games, unfortunately…
(Unless it's just something more simple like taking turns, for example.)

DadOfMrLog wrote:

…
Cloud vars seem to be fine if you're only reading them - they update after not much more than a second of being changed by someone else.
…
But if you start to set one yourself then the updates of *all* other cloud vars becomes far less reliable, unfortunately.
With the ping test I found I had to drop back to more than a second gap between setting a cloud var, otherwise you often don't see changes to *any* other cloud vars.
…

So the only problem I'm facing is the timing? As long as changes to the cloud data are timed one or more seconds apart, then the cloud data would update to several users. And I have implemented locking the data to only one user. If an update number coincides with your viewing ID, then you'll have access to the cloud data, but after a set time has past and the cloud data is not in use.