Author Topic: Target.All vs Target.Others  (Read 3008 times)

Deozaan

  • Newbie
  • *
  • Thank You
  • -Given: 44
  • -Receive: 4
  • Posts: 42
    • View Profile
    • Deozaan.com
Target.All vs Target.Others
« on: August 02, 2014, 10:37:29 AM »
Hello,

I'm curious about when to use Target.All vs using Target.Others, and what the delay is (if any) when sending an RFC to yourself.

For example, in my player input script, I don't want remote players controlling my character. So I perform the logic that converts input to movement, and use a tno.Send to tell the remote players how my character should be moving.

The question is: Is Target.All smart enough to instantly run the RFC on my local machine so there is no lag (waiting for the command to go to the server, then come back to me) before my character moves? Or do I need to just use Target.Others and then also update my movement locally?

In other words, which of the following is necessary for there to be no delay between input and movement on the local machine?

  1. void Update() {
  2.         // perform some logic determining dMov and other things first
  3.         // and then. . .
  4.         // send out the changes
  5.         tno.Send("SyncMovement", Target.All, dMov); // <-- does this get executed immediately on my own machine?
  6. }
  7.  
  8. [RFC]
  9. void SyncMovement(Vector3 deltaMovement) {
  10.         _char.deltaMovement = deltaMovement;
  11. }
  12.  

  1. void Update() {
  2.         // perform some logic determining dMov and other things first
  3.         // and then. . .
  4.         // send out the changes to other players
  5.         tno.Send("SyncMovement", Target.Others, dMov);
  6.         // make the changes locally
  7.         _char.deltaMovement = dMov;
  8. }
  9.  
  10. [RFC]
  11. void SyncMovement(Vector3 deltaMovement) {
  12.         _char.deltaMovement = deltaMovement;
  13. }
  14.  

Note that in these examples, I'm not syncing position, I'm syncing movement/input (which direction the character should be moving continuously). In case that makes any difference.

And a follow up question: Can I call an RFC without actually making an RFC? e.g., can I do something like:

  1. tno.Send(myRFC, Target.Others, arg);
  2. myRFC(arg); // <-- will this execute locally?
« Last Edit: August 02, 2014, 10:43:40 AM by Deozaan »

ArenMook

  • Administrator
  • Hero Member
  • *****
  • Thank You
  • -Given: 337
  • -Receive: 1171
  • Posts: 22,128
  • Toronto, Canada
    • View Profile
Re: Target.All vs Target.Others
« Reply #1 on: August 03, 2014, 10:31:20 AM »
Yes, and yes.

You could answer #1 just by looking at TNObject's SendRFC() function. Target.All and Target.AllSaved get executed locally right away. Current Pro version of TNet also handles Target.Host if you're the host.

An RFC function is just that -- a function that you can call freely. The [RFC] prefix is simply there so that TNet can find it (and cache it).

Deozaan

  • Newbie
  • *
  • Thank You
  • -Given: 44
  • -Receive: 4
  • Posts: 42
    • View Profile
    • Deozaan.com
Re: Target.All vs Target.Others
« Reply #2 on: August 03, 2014, 07:10:42 PM »
Yes, and yes.

You could answer #1 just by looking at TNObject's SendRFC() function. Target.All and Target.AllSaved get executed locally right away. Current Pro version of TNet also handles Target.Host if you're the host.

An RFC function is just that -- a function that you can call freely. The [RFC] prefix is simply there so that TNet can find it (and cache it).

OK, well, I'm confused. tno.Send() doesn't seem to do anything when I'm not connected. I added some Debug.Logs through the whole thing and it seems to make it all the way to TNUnityTools.Execute(), but the following if statement on line 163 is never true:

  1. if (ent.func.Name == funcName)
I just tested and discovered that if I call tno.Send() using the byte ID rather than the string name, it works. So I guess that's a bug in TNet when using the string name to call an RFC?

EDIT: OK, this is weird. I just updated my repository to a different version of the code where I was already using the Byte ID of the RFC and now it works either way, using Byte ID or string name.
« Last Edit: August 03, 2014, 07:20:09 PM by Deozaan »