Asynchronous Custom Blocks

Jonathan50

Asynchronous Custom Blocks
What this is suggesting is the ability to make a custom block run in a separate thread, or run asynchronously from the caller script (script/s using the custom block). This would mean that the caller script could call the custom block and while the custom block is busy running in the background, do it's own stuff, even if the custom block had a forever loop.

This is sort of like comparing broadcast and broadcast and wait. Broadcast runs all receiving scripts and continues on the main thread while the receiver scripts are running, but broadcast and wait waits for all receiving scripts to finish before continuing. This would be especially useful for 1s1s projects.

Take this example: For a game, you could have a custom block that would handle arrow keys something like this:

when gf clicked
wait until <(start) = [1]>
handle controls until [stop]
repeat until <(stop) = [1]>
  ... // do other stuff
end

define handle controls until (end)
repeat until <((end) of [Stage v]) = [1]> // Sorry this has to be modified outside
  if <key [left arrow v] pressed?> then // of Scratch ("hacked") because of an issue with my
    point in direction (-90 v) // chosen example
    move (speed) steps
  end
  if <key [right arrow v] pressed?> then
    point in direction (90 v)
    move (speed) steps
  end
  ...
end

The two repeat until loops would run at the same time.

I think this could be a really useful feature for some Scratch projects. Here is a basic mockup of how this could work:

(I made a spelling mistake

I'll fix it before I do another mockup)
(Also it should be “in”, not “on”)

Of course this could be different, and the text could be worded better and easier for New Scratchers or any Scratchers to understand.

Here is a new mockup (with spelling mistakes fixed):

Workaround
There is only one workaround that I know of (but it is not nice):

define async
...

when I receive [async v]
async

when gf clicked
broadcast [async v] // Always use BROADCAST ASYNC instead of the custom block

PS: If you don't understand some things about Scratch or general programming on this page, all the phrases in blue are links to a Scratch Wiki or Wikipedia article on the subject.

Last edited by Jonathan50 (May 21, 2019 09:00:01)

Jonathan50

Wait maybe run w/o screen refresh should be grayed out if run on separate thread is selected.
Also I made a spelling mistake in my mockup!
(I'll fix it in my next one if I do another one, maybe when I have more ideas and make run without screen refresh grayed out)
The mockup was made by modding Scratch 2.0, then screen recording using Microsoft Expression Screen Recorder, trimming and encoding was done in MS Expression, then finally using the GAP plugin extracted into GIMP, optimized and saved as a GIF, then uploaded to cubeupload and embedded in the forum post.

Last edited by Jonathan50 (Sept. 12, 2015 09:26:14)

stickfiregames

Semi-support, the workaround doesn't seem too hard.

Jonathan50

stickfiregames wrote:
Semi-support, the workaround doesn't seem too hard.

Added

Gaza101

Support! How about a…

create thread and run :: control cstart
    . . .
end

…block to make things easier? For example,

define example (threads)
repeat (threads)
    create thread and run :: control cstart
        . . .
    end
end

DaSpudLord

stickfiregames wrote:
Semi-support, the workaround doesn't seem too hard.

Jonathan50

Gaza101 wrote:

Support! How about a…

create thread and run :: control cstart
    . . .
end

…block to make things easier? For example,

define example (threads)
repeat (threads)
    create thread and run :: control cstart
        . . .
    end
end

Doesn't seem like a bad idea!
(this compares to the all at once block, for run without screen refrsh)

Last edited by Jonathan50 (Sept. 12, 2015 21:55:19)

Jonathan50

Ok I think, that threaded custom blocks shouldn't be able to run w/o screen refresh, and the checkbox should be grayed out, although, they can call run w/o screen refresh custom blocks.

Edit:

Last edited by Jonathan50 (Sept. 12, 2015 23:07:51)

Jonathan50

Bump

Jonathan50

Bump

Prinseskat

Support! I've thought about this before, and I see its uses. I know there's a workaround with broadcasts, but you could also workaround normal custom blocks with broadcast-and-wait blocks and variables for parameters… and that would be really annoying. Same logic applies here.

(also, I want to point out that in your example, the forever loop in

handle controls until ((stop) = [1])::custom

would either run forever or not at all depending on the value of

<(stop) = [1]>

at first - https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/topic/65798/ is some random topic I found about this)

Jonathan50

Prinseskat wrote:
Support! I've thought about this before, and I see its uses. I know there's a workaround with broadcasts, but you could also workaround normal custom blocks with broadcast-and-wait blocks and variables for parameters… and that would be really annoying. Same logic applies here.

(also, I want to point out that in your example, the forever loop in
handle controls until ((stop) = [1])::custom
would either run forever or not at all depending on the value of
<(stop) = [1]>
at first - https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/topic/65798/ is some random topic I found about this)

Ok!
(the example would be part of the game, but oh your right

that would need lambda!
A basic workaround would be to pass the name of the variable as a string and use hacked blocks to make

((gend::custom-arg) of [Stage v])

)

Last edited by Jonathan50 (Sept. 15, 2015 09:23:30)

Blank1234

workaroundable by using broadcast blocks
no support

Last edited by Blank1234 (Sept. 15, 2015 13:53:22)

Sonickyle

Support.

Jonathan50

Bump!

BookOwl

Support

ChocolatePi

Never mind

Last edited by ChocolatePi (Sept. 22, 2015 17:06:28)

Jonathan50

Bump

CatsUnited

Support

octad

75% as per above.

Blank1234 wrote:
workaroundable by using broadcast blocks
no support

Blank, just because it's workaroundable does not necessarily justify or warrant a no support.

Discuss Scratch