Now we can only use cloud variables for surveys and the worlds most basic high scores. I know I use them for very basic high scores, but it would be so cool to build your own online games.

18-2-18 11:52 AM: I've actually thought this through and this makes it safer to use scratch because people can't do horrible things such as cyber bully on chat rooms. So this actually makes it safer. So this is actually quite a good decision in my opinion.

FuturePr0 wrote:

Great, now we can only use cloud variables for surveys and the worlds most basic high scores. I know I use them for very basic high scores, but it would be so cool to build your own online games.

But the surveys wouldn't be able to prevent multiple entries from the same user. The only prevention is locally, through variables that are not reset on the press of the green flag.

I've now updated my tutorial database to store most entries locally in a list. Only new entries are stored in a cloud variable and when this gets nearly full it alerts the user to message me. I can then transfer the cloud data into the list & clear the cloud variable (automated of course) and re-save the project. This could work for quite a lot of things including long highscore lists. It's not ideal I know but for most scratchers I think it can work.

griffpatch wrote:

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

So like a write-only cloud variable, with the ordering worked out on the scratch server side? That could work, but would make it so you wouldn't be able to view the scores in the project though, unless that's not what you meant?

^ There are different ways for it to work. One way is to have a special sprite (perhaps underneath the stage) with special blocks for this feature.

You could then script it like so

when gf clicked
hide
high score sorting: [bigger v] is better ::#555555

when I receive [end of game v]
show

when this sprite clicked
render high score ::#555555

Once the “render high score” block has been invoked, you go to a screen on the project where all the scripts are paused. There are two arrows (project can't control the layout), one to go to the next page, one to go to the previous page. (If we want to allow more complicated sorting, we could have the project create a sandbox for the user-defined sorting algorithm to run.. there, no output could be displayed and it can't communicate with the original project).

Or, we could have the high score table in a seperate tab (either like the cloud logs; or, and this is my favourite, as a new section underneath “Notes and Credits”).

How the high score table is rendered is up to the Scratch Team; I personally like the idea of a hat block for sorting (run in a sandbox); but if this is too difficult, I'm perfectly happy for the sorting algorithms to just be “bigger is better” and “smaller is better”

TheGamer- wrote:

griffpatch wrote:

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

So like a write-only cloud variable, with the ordering worked out on the scratch server side? That could work, but would make it so you wouldn't be able to view the scores in the project though, unless that's not what you meant?

Like I said in an earlier post, my idea was to have a high score reporter block, like how you click on a list reporter tick box and the entire list view appears in the project? So a read only high score table could appear. You could move it around, perhaps double click it to change is rendering style (like variable reporters), resize it, and have blocks to show and hide it. In fact it really would work very much like a list, except that you can't read data from it and it does one score per player and is sorted.

^ you've got to be careful about the touching-colour block; otherwise you might be able to read off some data

This annoys me. In Scratch 3.0 they'll probably remove cloud entirely as “too hard to implement and it's taking too much CPU time anyway” >: (

While it is annoying, it is still possible to have the same features as you formerly did by writing in a backend mode of some sort. Correct me if I'm wrong but if you use cloud variables to send and receive requests between clients (users) and the server (just a dedicated computer running the “backend mode”). Basically you have the users store a request to the variable, the server takes the data and stores it, then clears the variable. The client can then send a request code of some sort which the server will read, respond to via another variable and clear. I'll try to create a proof of concept for this.

BagOfMandMs wrote:

While it is annoying, it is still possible to have the same features as you formerly did by writing in a backend mode of some sort. Correct me if I'm wrong but if you use cloud variables to send and receive requests between clients (users) and the server (just a dedicated computer running the “backend mode”). Basically you have the users store a request to the variable, the server takes the data and stores it, then clears the variable. The client can then send a request code of some sort which the server will read, respond to via another variable and clear. I'll try to create a proof of concept for this.

That is true, kind of like sending packets through the cloud (if I'm understanding correctly). Sadly I've tried it before and it works but it's extremely slow if it's handling a lot of data and many more requests are made than just the one like before the change. For smaller things like lines of text that surpass the 128 character limit, packets might be the best idea for now.

MCAnimator3D wrote:

BagOfMandMs wrote:

*clip*.

That is true, kind of like sending packets through the cloud (if I'm understanding correctly). Sadly I've tried it before and it works but it's extremely slow if it's handling a lot of data and many more requests are made than just the one like before the change. For smaller things like lines of text that surpass the 128 character limit, packets might be the best idea for now.

Yeah the biggest issues I could foresee are:
-Speed (at least four times as long to update potentially more)
-Having multiple requests at the same time (and overlapping)
-How to distribute packets to single users
-You need a server side constantly running
-You need to prevent clients from using the server mode (you have to have it in the save otherwise you can't run the server yourself, but you can't have it run automatically or let users run it or you'll double requests)

Edit: Had some ideas about potential for scratch 3.0
-Have the ability to have cloud vars cross between two or more projects
-Hiding code from public (for passwords and such) This could be problematic though as it means you can have a project that people can't remix
-Specific cloud variable types (hex, dec, string, bool, etc.)
-Limit exception requests?
I don't know, just some ideas.

Someone should make a Scratch mod that changes the cloud server to a custom server that allows strings and unlimited cloud vars.

CatIsFluffy wrote:

Someone should make a Scratch mod that changes the cloud server to a custom server that allows strings and unlimited cloud vars.

That would be nice but would require intensive strain on the host and probably wouldn't happen. What I'd like to see is an extension to host your own cloud variables easily from your own computer. This takes the strain off the scratch servers, and with a PI or something similar you could actually have more versatile data transfer (example: cloud lists).

BagOfMandMs wrote:

While it is annoying, it is still possible to have the same features as you formerly did by writing in a backend mode of some sort. Correct me if I'm wrong but if you use cloud variables to send and receive requests between clients (users) and the server (just a dedicated computer running the “backend mode”). Basically you have the users store a request to the variable, the server takes the data and stores it, then clears the variable. The client can then send a request code of some sort which the server will read, respond to via another variable and clear. I'll try to create a proof of concept for this.

For what it's relevant, this is discouraged by the Scratch Team.

thisandagain wrote:

We are very much not in favor of anyone manipulating Cloud Variable values directly using a server. This is the kind of use that has been causing a lot of headaches and maintenance problems.

BagOfMandMs wrote:

CatIsFluffy wrote:

Someone should make a Scratch mod that changes the cloud server to a custom server that allows strings and unlimited cloud vars.

That would be nice but would require intensive strain on the host and probably wouldn't happen. What I'd like to see is an extension to host your own cloud variables easily from your own computer. This takes the strain off the scratch servers, and with a PI or something similar you could actually have more versatile data transfer (example: cloud lists).

That would be cool. Support. Another possibility is the ability to directly manipulate data packets to/from the server so you can transfer positions and stuff without needing an expensive emulated packet system.

jokebookservice1 wrote:

^ I suggest having the timestamps be

(days since 2000)

That block isn't a ‘universal’ time, but dependent upon the time settings of the local machine.

If the time-stamp was returned relative to that, then it would probably be OK most of the time. But all sorts of Bad Things could happen if someone had their machine's time badly set up (say, set in the wrong time zone, or the time was out by more than a few mins, etc.), and the project relied on it for some kind of synchronisation between concurrent users.

I'd prefer if the cloud-server's time-stamp was synched against the user's machine time at project start/load (and maybe even every few mins or so after that?) – so the Scratch Player knows the difference between cloud server time and local machine time (it'll not be perfect, due to latency, etc., but it should be close enough, esp. if it's ‘corrected’ using approximately half the time between the local machine sending the request and receiving the response). And then the cloudvar change-times reported after that get worked out using that difference.

griffpatch wrote:

When you say per user variables, well that's not what I was getting at here…

Ah, yes – now that I read your first comment properly, I see it's rather different…

Still, it seems as though per-user vars would provide some of the desired functionality that has now been removed from cloudvars (i.e. the ability to store data for lots of users).

The main thing that would still be missing, when used within a specific project instance, would be a way to recover info for a *different* user (e.g. if the project wants to display a hi-score table, or pins on a map, then it needs to get the data for other users, and that means somehow being able to get a list of users that have entries, etc. – and then that raises the question of whether & how a project is able to change the stored list of users, as well as the data for these other users…?)


I can see the possibility, then, for this to expand into having several ‘types’ of ‘in-cloud’ variables specifically for different use-cases… one type for hi-score tables, another type for per-user storage, another for temporary ‘transactions’ of data between users currently on a project (i.e. current ‘short’ cloudvars), perhaps even yet another for ‘voting’ systems……

Hmmm… no… I'm starting to un-like the sound of this…

griffpatch wrote:
…my idea was to have a high score reporter block, like how you click on a list reporter tick box and the entire list view appears in the project… In fact it really would work very much like a list, except that you can't read data from it and it does one score per player and is sorted.

jokebookservice1 replied:
^ you've got to be careful about the touching-colour block; otherwise you might be able to read off some data

Touching blocks can't see anything of var/list/other watchers, only from backdrop/pen/sprites (& video), so I don't see this being an issue.

Hasanmajid10 wrote:

…What about Cloud Lists (which can only store numbers, but that can still be used for chats ) ?

BagOfMandMs wrote:

…you could actually have more versatile data transfer (example: cloud lists).

I've mentioned a couple of times in the past that there are reasons why I've not expected to see cloud lists appearing in Scratch anytime soon – and I've yet to see anyone actually recognise or address the practical difficulties that arise when attempting to implement such a thing.

I find it really hard to see how some of the list operations (adding/removing items) could be reliably synched across users (who could be performing ‘clashing’ operations at almost the same time) unless the whole list was being treated like a single massive cloudvar for each and every list change operation – and that ain't gonna happen given that we're still stuck with (in theory) only ten cloudvars, and now had to restrict even those to only 128 chars to prevent ‘cloud-server meltdown’…

If anyone has some inspiration how to create a reliable cloud list system, that doesn't fall foul of latency over the ‘net, and doesn’t potentially send shed-loads of data at every change, I'm sure the Scratch Team would be all ears.

BagOfMandMs wrote:

-Hiding code from public (for passwords and such)

I think we've been here before…

https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/topic/263069/ | https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/topic/262898/ | https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/topic/229336/ | https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/topic/206014/ | https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/topic/119372/ | https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/topic/71034/ | https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/topic/44052/ to name but a few…
(Hint: there's no need to hide code for a password, only to avoid using the password itself in the code, which can be done in various ways, for example, through a hashing technique – and I have a demo project here that can easily be imported into a project, since it's pretty much a single fairly short script.)

jokebookservice1 wrote:

^ you've got to be careful about the touching-colour block; otherwise you might be able to read off some data

I don't think list reporters have this problem?

jokebookservice1 wrote:

^ I suggest having the timestamps be

(days since 2000)

Also, why isn't it

(days since 1970)

or even better:

(seconds since 1970)

I'm pretty sure nobody every actually wants to know the number of days since 2000, I've always used it for precise timing personally. Having it in seconds would be much more convenient.

</offtopic>

If you want to store a high score table, then you could compromise a bit to get some more high scores, for example you could divide each score by 2 and round it off, then multiply it by 2 when showing the high scores, or 5 or 10 or 20…

_nix wrote:

For what it's relevant, this is discouraged by the Scratch Team.

thisandagain wrote:

We are very much not in favor of anyone manipulating Cloud Variable values directly using a server. This is the kind of use that has been causing a lot of headaches and maintenance problems.

I'm pretty sure BagOfMandMs means you make the Scratch project so it can act as a backend.

Jonathan50 wrote:

_nix wrote:

For what it's relevant, this is discouraged by the Scratch Team.

I'm pretty sure BagOfMandMs means you make the Scratch project so it can act as a backend.

Oh, right! My mistake, sorry.