## Discuss Scratch

Cyoce
Scratcher
500+ posts

### Work-arounds

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 stackendMotion :: motion hat{move (n) steps} :: grey cstartgo 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 celsepoint in direction ((direction) - (n)){turn cw (n) degrees} :: grey celsepoint in direction ((direction) - ((0) - (n))){point towards (n)} :: grey celsepoint 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 celsego to x: ([x position v] of (n)) y: ([y position v] of (n)){change x by (n)} :: grey celsego to x: ((x position) - ((0) - (n))) y: (y position){set x to (n)} :: grey celsego to x: (n) y: (y position){change y by (n)} :: grey celsego to x: (x position) y: ((y position) - ((0) - (n))){set y to (n)} :: grey celsego to x: (x position) y: (n)end`

Last edited by Cyoce (Dec. 10, 2014 01:02:35)

Iditaroid
Scratcher
500+ posts

### Work-arounds

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.

Last edited by Iditaroid (Nov. 30, 2014 04:18:45)

Chainmanner
Scratcher
100+ posts

### Work-arounds

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
Scratcher
500+ posts

### Work-arounds

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
Scratcher
1000+ posts

### Work-arounds

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
Scratcher
100+ posts

### Work-arounds

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
Scratcher
500+ posts

### Work-arounds

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
Scratcher
1000+ posts

### Work-arounds

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

Sadly, my kumquats were eaten by an evil forum signature.

Cyoce
Scratcher
500+ posts

### Work-arounds

Epicness123 wrote:

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

### Work-arounds

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.

Pingu is learning about politics with this amazing project.
Cyoce
Scratcher
500+ posts

### Work-arounds

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
Scratcher
56 posts

### Work-arounds

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 stackendMotion :: motion hat{move (n) steps} :: grey cstartgo 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 celsepoint in direction ((direction) - (n)){turn cw (n) degrees} :: grey celsepoint in direction ((direction) - ((0) - (n))){point towards (n)} :: grey celsepoint 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 celsego to x: ([x position v] of (n)) y: ([y position v] of (n)){change x by (n)} :: grey celsego to x: ((x position) - ((0) - (n))) y: (y position){set x to (n)} :: grey celsego to x: (n) y: (y position){change y by (n)} :: grey celsego to x: (x position) y: ((y position) - ((0) - (n))){set y to (n)} :: grey celsego 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.

test account.
I said I wouldn't make good art here, but I… I lied.
_Hope
Scratcher
100+ posts

### Work-arounds

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 stackendMotion :: motion hat{move (n) steps} :: grey cstartgo 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 celsepoint in direction ((direction) - (n)){turn cw (n) degrees} :: grey celsepoint in direction ((direction) - ((0) - (n))){point towards (n)} :: grey celsepoint 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 celsego to x: ([x position v] of (n)) y: ([y position v] of (n)){change x by (n)} :: grey celsego to x: ((x position) - ((0) - (n))) y: (y position){set x to (n)} :: grey celsego to x: (n) y: (y position){change y by (n)} :: grey celsego to x: (x position) y: ((y position) - ((0) - (n))){set y to (n)} :: grey celsego to x: (x position) y: (n)end[/quote]I think that's well-said.`

5955595595 5599995559995999555595559999955599959559595
5955595595 5955555595555955955959555595555955559559595
5999995595 5599955955555999559555955595559555559999595
5955595595 5555595595555959559999955595555955559559555
5955595595 5999955559995955959555955595555599959559595
Highlight the numbers, press Ctrl + F, press 9, and press Enter/Return. Or for Mac, CMD + F.
peppermintpatty5
Scratcher
1000+ posts

Cyoce
Scratcher
500+ posts

### Work-arounds

_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 stackendMotion :: motion hat{move (n) steps} :: grey cstartgo 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 celsepoint in direction ((direction) - (n)){turn cw (n) degrees} :: grey celsepoint in direction ((direction) - ((0) - (n))){point towards (n)} :: grey celsepoint 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 celsego to x: ([x position v] of (n)) y: ([y position v] of (n)){change x by (n)} :: grey celsego to x: ((x position) - ((0) - (n))) y: (y position){set x to (n)} :: grey celsego to x: (n) y: (y position){change y by (n)} :: grey celsego to x: (x position) y: ((y position) - ((0) - (n))){set y to (n)} :: grey celsego to x: (x position) y: (n)end`
I think that's well-said.
Thanks.
Epicness123
Scratcher
1000+ posts

### Work-arounds

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.

Last edited by Epicness123 (Dec. 2, 2014 03:47:51)

Sadly, my kumquats were eaten by an evil forum signature.

Cyoce
Scratcher
500+ posts

### Work-arounds

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
Scratcher
64 posts

### Work-arounds

No idea what this is all about
Cyoce
Scratcher
500+ posts

### Work-arounds

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
Scratcher
1000+ posts

### Work-arounds

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

Nothing Is EVER 100%, that is just an assumption.

My “..” and “…” are not spelling mistakes, it means that they are ways of telling someone that I can continue more about it and that the sentence isn't ended the best way. I like putting new indents and lines so I can split up what I am talking about.

Some important links: Here and here or need help click Here. Eats followers, Loves helping people. Check this MMO out! Kiwi = Support WHAT THAT'S IMPOSSIBLE: Through the drop down ;)
`if <> :: control cstartelse :: controlend`