Photon Views in Instances

Options
I'm working on an open world game than uses instances for things like dungeons (and not all players will be in the same instance at once). Most of the stuff in these "instances" (I'm using the term loosely) is static, and handled locally, but I use photonViews for things like enemies and doors that need to be synched between clients.

I have it setup currently so the first player who enters an instance locally instantiates prefabs & manually assigns the PhotonViews, and the IDs are stored in the room properties. When other players join the instance, they locally instantiate prefabs and assign them the viewIDs from the room properties, which are then updated w/ RPCs.

The issue I'm having is that if the player who creates an instance (and instantiates objects) disconnects, those photonviews & objects are destroyed on other player's games as well. I played around with using Scene Objects instead (that was my original idea), but that has the downside of requiring the Master Client to create & control them, and by default gets instantiated for all clients.

Basically, I'm trying to find a work around that will stop these objects/photon views from being destroyed when the owner leaves...or any other suggestions I guess? Thanks. :)

Comments

  • vadim
    Options
    Set PhotonNetwork.autoCleanUpPlayerObjects to false before creating the room.
  • Thanks for the response vadim. Is it possible to transfer ownership after the owner leaves? I always assumed the current owner had to respond, I guess maybe it would be handled by the master client? Also, is it possible to make OnPhotonSerializeView() on send updates to certain peers rather than everybody?
  • vadim
    Options
    Use PhotonView.RequestOwnership to change ownership (check Assets\Photon Unity Networking\Demos\DemoChangeOwner demo). Alternatively you can instantiate scene objects (PhotonNetwork.InstantiateSceneObject) which has no owner and therefore has no problems with it (technically master owns and controls them).
    OnPhotonSerializeView always sends updates to all other clients in room. RPCs has options to control who receives them.
  • Use PhotonView.RequestOwnership to change ownership (check Assets\Photon Unity Networking\Demos\DemoChangeOwner demo)

    Yeah, I know. But I wasn't sure how it worked when the current owner leaves. I see now that ownership reverts to the master client - which doesn't work for me as the master client likely won't have instantiated the objects in question.

    On top of that, using the built in ownership transfer methods can take close to 15 seconds to finish for larger instances - which is another problem in itself.
    Alternatively you can instantiate scene objects (PhotonNetwork.InstantiateSceneObject) which has no owner and therefore has no problems with it (technically master owns and controls them).

    While scene objects solve the ownership problems, I would have to juggle who the master client is. Every player could potentially be in a different instance at the same time, so everytime they attack something i would have to try and make them the master client first, which I haven't tested but I'm guessing is going to lead to glitches.

    I solved the issue by using a scene object with an "Instance Manager" class that I made. It keeps track of players entering & leaving instances (whether by leaving the game or just the instance itself), and stores everything in a dictionary. If I need to change ownership of the photonViews, if because the owner disconnected for instance, the instance manager sends RPCs to everyone currently in the instance and anyone who joins in the future with the new ID and they will just change it locally - it takes less than a second to find a new owner and have everyone update it this way.
  • vadim
    Options
    Nice to hear that you found the solution.
    On top of that, using the built in ownership transfer methods can take close to 15 seconds to finish for larger instances - which is another problem in itself.
    What does "large instances" mean? Owner changed with sending of one RPC I think and could not take so long. How do you measure that time?