1080GBA wrote:

are these blocks

(if <> then [] else []::control)
When <>::events

rejected

Those kind of already exist, albeit slightly different than that.

teamsonic2011 wrote:

Those kind of already exist, albeit slightly different than that.

(if <> then [] else []) is a bit different from the C block we know and love.
It reports the value put after “then” if the condition is met, and it reports the value after “else” if it is not.

teamsonic2011 wrote:

(#8921)

1080GBA wrote:

are these blocks

(if <> then [] else []::control)
When <>::events

rejected

Those kind of already exist, albeit slightly different than that.

The first block is known in programming as a “ternary operator.”

(if <> then [] else []::control

Unlike an if/else statement, which evaluates a boolean condition and then runs certain code based on whether the condition is true, a ternary operator simply returns one of two values based on the condition.

It is possible to work around this:

if <> then
set [variable v] to []
else
set [variable v] to []

…but this is more tedious and requires the use of a variable.

As for the second block:

when <>::events hat

It's not entirely clear when this block would run. Does it run once when the condition becomes true, or repeatedly as long as the condition remains true?

I haven't seen this particular suggestion before, but other blocks have been rejected for similar reasons. For example:

Za-Chary wrote:

1.1 “Broadcast received” boolean block
This in theory would allow a project to detect when a broadcast is sent, but there is ambiguity on how this would work. Would it return true if the broadcast was run at any point after the green flag was clicked, or only on the instant the broadcast was run, or something else? The workaround is simple: use variables that change when a broadcast is received, then use the “equals” block.

However, the blocks “repeat until broadcast received” and “wait until broadcast received” are NOT rejected. You can discuss them on this topic.

<[message v] received? :: events>

Scratch137 wrote:

(#8923)

teamsonic2011 wrote:

(#8921)

1080GBA wrote:

are these blocks

(if <> then [] else []::control)
When <>::events

rejected

Those kind of already exist, albeit slightly different than that.

The first block is known in programming as a “ternary operator.”

(if <> then [] else []::control

Unlike an if/else statement, which evaluates a boolean condition and then runs certain code based on whether the condition is true, a ternary operator simply returns one of two values based on the condition.

It is possible to work around this:

if <> then
set [variable v] to []
else
set [variable v] to []

…but this is more tedious and requires the use of a variable.

As for the second block:
-snip-

the workaround for the first one is annoying yk

Follow 1080GBA forever::#1080ba hat

(((((((((((KING::#ff0000 ring)::#ff8800 ring)::#ffff00 ring)::#88ff00 ring)::#00ff88 ring)::#00ffff ring)::#0088ff ring)::#0000ff ring)::#8800ff ring)::#ff00ff ring)::#ff0088 ring)

<<<<<<<<1080GBA::#000>::#222>::#444>::#666>::#888>::#aaa>::#ccc>::#eee>

REVIEW ON THIS:

1.1 - This would be quite useful but rejected means rejected.
1.2 - Well the good news is that the workaround is really easy.
1.3 - Well that would be weird so I think that was the right call.
1.4 - That would cause drama in the community leading to lots of fame hungry people.
1.5 - This would be very great to have implemented but issues with cloud variables is actually fair point.
1.6 - That makes no sense and I think they're should'nt ever be any such thing.
1.7 - That would break the point of scratch, especially to new scratchers
1.8 - Yeah, stuff like hiding mouse pointer would only be good if there was a sprite following the mouse
1.9 - Hmmm, I dont think that's bad but 1.4 blocks should be brung back.
1.10 - I think they stopped that though because this year there were no cat blocks.
1.11 - There's actually a Turbowarp extension called “comment” with a similar effect.
1.12 - Weird. Not much to say here.

Scratch :: events hat
forever
imagine :: motion
program :: looks
share :: sound
end
[scratchblocks]

[scratchblocks]
when (Ollie-Young) joined :: events hat
say [Nothin] :: motion
say [Spam :(] :: looks
say [good :D] :: sounds
say [Current me :/] :: control
say [Soon] :: sensing
say [Soon] :: operators
say [Soon] :: variables
say [Soon] :: list
So, yeah :P :: yellow
[scratchblocks]
Hey guys! I'm , [url=https://scratch.mit.edu/users/Ollie-Young/]Ollie-Young[/url]. I make animations and games on Scratch.
I like this: [url=https://scratchstats.com/Ollie-Young]Scratchstats[/url]
[/scratchblocks]

1080GBA wrote:

are these blocks

(if <> then [] else []::control)
When <>::events

rejected

I don't think so - but they are unlikely to ever get implemented.

AliMASTER430258 wrote:

greentreebee wrote:

Scratchedbyyou_forum wrote:

greentreebee wrote:

a wait time for posting on the forums got rejected

also, a forums tab at the top of the website also got rejected.

Those are already on the list.

whatever more helps

haha, thats funny.why do people think that adding the same stuff is helping

bro that is kinda insulting

when green flag clicked
forever
go to [my profile v]
if <[done with scratch] = [yes]> then
set [screen v] to [MINECRAFTTTTTTTTTTTTTT]
if <[mom says hop off the computer] = [yes]> then
cry
end

Ollie-Young wrote:

REVIEW ON THIS:

1.1 - This would be quite useful but rejected means rejected.
1.2 - Well the good news is that the workaround is really easy.
1.3 - Well that would be weird so I think that was the right call.
1.4 - That would cause drama in the community leading to lots of fame hungry people.
1.5 - This would be very great to have implemented but issues with cloud variables is actually fair point.
1.6 - That makes no sense and I think they're should'nt ever be any such thing.
1.7 - That would break the point of scratch, especially to new scratchers
1.8 - Yeah, stuff like hiding mouse pointer would only be good if there was a sprite following the mouse
1.9 - Hmmm, I dont think that's bad but 1.4 blocks should be brung back.
1.10 - I think they stopped that though because this year there were no cat blocks.
1.11 - There's actually a Turbowarp extension called “comment” with a similar effect.
1.12 - Weird. Not much to say here.

1 - How exactly would <I recieve?> be useful? Broadcasts are meant to represent events, not data.
2 - Not really. It still deserves to be rejected, though.
3 - Why is it weird?
4 - Good point.
5 - Good point.
6 - The implementation given for 2d lists is bad (not to mention it only supports 2d) - but the idea of multidimensional lists itself isn't bad. However, it could be considered too complex for Scratch, which is why this exists.
7 - Good point.
8 - Good point.
9 - The block is confusing because some Scratchers might not know if it should be if <> {forever {}} or forever {if <>{}} (the latter is correct)
10 - No comment.
11 - Turbowarp isn't official or officially endorsed by Scratch Team.
12 - It would jump to a line of code, which would be good in certain cases - however the blocks that already exist do well enough already. The reasons it might be used could be considered too complex for Scratch, which is why this exists.

I know some extension we need : So not everyone thinkee a new extension for scratch 4.0 so I will show you what is it

Extension is
Face Detection!

These are the variations of blocks
Showing what it is
Hides it
Set transparency / alpha

And here’s the blocks!


Detect For a :: extension
Detect :: extension
Hide Camera :: extension
Set to (50) :: extension

My browser / operating system: MacOS Macintosh X 10.15.7, Safari 16.6, No Flash version detected

Okk!!

if <(user) = [illegal]> then
report :: #ff0000
end

set [user v] to [blocked]

| - ‎ UNDERWHITE ♖ - [120]/145‎ ‎ -‎ | :: #171717
-<(| [FIGHT] | [MAGIC] | [ITEM] | [SPARE] | [DEFEND] | :: #444444) :: #170033>- ::  #171717
[Gaster Blaster (70% TP)] - [Antler Beam (30% TP)] - [Healing Ray (15% TP)] - [U-Action (0% TP)] :: #171717
- <<(TP :: #171714) :: #BFBFBF > = [34%] :: #171716> ‎ ‎ ‎ ‎- :: #171717

Underwhite wrote:

Okk!!

if <(user) = [illegal]> then
report :: #ff0000
end

set [user v] to [blocked]

You are probably gonna be banned soon too. Don't blockspam.

when my project gets clicked :: #3495eb hat
You hopefully say [This is a good project!] for (2) secs :: looks
Then you heart and favorite it :: operators
And leave a comment saying something nice about it :: #fc00ec

define [Scratch] 100x (1000) 6^78*9 [Cat] celsius 
set sky color to [#47af6e] + [119] [th v] element of the periodic table:: #fc00ec
if <[something v] contains [something] + DjangoBB ?> then
Do activity [Dance v] :: #574027
end
Create [1,000,000,000,000,000,000,000th] project :: #134567

BluePixelLOLLL wrote:

Underwhite wrote:

Okk!!

if <(user) = [illegal]> then
report :: #ff0000
end

set [user v] to [blocked]

You are probably gonna be banned soon too. Don't blockspam.

Blockspammers wouldn't get banned unless what they blockspammed was really inappropiate

DifferentDance8 wrote:

BluePixelLOLLL wrote:

Underwhite wrote:

Okk!!

if <(user) = [illegal]> then
report :: #ff0000
end

set [user v] to [blocked]

You are probably gonna be banned soon too. Don't blockspam.

Blockspammers wouldn't get banned unless what they blockspammed was really inappropiate

I got warned for doing this

<<<<<<>>>>>>

So I don't want that to happen to anyone else

when my project gets clicked :: #3495eb hat
You hopefully say [This is a good project!] for (2) secs :: looks
Then you heart and favorite it :: operators
And leave a comment saying something nice about it :: #fc00ec

define [Scratch] 100x (1000) 6^78*9 [Cat] celsius 
set sky color to [#47af6e] + [119] [th v] element of the periodic table:: #fc00ec
if <[something v] contains [something] + DjangoBB ?> then
Do activity [Dance v] :: #574027
end
Create [1,000,000,000,000,000,000,000th] project :: #134567

Make a true equation with <(5-5) = (0)> format return tru just got rejected.