Cyoce

This is not a normal suggestion, in that it does not present something to be added to Scratch it self; it is meant to be a suggestion for the Scratchers themselves, and how they respond to other suggestions.

I’m getting really tired of people using “But you can use 5 different functions to work-around this block, therefore this post is stupid!” as a justification for giving a “no support”.
I am not saying that it is bad to post a work-around that can be used, or to say “no support”, for that matter. What I am suggesting is that you give an actual reason as to why. As a matter of fact, I believe that it is important to think of, and post, work-arounds for suggestions. Iditaroid said it quite well:

Iditaroid wrote:

Coming up with a workaround for a function not already included in scratch can be a good mind exercise and gets children to think creatively! I believe that the current Scratch blocks library is pretty good and accessible as it is and if the team were to begin adding more blocks it could get very cluttered very fast.
But I digress. Below I will show you what our current motion and operators blocks look like, and then what they would look like if we removed all blocks that could be constructed (or work-around’ed) by other blocks, and show the work-arounds instead. I will be using n, a and b to represent input values. The blocks on the grey celse’s are the originals; the ones inside are the work-arounds.
Okay, here goes:

Operators :: operators hat
(((a) + (b)) :: grey cstart
((a) - ((0) - (b))) :: grey stack
(((a) * (b)) :: grey celse
(((a) / ((1) / (b))) :: grey stack
(not<a :: variables>::operators) :: grey celse
<(a) = [false]> :: grey stack
(<a :: variables> and <b :: variables>::operators) :: grey celse
(((a) / ((1) / (b))) :: grey stack
(<a :: variables> or <b :: variables> ::operators) :: grey celse
(((a) - ((0) - (b)) > [1] ::operators) :: grey stack
end

Motion :: motion hat
{move (n) steps} :: grey cstart
go to x: ((x position) - ((0) - ((n) / ((1) / ([sin v] of (direction)))))) y: ((y position) - ((0) - ((n) / ((1) / ([cos v] of (direction))))
{turn ccw (n) degrees} :: grey celse
point in direction ((direction) - (n))
{turn cw (n) degrees} :: grey celse
point in direction ((direction) - ((0) - (n)))
{point towards (n)} :: grey celse
point in direction (((180) / ((1) / <not <([x position v] of (n)) > (x position)>>)) - ((0) - ([atan v] of ((([x position v] of (n)) - (x position)) / (([y position v] of (n)) / (y position))))
{go to (n)} :: grey celse
go to x: ([x position v] of (n)) y: ([y position v] of (n))
{change x by (n)} :: grey celse
go to x: ((x position) - ((0) - (n))) y: (y position)
{set x to (n)} :: grey celse
go to x: (n) y: (y position)
{change y by (n)} :: grey celse
go to x: (x position) y: ((y position) - ((0) - (n)))
{set y to (n)} :: grey celse
go to x: (x position) y: (n)
end

Iditaroid

Coming up with a workaround for a function not already included in scratch can be a good mind exercise and gets children to think creatively! I believe that the current Scratch blocks library is pretty good and accessible as it is and if the team were to begin adding more blocks it could get very cluttered very fast.

Chainmanner

Iditaroid wrote:

Coming up with a workaround for a function not already included in scratch can be a good mind exercise and gets children to think creatively! I believe that the current Scratch blocks library is pretty good and accessible as it is and if the team were to begin adding more blocks it could get very cluttered very fast.
This. The only time I'd rather a suggestion implemented than using a workaround is when the suggestion involves optimizing the block.

Iditaroid

Chainmanner wrote:

Iditaroid wrote:

Coming up with a workaround for a function not already included in scratch can be a good mind exercise and gets children to think creatively! I believe that the current Scratch blocks library is pretty good and accessible as it is and if the team were to begin adding more blocks it could get very cluttered very fast.
This. The only time I'd rather a suggestion implemented than using a workaround is when the suggestion involves optimizing the block.
What do you mean by, “optimizing the block?”
I think most good block suggestions are ones that can't be done through workarounds at all, i.e. adding back in the removed stretch effect

djdolphin

Do you really expect people to use workarounds for basic, frequently-used blocks like these? It's a bit different for blocks like
point away from [Sprite v] :: motion
which is useful in fewer situations than existing blocks and can be worked around very easily:
point towards [Sprite v]
turn right (180) degrees

danielhal

djdolphin wrote:

Do you really expect people to use workarounds for basic, frequently-used blocks like these? It's a bit different for blocks like
point away from [Sprite v] :: motion
which is useful in fewer situations than existing blocks and can be worked around very easily:
point towards [Sprite v]
turn right (180) degrees
No they don't, they're proving how silly the infamous “workaroundable” response to suggestions is.

Cyoce

Iditaroid wrote:

Coming up with a workaround for a function not already included in scratch can be a good mind exercise and gets children to think creatively! I believe that the current Scratch blocks library is pretty good and accessible as it is and if the team were to begin adding more blocks it could get very cluttered very fast.
I definitely agree. My point is not that we should add every suggested block, nor is it that thinking of work-arounds is a waste of time. My point is, if the block would be useful, and the work-around would be complicated, then don’t use the fact that it could technically be constructed from several other blocks to dismiss the suggestion:

Cyoce wrote:

I am not saying that it is bad to post a work-around that can be used, or to say “no support”, for that matter. What I am suggesting is that you give an actual reason as to why.
If someone suggests a block, and you can construct a helpful work-around, please post it! It would be a great help for the poster and/or other Scratchers!

djdolphin wrote:

Do you really expect people to use workarounds for basic, frequently-used blocks like these? It's a bit different for blocks like
point away from [Sprite v] :: motion
which is useful in fewer situations than existing blocks and can be worked around very easily:
point towards [Sprite v]
turn right (180) degrees
I do not expect people to use work-arounds for the basic blocks; what I am trying to show is that if “work-aroundable” was a legitimate reason to not include a block in Scratch, it would be a much more confusing place. So I encourage Scratchers to have an open mind when a technically work-aroundable block is suggested: what if this reasoning was used when Scratch was being developed?

Epicness123

Sorry, no support. This would be too advanced, and would easily confuse some people.

Cyoce

Epicness123 wrote:

Sorry, no support. This would be too advanced, and would easily confuse some people.
Good: that’s my point.

GyroscopeBill

If the workaround is very complex, then a block for it would be justified.
However, I think it is silly to have tonnes of blocks that only have a couple of uses each.

Cyoce

GyroscopeBill wrote:

If the workaround is very complex, then a block for it would be justified.
However, I think it is silly to have tonnes of blocks that only have a couple of uses each.
I wholly agree. This is where people get confused: it you’re not opposing the block because it technically has a workaround; you are opposing it because (a) the work-around is simple; and/or (b) it does not have many uses.

TechnoDriveX

Cyoce wrote:

This is not a normal suggestion, in that it does not present something to be added to Scratch it self; it is meant to be a suggestion for the Scratchers themselves, and how they respond to other suggestions.

I’m getting really tired of people using “But you can use 5 different functions to work-around this block, therefore this post is stupid!” as a justification for giving a “no support”.
I am not saying that it is bad to post a work-around that can be used, or to say “no support”, for that matter. What I am suggesting is that you give an actual reason as to why. But I digress. Below I will show you what our current motion and operators blocks look like, and then what they would look like if we removed all blocks that could be constructed (or work-around’ed) by other blocks, and show the work-arounds instead. I will be using n, a and b to represent input values. The blocks on the grey celse’s are the originals; the ones inside are the work-arounds.
Okay, here goes:

Operators :: operators hat
(((a) + (b)) :: grey cstart
((a) - ((0) - (b))) :: grey stack
(((a) * (b)) :: grey celse
(((a) / ((1) / (b))) :: grey stack
(not<a :: variables>::operators) :: grey celse
<(a) = [false]> :: grey stack
(<a :: variables> and <b :: variables>::operators) :: grey celse
(((a) / ((1) / (b))) :: grey stack
(<a :: variables> or <b :: variables> ::operators) :: grey celse
(((a) - ((0) - (b)) > [1] ::operators) :: grey stack
end

Motion :: motion hat
{move (n) steps} :: grey cstart
go to x: ((x position) - ((0) - ((n) / ((1) / ([sin v] of (direction)))))) y: ((y position) - ((0) - ((n) / ((1) / ([cos v] of (direction))))
{turn ccw (n) degrees} :: grey celse
point in direction ((direction) - (n))
{turn cw (n) degrees} :: grey celse
point in direction ((direction) - ((0) - (n)))
{point towards (n)} :: grey celse
point in direction (((1) / ((1) / <not <([x position v] of (n)) > (x position)>>)) - ((0) - ([atan v] of ((([x position v] of (n)) - (x position)) / (([y position v] of (n)) / (y position))))
{go to (n)} :: grey celse
go to x: ([x position v] of (n)) y: ([y position v] of (n))
{change x by (n)} :: grey celse
go to x: ((x position) - ((0) - (n))) y: (y position)
{set x to (n)} :: grey celse
go to x: (n) y: (y position)
{change y by (n)} :: grey celse
go to x: (x position) y: ((y position) - ((0) - (n)))
{set y to (n)} :: grey celse
go to x: (x position) y: (n)

First off, your sig is wrong, because if something can be remade (“Work arounded”) then it is not being invalidated. It is being made. So there :V
Secondly, basic mathematical functions are a core function of all programming languages, so using that a point is silly. Steps workaround is large, sure… but you realize that that's why it's a thing.

_Hope

Cyoce wrote:

This is not a normal suggestion, in that it does not present something to be added to Scratch it self; it is meant to be a suggestion for the Scratchers themselves, and how they respond to other suggestions.

I’m getting really tired of people using “But you can use 5 different functions to work-around this block, therefore this post is stupid!” as a justification for giving a “no support”.
I am not saying that it is bad to post a work-around that can be used, or to say “no support”, for that matter. What I am suggesting is that you give an actual reason as to why. But I digress. Below I will show you what our current motion and operators blocks look like, and then what they would look like if we removed all blocks that could be constructed (or work-around’ed) by other blocks, and show the work-arounds instead. I will be using n, a and b to represent input values. The blocks on the grey celse’s are the originals; the ones inside are the work-arounds.
Okay, here goes:

Operators :: operators hat
(((a) + (b)) :: grey cstart
((a) - ((0) - (b))) :: grey stack
(((a) * (b)) :: grey celse
(((a) / ((1) / (b))) :: grey stack
(not<a :: variables>::operators) :: grey celse
<(a) = [false]> :: grey stack
(<a :: variables> and <b :: variables>::operators) :: grey celse
(((a) / ((1) / (b))) :: grey stack
(<a :: variables> or <b :: variables> ::operators) :: grey celse
(((a) - ((0) - (b)) > [1] ::operators) :: grey stack
end

Motion :: motion hat
{move (n) steps} :: grey cstart
go to x: ((x position) - ((0) - ((n) / ((1) / ([sin v] of (direction)))))) y: ((y position) - ((0) - ((n) / ((1) / ([cos v] of (direction))))
{turn ccw (n) degrees} :: grey celse
point in direction ((direction) - (n))
{turn cw (n) degrees} :: grey celse
point in direction ((direction) - ((0) - (n)))
{point towards (n)} :: grey celse
point in direction (((1) / ((1) / <not <([x position v] of (n)) > (x position)>>)) - ((0) - ([atan v] of ((([x position v] of (n)) - (x position)) / (([y position v] of (n)) / (y position))))
{go to (n)} :: grey celse
go to x: ([x position v] of (n)) y: ([y position v] of (n))
{change x by (n)} :: grey celse
go to x: ((x position) - ((0) - (n))) y: (y position)
{set x to (n)} :: grey celse
go to x: (n) y: (y position)
{change y by (n)} :: grey celse
go to x: (x position) y: ((y position) - ((0) - (n)))
{set y to (n)} :: grey celse
go to x: (x position) y: (n)
end[/quote]
I think that's well-said.

peppermintpatty5

http://wiki.scratch.mit.edu/wiki/Workarounds

Cyoce

_Hope wrote:

Cyoce wrote:

This is not a normal suggestion, in that it does not present something to be added to Scratch it self; it is meant to be a suggestion for the Scratchers themselves, and how they respond to other suggestions.

I’m getting really tired of people using “But you can use 5 different functions to work-around this block, therefore this post is stupid!” as a justification for giving a “no support”.
I am not saying that it is bad to post a work-around that can be used, or to say “no support”, for that matter. What I am suggesting is that you give an actual reason as to why. But I digress. Below I will show you what our current motion and operators blocks look like, and then what they would look like if we removed all blocks that could be constructed (or work-around’ed) by other blocks, and show the work-arounds instead. I will be using n, a and b to represent input values. The blocks on the grey celse’s are the originals; the ones inside are the work-arounds.
Okay, here goes:

Operators :: operators hat
(((a) + (b)) :: grey cstart
((a) - ((0) - (b))) :: grey stack
(((a) * (b)) :: grey celse
(((a) / ((1) / (b))) :: grey stack
(not<a :: variables>::operators) :: grey celse
<(a) = [false]> :: grey stack
(<a :: variables> and <b :: variables>::operators) :: grey celse
(((a) / ((1) / (b))) :: grey stack
(<a :: variables> or <b :: variables> ::operators) :: grey celse
(((a) - ((0) - (b)) > [1] ::operators) :: grey stack
end

Motion :: motion hat
{move (n) steps} :: grey cstart
go to x: ((x position) - ((0) - ((n) / ((1) / ([sin v] of (direction)))))) y: ((y position) - ((0) - ((n) / ((1) / ([cos v] of (direction))))
{turn ccw (n) degrees} :: grey celse
point in direction ((direction) - (n))
{turn cw (n) degrees} :: grey celse
point in direction ((direction) - ((0) - (n)))
{point towards (n)} :: grey celse
point in direction (((1) / ((1) / <not <([x position v] of (n)) > (x position)>>)) - ((0) - ([atan v] of ((([x position v] of (n)) - (x position)) / (([y position v] of (n)) / (y position))))
{go to (n)} :: grey celse
go to x: ([x position v] of (n)) y: ([y position v] of (n))
{change x by (n)} :: grey celse
go to x: ((x position) - ((0) - (n))) y: (y position)
{set x to (n)} :: grey celse
go to x: (n) y: (y position)
{change y by (n)} :: grey celse
go to x: (x position) y: ((y position) - ((0) - (n)))
{set y to (n)} :: grey celse
go to x: (x position) y: (n)
end
I think that's well-said.
Thanks.

Epicness123

There's a way to work around called More Blocks.

I'm trying to say, the point of Scratch is for everything to be basic and to script easily, it was never meant to have anything advanced in it.

Cyoce

First off, your sig is wrong, because if something can be remade (“Work arounded”) then it is not being invalidated. It is being made. So there :V
Secondly, basic mathematical functions are a core function of all programming languages, so using that a point is silly. Steps workaround is large, sure… but you realize that that's why it's a thing.

  1. Re-Check my signature.
  2. I’ve seen larger work-arounds than the steps work-arounds in stead of an explanation for their “no support”.

hawk9510

No idea what this is all about

Cyoce

hawk9510 wrote:

No idea what this is all about
It’s about not refusing a suggestion simply because there is a semi-complicated work-around.

RPFluffy

REALLY like this, these workarounds would help others' make more exact detailed blocks.. if you know what I mean!