Would this work like javascript localStorage?

Yeah it'd probably use local storage under the hood.
I think user variables that are stored on the server are rejected, but local storage or similar is not.

Bump

Wow- this is actually a really good idea. I actually don't see anything wrong with it!

redspacecat wrote:

Would this work like javascript localStorage?

yes it would use localstorage not storing it on the scratch severs

19mouse2009 wrote:

redspacecat wrote:

Would this work like javascript localStorage?

yes it would use localstorage not storing it on the scratch severs

Correct me if I'm wrong, but isn't localStorage device-specific? I think it would have to use Scratch servers to be account specific.

GRIFFPATCH supported!
Well, I certainly do too. It would be a lot more convenient for savecodes and whatnot!
I’m currently thinking of a way to save player data in the cloud, but I’m pretty sure it’s impossible.
Well, giant support

Romans be like:
SUPPQRT

TheBaton wrote:

19mouse2009 wrote:

redspacecat wrote:

Would this work like javascript localStorage?

yes it would use localstorage not storing it on the scratch severs

Correct me if I'm wrong, but isn't localStorage device-specific? I think it would have to use Scratch servers to be account specific.

well if it is part of the pacific to that users device then no we should not have to use scratch servers to be account specific.
also localstorage it like cookies so I will be saved from there

To clarify, the ST has rejected it being account-specific. The ST has not rejected device-specific, which is this suggestion.

50_scratch_tabs wrote:

To clarify, the ST has rejected it being account-specific. The ST has not rejected device-specific, which is this suggestion.

What’s your source?
(I don’t see it in the TOLORS)
Edit: It also looks like this suggestion is account specific because the title says “User variables & User lists”
Not local variables or device variables.

bluepig600 wrote:

50_scratch_tabs wrote:

To clarify, the ST has rejected it being account-specific. The ST has not rejected device-specific, which is this suggestion.

What’s your source?
(I don’t see it in the TOLORS)
Edit: It also looks like this suggestion is account specific because the title says “User variables & User lists”
Not local variables or device variables.

Source: trust me bro
But seriously, I remember seeing account variables rejected because it would be too much storage overhead for the Scratch Team.

50_scratch_tabs wrote:

bluepig600 wrote:

50_scratch_tabs wrote:

To clarify, the ST has rejected it being account-specific. The ST has not rejected device-specific, which is this suggestion.

What’s your source?
(I don’t see it in the TOLORS)
Edit: It also looks like this suggestion is account specific because the title says “User variables & User lists”
Not local variables or device variables.

Source: trust me bro
But seriously, I remember seeing account variables rejected because it would be too much storage overhead for the Scratch Team.

Yeah, I was thinking that, since it would basically take up the storage of all the cloud variables squared (or something to that effect). Wouldn't it make sense if there could only be ONE (or two, or three) user variables per project?

TheBaton wrote:

50_scratch_tabs wrote:

bluepig600 wrote:

50_scratch_tabs wrote:

To clarify, the ST has rejected it being account-specific. The ST has not rejected device-specific, which is this suggestion.

What’s your source?
(I don’t see it in the TOLORS)
Edit: It also looks like this suggestion is account specific because the title says “User variables & User lists”
Not local variables or device variables.

Source: trust me bro
But seriously, I remember seeing account variables rejected because it would be too much storage overhead for the Scratch Team.

Yeah, I was thinking that, since it would basically take up the storage of all the cloud variables squared (or something to that effect). Wouldn't it make sense if there could only be ONE (or two, or three) user variables per project?

Even that… Take any one project that would benefit from this. Take its viewcount. Convert it from bytes to kilobytes, megabytes, or even gigabytes. And that's for one user variable that can only store numbers 0-255.
Griffpatch's latest project has 114522 views. That's 114 kilobytes. 1000 projects that popular (or even 2000 projects half that popular) and you have a megabyte. Allowing numbers up to 1000 digits (probably about what's needed to store a map/user's drawing, etc) would be 4 kilobytes per view per project. That'd be 4 megabytes per project that popular.
Now, obviously, I've gone to some extremes here. But what you're proposing would still be a lot for the servers.

50_scratch_tabs wrote:

Even that… Take any one project that would benefit from this. Take its viewcount. Convert it from bytes to kilobytes, megabytes, or even gigabytes. And that's for one user variable that can only store numbers 0-255.
Griffpatch's latest project has 114522 views. That's 114 kilobytes. 1000 projects that popular (or even 2000 projects half that popular) and you have a megabyte. Allowing numbers up to 1000 digits (probably about what's needed to store a map/user's drawing, etc) would be 4 kilobytes per view per project. That'd be 4 megabytes per project that popular.
Now, obviously, I've gone to some extremes here. But what you're proposing would still be a lot for the servers.

If the ST made the maximum character limit be 64 (since it is a power of 2) for User Variables, it would make it a lot less stressful for the servers to handle. Each ASCII character takes up 8 bits, so that's one byte per character. Let's say for the sake of argument that they are all filled up, and that there are three of them. Then that would end us with 192 bytes per person on every project that uses them. And let's say now that half of all projects use these variables, which is somewhere around 25 million. Now let's multiply: that's 4,800,000,000 bytes, which is about 4.8 gigabytes. That's per person, so let's say every person accesses these projects, and there are around 130 million registered accounts here on Scratch. So, that gives us about 624,000,000 gigabytes, which is still a massive 624 petabytes. Oh Lord. You're right. Even if we scaled it down, to say, 16 characters, it would still be 156 PETABYTES. Now, for the absolute sake of argument, each character is still 9.75 PETABYTES! This cannot be in Scratch, you are absolutely correct.

What's more, is the fact that the size of the Scratch Servers (estimated by @Flowermanvista on this post) pales in comparison, at around 1-2 petabytes, while every single character takes up about 5 times that. This is actually disturbing to me.

Would be cool and could use cookies to store on device rather than using server storage

Swiftpixel wrote:

Would be cool and could use cookies to store on device rather than using server storage

That is a good point. Why couldn’t these types of variables be stored locally in some form?

50_scratch_tabs wrote:

TheBaton wrote:

50_scratch_tabs wrote:

bluepig600 wrote:

50_scratch_tabs wrote:

To clarify, the ST has rejected it being account-specific. The ST has not rejected device-specific, which is this suggestion.

What’s your source?
(I don’t see it in the TOLORS)
Edit: It also looks like this suggestion is account specific because the title says “User variables & User lists”
Not local variables or device variables.

Source: trust me bro
But seriously, I remember seeing account variables rejected because it would be too much storage overhead for the Scratch Team.

Yeah, I was thinking that, since it would basically take up the storage of all the cloud variables squared (or something to that effect). Wouldn't it make sense if there could only be ONE (or two, or three) user variables per project?

Even that… Take any one project that would benefit from this. Take its viewcount. Convert it from bytes to kilobytes, megabytes, or even gigabytes. And that's for one user variable that can only store numbers 0-255.
Griffpatch's latest project has 114522 views. That's 114 kilobytes. 1000 projects that popular (or even 2000 projects half that popular) and you have a megabyte. Allowing numbers up to 1000 digits (probably about what's needed to store a map/user's drawing, etc) would be 4 kilobytes per view per project. That'd be 4 megabytes per project that popular.
Now, obviously, I've gone to some extremes here. But what you're proposing would still be a lot for the servers.

I'm not sure this is a particularly huge concern. It's important to remember that the projects themselves take space to host too! A single image or sound on scratch can be up to 10 megabytes! (normally they are smaller than this, but music can easily approach this size limit.) So, assuming a scratch project can use 64 bytes of user data (seems like a reasonable limit), it would take 156,250 (oops! it would be 163,840!) separate accounts to generate a single asset worth of data. Most projects on scratch don't get nearly that much traffic, so I really don't think it would generate that much data, relative to the amount of data scratch normally stores per project.

YES!! This is what I want from scratch the most. If they were to add this it would probably be 50X easier to make big projects. Also the @ symbol being used is perfect. 100% support.

FULL support.