The Photon Forum
is Closed Permanently.

After many dedicated years of service, we have made the decision to retire our Forum and switch to read-only: we´ve saved the best to last! Your search result can be found below. Plus, we offer support via these channels:

Try Our

Please check if you can find an answer in our extensive documentation on PUN.

Join Us
on Discord

Meet and talk to our staff and the entire Photon-Community via Discord.

Stack Overflow

Find more information on Stack Overflow (for Circle members only).

Write Us
an E-Mail

Feel free to send your question directly to our developers.

Photon instantiated objects delete themselves when new player joins room.

2021-01-03 19:47:33

Hi all,
Been looking around and been unable to find someone having the same issue. Quite odd...

Player(Who becomes master client) joins an empty room, spawns fine (via PhotonNetwork.instantiate) and is able to run around.
Player 2, joins the room but from Player 2s client, Player 1 character destroys himself (confirmed by logging in OnDestroy).
From Player 1 perspective, everything is fine and player 2 is spawned in correctly.

I've removed as many things to keep this issue simple so it's clear what the problem is, so I have
now gotten the master client to photon instantiate a cube. Then have another client connect and see the cube
but again, the cube destroys itself when joining (only from player 2s perspective). This cube has no script attached to it other than a Debug log in the Awake and OnDestroy functions to prove its spawning then being destroyed instantly.

Any ideas?

Much Appreciated.


2021-01-04 13:07:02

Increased the PUN logging to full and seeing the following:
PUN-instantiated 'DummyNEW(Clone)' got destroyed by engine. This is OK when loading levels. Otherwise use: PhotonNetwork.Destroy().

However im not attempting to destroy the dummy box anywhere in the code base, has anyone experienced this before?

2021-01-04 18:20:30

After further investigation, seems that when a room is found and the player attempts to join the room, it instantly loads the data (in this case instatiated prefabs before the player joined) but at this point, the correct scene is still loading. Finding the right room is done in a different scene so the networked data gets spawned into that, but now the prefab has been spawned into the wrong scene because that scene then gets instantly unloaded to load the actual correct scene.... so it looks like running multiple scenes concurrently then having a dedicated scene for GameManager stuff is problematic. I would expect more people ran into this issue if that's the case... does this mean having multiple scenes is not a suitable option?

2021-01-05 22:31:48

If anyone else comes across this issue, I basically had to work around the issue. Essentially having all players waiting until the room is full then having the master client PhotonNetwork load the scene which causes all the other clients to load the scene too (Happens when you have PhotonNetwork.AutomaticallySyncScene = true;). Then once everyone has loaded, begin dealing with instantiating characters. It's a short-term solution till I get a decent reply here... I assume I will still have this issue if players leave then rejoin the room via disconnect/quit...

2021-01-07 15:22:03

Thanks for updating this thread with your findings. Glad you found a workable way.

Loading a scene in Unity will normally destroy the objects that are currently there. Except those you passed to DontDestroyOnLoad().

PUN does not support multiple scenes via AutomaticallySyncScene and the master loading some. It's only one.
In networked conditions, it's quite tricky to get the timing right for loading scenes and getting messages that already rely on objects some slow client might still be loading. Having multiple scenes in parallel and the option to unload either .. doesn't make this easier.

So for simplicity sake, we limit PUN to having one scene and it's best to load it after you joined the room (and PUN will pause dispatching any received messages while Unity loads).

2021-01-16 16:24:58

Thanks for your response, I think my workable solution is probably a better solution in the long run anyway!

Back to top