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;

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 (:

So true. Very, very helpful, and I wish more people could see this. So true.

when [chromometer altimeter v] = [5th length v] and [7th length v] with a [gap v] of (17) ::events hat
forge [chromometer v] altimeter until < (speed) = (velocity)> ::control cstart
	switch places with (759 v) altimeters with value of (speed) ::looks
	control [altimeter 1 v] at time (10):(17):(58) ::control
end
initialize sequence (24) so [object 3 v] moves to x (156) y (231) ::control
reveal [final answer v] and stop running this script ::events cap

Should be stickied. This is a great way to get rid of the flag problem. Cheers!

Although I disagree about this being stickied, this is good knowledge that Scratchers should know.

Yea nice!

say ["DONT INTERRUPT ME WHILE IM DREAMING OF BAKED BEANS!!"]]

Wonderful! I added it to the List of Helpful Topics. I wonder if we can get this added to the Wiki as well?

Paddle2See wrote:

Wonderful! I added it to the List of Helpful Topics. I wonder if we can get this added to the Wiki as well?

Thanks! And that would be neat

Zparx wrote:

Paddle2See wrote:

Wonderful! I added it to the List of Helpful Topics. I wonder if we can get this added to the Wiki as well?

Thanks! And that would be neat

I reported it to be stickied or mentioned in the stickies, just as a btw

zorfo1 wrote:

Zparx wrote:

Paddle2See wrote:

Wonderful! I added it to the List of Helpful Topics. I wonder if we can get this added to the Wiki as well?

Thanks! And that would be neat

I reported it to be stickied or mentioned in the stickies, just as a btw

Neat, thanks! I'm sure lots of Scratchers will find this useful!

Zparx wrote:

there are no problems with Scratch that are causing such an effect.

Well… that's not quite true.
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.

Very helpful and insightful. Very clear explanations.

Zacshap21 wrote:

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.

You didn't expect this to get so much support did you?

duckboycool wrote:

You didn't expect this to get so much support did you?

Well I wouldn't call it “so much support” just yet but indeed I think a lot of scratchers will appreciate this (:

Zacshap21 wrote:

Zacshap21 wrote:

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!

Thx! That's really helpful!

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!

Could you also use this?:

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

qwertysamo wrote:

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! (:

Zparx wrote:

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;

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 (:

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:

([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!

(Oops!! I got the code wrong! Guess I'll have to do it again!)