Scratch

Ah yes, I found this out when I was writing a script to only update the variable when it actually changes. Then I found out I didn't need to do that, it was already done for me.

I would suggest using broadcasts instead, since the same broadcast can be sent repeatedly without Scratch thinking "oh, I've already sent this, ignoring". But you do loose some speed when using broadcasts instead of variables.

Something you could do, is just add a zero before each variable update so like: sensor-update "test" 01, sensor-update "test" 001, etc. I don't know if it works, but it's a possibility. You could also do something like: sensor-update "test" "1 ignore everything after the first space" and just have the program ignore any extra data except for the first integer.

Hopefully that helps. 

SimpleScratch wrote:

I would suggest using broadcasts instead, since the same broadcast can be sent repeatedly without Scratch thinking "oh, I've already sent this, ignoring".

I'm using broadcasts as well but some users want to use variables (they think its a more "grown-up" way of doing it).

I use Scratch with age7-11 year olds and don't use variables much so I'm happy to use broadcasts but I'm just try to please ALL my potential users 

Yeah, variables would probably be a more "grown-up" way. But sometimes using the easier way can be more efficient depending on what you are doing.

But you do loose some speed when using broadcasts instead of variables.

I never thought/realised that there would be a speed issue - I'm just controlling LEDs ans simulating Trafiic Lights at the moment.  I'll have to check speed out once I start trying to build a line following robot 

The only reason broadcasts slow down Scratch, is because Scratch looks for any hats waiting to receive that block. It shouldn't make much of a difference as long as you aren't updating something more than 4 times a second.

Do you think if Scratch was changed to do sensor-updates on set and change variable blocks it would break any code that you've written or know about?

It wouldn't "break" any of my current projects or old ones, it would just remove some "potential" features. Like automatically stopping repeated messages on my future Chat server. But that isn't much of an issue. It won't be hard to create any scripts that stop duplicate messages from being sent for any future projects.

The main problem for me about changing Scratch to send updates every time a variable is updated (whether it's the same value or not) is saving bandwidth over the internet. But I'm sure there are things I can do to do that anyways.

You could also do something like: sensor-update "test" "1 ignore everything after the first space" and just have the program ignore any extra data except for the first integer.

Didn't really understand this - its the fact that I can't get Scratch to send sensor-update messages, not any problem in dealing with them when I get them 

Basically, you send sensor-update "test" "1" the first time. Then you send sensor-update "test" "1 1" the second time. On the third you could do either sensor-update "test" "1" again or sensor-update "test" "1 2". You would have an external application that parses the value of "test" to see if there is any "useless" data added to the sensor-update and have it ignore that. Bypassing Scratch's "same value, ignore" routine.

Scratch sends "1" and the application sends 1 to the hardware.
Scratch sends "1 2" and the application sends 1 to the hardware.
Scratch sends "1" and the application sends 1 to the hardware.

Does that make more sense?

So does

set [var v] to (var)

You could make a variable value of something like "Ping!" which would just awake scratch. The RSC client would ignore that value.