"User ID" reporter blocks

musicROCKS013

Note: This is not a duplicate. I explain why later in the post.

(User ID of [] :: sensing)

(username of user with ID () :: sensing)

In the scratch API for a username (example) you will see

"id":34853305

at the very beginning of the api. This is what the block will report. This is different from the other suggestion because that block reports the time that user viewed a project. (First view = User ID 1, Second = 2, etc.). This is suggesting a block which reports your user ID, which is part of the API and stays constant from the time you create your account. This is helpful because it is already a number that exists, it just needs to be accessible with a reporter. Since it isn't project specific, it is a LOT less data to save than the old User ID block.

For banned or deleted users, it would report as normal, so you can't tell if a user is banned or deleted. For GDPR'd accounts and signed out users, it would report “0” If the user was banned because they had an inappropriate name, such as a name with a curse word embedded, it would also report “0” This will help prevent comments like, “Put the number ####### into the (username of user with ID []) block,” and that number is the ID of an inappropriate account.

Pros/Uses:

Could be used to store less data in cloud projects. For example, storing a user's ID takes WAY less characters than storing their encoded username. This will help with cloud projects and cloud leaderboards to be more efficient.
Is better than the old “User ID” block because it is a constant value, the same for every user, and will store much less data than the old one.

Cons/Limitations:

Could take a while to report a value. It could take a long time to search through 80 million users!
…

Feel free to discuss! If you support/no support please give a reason why, please don't quote this whole post when making a reply, and don't suggest things here or ask unrelated questions.

Last edited by musicROCKS013 (July 29, 2022 14:17:10)

Unity_and_Cq

Wouldn't you be able to then ban people using this…?

Quantum-Cat

Unity_and_Cq wrote:
(#2)
Wouldn't you be able to then ban people using this…?

If you are referring to preventing people from viewing projects, then this is already possible with the username block, and should be reported.

Last edited by Quantum-Cat (July 29, 2022 13:32:34)

Unity_and_Cq

Quantum-Cat wrote:
Unity_and_Cq wrote:
(#2)
Wouldn't you be able to then ban people using this…?
If you are referring to preventing people from viewing projects, then this is already possible with the username block, and is reportable.

True. Though this block could be helpful, I don't see how everyone would benefit from this block.

musicROCKS013

Unity_and_Cq wrote:
True. Though this block could be helpful, I don't see how everyone would benefit from this block.

The main implementation here is that it makes storing and converting usernames to numbers a lot easier. For example this code will store the username of the first person to play the project:

when green flag clicked
if <(☁ first) = []> then//blank, as in not filled out
set [☁ first v] to (User ID of (username) :: sensing)
end

Then, to decode and turn that number back into a username:

set [Display v] to (username of user with ID (☁ first) :: sensing)
show variable [Display v]

This is just an example and can be easily worked around, I’m just using this as an example.

Last edited by musicROCKS013 (July 29, 2022 14:18:09)

Unity_and_Cq

musicROCKS013 wrote:
Unity_and_Cq wrote:
True. Though this block could be helpful, I don't see how everyone would benefit from this block.
The main implementation here is that it makes storing and converting usernames to numbers a lot easier. For example this code will store the username of the first person to play the project:
when green flag clicked
if <(☁ first) = []> then//blank, as in not filled out
set [☁ first v] to (User ID of (username) :: sensing)
end
Then, to decode and turn that number back into a username:
set [Display v] to (username of user with ID (☁ first) :: sensing)
show variable [Display v]
This is just an example and can be easily worked around, I’m just using this as an example.

This could be a little confusing for new users.

musicROCKS013

Unity_and_Cq wrote:
This could be a little confusing for new users.

How? It could be explained like this:

When you create an account, a number is linked to your account name. When you use this block, it takes the accounts name and finds the ID number and vice versa with the other block.

Okay, but you understand what I mean right?

Unity_and_Cq

musicROCKS013 wrote:
Unity_and_Cq wrote:
This could be a little confusing for new users.
How? It could be explained like this:

When you create an account, a number is linked to your account name. When you use this block, it takes the accounts name and finds the ID number and vice versa with the other block.

Okay, but you understand what I mean right?

I understand but how do you explain this to kids under the age of nine?

musicROCKS013

Unity_and_Cq wrote:
I understand but how do you explain this to kids under the age of nine?

When you create an account, a number is linked to your account name. When you use this block, it takes the accounts name and finds the ID number and vice versa with the other block.

RL1123

Unity_and_Cq wrote:
musicROCKS013 wrote:
Unity_and_Cq wrote:
True. Though this block could be helpful, I don't see how everyone would benefit from this block.
The main implementation here is that it makes storing and converting usernames to numbers a lot easier. For example this code will store the username of the first person to play the project:
when green flag clicked
if <(☁ first) = []> then//blank, as in not filled out
set [☁ first v] to (User ID of (username) :: sensing)
end
Then, to decode and turn that number back into a username:
set [Display v] to (username of user with ID (☁ first) :: sensing)
show variable [Display v]
This is just an example and can be easily worked around, I’m just using this as an example.
This could be a little confusing for new users.

I think that encoding and decoding usernames would be much, much more confusing to new users than just getting a user ID from the username. This gives a simple workaround for a complex problem.

The_5th_Scratcher

Unity_and_Cq wrote:
I understand but how do you explain this to kids under the age of nine?

How do you explain sin, cos, tan, and log to kids under the age of nine? Some blocks can be confusing for new scratchers.

I think this would be really nice to have instead of the really long strings of code for encoding/decoding usernames. High Scores or Multiplayer games with usernames would be so much easier to code. I support for these reasons

Unity_and_Cq

The_5th_Scratcher wrote:
Unity_and_Cq wrote:
I understand but how do you explain this to kids under the age of nine?

How do you explain sin, cos, tan, and log to kids under the age of nine? Some blocks can be confusing for new scratchers.

I think this would be really nice to have instead of the really long strings of code for encoding/decoding usernames. High Scores or Multiplayer games with usernames would be so much easier to code. I support for these reasons

I get what you are saying but just encoding a set numbers to a username would be much easier without needing a new block (ex. an a in a username translates to 1, b to 2, etc)

musicROCKS013

Unity_and_Cq wrote:
I get what you are saying but just encoding a set numbers to a username would be much easier without needing a new block (ex. an a in a username translates to 1, b to 2, etc)

You have obviously never tried to encode a username before.

A would be 01, B to 02, etc. This is because numbers like 26, with 2 digits, need to be differentiated from 2 and 6. With your method, if I type “Z” it would report BF.

This would make your username being encoded be this ( _ = 27 and - = 28):

Length: 24
211409202527011404270317

Meanwhile, if we simply use your profile ID, we have

Length: 8
82230082

This is cutting down the length by 3x! This will help to save so much cloud data.

Unity_and_Cq

musicROCKS013 wrote:
Unity_and_Cq wrote:
I get what you are saying but just encoding a set numbers to a username would be much easier without needing a new block (ex. an a in a username translates to 1, b to 2, etc)
You have obviously never tried to encode a username before.

A would be 01, B to 02, etc. This is because numbers like 26, with 2 digits, need to be differentiated from 2 and 6. With your method, if I type “Z” it would report BF.

This would make your username being encoded be this ( _ = 27 and - = 28):

Length: 24
211409202527011404270317

Meanwhile, if we simply use your profile ID, we have

Length: 8
82230082

This is cutting down the length by 3x! This will help to save so much cloud data.

Who else would this benefit besides game developers?

The_5th_Scratcher

Unity_and_Cq wrote:
I get what you are saying but just encoding a set numbers to a username would be much easier without needing a new block (ex. an a in a username translates to 1, b to 2, etc)

The_5th_Scratcher wrote:
I think this would be really nice to have instead of the really long strings of code for encoding/decoding usernames.

This is what my username encoder looks like and it's not easier…
(This is actually my decoder code)

(That's not even half the code)

I'm just trying to say that sometimes it's good to add a workaround for very long scripts and the suggested blocks would definitely help.

Last edited by The_5th_Scratcher (July 29, 2022 19:42:58)

Unity_and_Cq

(long unnecessary quote removed by moderator - please don't spam)

I understand what you guys are saying but how would this benefit everyone? Because yes, I could see this under sensing near the username option but for the average Scratch user who doesn't use a lot of cloud variables, when would we use this?

Last edited by Paddle2See (July 29, 2022 20:18:59)

musicROCKS013

Unity_and_Cq wrote:
Who else would this benefit besides game developers?

There are many implementations for this that could apply for usernames. For example, cloud votes could store more info.

And if anyone wants to mention animations, these blocks aren't necessary for animations either, yet they exist.

<key [ v] pressed?>
when [ v] key pressed
when this sprite clicked

Unity_and_Cq wrote:
I understand what you guys are saying but how would this benefit everyone? Because yes, I could see this under sensing near the username option but for the average Scratch user who doesn't use a lot of cloud variables, when would we use this?

I think this feature would make basic cloud things like cloud leaderboards much more approachable to the “average scratcher” and could help more people learn about cloud vars and get involved with them.

Last edited by musicROCKS013 (July 29, 2022 19:47:13)

Unity_and_Cq

musicROCKS013 wrote:
Unity_and_Cq wrote:
Who else would this benefit besides game developers?
There are many implementations for this that could apply for usernames. For example, cloud votes could store more info.

And if anyone wants to mention animations, these blocks aren't necessary for animations either, yet they exist.
<key [ v] pressed?>
when [ v] key pressed
when this sprite clicked

I'm sorry, what? Those could be used for games. Not every block needs to be used in one project. However, this block you are suggesting really only means something to those who use a lot of cloud variables but not a lot of people use them often enough to really care for this block.

musicROCKS013

Unity_and_Cq wrote:
This block you are suggesting really only means something to those who use a lot of cloud variables but not a lot of people use them often enough to really care for this block.

Read my edit.

The_5th_Scratcher

Unity_and_Cq wrote:
I understand what you guys are saying but how would this benefit everyone? Because yes, I could see this under sensing near the username option but for the average Scratch user who doesn't use a lot of cloud variables, when would we use this?

There are a lot of advanced blocks in scratch (especially in the operators section)

Discuss Scratch