I know the current status with Cloud variables that you can only use numbers, and that the Scratch team is looking into ways to integrate lists, strings, e tc. I think that the first new feature to be released should be allowing the username reporter to be set into cloud variables. This is because there would be no way to really abuse this… You can't have a good chat room where all you can say is your name, right? Additionally, this would be a great first step to integrating other data types. The reason is its usefulness. The obvious use is Highscores that report the user that achieved it, but I can think of all many other things, like lists of players etc. Ideas?

0bitasy0 wrote:

I know the current status with Cloud variables that you can only use numbers, and that the Scratch team is looking into ways to integrate lists, strings, e tc. I think that the first new feature to be released should be allowing the username reporter to be set into cloud variables. This is because there would be no way to really abuse this… You can't have a good chat room where all you can say is your name, right? Additionally, this would be a great first step to integrating other data types. The reason is its usefulness. The obvious use is Highscores that report the user that achieved it, but I can think of all many other things, like lists of players etc. Ideas?

when the ST finally allows strings in cloud variables, then you would be able to use the username block in cloud variables.
Oh, and “open” chatrooms, where you can type whatever you want, aren't allowed. Just a heads-up

SJRCS_011 wrote:

0bitasy0 wrote:

I know the current status with Cloud variables that you can only use numbers, and that the Scratch team is looking into ways to integrate lists, strings, e tc. I think that the first new feature to be released should be allowing the username reporter to be set into cloud variables. This is because there would be no way to really abuse this… You can't have a good chat room where all you can say is your name, right? Additionally, this would be a great first step to integrating other data types. The reason is its usefulness. The obvious use is Highscores that report the user that achieved it, but I can think of all many other things, like lists of players etc. Ideas?

Oh, and “open” chatrooms, where you can type whatever you want, aren't allowed. Just a heads-up

He/she knows. They said that you CAN'T make a chatroom with it, so it's good to start with usernames.

Oh I also wanted to talk about functionality with the join block (forgot). It would be great to be able to use it with other usernames and numbers etc but not have any characters that would create a string. For example a highscore var. would be set to join (score) (username).

The reason why you can't put strings in cloud variables is not because of the chat room issue, it is because strings simply haven't been implemented in cloud variables yet.

Rub0Gameton wrote:

The reason why you can't put strings in cloud variables is not because of the chat room issue, it is because strings simply haven't been implemented in cloud variables yet.

Yeah but if they are still working with strings n such, using usernames would be easy to implement, hard to abuse, and get quick testing results… I would think…

I support this for sure.

0bitasy0 wrote:

Rub0Gameton wrote:

The reason why you can't put strings in cloud variables is not because of the chat room issue, it is because strings simply haven't been implemented in cloud variables yet.

Yeah but if they are still working with strings n such, using usernames would be easy to implement, hard to abuse, and get quick testing results… I would think…

Usernames ARE strings. So we will have to wait until they implement strings.

Rub0Gameton wrote:

0bitasy0 wrote:

Rub0Gameton wrote:

The reason why you can't put strings in cloud variables is not because of the chat room issue, it is because strings simply haven't been implemented in cloud variables yet.

Yeah but if they are still working with strings n such, using usernames would be easy to implement, hard to abuse, and get quick testing results… I would think…

Usernames ARE strings. So we will have to wait until they implement strings.

I'm sure they could have a code with a list of all usernames that goes like

“if usernames contains (string)”
allow string for cloud variable integration
else
dont
end

GG

Supported
That's because you're right. I don't have an idea how'd you cyberbully someone with just usernames. IF they use an inappriorite usernames, then just report it. (I can't spell inapriblabla D: )

This will be good for highscores, etc. I like the idea of that.

Well, the scratch team has to see and allow your username, so I also think they should allow cloud variables to support usernames.

First, people might know this by now, but the server is not incapable of handling strings. Numbers are actually stored as strings if you enter them as strings (like setting a cloud var to the result of a join block), which is why they don't get rounded to the limited precision of floats, and why you can store a hex value and still retrieve it in hex format. It just does a check for “does this string represent a number?” before setting the cloud var to that string, which is purely for moderation reasons.

As for the actual suggestion I don't support because it would be so impractical to create.

Because cloud lists don't exist yet, people would probably store multiple usernames in a single var. When you want to change one of those you would have to decode the variable, change one of the usernames, and then encode it again. Consider this:

decode cloud list :: custom
replace item (1 v) of [usernames v] with (username)
set [☁ cloud list v] to (usernames)

Currently, it would just check if (usernames) represents a number, see that it doesn't (unless everyone who used the project has a one-digit name, but that's not going to happen), and reject the cloud var change.

If clout vars were made to support usernames, it would have to look at not just the value, but the (usernames) block that the cloud var was being set to. It would then have to work through each item in the list to check that it was either a number, a username, or part of an existing cloud variable. That then means going through the decode cloud list block, and chacking that each list item was set to itself plus the next letter of the cloud var. Then it has to check the previous value of each list item, and so on.

Now consider how many different ways there are to encode a cloud list. The ST would have to make it detect every possible way of doing that and allow it while not allowing false positives. Even if that's possible, which I suspect it isn't, it would be loads of effort for comething that people can just do with an easy-to-find cloud list engine.

Letting people chop and change cloud vars like that would also make it possible to put non-usernames in the string anyway, just by cutting out letters from existing usernames and repeating them wherever they need them. It wouldn't be that hard to get the full alphabet just be logging the name of everyone who uses the project.

Another practical disadvantage of that is that you couldn't really use multiple usernames in a cloud list anyway. The separators or padding characters would still have to be digits, and there would be no way of knowing if a digit was part of someone's name or a separator.

So at this point, it becomes clear that the only use would be setting a cloud var to the username block directly, like this:

set [☁ name v] to (username)

which is only really good for high scores. It would still have to check the type of block being passed rather than the value, and IMO it's not worth the effort of making it do that.

Zparx wrote:

“if usernames contains (string)”
allow string for cloud variable integration
else
dont
end

About this idea, I don't think it would work either. If it's a list of all usernames on Scratch it would allow basically any string to be valid because of all the short random usernames that exist, and it it was a list of all users of that project it would still have the problem that you can't tell a separator from part of someone's name in a cloud list.

0bitasy0 wrote:

I know the current status with Cloud variables that you can only use numbers, and that the Scratch team is looking into ways to integrate lists, strings, e tc. I think that the first new feature to be released should be allowing the username reporter to be set into cloud variables. This is because there would be no way to really abuse this… You can't have a good chat room where all you can say is your name, right? Additionally, this would be a great first step to integrating other data types. The reason is its usefulness. The obvious use is Highscores that report the user that achieved it, but I can think of all many other things, like lists of players etc. Ideas?

But then you could make something like if Q key is pressed then set 1st letter to Q and make it a cloud variable so yes you can make a valid chat room with letters

Rub0Gameton wrote:

The reason why you can't put strings in cloud variables is not because of the chat room issue, it is because strings simply haven't been implemented in cloud variables yet.

That is dead wrong. The string functionality is there, but it is disabled due to moderation issues. It was there in the Beta, was never removed, but instead was blocked off from everyone, like New Scratchers were from the cloud.