This article or section is about or uses Cloud Data. Users with the New Scratcher status cannot make projects using Cloud Data or use it in other users' projects. New Scratchers need to have Scratcher status.

Projects which use Cloud Data may have to send signals from one player to another. The scenario explained in this article is when a project can only continue when all players are ready – they therefore need to send signals to each other, which can be more complicated than it sounds for someone who is new to cloud data. The examples use a game which connects three players.

Using One Cloud Variable

 Note: This method should not be used. It is only given to illustrate why a more complex approach is necessary.

How to Do It

This section assumes that the project has a cloud variable named `(☁ wait)` and that this variable is initially set to 0. When the player has reached a certain stage in the project and is therefore ready to continue, it changes the variable by one. It then waits until the variable is equal to the number of players (in this case 3), before the script continues:

```change [☁ wait v] by (1)
wait until <(☁ wait)=(3)> // Waits until all players have got to this stage
```

Problems with This Method

Imagine that the variable is still 0 – none of the players a ready to continue yet. Then two players become ready very shortly after one another. The first player who is ready sees that the cloud variable is 0, and therefore sets it to 1. Before this has been uploaded to the Scratch server (there is always a short delay), the second player is ready. They also see the cloud variable to be 0 and therefore set it to 1. The server is told twice to set the variable to a value of 1, so even though two players are ready, the value remains 1. When the third player is ready, they set the variable to 2, and then all players continue waiting infinitely.

Using Four Cloud Variables

 Note: This method should not be used. It is only given to illustrate why a more complex approach is necessary.

How to Do It

This section assumes that the project has 3 cloud variables (because of 3 players) named `(☁ wait1)`, `(☁ wait2)` and `(☁ wait3)`, and that these variables are all initially set to 0. Each player also has a local variable called `(mynumber)` which has a value form 1 to 3, depending on which player they are.

When each player gets reaches this stage of the project, they change their own cloud variable (the one which corresponds to their number) by 1, and then wait until all the other players have done the same. This eliminates the problem in Method 1 above where two players were changing the same variable at the same time.

```if <(mynumber)=(1)> then
change [☁ wait1 v] by (1)
else
if <(mynumber)=(2)> then
change [☁ wait2 v] by (1)
else
if <(mynumber)=(3)> then
change [☁ wait3 v] by (1)
end
end
end
wait until <<(☁ wait1)=(1)> and <<(☁ wait2)=(1)> and <(☁ wait3)=(1)>>>
```

Problems with This Method

A problem can occur even here when there is a long delay from one of the players – this usually does not happen, but a script must always work, not just usually. Due to the limited number of cloud variables available in Scratch (10 per project), the variables will probably have to be reused in a cloud game soon after. Imagine that two players are already ready and have set their respective cloud variables to 1. Then the third player arrives and sets their cloud variable to 1. The other players continue, as all three variables equal 1, and give their own cloud variables new values. By the time the third player gets to the wait block (which could be several seconds later if there is a delay), the variables are no longer all equal to 1, and the third player once more waits infinitely.

Using Five Cloud Variables

 Note: This is the method which should be used and is guaranteed to work.

How to Do It

This section assumes that the project has 4 cloud variables (3 players plus one extra) named `(☁ wait1)`, `(☁ wait2)`, `(☁ wait3)` and `(☁ globalwait)`, and that these variables are all initially set to 0. Again, each player also has a local variable called `(mynumber)` which has a value form 1 to 3, depending on which player they are.

When each player gets reaches this stage of the project, they change their own cloud variable (the one which corresponds to their number) by 1, and then wait until all the other players have done the same. This eliminates the problem in method 1 above where two players were changing the same variable at the same time.

Once they have finished waiting, meaning that all players are indeed ready, they set the globalwait variable to 1. Then they can change their own cloud variables to anything they like, because globalwait acts as a signal to the final player. This solves the issue described in method 2 above.

```if <(mynumber)=(1)> then
change [☁ wait1 v] by (1)
else
if <(mynumber)=(2)> then
change [☁ wait2 v] by (1)
else
if <(mynumber)=(3)> then
change [☁ wait3 v] by (1)
end
end
end
wait until <<(☁ globalwait)=(1)> or <<(☁ wait1)=(1)>and< <(☁ wait2)=(1)> and <(☁ wait3)=(1)>>
set[☁ globalwait v] to (1)
```

This method should work even if there is a 5-second delay between the players and every player is ready at the same time.