Understanding how RPCs work

Hey guys,

I was sure I posted a reply to a previous topic about this, but for some reason I don't think it got posted.

Basically, this is a pretty general question. Although I would still consider myself as a bit of a newb when it comes to server programming using the Photon/Unity solution, I have been doing it for some time now. I still however am really stuggling to understand how RPCs work, and often find myself trying to use some sort of a work-around due to the lack of information I've been able to find on the subject.

If you could answer these two questions, it would be greatly appreciated, and hopefully will help anyone else who is struggling to grasp the concept:

1) How does a PhotonView tie in with an RPC? For example, what difference does it make to call an RPC on one PhotonView in comparison to another? If you could give some logical examples of how this process works behind the scenes (code is not needed) that would also be greatly appreciated.

2) The second parameter of the RPC method, the PlayerTargets enum or the PhotonPlayer, what exactly do the PlayerTargets point to? This is possibly the aspect that I am more so struggling to understand as I have tried numerous combinations of calls on different PhotonViews using the different PlayerTargets enums but the outcome is never quite what I'm expecting. Also, what difference does it make to use a PhotonPlayer instead of PlayerTargets?


I'm honestly dieing for that "Ahh now I get it!!" moment when it comes to this subject. Understanding how your RPCs work would be a dream come true! :D

Many thanks in advance.

Comments

  • 1) How does a PhotonView tie in with an RPC? For example, what difference does it make to call an RPC on one PhotonView in comparison to another? If you could give some logical examples of how this process works behind the scenes (code is not needed) that would also be greatly appreciated.

    Easy. If you know it :)
    The PhotonView's GameObject on which you call an RPC is also the target of that RPC on remote machines.
    So the PhotonView basically identifies the GameObject it is on. If there are multiple PhotonViews on one GameObject, you can call the RPC on either of those.
    Per GameObject, all scripts (components) that have the RPC method implemented get called once.
    2) The second parameter of the RPC method, the PlayerTargets enum or the PhotonPlayer, what exactly do the PlayerTargets point to? This is possibly the aspect that I am more so struggling to understand as I have tried numerous combinations of calls on different PhotonViews using the different PlayerTargets enums but the outcome is never quite what I'm expecting. Also, what difference does it make to use a PhotonPlayer instead of PlayerTargets?

    Most importantly, you can target everyone or everyone else. The latter is default and excludes yourself.
    You can also target the master client but this is tricky: If you do and the master leaves the room in same moment, the RPC never reaches this master and neither the new one.
    In 99% of the cases, the target enum should be "others" or "all". In a 4 player game, those call the RPC on the 3 other clients or on all 4 clients.
    If you target a player, you don't execute the RPC locally and in a 4 player game only one (the target player) will execute it at all.
  • Riiight, I think I'm starting to see it now.

    So I presume then that the RPC uses the viewID of the PhotonView to find each PhotonView for the copies of a particular object that exists in each client?


    Regarding the PhotonTargets enum, the all/others makes perfect sense now. I can see now why the masterClient enum was giving strange results.

    Delving into this one a bit further though. The system I'm devising at the moment builds the PhotonViews outside of rooms and assigns the viewID when they enter the rooms. (Sounds crazy I know, but ultimately what I'm working on is a seamless transition between rooms, so that I don't need to destroy and server instantiate the local objects between rooms). From the little bit of documentation in your pdf about this, and what it says about the buffered variations of the enums, I assume that the buffered enums sit in a queue somewhere on the server and when new players assign their viewID's of their PhotonViews, they recieve the buffered calls?

    It would be awesome if you could go over how buffered calls work in more detail as I presume I'll be needing to use them a hell of alot.


    Thanks again for the help.
  • So I presume then that the RPC uses the viewID of the PhotonView to find each PhotonView for the copies of a particular object that exists in each client?
    Exactly.

    Delving into this one a bit further though. The system I'm devising at the moment builds the PhotonViews outside of rooms and assigns the viewID when they enter the rooms. (Sounds crazy I know, but ultimately what I'm working on is a seamless transition between rooms, so that I don't need to destroy and server instantiate the local objects between rooms).
    If you don't server-instantiate them in the room, noone else will see them. If you send RPCs instead, you are re-implementing the ViewID concept.
    In the latter case, I guess you would be better off without PUN and just creating things from scratch in the "plain API" (meaning: Our Unity SDK from our download page).

    From the little bit of documentation in your pdf about this, and what it says about the buffered variations of the enums, I assume that the buffered enums sit in a queue somewhere on the server and when new players assign their viewID's of their PhotonViews, they recieve the buffered calls?
    It would be awesome if you could go over how buffered calls work in more detail as I presume I'll be needing to use them a hell of alot.
    Buffering is done on the server. It keeps a copy of the events we're sending. One level "below" PUN, every instantiate and rpcs is an "event". Those get cached in their incoming order (on demand). If a new user joins, he gets his join event and then all buffered events from the server (not another client).
    You can remove events from the server's buffer by a filter and when someone leaves, by default, all events from that client get removed from the buffer.
  • Thanks again tobias.

    After your help and some further playing around, I can finally put this one to rest. I no longer fear the use of RPCs! =p
  • Cool! :)