When variable changes

jokebookservice1

Support, it would look as mentioned in this thread https://scratch.mit.edu/discuss/topic/196179/ (i.e. orange in the Data category) and there it mentions the possibilities with Cloud Variables. I would also support for a list hat block counterpart

Austinato

I do not support this suggestion for two reasons:

1. Many workarounds.
Self explanatory; there are quite a few work arounds to this block, as mentioned by people above.

2. Programming Skills
If you disagree with 1, then remember - Scratch is designed to be an easier way to teach coding to all ages, but not too easy, as mentioned by rdococ:

rdococ wrote:
. . .

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

Last edited by Austinato (June 4, 2016 23:57:05)

Lythium

Support, as per bobbybee and jokebookservice1.

joefarebrother

Support.

There are 2 ways to do something similar in JavaScript:

1.

function watchChanges(obj, prop, callback){
  var old = obj[prop];
  window.setTimeout(function(){
    while(old === obj[prop]) /*nothing*/ ;
    old = obj[prop];
    callback(old);
  }, 1);
}

2.

function watchChanges(obj, prop, callback){
  var val = obj[prop];
  Object.defineProperty(obj, prop, {
     configurable: true,
     enumerable: true,
     writable: true,
     get: function(){return val;},
     set: function(newVal){
       val = newVal;
       callback(newVal);
     }
   });
}

If you've ever used JS before, you'll be able to see that the second one is WAY more efficient, because the first is checking every clock cycle, while the second does nothing until the variable is actually changed. The first way is also prone to race conditions where the variable could change too fast for it to notice.

But by rejecting this suggestion, you're essentially saying that Scratch should only teach the first way.

Last edited by joefarebrother (June 5, 2016 08:44:08)

Charles12310

No support. Not necessary really. I mean, do we need all of this?

when [x position v] changes :: hat motion

when [pen size v] changes :: pen hat

when [list v] changes :: list hat

when [variable v] changes :: variables hat

when [ghost effect v] changes :: looks hat

Last edited by Charles12310 (Nov. 18, 2017 00:37:05)

290Scratcher

No support as there is an easy workaround.

when green flag clicked
forever
if <not <(Score) = [Something]>> then
...
end
end

Charles12310

290Scratcher wrote:
No support as there is an easy workaround.
when green flag clicked
forever
if <not <(Score) = [Something]>> then
...
end
end

I don't think that's proper workaround.

when green flag clicked
forever
set [variable value check v] to (variable you want to detect changed)
wait until <not <(variable value check) = (variable you want to detect changed)>>
...
end

i8ey

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?

Were do you get when score changes? Please tell me I need it for my game.

DaEpikDude

i8ey wrote:
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?
Were do you get when score changes? Please tell me I need it for my game.

It's the suggestion.
A workaround for the block is:

when gf clicked
forever
set [original v] to (score)
wait until <not <(original) = (score)>>
...
end

You can use that for now.

Supreme_Scratcher

The workarounds may be fairly easy, but this may still be a good idea

Also the whole thing about hacking in the above comments is a little over the top.

when green flag clicked

forever
say (STOP THE HACKING COMMENTS!!!)

roboboy12504

I actually could use this right now. And while I love the ideas in these workarounds I just think that a block dedicated solely to this would allow more functionality in the code it's being used for.

Not_Me_You_Me_Me

roboboy12504 wrote:
I actually could use this right now. And while I love the ideas in these workarounds I just think that a block dedicated solely to this would allow more functionality in the code it's being used for.

First, kind of a necro, don't think ST is gonna add it after over three years. Second, actually having the block wouldn't provide any more functionality than these workarounds.

Last edited by Not_Me_You_Me_Me (Sept. 5, 2018 23:55:58)

TheAdriCoolManDude

No support, just do this:

forever
if <not <(foo) = [stuff]>> then
even more stuff :: stacks grey
end
end

Botcho_Otkho

removed because this post was cringe

Last edited by Botcho_Otkho (Oct. 13, 2020 15:55:11)

jdefayette

SUPPORT 110%

1) Event-based programming means 98% fewer errors in complex code. Very efficient for teams and for code that must evolve over time.
2) Work-arounds that pro-actively execute code when the variable is changed require complete knowledge and memory of every use of that variable and event. Death for a large project.
3) Work-arounds that require constant monitoring and polling of variables are resource (space and cycle) inefficient.

Just for the record, I am brand-new to Scratch, and so far it seems to be a great teaching tool for my kids. I don't want them to learn kludges….

Parma John

ILikeCorn

Broadcasting works, but if you were using it with a clone, it is impossible to do that. Its the only major problem. It would be nice to have an “if variable changes” block.

awesome5185

Support as the workarounds mainly feature forever blocks which are known to lag projects when used excessively.

Jonathan50

awesome5185 wrote:
Support as the workarounds mainly feature forever blocks which are known to lag projects when used excessively.

Use BROADCAST AND WAIT. If you like you could write a block to change it.

imfh

jdefayette wrote:
SUPPORT 110%

1) Event-based programming means 98% fewer errors in complex code. Very efficient for teams and for code that must evolve over time.
2) Work-arounds that pro-actively execute code when the variable is changed require complete knowledge and memory of every use of that variable and event. Death for a large project.
3) Work-arounds that require constant monitoring and polling of variables are resource (space and cycle) inefficient.

Just for the record, I am brand-new to Scratch, and so far it seems to be a great teaching tool for my kids. I don't want them to learn kludges….

Parma John

1. In Scratch, event based programming is usually done with broadcast blocks. This is arguably more organized than variable changing as they have names which clearly describe the event. Variables can have names too, but it is much more difficult to keep track of every time they are used.

2. Not necessarily. If broadcasts are used whenever a variable is changed, then it isn’t necessary to remember every place it is changed so long as they are put in as the project is made. This also encourages better practice of only throwing events when necessary. Often people check if the high score needs updating every time a variable is changed(or worse in a forever loop) when they should just check at the end of the game.

awesome5185 wrote:
Support as the workarounds mainly feature forever blocks which are known to lag projects when used excessively.

3. This could potentially hurt performance as well since it essentially makes variable set/change blocks double as broadcast blocks. For projects that run intense calculations, that small change would add up.

ILikeCorn wrote:
Broadcasting works, but if you were using it with a clone, it is impossible to do that. Its the only major problem. It would be nice to have an “if variable changes” block.

Actually clones work perfectly fine with broadcasts. Clones contain every single block that the sprite they were cloned from has. They can receive broadcasts and other events just like the parent. This means if you broadcast to a sprite to clone itself, the clones will also clone themself(which is a very common error).

Last edited by imfh (Dec. 11, 2019 21:56:15)

findanegg

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?!

Edit: I… I don't know what I was trying to say here.

programming at its core is about copying code from stackoverflow finding solutions to problems. this is a problem and the workaround is a solution. which you both got from stackoverflow

Discuss Scratch