Third Party [PhotonNetwork] Object's Owner

Hi everyone!

I am creating a room-based game, the player can create the room (then he is the master client) and choose how many bots (AI) will be in the room, and then he can play against the AI, and other players can join
In Photon, when a the master client disconnect, the "control" goes to another player automatically, which is working awesome!
But the problem is, that the AI clients are also getting destroyed with the master client...
How can I prevent that from happening, and let the next master client take control over them?

Thanks a lot!

 

If you instantiate the AI bots, you can use PhotonNetwork.InstantiateSceneObject() instead of Instantiate(). The objects are created for the room and stay even though the creator leaves.

 

and who is the "owner" of them?

 

Objects created with InstantiateSceneObject belong to the scene, so the Master Client owns them.

 

Thanks a lot!
Really every-time I had a question on Photon you answered really fast, I really appreciate it and is one of the many reasons I stay with Photon!

 

Until PUN is fully self-explaining, we will answer questions the best we can

 

@tobiass well I hope you still work at Photon. 7 years later to this thread, sorry but for me instantiateroomobject makes me owner of anything instantiated. They dont belong to the scene as you said above, anything instantiated has as owner the master client. I tried both instantiateroomobject and instantiatesceneobject, both cases there is an owner and the owner is the master. Has anything changed lately in photon? I'm in version 2.34.1

 

The PhotonViews always need some owner and controller.
The room does not have a representation within the client, so a PhotonView can not refer to the room as owner. The Master Client is taking that role.
When the Master Client is dropping / changing, the owner and controller should change as well (to the new Master Client).

 

But this wasn't always like this, right? I mean the docs specifically say the owner and the controller should be null here: https://i.gyazo.com/1fb29c31bf29dda877f7480014e0bb02.png

edit: damn seems i was too tired last night and read your above comment "Objects created with InstantiateSceneObject belong to the scene, so the Master Client owns them." literally the other way around.

Fair enough so the master owns them, but can you tell me why this weird behaviour i get where a room object will not be synced correctly within the room members?
I'm spawning bots and some kind of battle royale zone with instantiateroomobject. If a player joins in late, after the game has started, the bots will not be in the same place they are at the master client, some of them will not have moved from spawn and some of tham walk but it's some weird behavious. Also the battle royale zone will not be in the same place as it is for the master client.

Both bots and the zone have photon view and photon transform view, and the transform view is assigned at observed components

 

@tobiass, sorry for the tag, it might get your attention. So can instantiateroomobject be kind of broken in photon pun 2.34.1, Photon lib: 4.1.6.4 ?

Like i said, if a client joins late (after the roomobjects have been spawned), the roomobjects will not be in the in the same position as they are for the master client. I tested in another project i have that uses a newer photon, the objects seem to be behaving well for the late joiners. For my project upgrading photon is pretty hard and i would avoid doing it unless i need to. Could it be something else? What could it be?

 

Yes, the Master Client was always in charge of the scene objects. We did change the way how control and ownership is separated in newer PUN 2 versions but it's essentially only the icing in the cake. We wanted to get rid of situations, where we return null as controller, instead of properly returning the Master Client.

I would bite the bullet and update to PUN 2 latest. There are so many fixes in the last few iterations alone, that you don't want to miss out. It's not all on the PUN 2 level, so I think the update should be doable in a few hours, but it really depends on your project, too.

The changelog may help you identify what changed since 2.34.