Discuss Scratch

Zparx
Scratcher
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;

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
Scratcher
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.














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
Amazing_Ace
Scratcher
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
Scratcher
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.


#BringBackDiscuss
golfing
Scratcher
71 posts

The end of "Double click the green flag"

Yea nice!

say ["DONT INTERRUPT ME WHILE IM DREAMING OF BAKED BEANS!!"]]
Paddle2See
Scratch Team
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?

Scratch Team Member, kayak enthusiast, and servant to multiple cats.

;
Zparx
Scratcher
500+ posts

The end of "Double click the green flag"

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
zorfo1
Scratcher
100+ posts

The end of "Double click the green flag"

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

CLICK THIS LINK IF YOU'RE BORED AND WANNA TALK TO A BOT ———–> https://scratch.mit.edu/projects/76508476/
WHY? BECAUSE WHY ELSE WOULD I PUT A LINK THERE?
Please note i am not rsponsible for how loudly you read this message or if you damaged your hearing while reading it.
Also, if you need help with scripts or games you can ask me on my profile, if you need a logo, go to @laterbot , Thats where i got mine!
If you need something else just ask on the forums, (what your on if your reading this message).
Zparx
Scratcher
500+ posts

The end of "Double click the green flag"

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!
JABrules
Scratcher
100+ posts

The end of "Double click the green flag"

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.

Last edited by JABrules (May 17, 2015 20:01:43)

Zacshap21
Scratcher
100+ posts

The end of "Double click the green flag"

Very helpful and insightful. Very clear explanations.
Zacshap21
Scratcher
100+ posts

The end of "Double click the green flag"

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.
duckboycool
Scratcher
1000+ posts

The end of "Double click the green flag"

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

I used to be active on the forums, but I have mostly moved past Scratch. I still do check my Scratch messages, so if you'd like to talk to me, just pop a comment on my profile. My main project on Scratch was Cookie Clicker, but I've also recently made a project called Snake Snake, a game based off of Snake, but there are two snakes, and you can play either singleplayer or multiplayer.

Zparx
Scratcher
500+ posts

The end of "Double click the green flag"

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 (:
Zparx
Scratcher
500+ posts

The end of "Double click the green flag"

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!
cheezboy18
Scratcher
78 posts

The end of "Double click the green flag"

Thx! That's really helpful!

Generation 377: the first time you see this copy and paste it on top of your sig in the scratch forums and increase generation by 1. Social experiment.



TheCoolCreeper
Scratcher
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!

Go check this out - I guess I'm part of this now?
qwertysamo
Scratcher
13 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 ]

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)


Check out my chat - made safe by a dictionary built by the Moderators!
https://scratch.mit.edu/projects/77622766/
Zparx
Scratcher
500+ posts

The end of "Double click the green flag"

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! (:
monkeydood
Scratcher
57 posts

The end of "Double click the green flag"

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!

Hello. I'm a scratcher called monkeydood. I enjoy making OS projects of any sort.
(Oops!! I got the code wrong! Guess I'll have to do it again!)
___________________________________
Visit my profile!

Powered by DjangoBB

Standard | Mobile