- Last Active
- Registered, Administrator
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?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).1
Yes, with the "props listed in lobby" you should be able to get selected props as room info.
With all the rooms being used, make sure to close those you don't need anymore (or make them visible = false).
Hashtables for properties: On the server, we allow byte keys as well. Those are props Photon uses and the byte keys avoid clashes with custom keys. So Dictionary was not an option anyways.1
I copied the methods from my latest PUN where they might have other names.
StopThread is what I meant.
Glad it helped!1
Thunder currently just replaces the LLAPI of uNet and keeps the HLAPI completely intact. It's too early to say if we can fix issues in the HLAPI, as Unity is still actively working on it and it will change quite a bit before it settles in.
Thunder makes most sense when you got a uNet project for which you could use another networking implementation.