PhotonNetwork.InstantiateRoomObject has owner != null?

Sharad

Hi,

First time asking here and new to unity and PUN. I am trying to reconcile what I'm seeing here [https://doc.photonengine.com/en-us/pun/current/gameplay/ownershipandcontrol#room_object] with what I am observing in the game.

A networked room object is a networked object that does not belong to an actor but it is a 'global networked object' belonging to the room. It has no owner (null), nor controller (null) and it is not a result of a PhotonNetwork.Instantiate call (but could be a result of PhotonNetwork.InstantiateRoomObject).

In my code, I have written this:

   var go = PhotonNetwork.InstantiateRoomObject(this.rodPrefab.name, position, orientation, 0);
   var pv = go.GetComponent<PhotonView>();
   Debug.LogFormat("New object owner {0}", (pw.Owner == null) ? "null" : pv.Owner.ToString());

and the logs show:

The logs are when there is a single (MasterClient) connected.

Context: I am trying to get the MasterClient to create these "pickable" room objects that can be owned (and eventually destroyed) by the masterclient or other clients in the game. Any other pointers or tips would help!

Thanks,
Sharad

Sharad

Forgot to mention. The prefab > PhotonView component has "Ownership Transfer" set to "Request".

Tobias

Please update to PUN 2.29 and try to reproduce.

Sharad

I think I am using it already. I took a quick peek at my changelog and it says -->

  1 
  2 PUN 2 - Changelog
  3 Exit Games GmbH - www.photonengine.com - forum.photonengine.com
  4 
  5 
  6 v2.29 (15. March 2021)
  7 Updated: Minimum supported Unity version to 2018.4.x. We develop PUN 2 in Unity 2018.4.22 from now on. Also the language compatibility level '.Net Standard 2.0' is now being e    xpected.
  8 Updated: Export settings for the dlls in Assets\PhotonLibs. All platforms will use .Net Standard 2.0, except the UWP export with .Net Runtime (which uses Metro with a placehol    der being the lib in PhotonLibs\).
  9 Removed: Setting of protocol 1.6 when connecting directly to a Master Server. This was a workaround for older Photon Server SDKs.
 10 Note: If you host Photon yourself, you can set the LoadBalancingClient.SerializationProtocol to SerializationProtocol.GpBinaryV16, before you connect.
 11 Added: IPunOwnershipCallbacks.OnOwnershipTransferFailed. This helps react when an Ownership Transfer request failed (due to earlier changes). This might mean you have to imple    ment OnOwnershipTransferFailed in some scripts.
 12 Changed: PhotonView OwnerActorNr and ControllerActorNr to make use of the new Room.GetPlayer() option (to get the Master Client instance if the owner/controller is set to 0).
 13 Fixed: The PhotonView's "Find" button was not saving the observed components in scenes, which meant the script wasn't called at runtime. 
 14 Updated: Library to 4.1.5.2.

I am guessing this means I am already on this version (or do I have to manually switch current library version elsewhere too?).

Tobias

Ok.
That doc is a bit misleading.
A room object has no owner by default but it's controlled by some client. The Master Client has control in the beginning. You can transfer ownership and control. So these values don't have to be null.

Use RequestOwnership() on a client that does not control the object to request ownership or the current controlling player can call TransferOwnership().

Sharad

Thanks Tobias for clarifying.

Is there a suggested way for tracking a photonview as currently unassigned? I tried TransferOwnership(null) and that didn't go well

In the game I'm developing, all players are "equal" and initial ownership to the MasterClient seems to break the logic. Each player is trying to claim the prize and ownership seems like the most natural and race condition free (hopefully) approach to this.

Is adding a ghosting player a good solution? When the prefab is instantiated, pass ownership immediately to this player and wait it to be truly claimed by one of the players?

Is there a different attribute that's better suited for this work?

Thanks,
Sharad

Tobias

PUN uses distributed authority. There is no "unassigned" case. One of the clients has to simulate the object and produce a state for it. But the object does not have to move / do anything due to that.

It might make sense if you explain what you want to achieve over how you do it now and what you think is the problem