Logic Question With Creating Objects
Options
I need to create a number of objects in the scene, originally I had an RPC call that created them for everyone, but that doesn't track the photonviews if its not PhotonNetwork.Instantiate, so that doesnt work quite right.
If I create the objects without an RPC, and use PhotonNetwork.Instantiate, it works as far the photonviews and tracking them, but then I run into the issue of having all players have those created objects parent to the proper object and that kind of thing. Or other examples like turning off the newly created object's particle system for all players.
What is the best way to handle a situation like this? My guess thus far is to do the second way (PhotonNetwork.Instantiate) then have an RPC call in the function that creates the object, and the RPC call would child the new object, set the particle systems, etc. But then I'd have to pass the child and parent into the RPC call, which I guess could be photon view ID's. Is there a different way to handle this or is that about it?
If I create the objects without an RPC, and use PhotonNetwork.Instantiate, it works as far the photonviews and tracking them, but then I run into the issue of having all players have those created objects parent to the proper object and that kind of thing. Or other examples like turning off the newly created object's particle system for all players.
What is the best way to handle a situation like this? My guess thus far is to do the second way (PhotonNetwork.Instantiate) then have an RPC call in the function that creates the object, and the RPC call would child the new object, set the particle systems, etc. But then I'd have to pass the child and parent into the RPC call, which I guess could be photon view ID's. Is there a different way to handle this or is that about it?
0
Comments
-
I'm not sure how well this works with parenting. You can make a networked object parent but I guess the other way round it might cause problems. I'm not sure if all values are local (to the parent).
PhotonViews are the built-in way to identify objects over the network, so you could add them to more or less anything you want to reference. It's just an int per GO and it doesn't have to continuously sync any values if that's not needed. Alternatively you would have to build your own way to identify GOs and then reference them when you need to make them parent or child.
Even if a GO has a script with OnPhotonSerializeView on it, that method doesn't have to send anything. Just don't write something if the object is not top in it's networked hierarchy.
For the particle systems: Use RPCs to set them up or include an "on or off" bool in your stream provided by OnPhotonSerializeView.0
