breakfast_for_dinner wrote:

Ollie-Young wrote:

(#8905)
Bro it’s the offical list of rejected suggestions, obviously rejected should count

vvvv

Paddle2See wrote:

I don't think you need to include suggestions that are clearly absurd or are not likely to reappear. The idea is try to head off suggestions that keep coming up again and again. Trying to cover *every* suggestion would maybe make it so large that it no longer is useful.

doggy_boi1 wrote:

https://scratch.mit.edu/discuss/topic/348410/?page=1#post-3518582 https://scratch.mit.edu/discuss/topic/729255/?page=7#post-8147068 advertisements are rejected. As in actual company adverts, unlike what's already included in tolors

TOLoRS wrote:

7.7 Paid advertisements on the Scratch website
Some users are interested in seeing paid advertisements in their projects, like on YouTube, so they can make real money from people viewing their projects. Similarly, some users believe that having advertisements around the Scratch website can allow the Scratch Team to make more money. However, Scratch is supposed to be a non-profit organization. If the Scratch Team or any Scratchers start making money from anywhere on the Scratch website, that would contradict this non-profit philosophy, and that would be a huge legal issue.

Catscratcher07 wrote:

doggy_boi1 wrote:

https://scratch.mit.edu/discuss/topic/348410/?page=1#post-3518582 https://scratch.mit.edu/discuss/topic/729255/?page=7#post-8147068 advertisements are rejected. As in actual company adverts, unlike what's already included in tolors

TOLoRS wrote:

7.7 Paid advertisements on the Scratch website
Some users are interested in seeing paid advertisements in their projects, like on YouTube, so they can make real money from people viewing their projects. Similarly, some users believe that having advertisements around the Scratch website can allow the Scratch Team to make more money. However, Scratch is supposed to be a non-profit organization. If the Scratch Team or any Scratchers start making money from anywhere on the Scratch website, that would contradict this non-profit philosophy, and that would be a huge legal issue.

Spaceandmoon1 wrote:

This https://scratch.mit.edu/discuss/topic/280263/ discussion just got closed!

Paddle2See wrote:

While not rejected (that I know of), this topic is currently closed as constructive contributions appear to have dried up.

Spaceandmoon1 wrote:

This https://scratch.mit.edu/discuss/topic/280263/ discussion just got closed!

Spaceandmoon1 wrote:

This https://scratch.mit.edu/discuss/topic/280263/ discussion just got closed!

Za-Chary wrote:

TABLE OF CONTENTS
This is a concise version of the main list of rejected suggestions. Along with it are short reasons that each suggestion is rejected, in case you do not feel like reading paragraphs of text.

..Shortened to remove long posts.

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

1080GBA wrote:

are these blocks

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

rejected

teamsonic2011 wrote:

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

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.

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

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

when <>::events hat

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-

1080GBA wrote:

are these blocks

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

rejected

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

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.