Variable Sensing

The_5th_Scratcher

The boolean blocks are NO LONGER part of the suggestion!

I think a couple of blocks in the variable category could detect a change in variables. These would work for the shortest amount of time used in the coding interface. (I think it is 0.025 seconds)

The first block is very simple. It would just detect if the variable is different then it was a few milliseconds earlier. The last one would detect if the variable was changed by a certain number. (Ex. changed by 10)

[variable v] changed::variables hat //these would start a line of code
[variable v] changed by [number]::variables hat

wait until [variable v] changed ::variables

repeat until [variable v] changed {

}::variables

Even though one or more of these blocks can probably be made through the custom blocks option, I just think that these would be a good idea.

Workaround for the first hat block by Chiroyce:

when green flag clicked
set [cached var v] to (my variable)

when [timer v] > ((timer) - <not <(cached var) = (my variable)>>)
set [cached var v] to (my variable)
say [Variable changed!] for (2) secs // change this to code that should be run when the variable is changed

Last edited by The_5th_Scratcher (July 25, 2022 19:38:23)

Steve0Greatness

It looks like you're trying to use the block plugin. Here, let me help.
Here's what you may be trying to do with the block plugin:

[scratchblocks]<(☁variable) changed::sensing>
<(☁variable) changed from [] to []::sensing> 
<(☁variable) changed by [(Number or user)]::sensing>[/scratchblocks]

Preview:

<(☁variable) changed?::sensing>
<(☁variable) changed from [] to []?::sensing> 
<(☁variable) changed by [(Number or user)]?::sensing>

If you need more info, please consult the wiki article for the block plugin, or the guide for how to use the block plugin.

The_5th_Scratcher

Steve0Greatness wrote:
It looks like you're trying to use the block plugin. Here, let me help.

Thank you, but I'm looking for feedback (Yes, that was what I was trying to do,Thank you very much

)

han614698

For -Steave0Greatness-:
I think it should be

<[☁variable v] changed::sensing>
<[☁variable v] changed from [] to []::sensing> 
<[☁variable v] changed by [(Number or user)]::sensing>

not

<(☁variable) changed::sensing>
<(☁variable) changed from [] to []::sensing> 
<(☁variable) changed by [(Number or user)]::sensing>

Support, this would help reduce the number of broadcasts.

EatNYeet

han614698 wrote:
For -Steave0Greatness-:
I think it should be
<[☁variable v] changed::sensing>
<[☁variable v] changed from [] to []::sensing> 
<[☁variable v] changed by [(Number or user)]::sensing>
not
<(☁variable) changed::sensing>
<(☁variable) changed from [] to []::sensing> 
<(☁variable) changed by [(Number or user)]::sensing>
Support, this would help reduce the number of broadcasts.

If it's variable sensing, it doesn't feel right for it to look line sensing blocks. A minor change as well:

<[☁variable v] changed::variables>
<[☁variable v] changed from [] to []::variables> 
<[☁variable v] changed by [Number v] []::variables>//this looks nicer as a dropdown menu

Support.

It's such a pain to try and find a previous variable, but there could be some hat blocks for these as well, like how there's hat blocks and sensing blocks for the “key () pressed?” block.

when [variable v] changes::variables hat
when [variable v] changes from [] to []:: variables hat
when [variable v] is changed by [number v] []::variables hat

Last edited by EatNYeet (May 1, 2021 03:17:37)

Steve0Greatness

han614698 wrote:
-Steave0Greatness-

now this is just getting offending…

EatNYeet

Steve0Greatness wrote:
han614698 wrote:
-Steave0Greatness-
now this is just getting offending…

Ripperoni…

Let's try to keep things on topic, please.

fdreerf

The boolean blocks are useless and ambiguous. They would just return true and then immediately return false, since changing a variable is an action, not a condition.

The_5th_Scratcher

Update: I made the variable sensing in the variable category as requested & made it dropdown. Thanks for all the support!

fdreerf wrote:
The boolean blocks are useless and ambiguous. They would just return true and then immediately return false, since changing a variable is an action, not a condition.

You can do this:

wait until <[variable v] changed ::variables>

forever
if <[variable v] changed ::variables> then

end
end

fdreerf

The_5th_Scratcher wrote:

You can do this:

wait until <[variable v] changed ::variables>

forever
if <[variable v] changed ::variables> then

end
end

Even then, this has the exact same problem as the broadcast received boolean. Will it return false when you click the green flag? Will it turn true and stay true forever when the variable changes? There's too much ambiguity.

The_5th_Scratcher

-bump-

DarthVader4Life

fdreerf wrote:
The boolean blocks are useless and ambiguous. They would just return true and then immediately return false, since changing a variable is an action, not a condition.

Actually, only the

<[variable v] changed? ::variables>

is, since

<[variable v] changed from [ ] to [ ] ::variables>

is a condition that only returns true if the previous input of that variable was a certain number and it changed to another certain number. Also, the

<[variable v] changed by [ ] ::variables>

should be changed to

<[variable v] changed by < > ::variables>

so you can do both intentions

when green flag clicked
if <[variable v] changed by <(number) = ((number) - (0))> ::variables> then

end

when green flag clicked
if <[variable v] changed by <(username ::sensing) = [ RandomUser ]> ::variables> then

end

And you don't have much ambiguity on how it would know the difference between a number and a username.

Last edited by DarthVader4Life (May 2, 2021 15:34:38)

fdreerf

DarthVader4Life wrote:
<[variable v] changed from [ ] to [ ] ::variables>
is a condition that only returns true if the previous input of that variable was a certain number and it changed to another certain number. Also, the

But will it stay true forever? When will it become false? It's a pointless block as really the only true definition is to become true and then immediately become false.

Last edited by fdreerf (May 2, 2021 21:31:51)

The_5th_Scratcher

fdreerf wrote:
is to become true and then immediately become false.

It would turn false after 0.025 seconds, long enough for a string of code to be triggered

The_5th_Scratcher

DarthVader4Life wrote:
And you don't have much ambiguity on how it would know the difference between a number and a username.

Maybe the username part shouldn't be a part of this suggestion

han614698

fdreerf wrote:
The boolean blocks are useless and ambiguous. They would just return true and then immediately return false, since changing a variable is an action, not a condition.

This is the exact reason why

[message v] received::events boolean

is rejected.

Maybe,

wait until [var v] changes::variables stack

The_5th_Scratcher

due to a suggestion like this one being rejected because of booleans, I have decided to replace that part of the suggestion with these:

wait until [variable v] changed ::variables

repeat until [variable v] changed {

}::variables

I also added the hat blocks a few days ago because that was my original intent with this suggestion.

(This is starting to seem like it would be an extension like “pen” and “music”

The_5th_Scratcher

Many people have said:
BUMP

The_5th_Scratcher

BUMP

The_5th_Scratcher

BUMP bump BUMP bump

Discuss Scratch