Question about RPCs with existing objects

Hey there,

Right now I'm looking at altering the environment in the scene for all players when one player does an action. So obviously I need to use RPCs in that respect. Is there a way to tell an RPC to destroy an object that exists for all players, for example a door starts in the scene but is not created with PhotonNetwork.Instantiate. It simply starts in the level already existing.

The problem is I need to have all players replace that object with a "beat up" version of the door, and actually destroy the first door. It seems like making every door and window a network object would be inefficient to the network. Would all of the doors need photonviews if that were the case? Or would I need to make them with photonnetwork.instantiate and generate every level on load up instead of prebuilding it?

Also the RPC call doesn't want me to pass a GameObject as a parameter. I had that set up so that I could pass in the object used to break the door, to spawn its prefab. Is there something I can do about that as well?

Thank you for reading!

Comments

  • Hm, complicated. There are many ways to do this.
    The "best" solution depends on how many objects need to sync.

    In one way or another, you need to have IDs for every object you want to keep a (synced)state for. The pure GameObject doesn't work in this case, as it gets created on each client independently.
    The PhotonView's viewID is the same on all clients, however. This makes finding "the same object" on all clients easy. If you call an RPC, it will execute on the "same" object on all clients. It means you don't even have to send a GameObject - just the PV viewID.

    If you don't have too many objects, you could get away by assigning a PV to each, turn on reliable delta compressed and observe a script that provides the state. If that doesn't change, delta compression skips the update. In best case, your observed script can internally track if something changed and if not: don't write anything to the PhotonStream. This way, you save the delta-comparison but have to make sure you send updates when someone joins later on.
  • A team member suggested I change the name of objects in the inspector so that each one has a different name. Then pass the name of the object as a string parameter, and do a GameObject.Find in the RPC call to get the object. That is working well so far, I'll know if it works for sure after some more testing, but it has passed the first attempt.

    I could add photonViews to them, but that would end up being a large number of objects networked eventually, so this might be less traffic. Though I guess the reliable delta compression would accomplish a similar thing. If it ends up not working properly I will definitely try out the way you suggested. Thank you very much, Tobias :)
  • Actually, I would prefer it if you used PhotonViews. Naming everything and finding it every time you need it is slow and uses more bandwidth than needed.
    You can use RPCs on the PVs, even if you set them to not observe anything. If they don't observe anything, nothing is synced and you still save the extra work of identifying everything and sending names in RPCs.