When you click an orphaned block or script in the scratch coding area, it runs that script. But when? At the start or the end of the frame? Same question for “When (key) key pressed” hat blocks.

Firefly360 wrote:

When you click an orphaned block or script in the scratch coding area, it runs that script. But when? At the start or the end of the frame? Same question for “When (key) key pressed” hat blocks.

I don’t know the answer, although I would guess it’s rather arbitrary since you can have many hat blocks of the same type.

You could probably ask RokCoder. I think he knows more about that stuff.

For the

when [... v] key pressed

it runs whenever that key is pressed, even when the project is not running. This proves as a problem in many beginners' games as they do not know about this and add it when the flag needs to be clicked, therefor breaking the project. Though when you click an orphaned block, I am pretty sure it has some input delay. I will test this though to get the exact delay time, and this post will be edited when I find the fix.

EDIT: I found that it takes roughly 0.003 seconds to run. Hope this helps!

when green flag clicked
thank [you v]::obsolete cap

Rock-Joen wrote:

For the

when [... v] key pressed

it runs whenever that key is pressed, even when the project is not running. This proves as a problem in many beginners' games as they do not know about this and add it when the flag needs to be clicked, therefor breaking the project. Though when you click an orphaned block, I am pretty sure it has some input delay. I will test this though to get the exact delay time, and this post will be edited when I find the fix.

EDIT: I found that it takes roughly 0.003 seconds to run. Hope this helps!

Yeah, thats pretty much exactly one frame. But what I want to know is if it runs at the start or end of a frame?

PAPIKOKUSOUMAI wrote:

(wow youtube link)
ぜひ使ってみてください (tr: please give it a try?)

I don't think Youtube has a video about this yet…

Anyway, back to topic.
Sprites and scripts in Scratch have a run order (griffpatch did mention this problem in his lemon shooter tutorial I think?), and Rock-Joen found out that clicked scripts run the frame after.
I'm making an educated guess on this: maybe, probably, likely even, clicked scripts also follow the normal run order, but is one frame late? As in, if said script normally runs first in all frames, clicking it will make it run first on the next frame?

The start, I'm pretty sure.

Here's the code I tested with:

forever
reset timer
end

when [a v] key pressed
add (timer) to [values v]

If you activate the loop (with the project running) and press A a few times, every value in the list is 0. So 0.033 seconds didn't pass between the moment the timer was reset (the start of the frame) and the moment the script activated.

If anyone sees a flaw in this please point it out, there are a lot of ways to get erroneous results here.

say (something dumb)
switch costume to [dabbing v]

Woodfur wrote:

If anyone sees a flaw in this please point it out, there are a lot of ways to get erroneous results here.

I think there is a flaw, however it doesn't really change the results that much.
Run this script:

when green flag clicked
forever
add (timer) to [values v]
reset timer
end

If the timer measures are correct, all the values should be greater than 0, however the list is filled with zeros (like 60k of them during the first second? scratch goes crazy fast if there is no screen updates lol).
To fix this, I forced a screen update by making the sprite running the flag script to say something in the loop. Here are some of my observations:
- Whether the clickings happen in the sprite or the backdrop, the returned result is always 0.
- The say block does say different values if placed before or after the reset timer block: 0.03~0.04 if before, and 0 if after.

…Wait, 0 if after? Does that mean the clicked script runs after the already running scripts, aka at the end of the frame?????
I'm getting so confused…

Any event block pushes a pointer to the script into a stack which is processed at a yield point.

If no other scripts are running then it's a moot point as it will be added to the stack and then executed.

If scripts are running then the pointer is added to the stack (the same as happens when green flag is clicked, broadcasts are sent, or any other event type block is executed). The script will continue to a yield point and then the next script in the stack is processed (and this continues until all pointers in the stack have been processed at which point you reach the end of the frame).

More information here

RokCoder wrote:

Any event block pushes a pointer to the script into a stack which is processed at a yield point.

If no other scripts are running then it's a moot point as it will be added to the stack and then executed.

If scripts are running then the pointer is added to the stack (the same as happens when green flag is clicked, broadcasts are sent, or any other event type block is executed). The script will continue to a yield point and then the next script in the stack is processed (and this continues until all pointers in the stack have been processed at which point you reach the end of the frame).

More information here

Your scratch documentation is great, but I disagree with the lack of ability to control the threads execution order. Even from my experience the default order in which the blocks are executed is the order in which they appear in JSON file and while the project runs there is list of all treads of each sprite or stage, which contains reference to first block of each of the threads.

By placing one or multiple blocks connected, from block picker or detached from other script, as a alone script into workspace, it will add them to existing thread list, which intuitively is done by pushing them onto the stack, which makes them to be the last in thread list of the sprite. When the scripts get added into active threads they still follow the order from the thread list, so that last added added block or script will be executed at the end. My argument to support this is also the conclusion that if the threads could get assigned different order when queued, it would produce different results and therefore could break the projects.

For example after finding out the order of scripts being executed by using Debug watcher as shown in your document, the first script being on the stack of each frame is most surely the most first (in case the original first was removed) hat block that was added to the project.

With that in mind, there's no longer need to worry about arbitrary orders, if the project is planned properly and the scripts in the workspace are arranged in the order they were put in, it's easier to follow the flow of execution, debug the code knowing what happens when and can even be relied on it. If there's something unclear, let me know.

Have a Great day,
KaaBEL

KaaBEL_sk wrote:

RokCoder wrote:

Any event block pushes a pointer to the script into a stack which is processed at a yield point.

If no other scripts are running then it's a moot point as it will be added to the stack and then executed.

If scripts are running then the pointer is added to the stack (the same as happens when green flag is clicked, broadcasts are sent, or any other event type block is executed). The script will continue to a yield point and then the next script in the stack is processed (and this continues until all pointers in the stack have been processed at which point you reach the end of the frame).

More information here

Your scratch documentation is great, but I disagree with the lack of ability to control the threads execution order. Even from my experience the default order in which the blocks are executed is the order in which they appear in JSON file and while the project runs there is list of all treads of each sprite or stage, which contains reference to first block of each of the threads.

By placing one or multiple blocks connected, from block picker or detached from other script, as a alone script into workspace, it will add them to existing thread list, which intuitively is done by pushing them onto the stack, which makes them to be the last in thread list of the sprite. When the scripts get added into active threads they still follow the order from the thread list, so that last added added block or script will be executed at the end. My argument to support this is also the conclusion that if the threads could get assigned different order when queued, it would produce different results and therefore could break the projects.

For example after finding out the order of scripts being executed by using Debug watcher as shown in your document, the first script being on the stack of each frame is most surely the most first (in case the original first was removed) hat block that was added to the project.

With that in mind, there's no longer need to worry about arbitrary orders, if the project is planned properly and the scripts in the workspace are arranged in the order they were put in, it's easier to follow the flow of execution, debug the code knowing what happens when and can even be relied on it. If there's something unclear, let me know.

Have a Great day,
KaaBEL

I think I only suggest the order of execution of green flag blocks should be considered as arbitrary. Or, more specifically,

It is possible to work out the order but it’s far more useful to consider it as arbitrary

You can work out the order and the order will remain the same. It's still more useful to consider them arbitrary and use better programming practice to control the order of execution. Or were you meaning something else?

RokCoder wrote:

(#10)
I think I only suggest the order of execution of green flag blocks should be considered as arbitrary. Or, more specifically,

It is possible to work out the order but it’s far more useful to consider it as arbitrary

You can work out the order and the order will remain the same. It's still more useful to consider them arbitrary and use better programming practice to control the order of execution. Or were you meaning something else?

I am now confused in what the “work out” means, with the context of previous sentence:

It’s important to realise that we don’t control which order they’re added in. It is possible to work out the order but it’s far more useful to consider it as arbitrary.

I understand that work out is used meaning to find out what the order is, and considering them as arbitrary is easier, because it skips the part where the order must be ‘discovered’. Plus with previous statement “we don’t control which order they’re added in” it sounds more like there's nothing to do about it as a programmer, which could be true if it meant that the order, just like variable names can't be controlled programmatically. The order can't be changed nor inspected in vanilla editor (not even in TurboWarp), but (I've done some tests to correct myself):

1. Scripts (I think that's what you mention as threads) with the same type of hat or receive hat blocks with the same message will use the order in which they were added to workspace within the same sprite, the order of their execution can be controlled by swapping the scripts attached to them, although the best practice is to combine them to use only one hat block. (what I meant)

2. Scripts with the same type of hat or receive hat blocks with the same message will not always use the same order, by pressing green flag their order reverses for the three sprites I used to test green flag and receive message hat block, therefore it is necessary to choose different strategy for order sensitive solutions and best to enforce the order other way. (what I didn't know)

3. I was wrong about broadcasting messages and the order of scripts with receive message hats, I thought would follow the order in which the receive message hats were added, as that is the order I assume they were added also in the example, looks like a core mechanic which can be relied on. (there's always something new to learn)

4. I have not tested the order of scripts with other types relative to already running loop with rendering that OP asked for.

Project with the scripts I used for testing “(not) Always the same”: https://scratch.mit.edu/projects/721556751/

RokCoder wrote:

(#10)
. . . It's still more useful to consider them arbitrary and use better programming practice to control the order of execution. . . .

I agree with that.

Firefly360 wrote:

Rock-Joen wrote:

For the

when [... v] key pressed

it runs whenever that key is pressed, even when the project is not running. This proves as a problem in many beginners' games as they do not know about this and add it when the flag needs to be clicked, therefor breaking the project. Though when you click an orphaned block, I am pretty sure it has some input delay. I will test this though to get the exact delay time, and this post will be edited when I find the fix.

EDIT: I found that it takes roughly 0.003 seconds to run. Hope this helps!

Yeah, thats pretty much exactly one frame. But what I want to know is if it runs at the start or end of a frame?

Oh, it runs at the end of a frame!

when green flag clicked
thank [you v]::obsolete cap

RokCoder wrote:

Any event block pushes a pointer to the script into a stack which is processed at a yield point.

If no other scripts are running then it's a moot point as it will be added to the stack and then executed.

If scripts are running then the pointer is added to the stack (the same as happens when green flag is clicked, broadcasts are sent, or any other event type block is executed). The script will continue to a yield point and then the next script in the stack is processed (and this continues until all pointers in the stack have been processed at which point you reach the end of the frame).

More information here

OMG, ROK CODER SPOTTING :O!!!

when green flag clicked
thank [you v]::obsolete cap