Discuss Scratch
- Discussion Forums
- » Help with Scripts
- » The end of "Double click the green flag"
- Zparx
-
500+ posts
The end of "Double click the green flag"
We've all seen it. A project loads up and the instructions scream and insist to us that double clicking the green flag before interacting with the project is the only way our lives can continue in a comfortable fashion. Now, I don't want to call this a “glitch” or “bug” because there are no problems with Scratch that are causing such an effect. It happens to the best of us, but it's not your fault!
There are two problems with double clicking the green flag.. 1. It makes the project look unprofessional and bugs/glitches are usually imminent if a user doesn't adhere to this warning. 2. It doesn't have to happen. Ever. I'll explain why;
Let's say you have a variable named “game start” that starts your game when it equals 1. A user clicks the green flag, setting the variable to 0, and your title screen pops up, all blinged out and brilliantly designed, and requires the user to press the space key to start the game (or set “game start” to 1). When the space key is pressed, your variable is set to 1 and the game now begins, hiding the title screen. Everything seems ok, but there is a problem… The same user just tried to play your game again in the same sitting because they liked it so much, but the title screen didn't even pop up, and the game began anyway! Here's the most probable cause, and an issue I've personally encountered with many projects on the front page that ask users to double click in this kind of instance;
Usually, I'll see a few separate scripts like this;
With the title screen sprite bearing a script like this;
The reason a user may have to double click the green flag in this instance, is because of timing issues that can easily be resolved. The title screen won't always pop up in this scenario, because when the space key was pressed the first time (setting “game start” to 1 and starting the game), the variable stays at the value of 1 until the green flag is pressed for a second time, when the script will set it back to 0, BUT- with multiple scripts telling the variable what to do at relatively close times, the “set game start to 0” block doesn't always execute before the “wait until game start = 1” block, as obviously desired. As a result, the script that sets the variable to 0 for the intro and title screen isn't “skipped”, rather executes slower than the script that tells the game to wait until that variable = 1, making it difficult to diagnose the problem since scratchers will see that the variable indeed WAS set to 0 to begin the title screen process, but somehow still started the game undesirably. This is because your scripts saw the variable equal 1 before it could be set back to 0. Why? The separate scripts aren't initiated in sequential order and some of them start before others. The difference in time between starting each script is so tiny, that this effect usually isn't noticed. So here's how the scripts start in an undesired instance that would require a user to double click the green flag;
A user clicks the green flag, plays through the game and wants to play again. They click the green flag, but this is the order in which the scripts initialize, requiring a double click (example);
1.
2.
3.
So there you have it. One of the soul reasons behind this malicious effect. I've found that in every case, the project's timing for the scripts and variable settings needed adjustments. So here are a few ways to fix the issue;
The above revision ensures that the variable is seen as 0 before 1, starting the game as desired. You could also replace the block I added with a wait block that waits about a second before detecting your variable. Intuitively, you might think this will cause glitches, but if you examine the order of operations here, you'll see that this is not the case- We have your “game start” variable resetting to 0 always, and only when the green flag is pressed. It then stays at 0 until the space key is pressed, setting the variable to 1. So, the block will only wait until the variable is fully refreshed (making absolute sure it doesn't equal 1 anymore), then it carries on and waits for the game to start as desired.
UPDATE 6/24/15: I forgot to mention this, but merging your startup scripts is also highly efficient in resolving this issue;
This way, your scripts can't possibly miss the variable reset. Just make sure you don't have any other scripts that also reset the same variable, because you may still run into problems. And you should always try to keep your scripts organized because Scratch doesn't operate in a sequential order in terms of scripting!
NOTE: If you find that this doesn't solve your issue, please comment on my profile with a link to the project in question and I'll take a look and do my best to fix it, and if this is happening for a reason other than what's mentioned above, I'll be sure to add details and fixes here!
I hope I helped. Scratch on (:
There are two problems with double clicking the green flag.. 1. It makes the project look unprofessional and bugs/glitches are usually imminent if a user doesn't adhere to this warning. 2. It doesn't have to happen. Ever. I'll explain why;
Let's say you have a variable named “game start” that starts your game when it equals 1. A user clicks the green flag, setting the variable to 0, and your title screen pops up, all blinged out and brilliantly designed, and requires the user to press the space key to start the game (or set “game start” to 1). When the space key is pressed, your variable is set to 1 and the game now begins, hiding the title screen. Everything seems ok, but there is a problem… The same user just tried to play your game again in the same sitting because they liked it so much, but the title screen didn't even pop up, and the game began anyway! Here's the most probable cause, and an issue I've personally encountered with many projects on the front page that ask users to double click in this kind of instance;
Usually, I'll see a few separate scripts like this;
when green flag clicked
set [game start v] to [0]
when green flag clicked
wait until <(game start) = [1]>
forever
game stuff
end
when [space v] key pressed
set [game start v] to [1]
With the title screen sprite bearing a script like this;
when green flag clicked
show
wait until <(game start) = [1]>
hide
The reason a user may have to double click the green flag in this instance, is because of timing issues that can easily be resolved. The title screen won't always pop up in this scenario, because when the space key was pressed the first time (setting “game start” to 1 and starting the game), the variable stays at the value of 1 until the green flag is pressed for a second time, when the script will set it back to 0, BUT- with multiple scripts telling the variable what to do at relatively close times, the “set game start to 0” block doesn't always execute before the “wait until game start = 1” block, as obviously desired. As a result, the script that sets the variable to 0 for the intro and title screen isn't “skipped”, rather executes slower than the script that tells the game to wait until that variable = 1, making it difficult to diagnose the problem since scratchers will see that the variable indeed WAS set to 0 to begin the title screen process, but somehow still started the game undesirably. This is because your scripts saw the variable equal 1 before it could be set back to 0. Why? The separate scripts aren't initiated in sequential order and some of them start before others. The difference in time between starting each script is so tiny, that this effect usually isn't noticed. So here's how the scripts start in an undesired instance that would require a user to double click the green flag;
A user clicks the green flag, plays through the game and wants to play again. They click the green flag, but this is the order in which the scripts initialize, requiring a double click (example);
1.
when green flag clicked
show
wait until <(game start) = [1]> // this condition would be true too soon
hide
2.
when green flag clicked
wait until <(game start) = [1]> // another true condition from the last play through
forever
game stuff
end
3.
when green flag clicked
set [game start v] to [0] // all because this block executed too late!
So there you have it. One of the soul reasons behind this malicious effect. I've found that in every case, the project's timing for the scripts and variable settings needed adjustments. So here are a few ways to fix the issue;
when green flag clicked
wait until <(game start) = [0]> // added block
wait until <(game start) = [1]>
forever
game stuff
end
The above revision ensures that the variable is seen as 0 before 1, starting the game as desired. You could also replace the block I added with a wait block that waits about a second before detecting your variable. Intuitively, you might think this will cause glitches, but if you examine the order of operations here, you'll see that this is not the case- We have your “game start” variable resetting to 0 always, and only when the green flag is pressed. It then stays at 0 until the space key is pressed, setting the variable to 1. So, the block will only wait until the variable is fully refreshed (making absolute sure it doesn't equal 1 anymore), then it carries on and waits for the game to start as desired.
UPDATE 6/24/15: I forgot to mention this, but merging your startup scripts is also highly efficient in resolving this issue;
when green flag clicked
set [game start v] to [0]
wait until <(game start) = [1]>
forever
game stuff
end
This way, your scripts can't possibly miss the variable reset. Just make sure you don't have any other scripts that also reset the same variable, because you may still run into problems. And you should always try to keep your scripts organized because Scratch doesn't operate in a sequential order in terms of scripting!

NOTE: If you find that this doesn't solve your issue, please comment on my profile with a link to the project in question and I'll take a look and do my best to fix it, and if this is happening for a reason other than what's mentioned above, I'll be sure to add details and fixes here!
I hope I helped. Scratch on (:
Last edited by Zparx (June 24, 2015 20:23:45)
- rollercoasterfan
-
1000+ posts
The end of "Double click the green flag"
So true. Very, very helpful, and I wish more people could see this. So true.
- Amazing_Ace
-
100+ posts
The end of "Double click the green flag"
Should be stickied. This is a great way to get rid of the flag problem. Cheers!
- peppermintpatty5
-
1000+ posts
The end of "Double click the green flag"
Although I disagree about this being stickied, this is good knowledge that Scratchers should know. 

- Paddle2See
-
1000+ posts
The end of "Double click the green flag"
Wonderful! I added it to the List of Helpful Topics. I wonder if we can get this added to the Wiki as well?
- Zparx
-
500+ posts
The end of "Double click the green flag"
List of Helpful Topics. I wonder if we can get this added to the Wiki as well?Wonderful! I added it to the
Thanks! And that would be neat

- zorfo1
-
100+ posts
The end of "Double click the green flag"
I reported it to be stickied or mentioned in the stickies, just as a btwList of Helpful Topics. I wonder if we can get this added to the Wiki as well?Wonderful! I added it to the
Thanks! And that would be neat

- Zparx
-
500+ posts
The end of "Double click the green flag"
I reported it to be stickied or mentioned in the stickies, just as a btwList of Helpful Topics. I wonder if we can get this added to the Wiki as well?Wonderful! I added it to the
Thanks! And that would be neat
Neat, thanks! I'm sure lots of Scratchers will find this useful!

- JABrules
-
100+ posts
The end of "Double click the green flag"
no problems with Scratch that are causing such an effect.Well… that's not quite true. there are
When you load a project that uses cloud data, if a player presses the green flag before the cloud data has been loaded, there can be problems.
Apart from that, nice tutorial.
Last edited by JABrules (May 17, 2015 20:01:43)
- Zacshap21
-
100+ posts
The end of "Double click the green flag"
Very helpful and insightful. Very clear explanations. 

- Zacshap21
-
100+ posts
The end of "Double click the green flag"
Very helpful and insightful. Very clear explanations.
I just did it to one of my projects, and it worked! What a simple solution to a real annoying problem.
- duckboycool
-
1000+ posts
The end of "Double click the green flag"
You didn't expect this to get so much support did you?
- Zparx
-
500+ posts
The end of "Double click the green flag"
You didn't expect this to get so much support did you?
Well I wouldn't call it “so much support” just yet

- Zparx
-
500+ posts
The end of "Double click the green flag"
Very helpful and insightful. Very clear explanations.
I just did it to one of my projects, and it worked! What a simple solution to a real annoying problem.
I'm glad I could help!

- TheCoolCreeper
-
100+ posts
The end of "Double click the green flag"
I have tried making a fake super-quick loading screen at the begginning! It works pretty well to set your variables while its loading. Really helps with the flag issue!
- qwertysamo
-
13 posts
The end of "Double click the green flag"
Could you also use this?:
And
when green flag clicked
set [GStart v] to [0 ]
Game Stuff :: custom
set [GStart v] to [1 ]
And
when green flag clicked
wait (0.1) secs
wait until <(GStart) = [1 ]>
Start Game :: custom
Last edited by qwertysamo (Dec. 12, 2015 14:41:32)
- Zparx
-
500+ posts
The end of "Double click the green flag"
Could you also use this?:
when green flag clicked
set [GStart v] to [0 ]
Game Stuff :: custom
set [GStart v] to [1 ]
when green flag clicked
wait (0.1) secs
wait until <(GStart) = [1 ]>
Start Game :: custom
If you're talking about using them together then this will certainly work! (:
- monkeydood
-
57 posts
The end of "Double click the green flag"
no problems with Scratch that are causing such an effect. It happens to the best of us, but it's not your fault!Honestly, there is an easier way to do this. First of all, if you have an intro, you would be doing something like this anyway. Also, this little revision makes your game look more professional. Here it is: If you have an intro, then just use messages. Do something like: We've all seen it. A project loads up and the instructions scream and insist to us that double clicking the green flag before interacting with the project is the only way our lives can continue in a comfortable fashion. Now, I don't want to call this a “glitch” or “bug” because there are
There are two problems with double clicking the green flag.. 1. It makes the project look unprofessional and bugs/glitches are usually imminent if a user doesn't adhere to this warning. 2. It doesn't have to happen. Ever. I'll explain why;
Let's say you have a variable named “game start” that starts your game when it equals 1. A user clicks the green flag, setting the variable to 0, and your title screen pops up, all blinged out and brilliantly designed, and requires the user to press the space key to start the game (or set “game start” to 1). When the space key is pressed, your variable is set to 1 and the game now begins, hiding the title screen. Everything seems ok, but there is a problem… The same user just tried to play your game again in the same sitting because they liked it so much, but the title screen didn't even pop up, and the game began anyway! Here's the most probable cause, and an issue I've personally encountered with many projects on the front page that ask users to double click in this kind of instance;
Usually, I'll see a few separate scripts like this;when green flag clicked
set [game start v] to [0]
when green flag clicked
wait until <(game start) = [1]>
forever
game stuff
end
when [space v] key pressed
set [game start v] to [1]
With the title screen sprite bearing a script like this;when green flag clicked
show
wait until <(game start) = [1]>
hide
The reason a user may have to double click the green flag in this instance, is because of timing issues that can easily be resolved. The title screen won't always pop up in this scenario, because when the space key was pressed the first time (setting “game start” to 1 and starting the game), the variable stays at the value of 1 until the green flag is pressed for a second time, when the script will set it back to 0, BUT- with multiple scripts telling the variable what to do at relatively close times, the “set game start to 0” block doesn't always execute before the “wait until game start = 1” block, as obviously desired. As a result, the script that sets the variable to 0 for the intro and title screen isn't “skipped”, rather executes slower than the script that tells the game to wait until that variable = 1, making it difficult to diagnose the problem since scratchers will see that the variable indeed WAS set to 0 to begin the title screen process, but somehow still started the game undesirably. This is because your scripts saw the variable equal 1 before it could be set back to 0. Why? The separate scripts aren't initiated in sequential order and some of them start before others. The difference in time between starting each script is so tiny, that this effect usually isn't noticed. So here's how the scripts start in an undesired instance that would require a user to double click the green flag;
A user clicks the green flag, plays through the game and wants to play again. They click the green flag, but this is the order in which the scripts initialize, requiring a double click (example);
1.when green flag clicked
show
wait until <(game start) = [1]> // this condition would be true too soon
hide
2.when green flag clicked
wait until <(game start) = [1]> // another true condition from the last play through
forever
game stuff
end
3.when green flag clicked
set [game start v] to [0] // all because this block executed too late!
So there you have it. One of the soul reasons behind this malicious effect. I've found that in every case, the project's timing for the scripts and variable settings needed adjustments. So here are a few ways to fix the issue;when green flag clicked
wait until <(game start) = [0]> // added block
wait until <(game start) = [1]>
forever
game stuff
end
The above revision ensures that the variable is seen as 0 before 1, starting the game as desired. You could also replace the block I added with a wait block that waits about a second before detecting your variable. Intuitively, you might think this will cause glitches, but if you examine the order of operations here, you'll see that this is not the case- We have your “game start” variable resetting to 0 always, and only when the green flag is pressed. It then stays at 0 until the space key is pressed, setting the variable to 1. So, the block will only wait until the variable is fully refreshed (making absolute sure it doesn't equal 1 anymore), then it carries on and waits for the game to start as desired.
UPDATE 6/24/15: I forgot to mention this, but merging your startup scripts is also highly efficient in resolving this issue;when green flag clicked
set [game start v] to [0]
wait until <(game start) = [1]>
forever
game stuff
end
This way, your scripts can't possibly miss the variable reset. Just make sure you don't have any other scripts that also reset the same variable, because you may still run into problems. And you should always try to keep your scripts organized because Scratch doesn't operate in a sequential order in terms of scripting!
NOTE: If you find that this doesn't solve your issue, please comment on my profile with a link to the project in question and I'll take a look and do my best to fix it, and if this is happening for a reason other than what's mentioned above, I'll be sure to add details and fixes here!
I hope I helped. Scratch on (:
([intro script])
when green flag clicked
intro stuff
broadcast [ intro_finished]
([Title Screen Script])
when I receive [ intro_finished]
show
wait until <key [space] pressed?>
broadcast [start game]
hide
([Game Sprite(s) script])
when I receive [ start game]
your game here
broadcast [game over]
when I receive [game over]
broadcast [intro_finished]
hide
By doing this, you are restarting the game every time you lose. That way, there are no variables to reset and your game looks more professional because you don't have to restart your project every time you want to play again. Each time you see and orange block, it means that the script is for a different sprite.
Hope this is helpful!
- Discussion Forums
- » Help with Scripts
-
» The end of "Double click the green flag"