1

First I have to say I’m using Photon, but I’m not sure the issue is related to that.

It’s a multiplayer game, so when players are joining, they chose a team, and every other clients need to know it, even the ones joining afterwards.

All the following code is in the same Network Manager object.
So I’m using a RPC call like this :

photonView.RPC ("teamFunction", PhotonTargets.AllBuffered, whatTeam, PhotonNetwork.player);

whatTeam is just a boolean, true for the blue team and false for the red team.

Then there is the teamfunction :

[PunRPC]
	void teamfunction (bool wTeam, PhotonPlayer who)
	{
			if (wTeam) who.SetTeam(PunTeams.Team.blue);
			else who.SetTeam(PunTeams.Team.red);
		}
}

The problem is that players joining after that receive the RPC call, but for some reason they think they are the PhotonPlayer “who”.

For example a first player create a server and join the blue team.
A second one connect to it, and leave without choosing a team, the server is going to think this player was on the red team (because the previous player was).

This is annoying because it mess the team player count.

3

I wanted to reply but my answer got stuck in moderation.
As comment:

When I tried your code, I almost couldn’t believe it myself. Something seemed odd.
And then I found it: You send an RPC for teams, which are (network-) synchronized via properties. This has obviously funny effects, due to the workflow of both synchronization variants.

The RPC is sent to all but PUN will use a shortcut locally: It executes the method directly when you call the RPC instead of sending it to the server and waiting for the response. SetTeam() will be called in the RPC and update the player’s properties on the server. Properties always just store the last/current value.

When someone joins, the local team setting uses the same workflow but the remote player’s team is not. The remote player’s property (which has the “current” team), will show the remote player’s current team. Then the RPC gets executed and sets the team again. Somewhen, the local player’s RPC will also execute.

Best, just use SetTeam and skip the RPCs for this. SetTeam solves the problem you want to solve with your RPC. Actually, using AllBuffered, you will just create a (growing) list if RPCs that have to be executed when someone joins and that’s not necessary.

The DemoPickup folder has a scene which uses the team stuff.

2

Huh, when I tried your code, I almost couldn’t believe it myself. Something seemed odd.
And then I found it: You send an RPC for teams, which are (network-) synchronized via properties.
This has obviously funny effects, due to the workflow of both synchronization variants.

The RPC is sent to all but PUN will use a shortcut locally: It executes the method directly when you call the RPC instead of sending it to the server and waiting for the response.
SetTeam() will be called in the RPC and update the player’s properties on the server. Properties always just store the last/current value.

When someone joins, the local team setting uses the same workflow but the remote player’s team is not.
The remote player’s property (which has the “current” team), will show the remote player’s current team. Then the RPC gets executed and sets the team again.
Somewhen, the local player’s RPC will also execute.

Best, just use SetTeam and skip the RPCs for this. SetTeam solves the problem you want to solve with your RPC.
Actually, using AllBuffered, you will just create a (growing) list if RPCs that have to be executed when someone joins and that’s not necessary.

The DemoPickup folder has a scene which uses the team stuff.