Well, i'm not talking about super Scratchers lol i`m talking about Scratchers and Organizations that can probe(demonstrate?) who they are and are able to show the ST a complete dossier about their purpose and how their are instructive(or even just funny) for the Scratch community, then MIT evaluates it and decide. Sorry again if i cannot explai it well.

asivi wrote:

Well, i'm not talking about super Scratchers lol i`m talking about Scratchers and Organizations that can probe(demonstrate?) who they are and are able to show the ST a complete dossier about their purpose and how their are instructive(or even just funny) for the Scratch community, then MIT evaluates it and decide. Sorry again if i cannot explai it well.

I would Herby Argge with you

asivi wrote:

Well, i'm not talking about super Scratchers lol i`m talking about Scratchers and Organizations that can probe(demonstrate?) who they are and are able to show the ST a complete dossier about their purpose and how their are instructive(or even just funny) for the Scratch community, then MIT evaluates it and decide. Sorry again if i cannot explain it well.

I think you and @gor-dee have the same idea: To create a approved status that proves Scratchers are using Cloud Data constructively. The status' name isn't really that crucial but a ‘Super Scratcher’ fits the idea….

gor-dee wrote:

Yes, you have New Scratcher and Scratcher status, why not Super Scratcher!

littlebene wrote:

asivi wrote:

Well, i'm not talking about super Scratchers lol i`m talking about Scratchers and Organizations that can probe(demonstrate?) who they are and are able to show the ST a complete dossier about their purpose and how their are instructive(or even just funny) for the Scratch community, then MIT evaluates it and decide. Sorry again if i cannot explain it well.

I think you and @gor-dee have the same idea: To create a approved status that proves Scratchers are using Cloud Data constructively. The status' name isn't really that crucial but a ‘Super Scratcher’ fits the idea….

gor-dee wrote:

Yes, you have New Scratcher and Scratcher status, why not Super Scratcher!

I would agree to this.

jromagnoli wrote:

I would agree to this.

Me too. Or at least a variation. What about a forum like the ‘Propose Projects to be Featured’ studio?…

jromagnoli wrote:

littlebene wrote:

asivi wrote:

Well, i'm not talking about super Scratchers lol i`m talking about Scratchers and Organizations that can probe(demonstrate?) who they are and are able to show the ST a complete dossier about their purpose and how their are instructive(or even just funny) for the Scratch community, then MIT evaluates it and decide. Sorry again if i cannot explain it well.

I think you and @gor-dee have the same idea: To create a approved status that proves Scratchers are using Cloud Data constructively. The status' name isn't really that crucial but a ‘Super Scratcher’ fits the idea….

gor-dee wrote:

Yes, you have New Scratcher and Scratcher status, why not Super Scratcher!

I would agree to this.

Me Of Course, too.
They Could help a lot

I think there's a problem with the idea of a ‘Super Scratcher’ status…

One of the principles of Scratch that I feel is quite important is accessibility – that anyone should potentially be able to take a project they see uploaded to the website and recreate it for themselves. I think it should be rare for there to be projects that exist which don't allow that. (Yes, I'm aware I've shared a handful like that in the past, with external cloud servers, but I tried to do it quite sparsely, and for a specific and unusual purpose – and it was nowhere near as many as the various possibilties I had in mind!)

The Scratcher status is one which anyone can obtain with a relatively small amount of effort, and thereby have the potential to use all the available features of Scratch to create projects just as everyone & anyone else. But if it's only the ‘Super Scratchers’ who can use a certain ‘level’ of cloud in their projects, and only verified ‘institutions’ (or whatever) can access this status, then I can see it being annoying for the vast majority of Scratchers who try to emulate such projects.


I can understand why the ST have put the 128-char limit in place, given the longstanding performance issues there have been with the cloud systems (though I don't see why it couldn't still allow for hex strings…?)

I do think 128 digit-only chars is a little restrictive, since just encoding a username with a standard 2-digits-per-char encoder can take up to about a third of that space, and making a smooth & reliable near-real-time multiplayer game likely requires a ‘buffer’ of a second or so of player data, meaning it's hard to fit the username & all of such a stream of data into one cloudvar – so the in-game user limit on a project reduces from ten to probably five or so.

I also think it's possible this new restriction could backfire a bit in some cases, since Scratchers will just decide to use multiple cloudvars to hold data, instead of just one – and that means multiple separate change requests per ‘frame’ instead of just the one, and that, in turn, means a bit more stress on the servers…


I still think a part of a more robust solution would've been to implement something like I suggested in https://github.com/LLK/scratch-flash/issues/973 where cloudvar changes are ‘queued’, and then lumped together into a single request (and broadcast to users) at intervals (with only the last of multiple changes to the same cloudvar being sent).

TheLogFather wrote:

One of the principles of Scratch that I feel is quite important is accessibility – that anyone should potentially be able to take a project they see uploaded to the website and recreate it for themselves.

I can see that,,,, How about this idea: For Scratchers to have limited access to the Cloud Data only through one or two projects. That way they can create anything, not everything….

I agree with @TheLogFather with regard to the idea of users having special privileged access to cloud. I also thought the same about how multiple updates could result in more stress… But all these arguments are a little theoretical as they depend on what the real issue is and where (platform wise).

I guess the problem is that whatever feature is given to the scratch community, you have to expect that it will be used in every possible way and far beyond what was ever intended .

I don't see that the change would stop two time chat rooms in the slightest, but they do prevent the storing of data.

I too wish the limit has been perhaps even 256 characters instead of 128… Just to make real time games a little more flexible, or perhaps allowing ASCII in that 128 letters? I dunno… The reward is getting too small for the effort when it comes to larger scratch projects . And certainly 99% of kids have no chance of being at the level to understand the scripting required to achieve it, which is the whole point of scratch? It's all a bit backwards! But really… What can you do! I could see a score table system working, but that doesn't help with much else.

Even if there was a way of getting the user name of the last person to update a certain cloud variable, that would help a lot as then we wouldn't have to encode and decode the user names and the would be a lot more room in the cloud variable for other stuff?

griffpatch wrote:

I agree with @TheLogFather with regard to the idea of users having special privileged access to cloud. I also thought the same about how multiple updates could result in more stress… But all these arguments are a little theoretical as they depend on what the real issue is and where (platform wise).

I guess the problem is that whatever feature is given to the scratch community, you have to expect that it will be used in every possible way and far beyond what was ever intended .

I don't see that the change would stop two time chat rooms in the slightest, but they do prevent the storing of data.

I too wish the limit has been perhaps even 256 characters instead of 128… Just to make real time games a little more flexible, or perhaps allowing ASCII in that 128 letters? I dunno… The reward is getting too small for the effort when it comes to larger scratch projects . And certainly 99% of kids have no chance of being at the level to understand the scripting required to achieve it, which is the whole point of scratch? It's all a bit backwards! But really… What can you do! I could see a score table system working, but that doesn't help with much else.

Even if there was a way of getting the user name of the last person to update a certain cloud variable, that would help a lot as then we wouldn't have to encode and decode the user names and the would be a lot more room in the cloud variable for other stuff?

I Agree too, now. Forgeting what i said before. This is correct.
(I'm Blueparrot18)

^ (re: @griffpatch) We could have a special list block which stores both recent changes to a cloud variable; and those who made it. This would make leaderboards great!

(last 25 to change [☁ highscore v] with offset (0) :: list)
(last 25 values of [☁ highscore v] with offset (0) :: list)

Trouble is, this is a first class list, which is ScArY and not something Scratch supports. Perhaps these blocks could have a special, new shape, and could be dragged in place of the dropdowns for the names of lists

EDIT: This would be perfect for an extension; which could then have a new category which copies the list blocks, but exclusively for the cloud variable stuff

jokebookservice1 wrote:

^ (re: @griffpatch) We could have a special list block which stores both recent changes to a cloud variable; and those who made it. This would make leaderboards great!

(last 25 to change [☁ highscore v] with offset (0) :: list)
(last 25 values of [☁ highscore v] with offset (0) :: list)

Trouble is, this is a first class list, which is ScArY and not something Scratch supports. Perhaps these blocks could have a special, new shape, and could be dragged in place of the dropdowns for the names of lists

EDIT: This would be perfect for an extension; which could then have a new category which copies the list blocks, but exclusively for the cloud variable stuff

I agree that would work quite nicely, if the Scratch Team want to continue to support that use case. I guess we'd have to wait for 3.0 to be released to get it though.

The problem is that if scratchers can get access to the value in the score table, then a chat could be implemented? I was even wondering whether score board were such a desired prevalent feature that they might be implemented with a single block saying “record high score for user (score)”. Then you could either have a high score table reporter that is like a read only list reporter, or even a new pane in the scratch projects web page (like the information pane) that displays high scores (if the high score block is used).

So if I understand you correctly, “record high score for user (score)” would remove the previous entry for the user and then place them into the correct slot (i.e. the list would be ordered), along with their value. The obvious question is, what is the maximum size for a score to keep things secure?

Also, as @_nix mentioned earlier, you can always just make a cloud chat without any memory. Using the high score system, you could at least give the system a bit of memory (where you can remember the order in which the most recent messages from each user were sent – by attaching an ID to the “high score” which in our positional notation makes smaller numbers seem “worse scores” than bigger numbers; and maybe what the content of the message was if the size of the score is big enough). Sure, you can only store about 1 message per user… but if you don't care that the memory isn't perfect, you can quite easily break the rules.

I think placing all these restrictions on these cloud variables isn't going to be able to stop those who wish to make cloud chats; not without hindering the possible creativity that could've come from other uses of cloud variables (e.g., one solution is to remove cloud variables in their entirety…)

EDIT: Why not tell us that you didn't like whitelisted cloud chats… all of the Scratch Team used to say that whitelisted chats were fine… and I haven't seen an official announcement [except, perhaps, here] that tells us that we should stop.

I've updated my own highscore engine using 4 cloud variables. It can store the top ten scores and usernames which seems reasonable to me (but I come from and era where top 3 was the norm with a 3 letter “name”)
I also have a database project that I thought would be ruined but I think I can see a possible answer (not tried it yet). As people add things to the database they are stored in the cloud variable. When the variable is approaching the 128 limit the project can ask the user to leave a message. Then the owner of the project can transfer the data into a list and save and clear the cloud variable. Now some of the data is stored in a list and more new data can be added to the cloud variable. Ok, not ideal and it won't work for everything but it could help???

gor-dee wrote:

I've updated my own highscore engine using 4 cloud variables. It can store the top ten scores and usernames which seems reasonable to me (but I come from and era where top 3 was the norm with a 3 letter “name”)
I also have a database project that I thought would be ruined but I think I can see a possible answer (not tried it yet). As people add things to the database they are stored in the cloud variable. When the variable is approaching the 128 limit the project can ask the user to leave a message. Then the owner of the project can transfer the data into a list and save and clear the cloud variable. Now some of the data is stored in a list and more new data can be added to the cloud variable. Ok, not ideal and it won't work for everything but it could help???

This would be awesome, but you could also have your own serve do the notifying for you. I'm sure the ST won't mind you reading the cloud variables every five minutes?

EDIT: and tbh, having a script do the saving would be super awesome too…

griffpatch wrote:

Even if there was a way of getting the user name of the last person to update a certain cloud variable, that would help a lot as then we wouldn't have to encode and decode the user names and the would be a lot more room in the cloud variable for other stuff?

Yes, having the username for the most recent cloudvar update would help reduce the impact of the new limit for attempts at near-real-time multiplayer.

Perhaps something a bit like:

([username v] for [☁ cloudvar v]) // left dropdown has choices "username" and "time"

If the username and time could be as recorded by the cloud server itself (rather than the client), that would be an extra bonus (since it would then be possible to check that a cloudvar change made by the project did actually get to the server).

The “time” could be a time in seconds since the most recent change (or some universal server time-stamp, if there's a clear way to define it). Having that time from the server's point-of-view would require adding a server time-stamp to cloudvar updates (along with a way to get the time-stamp from the server at the start of a project, or when it's first loaded, in order to provide a reasonable initial synchronisation with the machine's local time), as well as having the server send ‘self-changes’ back to the originating client (so the username & time get updated).


As for per-user variables, well, we've been here before, of course…

^ I suggest having the timestamps be

(days since 2000)

TheLogFather wrote:

griffpatch wrote:

Even if there was a way of getting the user name of the last person to update a certain cloud variable, that would help a lot as then we wouldn't have to encode and decode the user names and the would be a lot more room in the cloud variable for other stuff?

Yes, having the username for the most recent cloudvar update would help reduce the impact of the new limit for attempts at near-real-time multiplayer.

Perhaps something a bit like:

([username v] for [☁ cloudvar v]) // left dropdown has choices "username" and "time"

If the username and time could be as recorded by the cloud server itself (rather than the client), that would be an extra bonus (since it would then be possible to check that a cloudvar change made by the project did actually get to the server).

The “time” could be a time in seconds since the most recent change (or some universal server time-stamp, if there's a clear way to define it). Having that time from the server's point-of-view would require adding a server time-stamp to cloudvar updates (along with a way to get the time-stamp from the server at the start of a project, or when it's first loaded, in order to provide a reasonable initial synchronisation with the machine's local time), as well as having the server send ‘self-changes’ back to the originating client (so the username & time get updated).


As for per-user variables, well, we've been here before, of course…

Yes, something like that would do the job. Put it in the new cloud extension along with the new high-speed table blocks

When you say per user variables, well that's not what I was getting at here. My idea was, yes to store a players score against their username, but that the project does not have the ability to read it back, only a block to store it. Scratch or the scratch web page is responsible for maintaining the high score table, ordering it, and displaying it. Perhaps there could be a scratch block for configuring it (specifying sort order), and perhaps clearing it down to (n) places, including 0 to reset the whole thing.

Just trying to think of ways to stop it being abused

Well, that my idea of a project down the drain. What about Cloud Lists (which can only store numbers, but that can still be used for chats ) ?