jokebookservice1 wrote:

It would be wonderful if Scratch had the ability to convert to and from a Unicode codepoint; because that would make the filesize of the compressor much smaller.

Scratch can convert unicode codepoints with hacked blocks, there's a demo project somewhere.

Hi folks,
As many of you have noticed we have added some limits to the Cloud Variables system that previously did not exist. We have added a 128 character limit and we are now restricting cloud variables to be numbers only (no hexadecimal, E-notation, etc). These new limits were put into place to prevent abuse of the cloud variables system that was causing it to be unreasonable to maintain, scale, moderate, and support financially. In addition, these new limits help reduce the possibility of projects like “Chat Rooms” (which are incredibly difficult for the ST to keep safe). We recognize that these new limits may impact some projects, but hope the community will be empathetic in understanding that as a non-profit Scratch needs to make sure that the services we provide are sustainable. Thanks for understanding and sorry it took a few days for us to clarify the situation.

Oh bother . So no more high score tables, achievements, and definitely no scratcharia as I can't store the level . What a shame.

Since cloud cars could no longer be used for high score tables or storing achievements, do you think there will be score in new scratch 3 blocks for implementing this kind of functionality in a more scalable controllable way? For example, achievements want to be recorded per user, but not accessable by other scratchers, so this is like a local cloud variable or list for that scratcher? Couldn't be used for chat rooms, and could be set to only save very periodically as it only needs to persist between sessions not in real time.

The high score table is more tricky, but perhaps an extension for high score tables that is limited in functionality just to record the username and a number for score. It might even present itself in a common way across all scratch projects?

Just a few ideas too try to handle the huge disappointment in the loss of a highly appreciated feature of scratch.

Not sure what could be done about the saving levels like scratcharia… In that game the level was saved once a minute to a cloud var to persist it between games… Guess there's nothing that could be done there

^ for your last point, you can always use an external server to save things, and then have the server and project communicate in 128-length chunks? (this has the obvious drawback of needing your own server; and the ST might be against this)

jokebookservice1 wrote:

…and the ST might be against this.

I'm not the Scratch Team, but I wouldn't be surprised if they are. I could just as easily make a chat room with that as I could make a highscore table. Although it's technically far more difficult, and probably easier to be handled on a case-by-case basis.

Honestly, it's not that hard to still make a chat room now, using the more “basic” method…

_nix wrote:

jokebookservice1 wrote:

…and the ST might be against this.

I'm not the Scratch Team, but I wouldn't be surprised if they are. I could just as easily make a chat room with that as I could make a highscore table. Although it's technically far more difficult, and probably easier to be handled on a case-by-case basis.

Honestly, it's not that hard to still make a chat room now, using the more “basic” method…

By basic, are we talking about the method of using 10 or less cloud vars; or using more than 10?

griffpatch wrote:

The high score table is more tricky, but perhaps an extension for high score tables that is limited in functionality just to record the username and a number for score. It might even present itself in a common way across all scratch projects?(

I think I would be very open to considering something like this as an extension or expansion to cloud vars. I think this is a use case that we'd like to continue to find a way to support.

jokebookservice1 wrote:

^ for your last point, you can always use an external server to save things, and then have the server and project communicate in 128-length chunks? (this has the obvious drawback of needing your own server; and the ST might be against this)

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.

jokebookservice1 wrote:

_nix wrote:

jokebookservice1 wrote:

…and the ST might be against this.

I'm not the Scratch Team, but I wouldn't be surprised if they are. I could just as easily make a chat room with that as I could make a highscore table. Although it's technically far more difficult, and probably easier to be handled on a case-by-case basis.

Honestly, it's not that hard to still make a chat room now, using the more “basic” method…

By basic, are we talking about the method of using 10 or less cloud vars; or using more than 10?

I mean just a simple chat like this:

when green flag clicked
delete (all v) of [chat log v]
show list [chat log v]
delete (all v) of [messages v]
add [Hello!] to [messages v]
add [Goodbye!] to [messages v]
forever
  wait for cloud variable to change :: custom // Implement this however you want; you definitely don't need 128 chars
  decode username and message code from (cloud variable) :: custom // Storing a name does not take 128 digit chars
  add (join (username) (join [: ] (item (message code) of [messages v]))) to [chat log v]
end

when [1 v] key pressed
encode text (username) :: custom
set [cloud variable v] to (join (username) [1])

when [2 v] key pressed
encode text (username) :: custom
set [cloud variable v] to (join (username) [2])
// etc

The general idea of this is that the chat log is not stored on the server (so there is no way to fetch old messages). Instead, clients build their own log as messages come in.

That code is extremely simple in that it requires that users pick from a list of messages, but it could be a lot more powerful - and dangerous. For example:

replace this: {
  delete (all v) of [messages v]
  ...
} with this: {
  delete (all v) of [words v]
  add [I] to [words v]
  add [me] to [words v]
  add [you] to [words v]
  add [like] to [words v]
  add [do not] to [words v]
  add [do] to [words v]
} :: grey
replace this: {
  add (join (username) (join [: ] (item (message code) of [messages v]))) to [chat log v]
} with this: {
  set [i v] to [1]
  set [message v] to []
  repeat (length of (message code))
    set [message v] to (join (message) (join [ ] (item (letter (i) of (message code)) of [words v])))
    change [i v] by [1]
  end
  add (join (username) (join [: ] (message))) to [chat log v]
} :: grey

This would let you form any string of the specified words. “Do you like me”, “I do not like you”, “I do not like me” etc are all possible with that very minimal selection of words, and hardly any effort in writing the code for the project.

thisandagain wrote:

jokebookservice1 wrote:

^ for your last point, you can always use an external server to save things, and then have the server and project communicate in 128-length chunks? (this has the obvious drawback of needing your own server; and the ST might be against this)

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.

What if someone kept a PC constantly running the project in “server” configuration with longer normal lists, and then interfaced with the online “clients” and updated them? This would mean, in a chat room scenario (just as an example) that users could receive messages while not online and old ones would still be saved.

What's your policy on this?

thisandagain wrote:

griffpatch wrote:

The high score table is more tricky, but perhaps an extension for high score tables that is limited in functionality just to record the username and a number for score. It might even present itself in a common way across all scratch projects?(

I think I would be very open to considering something like this as an extension or expansion to cloud vars. I think this is a use case that we'd like to continue to find a way to support.

Also, for Scratch 3, would you consider a kind of cloud var that persisted across projects?

I've had dreams of a multiplayer project (assuming those will still exist) player blacklist for a while now- so one player banned on a master project would be barred from interfacing with any other projects with the same code.

cmk1234 wrote:

What if someone kept a PC constantly running the project in “server” configuration with longer normal lists, and then interfaced with the online “clients” and updated them? This would mean, in a chat room scenario (just as an example) that users could receive messages while not online and old ones would still be saved.

That's what I was thinking too… kind of. I would gladly have a server script with a cloud API running for a few of my projects which won't store data on Scratch, but instead on mine. However, I feel like that would be highly unlikely since Scratch projects and its features are intended to be accessible by all Scratchers and most people don't have a server or computer running 24/7.

(Also, as a side note I will unshare my projects that modify cloud data externally)

Oof, that hurts… Guess people will just have to figure out how to condense mass amounts of information…

TNTninja101 wrote:

Oof, that hurts… Guess people will just have to figure out how to condense mass amounts of information…

Pure information can't be condensed; but you can condense stuff into pure information

correct me if I'm wrong

thisandagain wrote:

We have added a 128 character limit and we are now restricting cloud variables to be numbers only (no hexadecimal, E-notation, etc).

Couldn't people just use, say, 20 cloud variables in order to simulate the effect of a larger character limit?

If so, I don't see the purpose of this “fix” except for making cloud projects more difficult to program…

For example, if I wanted to save something longer than 128 characters, I would split the message into 2 or more parts, and simply join the cloud variables when deciphering information, and split the message when saving it.

TNTninja101 wrote:

Couldn't people just use, say, 20 cloud variables in order to simulate the effect of a larger character limit?

If so, I don't see the purpose of this “fix” except for making cloud projects more difficult to program…

It is possible now to create variables that didn't exist when the project was started through referencing hacked blocks. If a similar thing could be done in 3.0, all the problems would be solved…. However that doesn't really meet the Scratch Teams goal….

Yeah…

Also, awesome banner

littlebene wrote:

It is possible now to create variables that didn't exist when the project was started through referencing hacked blocks.

Do you mean it is possible to create variables of a sprite or cloud variables? I am aware that referencing an unknown variable creates a local sprite variable of the same name, but I'm not sure if this works for cloud variables.