Wait until versions of hats

[sarpnt]

hats can't be put in rings, can't be disabled, can't be put in libraries, and in general can't be worked with like actual blocks.
snap can easily LAUNCH scripts, so WAIT UNTIL versions of nearly all these blocks could work as a replacement. it would probably make a lot of things that are already possible a lot easier.

[coder_07]

@sarpnt

hats can't be put in rings

@ego-lay_atman-bay

hey guys, I managed to put hat blocks in grey rings (by editing the xml), so here they are

and here's the link so you know this is not a prank https://snap.berkeley.edu/snap/snap.html#present:Username=ego-lay_atman-bay&ProjectName=hat%20blocks%20in%20grey%20rings

[pumpkinhead]

but that isn't intentional behavior and so isn't functional.

if they don't add this anytime soon, there are a few workarounds i thought of:

1. set a variable to true whenever the hat block in question is ran. in a separate script, wait until or read if the variable is true, then set it back to false and do whatever it is. or, you can set it back to zero whenever the frame is done processing.
2. if multiple scripts want to read the variable and you don't know when/where the frame will finish processing, instead of setting it to true when the hat block is ran, set it to the number of scripts that want to read the value. when a script reads the variable and it is greater than zero, decrement it.
3. for waiting until the hat block is ran -- have a list of continuations/lambdas that will be ran whenever the hat block is fired. if you want to wait until the event happens in a script, capture its continuation, put it in the aforementioned list and stop the script. that way it will be resumed when the hat block is ran. you can also use this as asynchronous callback functions.

[sarpnt]

that doesn't work for libraries, requires every sprite to have those particular scripts and sprite variables to make this possible, and because of the variable, codification has all sorts of scoping issues.

[bh]

Hat blocks (other than the generic WHEN) are better than WAIT UNTIL because the latter has to keep checking the condition, while the specific hat blocks can be triggered by the event happening. E.g., you have a WHEN SPACE KEY PRESSED hat block, and the code inside Snap! that reads from the keyboard can check for WHEN _ PRESSED waiting scripts and start them, no polling needed.

We could do it if we made a separate WAIT UNTIL for each hat block, e.g., WAIT UNTIL KEY SPACE PRESSED, that would add the current thread to an event queue as if it were the hat block.

[d4s_over_dt4]

@bh

while the specific hat blocks can be triggered by the event happening

Using JS:(not snap source code tho)
Hat:
addEventListener("mouseup",e)
Wait:
var mouse=false;
addEventListener("mouseup",()=>mouse=false)
addEventListener("mousedown",()=>mouse=true)
setInterval(()=>{if(mouse)k()},20)

[bh]

@bh

We could do it if we made a separate WAIT UNTIL for each hat block, e.g., WAIT UNTIL KEY SPACE PRESSED, that would add the current thread to an event queue as if it were the hat block.

Aren't you saying the same thing I said? If you write code for the specific case of a keypress, then you can get in the event queue for key presses, same as the hat block does. But we don't have a WAIT UNTIL KEY _ PRESSED block; we just have a generic WAIT UNTIL <predicate>. That works by polling, like the generic WHEN <predicate> hat block.

[d4s_over_dt4]

@bh

Aren't you saying the same thing I said

Yes,thats exactly what i am saying

[sarpnt]

this is exactly what i'm suggesting.

[bh]

@sarpnt

this is exactly what i'm suggesting.

Okay, so, you're asking for half a dozen new Control blocks. It's not a stupid idea, but it's a big ask. You'd have to catch Jens in a really good mood. :~)

[sarpnt]

only 4:
wait until key pressed (with key repeat and the "any key" feature)
wait until i am [clicked v] (not including [stopped])
wait until i receive [ v] (data)
Wait until [ v] is edited (capitalized for some reason)

it would be 3 if that edited block wasn't added, i can't be bothered to figure out what that block actually does, so you might only need 3 if the wait block wouldn't make sense for that.

[ego-lay_atman-bay]

The edited block just triggers whenever the user edits whatever is in the first input.

[bh]

We have WHEN I AM EDITED??

[bh]

@sarpnt

you might only need 3

Okay, I'll remember this for the next leisurely moment to ask Jens about.

[ego-lay_atman-bay]

Well, it's WHEN [sprite v] IS EDITED, and an option is "anything".

[mr_owlssssnap2]

i also did this

[d4s_over_dt4]

me too,when trying to get hats out of stuff

[qw23]

If you're planning to build WAIT UNTIL versions of WHEN (hat) blocks you may want to consider constructing a more general solution, separating WHEN / WAIT UNTIL from the event they're waiting to be triggered by:

This would probably involve a new data type (event, trigger or something; or perhaps it already exists “under the hood”).The main advantage would be that whatever sort of trigger is going to be invented somewhere down the road, will be easy to fit in. On balance, no extra primitive blocks are required for now (provided the existing WHEN and WAIT UNTIL blocks can be used both for this kind of event-triggered operation and for their existing condition-polling purposes).

[bh]

@ego-lay_atman-bay

WHEN [sprite v] IS EDITED

Huh. You learn something every day. Thanks.