Dragonmyflesh wrote:

:D :: sensing boolean //Dont use the support convention! It's undescriptive! *Rickrolls you* 

medians wrote:

Dragonmyflesh wrote:

:D :: sensing boolean //What did I just say?! 

Dragonmyflesh wrote:

That was a long time ago.

If July 2024 was a long time ago, I must be extremely old

TheCreatorOfUnTV wrote:

medians wrote:

DangerPuppy10 wrote:

you could use this to report how many views a project has (if you have good coding skills), thus leading me to this rejection. I dont know if this rejection entirely related to the post, it's just something to think about.

This has been opened for a while, and people who are logged out or are New Scratchers count towards the views.

Someone could just use cloud variables to make sure that the user is a Scratcher, and restrict from there.

Then that is already reportable xD if they are just locking people out for being a new Scratcher (unless the main project purpose of the project was cloud or something like that)

(username) //this block works the same

canarycat2000 wrote:

No support(FIGHT ME, ELITISTS)

(username) //this block works the same

And if you're gonna bring up the “this project can detect who's using it” warning the Username block pulls up, can't the User ID block do the same?

The two blocks basically do the same thing, adding one would make the other redundant.

A user wrote:

which means you will always have the same username, but your user ID varies depending in the project, and second of all, is a number, which means you can do a lot more with it than usernames.

mingo-gag wrote:

there's a difference between that one and this one

A user wrote:

which means you will always have the same username, but your user ID varies depending in the project, and second of all, is a number, which means you can do a lot more with it than usernames.

That's why I support it

BigNate469 wrote:

(#667)

mingo-gag wrote:

there's a difference between that one and this one

A user wrote:

which means you will always have the same username, but your user ID varies depending in the project, and second of all, is a number, which means you can do a lot more with it than usernames.

That's why I support it

But your actual user ID doesn't change between projects though, it just shows which user you are (and starts at 1). I'm user #35352848. This account was the 35352848th to join Scratch.

IndestructableshadoW wrote:

How about just backpack the script in this:
https://scratch.mit.edu/projects/1134829743/
It takes the number of your username and sets it as numbers. Numbers are able to be saved globally and although they act differently, from the actual ID block, it works.
Unless you'd rather it be a smaller number, then just wait for 4.0 if the devs remake the block.

repeat until <[Scratch blocks v] contains (user id::sensing)>
support::events

end

soarroying wrote:

OOF. That is a big intake, my friend. Also, listen to Marcus the boolean. Don't just say “Support”. Give reasoning! (Ik im not exactly qualified to critisize about that but whatever)


Also king of the page

BigNate469 wrote:

mingo-gag wrote:

there's a difference between that one and this one

A user wrote:

which means you will always have the same username, but your user ID varies depending in the project, and second of all, is a number, which means you can do a lot more with it than usernames.

That's why I support it

But your actual user ID doesn't change between projects though, it just shows which user you are (and starts at 1). I'm user #35352848. This account was the 35352848th to join Scratch.

medians wrote:

Could also work like this

(user [id v]::sensing
(user [name v]::sensing)

when green flag clicked
if <(user id ::sensing reporter)  = [insert person you don’t want to view your project here]> then
say [>:(]
else
…

Turbo_yeeter wrote:

+1, this would revolutionize cloud games… if the scratch team added cloud lists, but until then, +0.75, because the 10 cloud variables that we already have can make for a small list on its own.

TOLORS wrote:

1.5 Cloud lists
This block would allow you to create lists available for everyone to see, similar to cloud variables. However, cloud lists would require similar restrictions as cloud variables, and the issues currently present with cloud variables would only grow with the addition of cloud lists. You can still use cloud variables to create a list which contains entries everyone can see.

(☁ list :: list)

tagrim123 wrote:

Can’t someone discriminate a specific group of people like this?

when green flag clicked
if <(user id ::sensing reporter)  = [insert person you don’t want to view your project here]> then
say [>:(]
else
…