Ownership transfer

Hi!

I have the following situation:
Player loses connection, becomes inactive and server waits for that player's reconnect. And I'm trying to get that disconnected player controlled by AI or something like that until he/she reconnects. So the master client takes care of everything, but only after playerTtl time expires, since only then player view is owned by scene. So the question is: is there a way to get ownership of the disconnected player view?
I've read something about Ownership Transfer and I know I shoud choose TakeOver option for the desired PhotonView. But I don't get what to do next and I'm not sure if that ownership transfer would succeed since the current owner is disconnected. Also, what will happen if that player reconnects? Will he be the owner of that view again?

P.S. I'm sorry for my English

Comments

  • After the player disconnected, someone takes ownership of his view.
    Then player reconnects, he's sure he still owns his view, but all other players know he's not - who's right?
  • And another case:
    player disconnects, other player takes ownership of disconnected player view, then new owner disconnects, then the first one reconnects - who owns his view?
  • Regaining control in PUN is a bit tricky. Partly, this is due because there is no clear solution.
    When someone is gone for a while, the stand-in controller of an object may move it. When the creator returns, the most recent state of that object is unknown to this player. Taking back control can not be done instantly due to this. It's worse, when the most recent controller of an object gets disconnected, before the original "owner" comes back.

    In best case, you'd use Ownership Transfer to clarify the situation. The current controller of an object should return the control, when the original player comes back. You could use PhotonView TransferOwnership() or RequestOwnership() accordingly.
  • Hi @Tobias

    Thank you very much for your reply!
    Tobias said:


    In best case, you'd use Ownership Transfer to clarify the situation. The current controller of an object should return the control, when the original player comes back. You could use PhotonView TransferOwnership() or RequestOwnership() accordingly.

    Yes, I do something like that, but I don't understand what actually happens under the hood and it leads to unpredictable results.
    For example,
    Djebedia said:

    After the player disconnected, someone takes ownership of his view.
    Then player reconnects, he's sure he still owns his view, but all other players know he's not - who's right?

    Is ownership synchronized somehow? When does the reconnected player knows who is the current owner of his view?
    Maybe there is some kind of documentation? I have sooo many questions
  • Also, I have the following problem:
    There are some scene objects in the room, and two players in that room see different owners of the same object. I don't get how to embed images so there are links to screenshots:
    https://prnt.sc/n94vpa
    and
    https://prnt.sc/n94yrw
    Could someone explain me why is it so?
  • And in case both of those players disconnected and rejoined the room again, if the first one to rejoin is NOT a master client, then that player becomes one but he is sure that those scene objects are still owned by the other player (which owned them before disconnect) and the other player (which was the mc before the disconnect) knows that those objects are scene objects and he is no longer the master client and there for he doesn't control those objects. And the result is - noone controls scene objects.
    https://prnt.sc/n9573b
    and
    https://prnt.sc/n957rd
  • It looks like I could just assign the master client to the second player and this would lead to the same result: noone controls scene objects.
    And it looks like the NetworkPeer is responsible for that
    
    // This is when joining late to assign ownership to the sender
    // this has nothing to do with reading the actual synchronization update.
    // We don't do anything is OwnerShip Was Touched, which means we got the infos already. We only possibly act if ownership was never transfered.
    // We do override OwnerShipWasTransfered if owner is the masterClient.
    if (sender.ID != view.ownerId && (!view.OwnerShipWasTransfered || view.ownerId == 0) && view.currentMasterID == -1 )
    {
           // obviously the owner changed and we didn't yet notice.
           // Debug.Log("Adjusting owner to sender of updates. From: " + view.ownerId + " to: " + sender.ID);
           view.ownerId = sender.ID;
    }
    Why are scene objects becoming NOT scene objects on the not master clients?
  • there's something similar: https://forum.photonengine.com/discussion/8595/late-joining-bug
    @Tobias could you just tell me if there would be any answer or that's all?
  • Sadly, there is no sync of ownership/control through the server, so the clients currently have to manage. This leads to the problems you encountered. I will try to look into this but can't promise swift solutions...

    As a first step: Use PUN 2.
    It looks as if you use PUN Classic, which is no longer actively developed.

    When an object PhotonView tells you it's controlled by "Scene", some player is in fact controlling it. It's the Master Client. There is always a Master Client. For a new room, the first player is the Master Client. Should this client leave, the next takes over.

    When someone returns to a game and doesn't know the current state, then everyone else is "correct". When this happens, we have to look into solutions how to sync this.
  • Alright, I got it, thanks
  • And back to this theme
    Tobias said:


    When an object PhotonView tells you it's controlled by "Scene", some player is in fact controlling it. It's the Master Client. There is always a Master Client. For a new room, the first player is the Master Client. Should this client leave, the next takes over.

    Should the Master Client leave, the next does nothing, cause he's sure scene objects are not scene objects, he thinks scene objects are owned by previous MC.
    if (sender.ID != view.ownerId && (!view.OwnerShipWasTransfered || view.ownerId == 0) && view.currentMasterID == -1 )
    {
           // obviously the owner changed and we didn't yet notice.
           // Debug.Log("Adjusting owner to sender of updates. From: " + view.ownerId + " to: " + sender.ID);
           view.ownerId = sender.ID;
    }
  • This is still PUN Classic code, right?
    PUN Classic is in maintenance mode and we can only fix export issues or updates for newer Unity iterations. PUN 2 has a better implementation of this already and it's not feasible to port all features back.

    This code in particular was considered problematic and we commented it out.

    If the other player leaves, then the current Master Client should realize that he's standing in for that player, taking control of the object for someone who's not active.
    That code you pasted may be overruling this but I'm not sure.
  • Yes, this is PUN Classic.
    And yes, I've commented it out too.
    And I'll think about update to PUN2, thanks for your reply
Sign In or Register to comment.