NoMod-Programming wrote:

scrooge200 wrote:

[sarcasm] If those have such easy workarounds that we should delete them, let's also delete this block!

if <> then
    
else

end

It has a workaround! Then we can delete this one!

wait (1) secs

And then this one!

when [ v] key pressed

Then we can remove every workaroundable block!

[/sarcasm] No support.

While we're at it, let's remove every number except for 1 and 0! the number 21 can be made from the following:

((((((1)+(1))+(1))*((1)+((1)+(1))))*((1)+(1)))+((1)+((1)+(1))))

But if we remove every number except 1 and 0, how can you get to twenty-one? You'd just get 1+.

I'm not going to support nor not support since I think the OP has had enough of this. (Correct me if I'm wrong OP.)

charlesdog wrote:

NO SUPPORT!!!!!

If you don't list a reason, your entire argument is useless.

No support, it's for newer scratchers.

No support due to this - https://scratch.mit.edu/discuss/topic/195968/

<sarcasm>Can't we just do this?

run code::control cstart
cd [C:/DOS]::control
move to [next folder v]::control
write binary: (0101010)::operators
end program::cend

(No offence to original poster)

No support as per everybody else. That workaround isn't complete since pen projects will produce an L shape rather than a diagonal line \ when using the workaround. The glide block could be an alternative, but I think that that block should be kept because each of the movement blocks are workaroundable with that one block:

define move (steps) steps
go to x: ((x position) + ((steps) * ([sin v] of (direction)))) y: ((x position) + ((steps) * ([cos v] of (direction))))
define go to (sprite name) //Hack the JSON
go to x: ([x position v] of (sprite name) ) y: ([y position v] of (sprite name) ) //Hack the JSON
define set x to (x)
go to x: (x) y: (y position)
define change x by (x)
go to x: ((x position) + (x)) y: (y position)
define set y to (y)
go to x: (x position) y: (y)
define change y by (y)
go to x: (x position) y: ((y) + (y position))

And even glide is wrkaroundable via atan.
So really, the goto block can workaround the others, but the set block leaves an L shape.

And therefore, I do not support the removal of the goto block, since the workaround provided is not perfect, but the two blocks that you have tried to use as a workaround can be replaced with a goto block. So, if you want to remove any blocks, remove all of the (non rotational) movement blocks, since they are all wrkaroundable with the goto block (actually, don't, I'm just saying that we don't need the others, not saying to remove them)

Thanks for reading.

Summary: No support, workaround is not complete

jokebookservice1 wrote:

define go to (sprite name) //Hack the JSON
go to x: ([x position v] of (sprite name) ) y: ([y position v] of (sprite name) ) //Hack the JSON

Actually you don't need to hack the json since you can include any string in that reporter block:

([x position v] of (join [] [name of sprite]))

([x position v] of (name of sprite))

([x position v] of (item ( v) of [  v]))

asivi wrote:

jokebookservice1 wrote:

define go to (sprite name) //Hack the JSON
go to x: ([x position v] of (sprite name) ) y: ([y position v] of (sprite name) ) //Hack the JSON

Actually you don't need to hack the json since you can include any string in that reporter block:

([x position v] of (join [] [name of sprite]))

([x position v] of (name of sprite))

([x position v] of (item ( v) of [  v]))

True. But if you want a drop down menu for the hat, you have to hack the JSON though

gamebeater187_tutor wrote:

instead of

go to x: () y: ()

do

set x to ()
set y to ()

instead of

go to [mouse pointer]

do

set x to (mouse x)
set y to (mouse y)

I would delete

set x to ()
set y to ()

and just use the go to X: Y:

iamunknown2 wrote:

Multiplication is workaroundable, so should we take that out as well? No support.

hey thats my suggestion!

also this topic will become this topic if this keeps going on @Harakou the one that closed my topic before it became an lag monster would need to close this

iamunknown2 wrote:

Multiplication is workaroundable, so should we take that out as well? No support.

Yep because

repeat ( muitiplyer )
change [output v] by (muitlypier)
end