PhotonView on child destroys parent gameObject?
Options
Bren
✭
I have a player character with a photonview and a gun with a photonview. The gun is a child of the player. If the player drops the gun, that client destroys the gun and instantiates another on the server via RPC.
However, when the gun calls PhotonNetwork.Destroy(gameObject) -- i.e. itself -- it's actually the player character parent that gets destroyed on other machines. Not the gun. The player character remains on the player's client, and the gun is destroyed, but on others, it the reversed -- destroyed player, remaining gun.
This happens for both ordinary clients and the master client. Doesn't matter who does the dropping, the parent is destroyed instead of the child.
I have traced through the code very carefully and am 100% certain that the PhotonNetwork.Destroy() is called on the gun's own gameobject and not accidentally its parent's.
Naturally, once this has happened, I start seeing tons of "Received OnSerialization for view ID 2001. We have no such PhotonView!" blah blah blah errors because the player has been destroyed on the others clients.
What gives?
However, when the gun calls PhotonNetwork.Destroy(gameObject) -- i.e. itself -- it's actually the player character parent that gets destroyed on other machines. Not the gun. The player character remains on the player's client, and the gun is destroyed, but on others, it the reversed -- destroyed player, remaining gun.
This happens for both ordinary clients and the master client. Doesn't matter who does the dropping, the parent is destroyed instead of the child.
I have traced through the code very carefully and am 100% certain that the PhotonNetwork.Destroy() is called on the gun's own gameobject and not accidentally its parent's.
Naturally, once this has happened, I start seeing tons of "Received OnSerialization for view ID 2001. We have no such PhotonView!" blah blah blah errors because the player has been destroyed on the others clients.
What gives?
1
Comments
-
Hm. That must be a side effect of how we select the GO when a Destroy() gets sent for a PhotonView. The current setup doesn't handle parenting and maybe we get the wrong GO for a PhotonView.
I can take a look but over the holidays, I can't promise much.
Actually, I would propose a better solution. You don't have to destroy and re-instantiate the gun in best case.
While a player carries a gun, it does not need a PhotonView. It's at the position of the player and in the character's hand. Done.
When you drop it, there is nothing to network-destroy. You simply instantiate a dropped weapon somewhere and when it's picked up, you can destroy that. Again, without parenting.
You say you do a RPC? What exactly does it do?0 -
The design goal is that players can drop weapons in the world, and other players pick them up. This should work even if the player that dropped the weapon leaves the game.
My strategy has been to create/attach player owned weapon instances when they are picked up. When they drop them, the weapon is destroyed, and the player tells the master to create a new weapon which is in the world. This is what the RPC is for. When that weapon is picked up, that instance is destroyed, and a new one is created, owned by the player. So basically, the master owns weapons in the world, and players own the weapon they're carrying.
If I understand your suggestion, only the weapon in the world needs a PhotonView, and the ones held by players need only be attached objects if you will, not PhotonView controlled. I will still need to instantiate this held weapon across the network, so other players see the weapon on the player. Does this prefab not need a PhotonView? Can I network instantiate object without a PV? I assumed I could not.
Incidentally, I do detach the weapon from the owner player before calling network destroy, but only on the owner and just before the destory. The detachment is not distributed.-1 -
How many weapons do you expect in a room/scene?
If they are loaded with the level, each could be a scene object. You would have to pick it up (and "save" that state) and be able to put it somewhere else (switching back to state "dropped" and setting a new pos).
In PUN 1.50, you can take over control for any object. So players can pickup weapons and take control. They don't send position updates or anything until they drop the weapon again.
http://doc.exitgames.com/en/pun/current ... p-transfer
While a player has a weapon, it does not need to have it's own PhotonView at all: It's part of the player. You just need to sync that a player has some weapon currently and any client can display that (much in the way that a client also shows the character someone is playing).0 -
Sorry for the necro, but there is no other forums that contain a legit answer.
We found that by changing the value of isRuntimeInstantiated to false (view.isRuntimeInstantiated = false;)
before running the PhotonNetwork.Destroy on the view, this solves the problem, when that value is true it finds the parent instantiationId, when it is false it uses the child photonview id instead1 -
Is Amazing how after 8 years they havent take the time to solve this issue...1
-
@Fizzostia Thank you brother!
0
