When [variable v] changes hat

theonlygusti

I support, as I've said before, but I'd also like to contribute some more, just a tiny and obvious statement, but it irrefutably voids all the non-supporter's arguments so far: I'd like to point out that there is no work around.

Last edited by theonlygusti (April 28, 2016 17:57:59)

adespotist

This suggestion would be great for my projects! You could also do a (very hacky) loop workaround with this too.

adespotist

DaSpudLord wrote:
joefarebrother wrote:
change [ v] by (0)
has an easy workaround, but I bet you still use that.

If you had to use a workaround a lot, the ratio of boilerplate code to code that actually does stuff adds up.
So how easy do you want us to make coding? Do you want us to make coding super easy to the point where there is literally no effort involved? How about we add a block that does this?
when gf clicked
make a platformer::control
also I want there to be enemies that shoot [fireballs v]::motion
We can't make coding too easy, now can we?

https://en.wikipedia.org/wiki/Slippery_slope

No one ever said anything about making enemies that shoot fireballs. I suggest you look at the “related” section of that article to brush up on your other logical fallacies too.

DaSpudLord

adespotist wrote:
DaSpudLord wrote:
joefarebrother wrote:
change [ v] by (0)
has an easy workaround, but I bet you still use that.

If you had to use a workaround a lot, the ratio of boilerplate code to code that actually does stuff adds up.
So how easy do you want us to make coding? Do you want us to make coding super easy to the point where there is literally no effort involved? How about we add a block that does this?
when gf clicked
make a platformer::control
also I want there to be enemies that shoot [fireballs v]::motion
We can't make coding too easy, now can we?
https://en.wikipedia.org/wiki/Slippery_slope

No one ever said anything about making enemies that shoot fireballs. I suggest you look at the “related” section of that article to brush up on your other logical fallacies too.

https://yourlogicalfallacyis.com/the-fallacy-fallacy
I suggest you read that.

Anyway, fallacies, aside, you know what I mean. I'm saying we can't make something too easy by adding blocks that do everything, and at some point we have to draw the line.

theonlygusti wrote:
I'd like to point out that there is no work around.

Would you like to explain how you reached that conclusion? Because I'm pretty sure I can prove it false right now.

theonlygusti

DaSpudLord wrote:
adespotist wrote:
DaSpudLord wrote:
So how easy do you want us to make coding? Do you want us to make coding super easy to the point where there is literally no effort involved? How about we add a block that does this?
when gf clicked
make a platformer::control
also I want there to be enemies that shoot [fireballs v]::motion
We can't make coding too easy, now can we?
https://en.wikipedia.org/wiki/Slippery_slope

No one ever said anything about making enemies that shoot fireballs. I suggest you look at the “related” section of that article to brush up on your other logical fallacies too.
https://yourlogicalfallacyis.com/the-fallacy-fallacy
I suggest you read that.

No, adespotist doesn't need to read that, as he is not subject to the fallacy-fallacy. You are however subject to the slippery slope fallacy, because the implementation of this block does not mean that soon all Scratchers will devolve into mindless zombies because Scratch is too easy. Also, you have not provided any evidence or rational behind your claim that soon Scratch will be using a make platformer block.

DaSpudLord wrote:
Anyway, fallacies, aside, you know what I mean. I'm saying we can't make something too easy by adding blocks that do everything, and at some point we have to draw the line.
theonlygusti wrote:
I'd like to point out that there is no work around.
Would you like to explain how you reached that conclusion? Because I'm pretty sure I can prove it false right now.

Okay: any “workaround” will only be able to run after the green flag has been clicked, or during the project's running-time. Every event hat block currently in Scratch can run without the green flag being clicked.

DaSpudLord

theonlygusti wrote:
DaSpudLord wrote:
adespotist wrote:
DaSpudLord wrote:
So how easy do you want us to make coding? Do you want us to make coding super easy to the point where there is literally no effort involved? How about we add a block that does this?
when gf clicked
make a platformer::control
also I want there to be enemies that shoot [fireballs v]::motion
We can't make coding too easy, now can we?
https://en.wikipedia.org/wiki/Slippery_slope

No one ever said anything about making enemies that shoot fireballs. I suggest you look at the “related” section of that article to brush up on your other logical fallacies too.
https://yourlogicalfallacyis.com/the-fallacy-fallacy
I suggest you read that.
No, adespotist doesn't need to read that, as he is not subject to the fallacy-fallacy. You are however subject to the slippery slope fallacy, because the implementation of this block does not mean that soon all Scratchers will devolve into mindless zombies because Scratch is too easy. Also, you have not provided any evidence or rational behind your claim that soon Scratch will be using a make platformer block.

Who decides who is subject to who's fallacy? And I'm not saying that the implementation of this block will cause all Scratchers to “devolve into mindless zombies.” I'm saying this will set a precedent that users can request blocks that make programming easier, even totally unimportant events that would only matter in a few select circumstances, and all of those will be added under the logic that “the variable one was added, so why not this one,” and not only will the block library become much, much larger, thus raising Scratch's low floor, but it will also destroy the purpose of programming by making users used to easy programming.

theonlygusti wrote:
DaSpudLord wrote:
Anyway, fallacies, aside, you know what I mean. I'm saying we can't make something too easy by adding blocks that do everything, and at some point we have to draw the line.
theonlygusti wrote:
I'd like to point out that there is no work around.
Would you like to explain how you reached that conclusion? Because I'm pretty sure I can prove it false right now.

Okay: any “workaround” will only be able to run after the green flag has been clicked, or during the project's running-time. Every event hat block currently in Scratch can run without the green flag being clicked.

But how would a variable be changing when the project is not running? The only way a variable can change is through a block, and the only way that block takes effect is when the project is running.

Last edited by DaSpudLord (April 28, 2016 19:26:22)

jokebookservice1

Support

DaSpudLord wrote:
-snip-
But how would a variable be changing when the project is not running? The only way a variable can change is through a block, and the only way that block takes effect is when the project is running.

It can change if it is a cloud variable, or if it is triggered by an event that is not the green flag hat. But anyway, there is a workaround:

when [timer v] > (-1)
forever
    ...//put green flag workaround here
end

iamunknown2

DaSpudLord wrote:
joefarebrother wrote:
change [ v] by (0)
has an easy workaround, but I bet you still use that.

If you had to use a workaround a lot, the ratio of boilerplate code to code that actually does stuff adds up.
So how easy do you want us to make coding? Do you want us to make coding super easy to the point where there is literally no effort involved? How about we add a block that does this?
when gf clicked
make a platformer::control
also I want there to be enemies that shoot [fireballs v]::motion
We can't make coding too easy, now can we?

There are 4 levels of complexity (with sublevels in-between):

Super low level. This means that you are only equipped with a bit reader, a bit writer and a bit cursor mover.
Low level. You have basic blocks you need for practically everything, and that's about it.
High level, but still good programming. High-level programming means learning more complex but handy systems to use in programming.
You don't de the actual work level. This is when you leave everything to the AI.

The point of programming is to get the work done elegantly - not use a dozen of ugly workarounds that can mess up your program and require you to spend countless hours to debug.

jokebookservice1

This has turned out to be a duplicate: https://scratch.mit.edu/discuss/topic/196179/ THE LINK IS THIS: https://scratch.mit.edu/discuss/topic/94460/ but I do support the idea.

Last edited by jokebookservice1 (June 5, 2016 00:06:29)

Austinato

jokebookservice1 wrote:
This has turned out to be a duplicate: https://scratch.mit.edu/discuss/topic/196179/ but I do support the idea.

The link you provided is the same as this discussion…

Last edited by Austinato (June 4, 2016 23:58:14)

jokebookservice1

Austinato wrote:
jokebookservice1 wrote:
This has turned out to be a duplicate: https://scratch.mit.edu/discuss/topic/196179/ but I do support the idea.
The link you provided is the same as this discussion…

Sorry 'bout that EDIT: Fixed btw

Last edited by jokebookservice1 (June 5, 2016 00:06:51)

Austinato

jokebookservice1 wrote:
Austinato wrote:
jokebookservice1 wrote:
This has turned out to be a duplicate: https://scratch.mit.edu/discuss/topic/196179/ but I do support the idea.
The link you provided is the same as this discussion…
Sorry 'bout that EDIT: Fixed btw

No problem.

f1lip

I don't support as you can sense variable changes with broadcasting. Just make a broadcast message and call it var change. Use the following code below.

when green flag clicked
change [var v] by (1)
if <(var) = [1 ]> then
   
broadcast [var change v]
end

when I receive [var change v]
do the thing

Try experimenting with that code in the editor and see what happens by modifying the code or try it in a game you are making.

customhacker

Support

DiamondSmartTuber

when [my variable v] changes ::hat events

when green flag clicked
forever
set [var2 v] to (var1)
wait (0) secs
end

when green flag clicked
wait (0) secs
forever
if <not <(var1) = (var2)>> then
broadcast [ v]
end
end

Discuss Scratch