What happens when you click the Green Flag

We usually click the Green Flag to start our projects.

When we click the Green Flag, all scripts headed by a “when Green Flag clicked” hat block are run first.

when green flag clicked

Can we make Scratch projects without a when Green Flag clicked script

Yes. There are Scratch projects that do not need any “when Green Flag clicked” hat blocks.

eg. a project that just shares a piece of art.




But projects with no “when Green Flag clicked” blocks can be interactive too, and react to clicks on sprites and key presses.

eg. a newspaper or slide show where you press the arrow keys to turn the pages or see the next slide.
eg. a music project where you click instrument sprites to make sounds.

What problems occur when a project has two when Green Flag clicked scripts

Let us look a project that has two “when Green Flag clicked” scripts.

Our example is a six line project that counts to 3 and plays a musical note 3 times.
What could possibly go wrong?

when green flag clicked
set [Count v] to [0]

when green flag clicked
repeat until <(Count) = [3]>
play sound [A Bass v] until done
change [Count v] by (1)
end

The project is supposed to play a musical note three times and count to 3.
The top script sets Count to 0.
The bottom script should loop 3 times, playing a sound and adding 1 to Count each time until Count = 3.

The project always works perfectly if the top script is always run before the bottom script.

This is the link if you want to see the project working: Scratch Can Count - if you are lucky!


BUT when you create a Scratch project with two “when Green Flag clicked” scripts, Scratch decides which script runs first.

Two projects could look exactly identical with the same code in the same positions in the editor, but Scratch may always run the top script first in one of the projects and always run the bottom script first in the other.

The rules that Scratch uses to decide which “when Green Flag clicked” script it will always run first are complicated.
I will discuss them near the end of this tutorial but you should not use them.

Instead we will see that you should change the project so that you decide the order that the scripts will be run.

But first let us see what happens if Scratch decides that the bottom script always runs first before the top script!


What happens when the bottom script always runs first?

Suppose Count is 3 after we last ran the project.

The bottom script runs first.
The “Repeat until Count = 3” loop repeats 0 times as Count is already 3.
The project doesn't work as intended - no sound is produced!
The top script runs second.
It sets Count to 0.

Now that Count = 0, the project will work properly and play the note three times next time it is run.

The project alternates.
It works properly when it starts with Count = 0 and plays the note three times finishing with Count = 3.
It doesn't play the note at all when it starts with Count = 3 but finishes by setting Count = 0.

This is the link to the project that loops either 3 times or 0 times: Scratch Can Count - 50% of the time

Why do some project instructions say Click the Green Flag twice
Quick Explanation

If “when Green Flag clicked” scripts all ran in the correct order in a project, there would be no need to click the Green Flag twice.

Suppose a project has two “when Green Flag clicked” scripts that run in the wrong order!

When the Green Flag is clicked the first time, the second “when Green Flag clicked” script runs first.
But this second “when Green Flag clicked” script may not work as values that it needs have not yet been initialized by the first script.
After the second script has run, however, the first “when Green Flag clicked” script runs and initializes those values.

When the Green Flag is clicked for the second time, the second script again runs first.
This time, however, it may work properly because the values that it needs to be initialized may have been initialized by the first “when Green Flag clicked” script when it ran above.


The instruction “Click the Green Flag twice” is often seen in some animation projects and projects where sounds have to play in time.
The wrong script running first can cause these synchronization issues as the correct animation start costume may not have been set or sound scripts may be started in the wrong order.

Many projects use not just two but lots of “when Green Flag clicked” scripts so they may easily run in the wrong order.

Why do some project instructions say Click the Green Flag twice - More Detail

This answer refers to the same project as discussed in the above post.
The bottom “when Green Flag clicked” script always runs first (although we wanted it to always run second).

when green flag clicked
set [Count v] to [0]

when green flag clicked
repeat until <(Count) = [3]>
play sound [A Bass v] until done
change [Count v] by (1)
end

Suppose we click the Green Flag twice in quick succession.

When we click the Green Flag the first time:
- either the project starts with Count = 3 and quickly sets Count = 0 (as described above), or
- the project starts with Count = 0 but the second Green Flag interrupts and stops the project before Count is increased!

Either way, when we click the Green Flag the second time, the project starts with Count = 0 and works.


Here again is the link to that project: Scratch Can Count - 50% of the time
When clicking the Green Flag once to start the project, it only works every second time.
But click the Green Flag twice and the project always seems to work.

But other projects with two “when Green Flag clicked” scripts never work properly if the scripts run in the wrong order!

Try this project which is almost identical: Scratch Can't Count
The project would work properly if the top script was always run first and play the sound three times.
But the bottom script always runs first!
The project plays the sound 4 or 0 times but never 3 times, even if you click the Green Flag twice or more.

The way that this project runs is discussed later in the section about scripts not running to completion but pausing and yielding to give other scripts a turn.
What are “yield points” for scripts in a project
Scratch Can't Count - An Example of “yields” and How Scratch Runs

I do not recommend reading that now as it discusses what happens when projects go wrong.
Instead continue below to see how to fix the problem by controlling the order in which scripts are run!

It is important to note again that these projects run properly when the “when Green Flag clicked” scripts are run in the correct order!

Also note that many projects have lots of “when Green Flag clicked” scripts and the chance of them all working properly when they are run in a random order is not good even when the Green Flag is clicked twice or more.

How do we fix project problems caused by two when Green Flag clicked scripts


Problems may occur when “when Green Flag clicked” scripts run in the wrong order.

The solution is to write our projects so that scripts are forced to run in the order we want.

We usually rewrite these projects with just one “when Green Flag clicked” script.
We then force scripts to run in order using “broadcast and wait” blocks.

Let us consider the same example project used above with 2 “when Green Flag clicked” scripts.
This was written as a very simple project with only 6 lines to show the problems if the bottom “when Green Flag clicked” script ran first.

when green flag clicked
set [Count v] to [0]

when green flag clicked
repeat until <(Count) = [3]>
play sound [A Bass v] until done
change [Count v] by (1)
end

For this tiny example project, we can fix the problem by combining the two scripts into one script.
We place the “set count to 0” block (which must run first) before the repeat loop.
The is how this project would normally be written!
The project now has only one “when Green Flag clicked” script and there is no ambiguity as to which code runs first.

when green flag clicked
set [Count v] to [0]
repeat until <(Count) = [3]>
play sound [A Bass v] until done
change [Count v] by (1)
end

This is the fixed project: Scratch Can't Count Fixed - 2

(This fixed project actually fixed the project Scratch Can't Count which has the lines inside the repeat loop in reverse order.
This makes no difference as our fix forces Count to be set to 0 before the loop is executed).

In most cases, however, the fix would not be as simple as above.
Projects often have many “when Green Flag clicked” scripts in different sprites.

We then fix our project by rewriting it to use just one “when Green Flag clicked” script and use “broadcast and wait” blocks to force other scripts to run first before our main project loop.

We will look at examples with bigger projects later, but here is the modified code for our small example project:

when green flag clicked
broadcast [Initialize v] and wait
repeat until <(Count) = [3]>
play sound [A Bass v] until done
change [Count v] by (1)
end

when I receive [Initialize v]
set [Count v] to [0]

This is the fixed project: Scratch Can't Count Fixed - 1

(This fixed project actually fixed the project Scratch Can't Count which has the lines inside the repeat loop in reverse order.
This makes no difference as our fix forces Count to be set to 0 before the loop is executed).

Usually there would be many sprites that receive the Initialize broadcast.
They would set up all values required to start the project, before the code continues with the action in the main project loop.

Project Initialization and Running when Green Flag clicked scripts in Order

What things do we need to initialize in our projects

When we write Scratch projects, we may need to initialize data values!
eg. set Score = 0, set Player Lives =3

When a Scratch project is saved, its current data values are saved with it.
If you rerun a Scratch project, it will start with the data values from the end of its previous run.

We need to write scripts in our projects to initialize data values such as Score = 0, and Player Lives =3.

We may also need to initialize sprites.

We must put sprites in their start positions with their start properties such as direction as size.
For example, in a dress-up project, we may want to put all clothes back around the edges of the stage.

We may also need to create clones of sprites when we start our projects.

In Pen projects, we would usually clear the stage with “erase all” and initialize pen properties such as up/down, size and color.

Initializing Data

We can often initialize data in a project with one “when Green Flag clicked” script and a “broadcast and wait” as follows:

when green flag clicked
broadcast [Initialize v] and wait
repeat until <>
...
end

The main project loop runs after all data has been initialized.

Note that there may be many “when I receive Initialize” scripts in many sprites.
Their code sets data to its initial values, shifts sprites to their start positions, creates clones etc.

We don't know the order in which the many “when I receive Initialize” scripts will run with the above project structure. This structure only works if the order in which we run these Initialize scripts is not important.


If some data must be initialized before other data, we could use the following structure:

when green flag clicked
broadcast [Initialize 1 v] and wait
broadcast [Initialize 2 v] and wait
broadcast [Initialize 3 v] and wait
broadcast [Initialize 4 v] and wait
repeat until <>
...
end

Is it ok to make projects with many when Green Flag clicked scripts

Yes! A lot of Scratch projects will work fine with many “when Green Flag clicked” scripts.

Also a lot of Scratchers are beginner programmers and find it easy to write projects with many “when Green Flag clicked” scripts.


* But it is not ok if your project requires some “when Green Flag clicked” scripts to run before others!

* And it is not ok if some scripts will still be initializing data when your project has started its main code.
eg. Your project is still creating clones while already running code to move those clones.


It is good programming practice to have just one “when Green Flag clicked” script and use “broadcast and wait” for initialization.
But a lot of Scratch projects will work fine with many “when Green Flag clicked” scripts.

If your project starts with an intro, or displays a menu, or asks the user to press a key to start, then “when Green Flag clicked” scripts that do initialization tasks can normally run to completion in this time before the “main” project starts.


If you want sound to play a music clip repeatedly while your project runs, it is much easier to write this in its own Green Flag script.

when green flag clicked
forever
play sound [Background Music v] until done
end

Good Project Structure - with a Main Project Loop

As an example of good project structure we will look at a Space Invaders type game.

Several rows of Invaders move down the screen.
The player moves their Player Craft back and forth across the bottom of the stage.
The Player Craft can fire bullets.
The bottom row of Invaders also fire bullets.




Here is a brief project structure:

when green flag clicked
broadcast [Initialize v] and wait
set [Game Over v] to [false]
repeat until <(Game Over) = [true]>
broadcast [Move Player Craft v] and wait
broadcast [Move Invaders v] and wait
broadcast [Move Player Bullets v] and wait
broadcast [Move Invader Bullets v] and wait
broadcast [Process Player Bullet Collisions v] and wait
broadcast [Process Invader Bullet Collisions v] and wait
end

The script broadcasts “Initialize” then waits until all “when I receive Initialize” scripts have run.

The “when I receive Initialize” scripts would set the score to 0, set the starting number of player lives, create and display all the Invaders in their start positions, display the Player Craft in its start position, set the number of active Player bullets to 0, set the number of active Invader bullets to 0, clear all bullets from the screen, etc etc.
It is important that all these setup tasks are done before the main project loop.

In the main project loop, the Player Craft will be moved if the left/right arrow was pressed, then the Invaders will be moved, then the Player Bullets will be moved, then the Invader Bullets will be moved, then Player Bullet Collisions will be processed and finally Invader Bullet Collisions will be processed.

* Note that this main loop controls the order that actions occur.
We move all objects before we check for collisions.
We move the Player Craft and Invaders before any bullets (this could be important if new bullets are fired).
We check if Player Bullets have hit any Invaders which would increase our score (and destroy the Invader) before we check if any Invader Bullets have hit our craft which could end the game.

Why is this project structure good

The “broadcast Initialize and wait” block makes sure everything is set up before the main project loop starts.
(Note that this project would have just one “when Green Flag clicked” script).

The main project loop controls the order in which objects are moved and bullet collisions are processed.

What problems occur with some other project structures

If a project has many “when Green Flag clicked” scripts, they may not all run before the main project scripts start.

If a project has repeat loops in many sprites (eg. a repeat loop to Move Invaders, a repeat loop to Move Player Bullets, a repeat loop to Process Bullet Collisions etc) then we don't know the order in which these actions will be done.

Some programmers have many “when Green Flag clicked” scripts and use a “wait 0 seconds” block before the main project loop(s).
This does not guarantee that the initialization tasks in those Green Flag scripts are completed before the main project loop(s).
eg. a project may create 60 clones in a loop. This takes 2 seconds if the clones are visible as the screen needs updating 60 times.
(The clones could be created in a “run without screen refresh” custom block to create them all at once).

Also if several Initialization scripts need to run in order, the structure “broadcast Initialize 1 and wait”, “broadcast Initialize 2 and wait”, “broadcast Initialize 3 and wait” etc is better than using wait 0.1 seconds, wait 0.2 seconds, wait 0.3 seconds etc to synchronize scripts.


Many programmers use this structure:

when green flag clicked
broadcast [Initialize v] and wait
set [Game Over v] to [false]
repeat until <(Game Over) = [true]>
broadcast [Tick v] and wait
end

The idea is that the screen will be updated after all the scripts for each Tick (or frame) have been executed.

Many sprites will have a “when I receive Tick” scripts.
This project structure works well unless some “when I receive Tick” scripts should be run before others.

In our Space Invaders example, we would not know whether the Player Craft and Invaders would be moved before the Bullets, or that all objects would be moved before we test for Bullet collisions.
These actions would all be in “when I receive Tick” scripts and we wouldn't know which scripts would run first.


Whenever there are several scripts for one event, we don't know which of these scripts Scratch will run first.

We have already seen this with “when Green Flag clicked” scripts.
It applies to scripts that receive the same broadcast eg. “when I receive Tick”.
It applies to clones that receive the same broadcast. Fortunately with clones we don't usually worry about which scripts run first.

Good Project Structure - with a Chain of Broadcasts

Some Scratch projects such as animations and MAPs (multi animator projects) may not have a main loop but a series of scripts to run in order.

These projects can be structured using a series of “broadcast and wait” blocks in a main controlling sprite.
Alternatively they can be structured with a “chain” of broadcasts at the end of each script.

We will look at an animation project with 10 parts as an example.
Here is the project structure controlled from a main sprite using “broadcast and wait” blocks.

when green flag clicked
broadcast [Initialize v] and wait
broadcast [Animation Part 1 v] and wait
broadcast [Animation Part 2 v] and wait
broadcast [Animation Part 3 v] and wait

…

broadcast [Animation Part 10 v] and wait

Here is the project structure as a chain of broadcasts from the end of each script.

when green flag clicked
broadcast [Initialize v] and wait
broadcast [Animation Part 1 v]

when I receive [Animation Part 1 v]
...  // script for Animation Part 1
broadcast [Animation Part 2 v]

when I receive [Animation Part 2 v]
...  // script for Animation  Part 2
broadcast [Animation Part 3 v]

…

when I receive [Animation Part 10 v]
...  // script for Animation Part 10

What is Turbo Mode - Quick Explanation

Scratch projects run at a faster speed if you put Scratch into Turbo Mode.

How do you put Scratch into Turbo Mode

You put Scratch into Turbo Mode by holding down the <Shift> key and clicking the Green Flag.

When Scratch is in Turbo Mode you will see the words “Turbo Mode” and a little lightning flash picture



To return Scratch to its normal speed, hold down the <Shift> key and click the Green Flag again.

How does Turbo Mode make projects run faster - More Detail

To understand how Turbo Mode makes projects run faster, we need to understand how Scratch actually runs the scripts in our projects in Normal Mode.

Here is a brief summary:

Scratch only runs one script at a time. Scripts have to take turns.

Scratch makes a list of the scripts that it has to run.
Scratch runs each script until it reaches a “yield point” where it pauses so that other scripts can run.
Scripts yields to let other scripts run each time they reach the end of a loop, eg. a Repeat or Forever loop.

After all scripts in the list have run to their yield points, Scratch will update the screen, but only after 1/30th second has elapsed since the last screen update.

Scratch will then run a new list of scripts to their yield points.
This list includes the scripts that were paused at their yield points. These scripts resume after their yield points.
The list also includes scripts for new events such as key presses and mouse clicks.

Again Scratch will update the screen after all scripts have run to their yield points and 1/30th second has elapsed since the last screen update.

So, in Normal Mode, Scratch does 30 screen updates per second.
We also say that Scratch has a frame rate of 30 FPS (Frames Per Second).

In Turbo Mode Scratch runs lists of scripts to their yield points as in Normal Mode.
But Scratch does not refresh the screen after the current set of scripts have finished running and 1/30th second has expired since the last screen refresh.

In Turbo Mode Scratch runs as many of these sets of scripts as it can until 1/30 second has elapsed and then refreshes the screen.

Why is Turbo Mode not normally recommended for games

First, some edited quotes from this forum post https://scratch.mit.edu/discuss/post/2264077/ by TheLogFather

“Scratch will normally run loops 30 times per second, refreshing the screen after each pass through the running loops.
This allows games, for example, to run at a reasonable speed.

In Turbo Mode, however, Scratch allows the loops to run through as many times as your computer can manage between each screen refresh.
For many games, this could well make them run way too quickly.”


“If you are writing a game that needs to run at a consistent rate, then turbo mode will likely ruin it.” (without extra coding to synchronize scripts)

* “This is a good reason to have a single main control loop in your projects that sends broadcasts out to sprites/clones to do things at each frame, rather than having separate loops in all your sprites/clones.”


“There are not many scenarios where you need to use Turbo Mode.
Usually if you want to run code quickly, you should put it into a Custom Block and set it to ”run without screen refresh".

Good Project Structure - with a Main Project Loop “run without screen refresh” Custom Blocks

What projects are particularly suited to Turbo Mode

It is great fun to see how many projects run in Turbo Mode!

Some projects are particularly suited to Turbo Mode as we want them to run as fast as possible.

Turbo Mode is good for complex artificial intelligence projects such as determining moves in a game such as chess, checkers or scrabble.

Turbo Mode is good for complex algorithmic Pen drawing projects.on the screen.
As an example, some projects calculate the colour of each pixel on the screen (480 x 360 = 172,800 pixels).
As there are so many calculations to do, the drawing appears quickest if the project does as many calculations as it can in 1/30th second before updating the screen.

Here are two Pen projects that draw pictures on the screen calculating colours pixel by pixel:



Extra Note: a combination of “run without screen refresh” custom blocks and Turbo Mode is often faster than Turbo Mode alone.
This could be because Scratch would not check as often if 1/30th second had elapsed inside a “run without screen refresh” custom block or that “run without screen refresh” custom blocks can run for 1/2 second before Scratch forces a yield and screen update.

How can a project detect whether it is running in Turbo mode

In Normal Mode Scratch scripts yield every time they reach the end of a Repeat loop.
We run a project that updates the screen 10 times in a Repeat loop.
This “Repeat 10” script will yield 10 times for screen updates at 1/30th second intervals.
Thus the script will take at least 10 x 1/30 = 1/3 (or 0.3333) seconds to run in Normal Mode.

If we run the same “Repeat 10” script in Turbo Mode, Scratch can run this script 10 times within 1/30 second before it does a screen update.
Thus the script only takes 1/30 (or 0.0333) seconds in Turbo Mode.

When we run such a script we can detect whether Scratch is in Turbo Mode by the time that it takes.
Here is such a script.

define Detect if Project in Turbo Mode
set [Start Time for Turbo Test v] to (timer)
repeat (10)
switch backdrop to [backdrop name v]
end
if <(timer) < ((Start Time for Turbo Test) + (0.1))> then
set [Turbo Mode v] to [true]
else
set [Turbo Mode v] to [false]
end

*** Note that “backdrop name” above should have new Scratch Blocks in Scratch 3

Here are two similar projects with the “Detect if Project in Turbo Mode” custom block.
The first project draws dots on the screen. The second project is more boring and just detects Turbo Mode.



Notes:

- This custom block tests whether it takes longer (Normal Mode) or shorter (Turbo Mode) then 0.1 seconds to run the code.
If we reset the timer to 0 this could interfere with timer code in the project.
Instead we store Start Time for Turbo Test and then measure whether 0.1 seconds have passed.

- Switching the backdrop to the current backdrop does trigger a screen update in Scratch.
Switching the backdrop to the current backdrop is a useful way to detect Turbo Mode as it does not change the appearance of the screen.

- If you tried to switch the project backdrop to a backdrop that didn't exist, then no screen update would be required, so the project would not wait until 1/30th second had elapsed since the last screen update. The custom block would not detect Normal Mode.
That is why the code uses switches the backdrop to the current backdrop name.

- You can use other blocks that force a screen update to detect Turbo Mode but it is preferable not to alter the appearance of the screen.

- The custom block “Detect if Project in Turbo Mode” must NOT be defined with “run without screen refresh” as this would stop the project from yielding each time it reached the end of the Repeat loop, even in Normal Mode.
“run without screen refresh” Custom Blocks

How can you force a project to start in Turbo mode

We can force the user of a project to switch to Turbo Mode before the project will continue.

We detect whether the project is in Turbo Mode.
If not, we display a message to the user, then loop again and again testing whether Scratch is in Turbo Mode until it is!

Here is a project that forces the user to switch to Turbo Mode before it will continue:

What happens when you click the Red Stop Sign - Quick Explanation

What does the stop all block do

*** ADD images of stop sign button and Scratch 3 version of stop all block

The Stop Sign is a button that when clicked stops the running project immediately. It can be clicked at any time during a project.
(quoted from the Scratch Wiki)

The “stop all block” is similar to the Stop Sign button. Once the “stop all” block has been reached in a script, the project will end.
(edited quote from the Scratch Wiki)

What happens when you click the Red Stop Sign - More Detail

What does the stop all block do

Clicking the Red Stop Sign button or the project executing a “stop all” block stops the running project immediately.

That is all most Scratch programmers need to know! But it is not completely true.

Let us look at a quote from TheLogFather at https://scratch.mit.edu/projects/142160293/

“Scratch will not necessarily immediately stop all running scripts when it reaches a ”stop all“ block.

Any scripts which are scheduled to run after the script which did the ”stop all“ will still get executed for one more pass of any loops they are running before they get stopped. (But scripts which were scheduled to run before the ”stop all“ script will not do another pass of their loops.)”

So after the Red Stop Sign is clicked or “stop all” is run, Scratch will still run any currently queued threads/scripts at least to their yield points.

Here is an interesting example project in which a script is clearly run after a “stop all” block is executed:
(Click on the project picture if you want to see it)



We can take advantage of the fact that some scripts run after the Red Stop Sign or “stop all” block.

If we add a broadcast into one of these scripts, this creates a new script/thread to add to the list of scripts/threads yet to run. This lets us run any scripts we want after the Red Stop Sign or “stop all” block.

If your project has a “when timer > …” script (eg. “when timer > 0.1”) the code for this event will still be triggered when the timer first exceeds the value.
If the “when timer > …” test is false, it is again added to the lists scripts/threads to be run until it finally becomes true.

These features let us deliberately program scripts to run after the Red Stop Sign or “stop all”.
Can you write scripts that run after the Red Stop Sign

What objects/features persist when the Red Stop Sign is clicked

When the Red Stop Sign button is clicked or the project runs the “stop all” block the following objects/features remain:

- Although Scratch stops running all scripts, the project scripts are still accessible.
The user can click sprites and press keys and the corresponding “when this sprite clicked” and “when … key pressed” scripts will be run.
- Sprites (but not clones) remain on the screen with most of their current properties eg. size, costume, layer, show/hide, x position, y position, direction
(sprites do not retain their graphic effects: ie. - color, fisheye, whirl, pixelate, mosaic, brightness, ghost)
- The timer still runs measuring the time since the Green Flag was pressed or the last “reset timer” block was executed.
(in the Sensing blocks tab you can put a tick in the box next to the timer, then you can see the project timer running)
- all pen drawing on the stage remains. Also pen characteristics remain: pen up or down, size, color, transparency etc.

- Data (ie. variables and lists) keep their values when a project is stopped.

If you then click the Green Flag to start the project again, the project will start with these data values!

If data needs specific starting values in a project (eg. Score = 0), the programmer must set (initialize) that data in their project code.
eg. If Score is not set to 0 in a project's code, then when rerunning the project, Score will start with its value when the project was stopped.

Note: Data values remain when you rerun a project (ie. click the Green Flag again).
If you reload a project, eg. by refreshing the page in your browser, then the data is lost.
The project will then start with the data values that the project had when it was saved by the programmer.

When a project is saved in Scratch, it is saved with its data!
This is the data that the project has when you load the project to run, or if you reload the project by refreshing your browser page.

- Although I wrote above that Scratch stops running all scripts, it actually still runs any scripts/threads that were already queued to be run. (as described above)

What objects/features disappear when the Red Stop Sign is clicked

When the Red Stop Sign button is clicked or the project runs the “stop all” block the following objects/features disappear:

- Scratch stops all running scripts. (*** See above topic that this is not quite true)
- all clones are deleted and vanish from the screen.
- all graphic effects on sprites stop. The effects are removed from sprites displayed on the screen.
ie. any color, fisheye, whirl, pixelate, mosaic, brightness or ghost effects on sprites disappear.
- any sprite speech bubbles or thought bubbles think from “say” blocks or “think” blocks) disappear.
- all sounds that are playing stop immediately
- if a sprite is moving in a glide block (eg. glide … secs to x: … y: …) it stops in its current position.

Notes:

The above objects/features are only stopped if the project is stopped by the Red Stop Sign or a “stop all” block.
If a project just finishes running its scripts but is not stopped, these features persist/remain!

If the user clicks the Green Flag when a project has not been stopped, the project is first stopped, then run again.
This means that clones will be deleted and graphic effects removed from sprites before the project is restarted.

Displaying a project title after the Red Stop Sign is clicked

We can take advantage of the fact that graphic effects cease after the Red Stop Sign or “stop all” block.

Scratchers most commonly use this stopping of graphic effects to redisplay a project title after the Red Stop Sign or “stop all” block.

This is done by setting Ghost Effect to 100 (transparent) for the title sprite when the Green Flag is clicked.
When the project is stopped, graphic effects cease and without Ghost Effect = 100, the title sprite reappears.

when green flag clicked
set [ghost v] effect to (100)

Here is an example project with all this code in the Title sprite:




Notes:
- If other sprites are moved to the front layer while a project is running, you will need to move the title sprite to the front layer again.
You could add “forever go to front layer” to the above script.
Alternatively you could add a broadcast to run after the Red Stop Sign button is clicked to move the title to the front layer. This is discussed below.

- Some Scratchers program a forever loop around “set Ghost Effect = 100” in the above script.
The forever loop is unnecessary. You only need to set Ghost Effect = 100 once.

Can a project detect when the Red Stop Sign is clicked

Can you write scripts that run after the Red Stop Sign

Yes! Here is the code:

when green flag clicked
forever
set [Previous Timer Value v] to (timer)
end

when [timer v] > ((Previous Timer Value) + (0.1))
Red Stop Sign Detected as timer not being reset - Add Script for after Stop here

The logic of this project is: Keep setting the variable Previous Timer Value to the project Timer. When the user clicks the Red Stop Sign button to stop the project, the forever loop ends and Previous Timer Value is no longer updated. The project Timer doesn't stop, so after 0.1 seconds the Timer becomes greater than Previous Timer Value + 0.1
This project works because the thread/script with “when timer > …” is still checked after the project is stopped. If the “when timer > …” test is false, it is again added to the lists threads/scripts to be run until it finally becomes true.

Note that the code above does not use “reset Timer” as as projects may need to use the project Timer.
this idea from the Scratch Wiki - https://en.scratch-wiki.info/wiki/Action_After_Stop

Here is a project that runs some nice code after the user clicks the Stop Sign button or the “stop all” block is run:




Can you write a project that cannot be stopped with the Red Stop Sign

You could write your end sequence script(s) to force your project to start again so that it would never stop, but I would never suggest that