Scratch

slayerrobe7 wrote:

sdg1 wrote:

Another reason is that we do not want code that is specifically tailored for someone in the community - one could easily have a project that says something inappropriate for a specific user through a if block:

when gf clicked
if <(username) = [sdg1]>
  be mean
else
  act normal
end

Considering these possible drawbacks, we decided not to implement the username block, though we agree with you that username blocks will make things much easier for certain type of projects.

and that is why i say no

slayerrobe7, here is a summary of past discussions about the <username> reporter:

PerspectiveDesigns wrote:

That certainly makes sense. But there could also be a lot of problems with not having a username variable. I've been wanting to make a MMOG where people could create a (free of course XD ) account. But people could easily lie about who they are and then ruin the other persons reputation. If there was a username variable, people couldn't cheat.

BoltBait wrote:

Regarding cloud data:

If we do not have access to the currently logged in user's name, we can't make an accurate high score table for our games.

We will have to prompt for a username and the user will be able to respond with anything... even inappropriate words.  Who gets the blame when those show up in the highscore table?

You, seriously, need to rethink this.

Here is a potential solution for you:

If a project wants to access a user's name, perhaps Scratch could prompt the user for access.  Something like "This project would like to know your username.  Allow access to this information?  [YES] [no]"

If the YES button is clicked the USERNAME block contains the username.  If the NO button is clicked the USERNAME block is empty.

Prestige wrote:

As BoltBait said, when it asks for your name to use a leader board with cloud data and someone writes an inappropriate word which now everyone sees on the leader board - who's fault is it when the project is taken down? If it sets itself to username with the players permission it can be policed in the same way usernames already are.

(username), not <username>.

...But yeah, we need it. I agree with BoltBait, the user should have a choice.

slayerrobe7 wrote:

sdg1 wrote:

cpumaster930 wrote:

Regarding cloud data: Will you eventually be able to make persistent variables and lists so that, for example, your progress in a game could be saved and loaded automatically when you play the game again?

Additionally, is it possible to have a hardcoded variable (like timer, volume, etc.) that always reports the Scratch username of the currently logged in user?  This would be extremely useful for high score lists 

It's great that you are thinking about a username reporting block  . We thought about it during our design process, and decided not to go with it, mainly for a couple of reasons.

One reason is privacy - with a username block, a Scratcher may be able to record every action that other Scratchers take on his project (for example, every click), and sometimes this can be done without the other Scratchers knowing that they are being recorded.

Another reason is that we do not want code that is specifically tailored for someone in the community - one could easily have a project that says something inappropriate for a specific user through a if block:

when gf clicked
if <(username) = [sdg1]>
  be mean
else
  act normal
end

Considering these possible drawbacks, we decided not to implement the username block, though we agree with you that username blocks will make things much easier for certain type of projects.

and that is why i say no

But, if it's being mean only if it's to a specific username and the person under the username sees it, they could flag it as inappropriate and in the "Why are you flagging this project?" part the username would say something like this "The creator of this project is being mean to me! The comments look good because he has an awesome game but if I specifically go on it stops the game and says mean things! Go and see for yourself!" and it would be very easy in scratch 2.0 to see that due to the "See inside" button. The username sensor is a valuable reporter block, it shouldn't be taken off.

Those would both be very nice.

Another very needed block:

when gf clicked
forever if <key [space v] pressed>
previous costume
end

when [space v] key pressed
if <(costume #) = 3>
switch to costume [costume 2]
end
if <(costume #) = 2>
switch to costume [costume 1]
end