zubblewu wrote:

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

Common log, log written without a base is given to be log base 10.

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?

We're supposed to add blocks that aren't possible currently. Video blocks aren't possible to “workaround” in 1.4, that's why they added it. Cloud variables, etc. They're new features without workarounds.

Please excuse me for saying this, but “innovative” typically implies something new, as in something not seen before. Stamping the video is a great idea, and very innovative. For that, full support. However, as stated before, many of these have workarounds, and can be coded using existing blocks, so if you want to innovate, you can do it yourself. If you want them in block form, you can always use custom blocks. They are fairly simple, though there's that one pesky boolean glitch… And if you can't code them yourself, there is always the request forums…

the more blocks it gets, the harder to learn scratch would be. Many new blocks would help to make things easier with less blocks for the same code, but too many blocks, which aren't really usefull are too bad for learning scratch.
I started learning Stencyl today, it's in some ways similar to scratch, but it has so many new blocks and many blocks are replaced wiht other ones, its like learning a new block-language. And when i now think about my first tries with scatch: I had almost no problems, it was easy to learn and after 2-3 weeks i got how all blocks instead of variables and lists work (and some operators). Stencyl has 100s of blocks and i have no idea where to begin

So better keep just the usefull blocks. New operators like ()^() are always good, because only experienced use will use them, but blocks like the lock are just used for 0.000001% of all the projects we ever will create. I never needed many things you suggested and i think other scratcher do not need them, too.

ProdigyZeta7 wrote:

What's the boolean glitch you speak of?

I saw on another forum that making a “say until < >” block with custom blocks won't work because of a glitch.

TM_ wrote:

the more blocks it gets, the harder to learn scratch would be. Many new blocks would help to make things easier with less blocks for the same code, but too many blocks, which aren't really usefull are too bad for learning scratch.
I started learning Stencyl today, it's in some ways similar to scratch, but it has so many new blocks and many blocks are replaced wiht other ones, its like learning a new block-language. And when i now think about my first tries with scatch: I had almost no problems, it was easy to learn and after 2-3 weeks i got how all blocks instead of variables and lists work (and some operators). Stencyl has 100s of blocks and i have no idea where to begin

Everyone says more blocks = more problems. I say more blocks = more opportunities. I also starting learning Stencyl recently, and seeing all the newer code excited me. It's intimidating to see a larger variety of coding, but at the same time exhilarating because you can do more things than before.

ProdigyZeta7 wrote:

TM_ wrote:

the more blocks it gets, the harder to learn scratch would be. Many new blocks would help to make things easier with less blocks for the same code, but too many blocks, which aren't really usefull are too bad for learning scratch.
I started learning Stencyl today, it's in some ways similar to scratch, but it has so many new blocks and many blocks are replaced wiht other ones, its like learning a new block-language. And when i now think about my first tries with scatch: I had almost no problems, it was easy to learn and after 2-3 weeks i got how all blocks instead of variables and lists work (and some operators). Stencyl has 100s of blocks and i have no idea where to begin

Everyone says more blocks = more problems. I say more blocks = more opportunities. I also starting learning Stencyl recently, and seeing all the newer code excited me. It's intimidating to see a larger variety of coding, but at the same time exhilarating because you can do more things than before.

I think we all can find a solution:
At first we can use only the blocks we can use at the moment. But on edit we can tick “show extended variaty of blocks” and we can use some of your ideas

I think we should add these:

ProdigyZeta7 wrote:

• sprite height and length reporters
  
• set pen color to {red/green/blue/purple/black/white/random/etc} - Quickly select the color from a drop-down menu at shade 50
  
• add left and right shift, tab, and enter to “if/when key { } pressed”
  
• right mouse-button clicked reporter

EXPONENTZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ

*Workaround Shown Below
**Workaround Not Shown Below

ProdigyZeta7 wrote:

Just getting straight to the blocks :

• Timers for individual sprites and stage (Some Support)
  
• ( ) ^ ( ) operator - first number raised to the second number power (*Some Support)
  
• turn for ( ) seconds to direction ( ) (**Some Support)
  
• 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. (**Not Much Support)
  
• revolve ( ) degrees around {sprite} (**Not Much Support)
  
• sprite height, length, and name reporters (No Support)
  
• set pen layer to ( ) - Enable for pen drawing behind other pen drawings (Some Support)
  
• set pen color to {red/green/blue/purple/black/white/random/etc} - Quickly select the color from a drop-down menu at shade 50 (Not Much Support)
  
• stamp video - like taking a picture (Not Much Support)
  
• set video resolution to ( ) - sets how pixelated the video is, lower is greater detail (Some Support)
  
• break - stops repeating through a loop to execute the blocks after it (*Not Much Support)
  
• 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. (Not Much Support)
  
• delete clone of {sprite} (Not Much Support)
  
• showing and hiding other reporters, such as timer and costume # without having to use the checkbox. (Some Support)
  
• pause/resume timer (Support)
  
• when < > - A hat block with a boolean input (Support)
  
• touching stage reporter (No Support- A Sprite Cannot be Not Touching the Stage)
  
• add left and right shift, tab, and enter to “if/when key { } pressed” (Some Support)
  
• right mouse-button clicked reporter (Some Support)
  
• toggle screen refresh on/off (No Support)
  
• point towards x: ( ) y: ( ) - I know this is already suggested (**Some Support)
  

I'll be thinking of more block ideas later. I'm sure some of these have already been suggested, and I know some are pointless to make, but Scratch is made to improve. The more blocks to choose from, the easier Scratch gets.

So, do you support these?

Update: Some ideas crossed out.

Define Repeat (Times) or Until <Repeat>
Set [Counter v] to [0]
Repeat Until <<(Counter) = (Times)> or <Repeat>>
Change [Counter v] by [1]
end

Define (Base) ^ (Exponent)
Set [Output v] to (Base)
Repeat (Exponent)
Set [Output v] to ((Output) * (Base))
end

when this block is clicked::sensing hat//FYI, this is my old account that I no longer use. My current account is @DaSpudLord.
forever {do (a [scratch v]::events ring)::sound}::extension cstart
say [what the...?] in (the language of [the moon people v]::red)::control
create [spontaneous v] explosion in [a flea's stomach]::motion
That's not right...::cend

I think that pretty much all of these are brilliant suggestions.

I know that there are some workarounds, but they're not as intuitive as one may think, especially the ()^() block (I have only a really basic idea of how the [log v] function works)

Just a normal bump.

Support!

Motion.
1. I don't know why this is needed.
2. .5upport
3. ibid
4. Support!
Looks
1. I don't get how this one would work.
2. Not needed, there is no way to change a sprites name, and therefore no need to report it.
3. Oh yes, I like this one.
4. ibid
5. ibid
Sounds
(complete support)
Pen
1. Support, provided there are blocks for clearing specific pen layers, etc…
2. What sort of dropdown is this?
Events
1. This is something that I have thought of.
2. Why?
3. Can be replicated with the 1st event block.
Control
1. Why?
2. Must. Be. Added.
3. Isn't this what stop all other scripts in this sprite does?
Sensing
1. Yes
2. Yes
3. Yes
4. Yes
5. Good idea!
6. ibid
7. Yup!
8. Why?
9. ibid
Operators
Support all.
Custom Blocks
1. Good idea. What else would be in the dropdown?

____                  _____  _______              
|   \  |     |     | |          |    |\    | | /
|___/  |     |     | |__        |    | \   | |/  
|   \  |     |     | |          |    |  \  | |\   
|    | |     |     | |          |    |   \ | | \  
|___/  L____  \___/  |_____  ___|___ |    \| |  \ 
               PRODUCTIONS

Support.

ProdigyZeta7 wrote:

set costume center to x: (0) y: (0) ::looks //

SUPPORT TIMES A GAZILLION

We support ideas all we want, and ST almost never cares XD

ShadowFlareX wrote:

We support ideas all we want, and ST almost never cares XD

Yes they do or there wouldn't be a suggestions forum.