when variable changes

jmb1293634

sorry if this was a duplicate I did check hard I checked the directory and 100 pages of the suggestions forum so here it is:

when [ v] changes::variables hat

so if the selected variable changes then it starts a script under it could also be:

[ v] changing?::variables boolean

cloverfly also suggested

wait until [ v] changes::variables stack

and

repeat until [ v] changes{

}::variables

acohen_bhused also suggested

if [variable v] changes{

}::variables

cloverfly also suggested

if [variable v] changing{
}else{
}::variables

note: all the last ones would be very easy to workaround with

[ v] changing?::variables boolean

so I don't really care about those

Last edited by jmb1293634 (May 1, 2025 15:36:00)

YtArie5

A workaround DOES exist but it's a but annoying

wait until <not <(foo) = [something]>>
...

cloverfly

[variable v] changing?::variables boolean

seems rather ambiguous. would it be true on like, the frame the variable changes?

jmb1293634

cloverfly wrote:
[variable v] changing?::variables boolean
seems rather ambiguous. would it be true on like, the frame the variable changes?

yes but generally the hat is better so if I had the choice I would use that

jmb1293634

Bump
u
m
p

jmb1293634

bump
u
m
p

jmb1293634

bump
uu
m m
p p

cloverfly

when [variable v] changes::variables hat

is cool
I think it should be events:

when [variable v] changes::events hat

there should also be

wait until (variable v) changes :: control

and

repeat until (variable v) changes {
} :: control

jmb1293634

cloverfly wrote:
when [variable v] changes::variables hat
is cool
I think it should be events:
when [variable v] changes::events hat
there should also be
wait until (variable v) changes :: control
and
repeat until (variable v) changes {
} :: control

added to main suggestion

greenrid

I support!
However, the

<[variable v] changing?::variables>

Boolean block could be turned into this to make a little more sense:

<When [variable v] changes::variables>

This way, it would be easier to tell what it means!

cake__5

here is the workaround

set [temp v] to (a)
wait until <not <(temp) = (a)>>
your code here::#0000ff

BigNate469

cake__5 wrote:
here is the workaround
set [temp v] to (a)
wait until <not <(temp) = (a)>>
your code here::#0000ff

But that hangs the thread (prevents code later on from executing until the variable changes).

A better workaround would be:

forever
if <not<(previous value) = (variable)>> then
broadcast [variable has changed v]
end
set [previous value v] to (variable)
... // other code
end
when I receive [variable has changed v]
... // code for when variable changes here

Or, alternatively:

when [timer v] > ((timer) + <not <(previous value) = (variable)>>)
set [previous value v] to (variable)
... // code for when variable changes here

Last edited by BigNate469 (Jan. 21, 2025 15:18:57)

jmb1293634

bumpbumpbump

jmb1293634

bumpbumpbump

jmb1293634

bumpbumpbump
bump
bump

TheGreatestGoofy

nice, but mentioned above, there are workarounds

buhmppp

Last edited by TheGreatestGoofy (Jan. 24, 2025 19:04:45)

jmb1293634

bump

seriouslyscratchy1

Support! High five!

AHypnoman

seriouslyscratchy1 wrote:
Support! High five!

Please tell us why you support - asserting support, or lack-thereof, doesn't contribute to the discussion - the forums are not for polling.

jmb1293634

bump

Discuss Scratch