Please note that I don't like to clutter the forums with so many topics about each of the blocks below, so I much prefer to consolidate them in this topic, which also makes it easier to manage than across, say, 10 or more topics. I'll add descriptions under each category when I have the time.

//Motion
turn for (3) secs to direction (30) ::motion
revolve (15) degrees around [sprite v]  ::motion //clockwise
revolve (15) degrees around x: (100) y: (-50) ::motion
point towards x: (100) y: (100) ::motion //*
[lock/unlock v] sprite to [sprite v] ::motion //Basically like how grouping works in the vector editor, except with sprites

//Looks
set [x-stretch v] effect to (0) //Increases width of sprite
set [y-stretch v] effect to (0) //Increases height of sprite
set costume center to x: (0) y: (0) ::looks //This would set the costume center to the x and y as if the sprite were in the center of the stage.
set costume center x to (0) ::looks
set costume center y to (0) ::looks

(sprite name ::looks)
(costume name ::looks) //*
(costume width ::looks)
(costume height ::looks)
(costume [name v] ::looks) //An alternative to #, name, height, width...

//Sounds
play sound [sound v] in reverse ::sound
set play speed at (1.5) times normal speed ::sound
set play speed at (64) kbps ::sound //Alternate version
set pitch offset to (1) Hz ::sound
change pitch offset by (1) Hz ::sound
play note (32) for (0.5) beats and continue ::sound //Plays note and does not wait for block to finish

//Pen
set pen layer to (1) ::pen //Enable for pen drawing behind other pen drawings
set pen color to [red v] ::pen  //Quickly select the color from a drop-down menu at shade 50
set pen color to r:(0) g:(0) b:(0) ::pen //Yeah, there are workarounds
set pen alpha to (0) ::pen //* Pen transparency, 100 = invisible
change pen alpha by (10) ::pen //*
//Events
when [sprite1 v] switches to costume [costume1 v] ::events hat
broadcast [message v] locally ::events //Sender sprite is the only one receiving the message
broadcast [message v] locally and wait ::events

//Control
break loop ::control cap  //* stops repeating through a loop to execute the blocks after it

stop [every other script v] ::stack //*

while <> ::control cstart //*
end
repeat  ::control cstart
until <> ::control cend //A post-test version of the repeat until loop
repeat ::control cstart
while <> ::control cend //A post-test version of the while loop

//Sensing
show [timer v] ::sensing  //also for minute, hour, second, costume #, volume, etc...
hide [timer v] ::sensing
resume timer ::sensing //*
pause timer ::sensing //*
set microphone volume to (100) ::sensing
change microphone volume by (10) ::sensing
(mic volume ::sensing)
set video resolution to (1) ::sensing  //sets how pixelated the video is, lower is greater detail
([days v] since 2000 ::sensing) //can change to months, years, hours, minutes, seconds
(project id ::sensing) //*

//Operators
((2) ^ (5) ::operators)  //******* So much want!
((3)! ::operators)
([hexidecimal v] of (15) ::operators) //Returns the number converted to base 16
([factorial v] of (3) ::operators) //* Alternate version of (()!)
([sinh v] of (9) ::operators) //I've made workarounds but they get expensive to process
([cosh v] of (9) ::operators)
([tanh v] of (9) ::operators)

//Custom
custom block [dropdown v] ::custom
//Custom reporters
(xyz of (a)(b)(c) ::custom) //*
<xyz is (this)? ::custom> //Boolean
return [] ::custom cap //*

REJECTED Blocks – The blocks that I've removed from my wish-list due to uselessness, ambiguity, easy workaround, etc etc.

repeat for (1) secs ::control cstart //Will not work if internal code executes longer than expected
end
while <> ::events hat //Exactly like the forever if block -- not worth making.
when <>  ::events //Too many backend processes to handle this smoothly

<right mouse down? ::sensing> //Flash player does not allow it

stamp video ::sensing //Too dangerous / invasion of privacy

-The locking/unlocking sprites together I don't support, it'd be buggy and you can script it.
-for revolving around sprites, you can just go to the sprite, point in a direction, and move x steps
-support sprite height, length, but not name
–point towards x y has workaround

The more blocks to choose from, the more COMPLEX scratch gets. Imagine you just start using scratch. 100 blocks to learn or 1000?

kayybee wrote:

The more blocks to choose from, the more COMPLEX scratch gets. Imagine you just start using scratch. 100 blocks to learn or 1000?

You're seeing it the wrong way. The more updates Scratch gets, the greater variety of coding that can be used. The more coding that can be used, the faster projects can be made. You're viewing it as having too big of a variety to find anything useful. 1000 sure is a lot of blocks that we will never have.

Think about it. What if we had to make all of Scratch 2.0's projects with the same blocks from 1.4? 1.1?

Well, you know how sqrt and the trig functions, etc. are combined?
Well, maybe mod and the ^ could be combined in a dropdown fashion?

(EDIT: Anyways, I like A LOT of these ideas! The delete clones one, the lock one, there are too many awesome suggestions!)

dracae wrote:

Well, you know how sqrt and the trig functions, etc. are combined?
Well, maybe mod and the ^ could be combined in a dropdown fashion?

The properties of logarithms can form a workaround with x^y = 10^(y log x). However, most users aren't that advanced into exponents, so they would prefer to have ( ) ^ ( ).

ProdigyZeta7 wrote:

dracae wrote:

Well, you know how sqrt and the trig functions, etc. are combined?
Well, maybe mod and the ^ could be combined in a dropdown fashion?

The properties of logarithms can form a workaround with x^y = 10^(y log x). However, most users aren't that advanced into exponents, so they would prefer to have ( ) ^ ( ).

it's not just that, but the log block in scratch doesn't specify the base so you have to figure it out through experimentation

ProdigyZeta7 wrote:

Just getting straight to the blocks :

• Timers for individual sprites and stage Don't know. Interesting idea.
  
• ( ) ^ ( ) operator - first number raised to the second number power Why has this not been implemented yet? Support.
  
• turn for ( ) seconds to direction ( ) Don't know. Can't see a common use.
  
• lock/unlock sprite to {another sprite} - This would save the x and y position of the first sprite in relation to the second sprite, so that they are moving and turning together. Interesting idea. But it can be worked around quite easily.
  
• revolve ( ) degrees around {sprite} Good idea, but don't see a use.
  
• sprite height, length, and name reporters Why would you need to report a sprite's name? Or its length/width? You can find them out by yourself.
  
• set pen layer to ( ) - Enable for pen drawing behind other pen drawings Would be very hard to implement and sometimes not work how you want. Useful, but confusing.
  
• set pen color to {red/green/blue/purple/black/white/random/etc} - Quickly select the color from a drop-down menu at shade 50 Support. What happened to the color picker, anyways?
  
• stamp video - like taking a picture Support.
  
• set video resolution to ( ) - sets how pixelated the video is, lower is greater detail Interesting, but would be hard to implement.
  
• break - stops repeating through a loop to execute the blocks after it Support. The forever block would need to have a puzzle piece stub at the end.
  
• set costume center to x: ( ) y: ( ) - Note: this would set the costume center to the x and y as if the sprite were in the center of the stage. Can you not just have multiple costumes? I don't see why you would need the costume center changed so much.
  
• delete clone of {sprite} Which clone? What if I have 300 clones (the max)? Which clone does it delete?
  
• showing and hiding other reporters, such as timer and costume # without having to use the checkbox. Support.
  
• pause/resume timer Support.
  
• when {variable name} {</>/=} ( ) - Like the “when timer > ( )”, but using variable names and different arguments. I don't even see why have that block in the first place. It's very easily worked around.
  
• touching stage reporter Would it not always be touching the stage?
  
• add left and right shift, tab, and enter to “if/when key { } pressed” Support, unless not having it is just a technical limitation.
  
• right mouse-button clicked reporter Support, unless this is technically limited.
  
• toggle screen refresh on/off Support, but there would need to be a warning if they are going into turbo mode.
  
• point towards x: ( ) y: ( ) - I know this is already suggested Good suggestion, but easily worked around.
  

Put my opinions above, color-coded. Green is yes, blue is kind of/don't know, and red is no.

mathfreak231 wrote:

ProdigyZeta7 wrote:

See post above.

Put my opinions above, color-coded. Green is yes, blue is kind of/don't know, and red is no.

The “turn for ( ) seconds to direction ( )” would be for games that, for example, would have a turret rotating to face a tank, but not immediately.

The “lock/unlock sprite to {another sprite}” would be useful for Paper Minecraft, where the item count wouldn't lag behind the item when dragged. Or when you want to have multiple sprites move in coordination of a single script.

“Revolve ( ) degrees around {sprite}” would be for projects that have orbiting planets or spinning blades. Y'know, not everyone uses, or even knows, polar equations for the same matter.

There's a reporter for a backdrop name, why not a reporter for a sprite name? In fact, we should also have a reporter for the backdrop #.

Often times, the costume center gets misaligned when editing. In my Rampart game, I used several, size-specific costumes that had to be aligned perfectly in the center, but a glitch occurred when uploading that shifted the centers by 1 pixel. That's why this block is important.

“Delete clone of {sprite}” is useless now. I agree on that one.

What I meant on the “when {variable name} ….”, is that it would detect more than just video, audio, and timer. I want it to detect other reporters such as costume #, time/date, etc. without having to click the Green Flag and run a script.

“Touching stage” Yeah, scratch that. pun intended

“Point towards x: ( ) y: ( )” I got annoyed having to remake the script for this over and over and over and over… So I want just a single block to save me time and resources.

You can use backdrop #.
There's one in the stage section, and you can drag it to the sprite you need it in!
HAX FTW! (Not really)

The scratch team often does not add blocks that have easy workarounds in.

Others are nice ideas though.

ProdigyZeta7 wrote:

kayybee wrote:

The more blocks to choose from, the more COMPLEX scratch gets. Imagine you just start using scratch. 100 blocks to learn or 1000?

You're seeing it the wrong way. The more updates Scratch gets, the greater variety of coding that can be used. The more coding that can be used, the faster projects can be made. You're viewing it as having too big of a variety to find anything useful. 1000 sure is a lot of blocks that we will never have.

Think about it. What if we had to make all of Scratch 2.0's projects with the same blocks from 1.4? 1.1?

You're both shooting the straw man. Kayybee, ProdigyZeta wasn't suggesting that many blocks. ProdigyZeta, Kayybee was never suggesting that we get rid of all these new blocks.

Personally, I think maybe a couple of these could be useful, but most of these have workarounds. Scratch isn't made to have blocks for simple functions that can be replicated with other blocks. Part of Scratch is learning to do what you want with what you have.

turn toward x for x seconds and revolve around x for x seconds, etc. wouldn't work unless there were extra parameters like speed, distance, etc.

darkness3560 wrote:

ProdigyZeta7 wrote:

kayybee wrote:

The more blocks to choose from, the more COMPLEX scratch gets. Imagine you just start using scratch. 100 blocks to learn or 1000?

You're seeing it the wrong way. The more updates Scratch gets, the greater variety of coding that can be used. The more coding that can be used, the faster projects can be made. You're viewing it as having too big of a variety to find anything useful. 1000 sure is a lot of blocks that we will never have.

Think about it. What if we had to make all of Scratch 2.0's projects with the same blocks from 1.4? 1.1?

You're both shooting the straw man. Kayybee, ProdigyZeta wasn't suggesting that many blocks. ProdigyZeta, Kayybee was never suggesting that we get rid of all these new blocks.

Personally, I think maybe a couple of these could be useful, but most of these have workarounds. Scratch isn't made to have blocks for simple functions that can be replicated with other blocks. Part of Scratch is learning to do what you want with what you have.

dis one pls

mathfreak231 wrote:

ProdigyZeta7 wrote:

Just getting straight to the blocks :

• Timers for individual sprites and stage Don't know. Interesting idea. Easily worked around. Set a local variable to the timer.
  
• sprite height, length, and name reporters Why would you need to report a sprite's name? Or its length/width? You can find them out by yourself. Sprite width could be used in typing programs where letters are different width, so the letters could be easily spaced. This is the only reason I support. The name reporter is unnecessary, though.
  
• set video resolution to ( ) - sets how pixelated the video is, lower is greater detail Interesting, but would be hard to implement. Pixelate effect?
  
• pause/resume timer Support. You could have a script that sets a variable to timer if (pause)=0.
  

Put my opinions above, color-coded. Green is yes, blue is kind of/don't know, and red is no.

The purple sentences are my thoughts. Everything else mathfreak231 already said.

mitchboy wrote:

See above

The thing about the timer is that there's only one. It cannot be stopped, as time is continuous. But if we could pause/resume the timer, our options are much greater. And if there's several timers, we can program things like cloud games…
I can live without sprite name.
Please don't set text color to yellow. :P

ProdigyZeta7 wrote:

mitchboy wrote:

See above

The thing about the timer is that there's only one. It cannot be stopped, as time is continuous. But if we could pause/resume the timer, our options are much greater. And if there's several timers, we can program things like cloud games…
I can live without sprite name.
Please don't set text color to yellow. :P

I'm saying you could set variables to the timer so you could have more timers. And also, you could have the variable set only to the timer if a condition is true.

mitchboy wrote:

ProdigyZeta7 wrote:

mitchboy wrote:

See above

The thing about the timer is that there's only one. It cannot be stopped, as time is continuous. But if we could pause/resume the timer, our options are much greater. And if there's several timers, we can program things like cloud games…
I can live without sprite name.
Please don't set text color to yellow. :P

I'm saying you could set variables to the timer so you could have more timers. And also, you could have the variable set only to the timer if a condition is true.

Well, while the condition is false, the timer will still increase, while the variables that were assigned to the timer's value stop updating. Then when, the condition is true, the variables ‘skip’ the gap between its value and the timer. It won't make much sense to have a variable always equal to the timer.

Bumpity bump bump…