(Edit: This post is several years old.)

when [score v] changes :: events hat
say [It changed!] for (2) secs

When the variable specified changes, the script runs. I think it would be one of the most intuitive blocks in the language. Not only that, but it will reduce the amount of forever loops people use in games.

Any thoughts?

No support, easy workaround…

forever
    
if <doing something :: sensing> then
    
change [score v] by (1)
... :: grey
end

end

No support, workaround:

when green flag clicked
forever
set [storage v] to (var)
wait until <not<(var) = (storage)>>
do stuff...::grey
end

Easy workaround? Yes. But good workaround? Not so much.

I'm in full support; getters and setters teach much better programming practices than ugly polling hacks like those posted above.

bobbybee wrote:

Easy workaround? Yes. But good workaround? Not so much.

I'm in full support; getters and setters teach much better programming practices than ugly polling hacks like those posted above.

Then we'd have 100 hat blocks.

(Edit: This post is several years old.)

Why don't we get rid of the move block too? That has a workaround. When sprite clicked has a workaround too, let's get rid of that.
</sarcasm>

Seriously? Did you guys completely forget that Scratch was made to help students learn about programming?!

I support, but there should be a boolean like it too.
Here's a workaround until it's added:

when green flag clicked
forever
    
wait until <not <(oldscore) = (score)>>
set  [oldscore v] to (score)
broadcast [score changed! v]
end

I think a boolean form would be rejected for the same reason < broadcasted?> was.

rdococ wrote:

I think a boolean form would be rejected for the same reason < broadcasted?> was.

Oh yeah, that's right.
All righty then, full 100% support!

No support. I'm not one to like workarounds, but I definitely think the workaround(s) given are “better” than the suggestion, and for a few reasons.
1) I would never find this handy. Because I don't see why you wouldn't know when a variable changes in your own project. (If you mention remixes, then consider the ratio of original projects to remixes. Then, consider how many of those remixes don't even include a single change.)
2) Again, I don't really like workarounds, but in this case, I would definitely prefer them over your suggestion.

rdococ wrote:

Why don't we get rid of the move block too? That has a workaround. When sprite clicked has a workaround too, let's get rid of that.
</sarcasm>

Seriously? Did you guys completely forget that Scratch was made to help students learn about programming?!

No, people didn't forget. Learning includes learning ways to do things, not having blocks already made for you to do so. It's called avoiding laziness.

bobbybee wrote:

Easy workaround? Yes. But good workaround? Not so much.

I'm in full support; getters and setters teach much better programming practices than ugly polling hacks like those posted above.

Good workaround? Yes. It's not hacks. It's called knowledge. And it's very simple compared to other things you can do in Scratch.

_Hope wrote:

bobbybee wrote:

Easy workaround? Yes. But good workaround? Not so much.

I'm in full support; getters and setters teach much better programming practices than ugly polling hacks like those posted above.

Good workaround? Yes. It's not hacks. It's called knowledge. And it's very simple compared to other things you can do in Scratch.

I disagree. Creating a thread with the sole purpose of repeatedly performing a comparison is a nightmare.

The workaround and the hat block are fundamentally different solutions to the same problem.

In the workaround, the variable is treated as volatile input which is constantly changing and therefore is being monitored.

In the event hat block, the variable is treated as an event source which will change once in a while as a result of another event.

These two philosophies are dramatically different, and they have dramatically different applications. I can imagine plenty of use cases when both are being used in the same project: for instance, in a hypothetical Mario clone, we might be using the “workaround” polling methodology for changing the score colour whenever the player earns points; however, we would want to be using the hat block as opposed to the polling method for updating the music whenever the level changes.

Again, you might retort that broadcasts are better here. They probably are. But broadcasts themselves have a very different usage compared to variable events.

Last but not least, if you read all of that, even if you disagree, I love you; have a cookie <3

I sort of agree with bobbybee on this. Let's say that you have the following scripts:

when green flag clicked
forever
wait until <not<(var) = [0]>>
turn cw (15) degrees
end

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

The sprite does not turn because the wait until (which is essentially and empty repeat until…) does not execute the logic statement fast enough to detect the sudden variable spike.

peppermintpatty5 wrote:

I sort of agree with bobbybee on this. Let's say that you have the following scripts:

when green flag clicked
forever
wait until <not<(var) = [0]>>
turn cw (15) degrees
end

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

The sprite does not turn because the wait until (which is essentially and empty repeat until…) does not execute the logic statement fast enough to detect the sudden variable spike.

That's not quite the use case that matters here, but yes, this block would actually fire twice in this event (pun intended)

bobbybee wrote:

_Hope wrote:

bobbybee wrote:

Easy workaround? Yes. But good workaround? Not so much.

I'm in full support; getters and setters teach much better programming practices than ugly polling hacks like those posted above.

Good workaround? Yes. It's not hacks. It's called knowledge. And it's very simple compared to other things you can do in Scratch.

I disagree. Creating a thread with the sole purpose of repeatedly performing a comparison is a nightmare.

The workaround and the hat block are fundamentally different solutions to the same problem.

In the workaround, the variable is treated as volatile input which is constantly changing and therefore is being monitored.

In the event hat block, the variable is treated as an event source which will change once in a while as a result of another event.

These two philosophies are dramatically different, and they have dramatically different applications. I can imagine plenty of use cases when both are being used in the same project: for instance, in a hypothetical Mario clone, we might be using the “workaround” polling methodology for changing the score colour whenever the player earns points; however, we would want to be using the hat block as opposed to the polling method for updating the music whenever the level changes.

Again, you might retort that broadcasts are better here. They probably are. But broadcasts themselves have a very different usage compared to variable events.

Last but not least, if you read all of that, even if you disagree, I love you; have a cookie <3

I'm sorry. I read everything except the big paragraph near the middle.
I guess all I can say is that I have never and would never find this useful, so…I will back off on this.

bobbybee wrote:

_Hope wrote:

bobbybee wrote:

Easy workaround? Yes. But good workaround? Not so much.

I'm in full support; getters and setters teach much better programming practices than ugly polling hacks like those posted above.

Good workaround? Yes. It's not hacks. It's called knowledge. And it's very simple compared to other things you can do in Scratch.

I disagree. Creating a thread with the sole purpose of repeatedly performing a comparison is a nightmare.

The workaround and the hat block are fundamentally different solutions to the same problem.

In the workaround, the variable is treated as volatile input which is constantly changing and therefore is being monitored.

In the event hat block, the variable is treated as an event source which will change once in a while as a result of another event.

These two philosophies are dramatically different, and they have dramatically different applications. I can imagine plenty of use cases when both are being used in the same project: for instance, in a hypothetical Mario clone, we might be using the “workaround” polling methodology for changing the score colour whenever the player earns points; however, we would want to be using the hat block as opposed to the polling method for updating the music whenever the level changes.

Again, you might retort that broadcasts are better here. They probably are. But broadcasts themselves have a very different usage compared to variable events.

Last but not least, if you read all of that, even if you disagree, I love you; have a cookie <3

Browser cookie :3 . Also, scratch runs at 30FPS and if we had Scratch 2 go at 60FPS, it'll be more likely to detect somethiny using a wait until block peppermintpatty5, however the script should always work becuase of the code, yet the variable spike is too fast to execute the block after the wait until. Also, those kinds of loops can slow down projects.

Sorry, this can only be a block if the workaround is too long or tedious and if people are actually going to find this useful.

The workaround is way too easy. I really don't think you're going to be needing so many of these that your block would save space.

And what would people use this for? Are there really lots of projects that need to detect variable changes?


And also why not this.

when green flag clicked
forever
    
if <(Something) = (Happened)> then
    
change [Variable v] by (Any number)
Do stuff that happens when the variable changes, or make a broadcast.::grey
Why not use a broadcast after the variable changes?::grey
end

end

rdococ wrote:

when [score v] changes :: events hat
say [It changed!] for (2) secs

When the variable specified changes, the script runs. I think it would be one of the most intuitive blocks in the game. Not only that, but it will reduce the amount of forever loops people use in games.

Any thoughts?

I think that it is very simple to do without a new block

Support because of BobbyBee's reasoning, and the lag reduction this block would provide over its workaround.

No support. Easy Workaround…

when green flag clicked
change [score v] by (1)
broadcast [score change v]

when I receive [score change v]
if <(score) = [ 1]> then
say [the score has changed.] for (2) secs    
end

No support. Either f1lip's workaround or peppermintpatty5's workaround do really well. I actually used peppermintpatty5's storage variable idea to detect when the timer goes up to rotate the hand on a stop watch (I gave credit, of course).

when I receive [ begin]
repeat until <[(round (direction))] = [ 90]>
    
set [ old timer] to [ timer]
wait until <not <[ old timer] = [ timer]>>
turn cw () degrees
end