Master takes ownership of client's object when created via RPC

Options
I have an online FPS which contains 2 prefabs for a game player. A local prefab which each player uses for themselves and a remote prefab which each user spawns for all remote players. The local prefab is synced by the view ID to the remote prefabs on the remote player machines.

When a client sends an RPC to all remote players to spawn them in the scene. This works but when the master receives the RPC, it uses the standard Unity instantiate on the remote player prefab (photon view with a photon view transform). The view ids are set correctly and everything works but the master hijacks ownership of this object. This means the client isn't able to move as the master is controlling their game object.

The only way I got to it to work was to set the prefabs ( local & remote ) to both have their view owner set to "request". The local client instantiates their local prefab, immediately requests ownership of this, and then sends an RPC to all remote players telling them to instantiate a remote prefab on their machine.

When the other clients and master receive the RPC, they instantiate the prefab for a remote player, set the view id, and then immediately call view.TransferOwnership() for the remote player who sent the RPC.

This seems to work but I wanted to check if this is the correct way to handle clients using an RPC to spawn objects in the game. Also, I was concerned that because the local player requests ownership before the master might receive the RPC to create the object, was there any danger in this getting dropped and the transfer not occurring?

Thanks in advance,
SGS

Comments

  • Hi @strangegames,

    I have an online FPS which contains 2 prefabs for a game player.


    Are those two different prefabs? If not, using PhotonNetwork.Instantiate(...); would be the easiest solution.

    The view ids are set correctly and everything works but the master hijacks ownership of this object.


    Does this only happen on the MasterClient? Whats happens if you add a third client? Do you have the same behaviour?
  • strangegames
    Options
    The 2 prefabs are different. The local prefab has a camera, input controls, FPS arms models, etc.. so it's only used for the local player. The remote prefabs obviously don't need these so that's why there are 2 prefabs.

    I haven't tested it with additional clients so I don't know what that behavior is. When I found the master was hijacking it, I didn't bother going forward with more clients.
  • I would recommend you taking a look at the Oculus Avatar documentation page even if you don't work with that SDK. Anyway this page provides an example which is similar to your case and shows how to instantiate two different prefabs, one for you and another one for each other client in the room. It's in the section 'Instantiating Avatars'. Please check if this helps you solving the problem.
  • strangegames
    Options
    Ok thanks, that helped me see what I was doing wrong. I was just setting the viewIDs manually based on the players photonID which worked but I'm guessing Photon had no way to know who was the owner and defaulted to the master. I think I needed to call RegisterPhotonView() after setting the viewID. I decided to use PhotonNetwork.AllocateViewID() instead to make sure the viewIDs were always unique. I think either call will allow Photon to know who the owner is of the view. It's now working so thanks for pointing me in the right direction!
  • BFX
    Options
    Hi Strange games, I have exactly the same problem. Two different prefab instantiated, when I instantiate the master's remote avatar on the guest everything works fine, but when I instantiated the guest's remote avatar on the master it doesn't move because it's controlled by the master "locally controlled: (master)".
    I tried to pass over the actorNumber and perform a TransferOwnership() but it doesn't work. The problem is that I cannot instantiate the prefab at run time for the local avatar since it's required by some logic to have the prefabs there. This mean the prefabs have already a PhotonViewID and I don't need to allocate it. I just pass it over with a custom event and let the remote clients instantiate their copy and connect the photonviewid which I pass as parameter. you can find a more detailed explanation here:
    https://forum.photonengine.com/discussion/16272/remote-avatar-created-by-master-cannot-be-controlled-by-remote-user/p1?new=1

    Please let me know if this rings any bell. Any help would be much appreciated
  • strangegames
    Options
    Sorry for the slow response but I haven't had time to look back at this. I just had a chance to pull this code back up and it appears that what I ended up doing was not relying on transfer ownership. It seems the key part was using PhotonNetwork.AllocateViewID to get a unique view ID and then setting that on the photon view once it's instantiated on what you call the guest. I then had the guest send a message to everyone else (what you call the master) and have them instantiate a prefab and then set the photon view's ID to the ID sent in the message. It seems that I never had to use transfer ownership. I think just doing those 2 things should work for you.