While I'm in the mood for composing suggestions, I might as well throw this one out there too…
I guess the idea has been said in various forms before, but I thought I'd make a few points more clearly, to show why I think it's a good idea, and why I think they'd be best implemented separately from cloud variables.


EDIT: A ‘pre’-thought…

Probably the main reason I'm proposing this is because I get the impression that one of the major things Scratchers would like to do with Cloud Variables is store in-game per-user data. However, I think cloud variables come with various ‘issues’ that make them somewhat unsuitable for that purpose (see below) - at least, at the moment they do…


User Variables (and Lists)

A “User Variable” is kinda like a Cloud Variable in certain ways, in that it gets retrieved from a scratch server when a project loads, and saved to the server whenever it is changed. But, unlike a cloud variable, the value it has is specific to that user (not shared by users).

They could look something like a cloud variable, but with a side-profile head replacing the cloud:

( @  variable) // the "@" symbol is where the 'head' goes (anyone know Unicode symbol for a side-profile head...?)

What are User Variables for?

The major use for User Variables/Lists would be to save in-game data for each user - so you can come back to a more long-term game with your current level/status/equipment/power-ups/etc. intact, ready to continue.


Why not Cloud Variables?

The above functionality can, of course, be gained through Cloud Variables (better, Cloud Lists, eventually), but that has four major drawbacks:

• all users see the same cloud variables, so all in-game data for all users is visible to all users, and you get all of it for everyone when you first load a project
  – but user variables would be private, so you only get the in-game data that belongs to you;

• cloud variables have to be ‘watched’ all the time (polling the server), meaning continuous network usage
  – user variables still need writing when changed, but only need reading when a project first loads
  – anyway, typical use for user variables would be only occasional writing, rather than attempting to make multiplayer games where the value is changing really often;

• changes to cloud variables are subject to race conditions (multiple users changing them at nearly the same time)
  – however, a user variable/list is different for each user, so the only possibility of such a problem comes from running the project in two places at the same time while signed in as the same user (in which case, what do you expect!)

• cloud variables can be hacked, meaning all players could potentially lose all in-game data just through the silliness of one person
  – but user variables can work via the standard per-user authentication that the website uses, and since they are private, you can only change (or hack!) your own value.

A final thought…

Finally, User Variables/Lists provide *really useful* capability that only becomes reasonable to do (without mega-pain) once Cloud Lists become available. But because they are private, there are not the same kind of problems with moderating them - you can't ‘chat’, etc., so no user-to-user interaction issues. That means there's no reason to restrict them to digits only, and User Lists could be introduced right alongside User Variables (assuming the protocol is there to talk to the server).

Hope that sounds reasonable!


EDIT: A final final thought…… (honest! )

Meant to include this in the last section, considering user lists vs cloud lists:
I would think the protocol for talking to the server (for user lists) is much simpler than for cloud lists. With a cloud list, you likely don't want the server to send the whole list at every poll - rather, only the bits that may have changed since the running player last polled the server. But that's not a particularly straightforward thing to work out & keep track of (probably needs database of info about users' last access times, or something…? I'd guess that may be one reason why cloud lists are proving so long in appearing…)
But for user lists, the only time you ever need to read them is when the project first loads - and then you obviously do want the whole lot.
Simples!

Support

Amazing how quickly these things disappear off the bottom of the page…
Or maybe it's 'cos people bump their posts too often?

Support.

Support. Also does this work?
EDIT: No, no it does not.

I like that idea…

+2..

Wait, can I do that?

I really wanna see this…. this is an amazing idea :3

SUPPORT!!! THIS WOULD BE AWESOME!!!!

Bump

Hmmm… Is it weird that I've spent the last ~40 minutes looking for a good Unicode head?
There's not much out there. What I found:
ଡ଼ (0x0B5C) looks a bit like a boy with big hair…
There's of course the Korean guy-with-hat: ᇂ(0x11C2)
Enclosed CJK features some fun faces, like ㋡ (0x32E1)
If you've got emoji there's people down in private use (naturally, they're tacky):  (0xE0001-E0005)

…and bottom. Well, that was a waste of time.

Idea: +1

Good luck with a symbol.
Perhaps ST could create their own glyph, stick it somewhere in private use and use that? Needs looking into…

Did I really just scroll through an entire Unicode table looking for a head…

Support!

Support. Although I DO think there was something similar mentioned…

Support!

(SUUUPER-bump-man!)
Support!

Support! Also, the Unicode symbol for a head is this: ☺

davidkt wrote:

Support! Also, the Unicode symbol for a head is this: ☺

What I had in mind was more a side profile type view - but, still, that's useful to know… ☺

Tried it in original post, but it comes out too small to be reasonably discernible, unfortunately (now I need a sad version to use here…)

Good idea! But what if instead of saving it to the server, it saved it to cookies? That might work better because then there would be less load on the server, even if it wouldn't work for people who have cookies off.

Also, I think that the “@” sign would work better than a profile-human-head-picture-thing, seeing as how it is used to @Mention someone in comments!

AonymousGuy wrote:

Good idea! But what if instead of saving it to the server, it saved it to cookies? That might work better because then there would be less load on the server, even if it wouldn't work for people who have cookies off.

I like the idea of making use of local storage. I think I'd prefer to have the same data available from anywhere you sign in, though, so I still think it'd be good to ultimately save to the server.

However, a scheme using some kind of timestamp, or revision number, could keep network traffic lower - so when a user loads a project, any User Variables/Lists in there just have a revision number associated with them. If the client has the local data, and the revision number matches, then it doesn't need to talk to the cloud/uservar server any more. Otherwise, it would ask for the values in the same kind of way as it currently does with cloudvars. (And if the value gets changed while the project is running, then it updates the local one, and tells the server, too. Interesting question over who gets to decide the revision number or timestamp though…)

Seems like a possible compromise.

I like this idea a lot! I have tried replicating something like this with synchronized lists and cloud vars but I gave up. I would love to see this implemented, maybe even more than I want cloud lists!