Tno.SendQuickly

[voncarp]

After updating Tnet I am having some issues.  Before I used Tno.SendQuickly for my mecanim movement controls and had no issues.  I haven't changed any code since I updated.  The clients that log in move fine and have no problems.  However, the host seems to have movement issues. 

1.         void Update () {
2.                 if (!tno.isMine)
3.                         return;
4.                         //hc.movePublicX = move.AxisX;
5.                         //hc.movePublicY = move.AxisY;
6.                         //hc.rotatePublicX = rotate.AxisX;
7.                         hc.rotatePublicY = rotate.AxisY;
8.  
9.                         mX = rotate.AxisX; //
10.  
11.                         h = move.AxisX;
12.                         v = move.AxisY;
13.                 //      hc.rotatePublicX = rotate.AxisX;
14.                         //mouseY = rotate.AxisY;
15.  
16.                         //tno.SendQuickly ("UpdateMouseY", Target.AllSaved, mouseY);
17.                         //tno.SendQuickly ("SetMecanimState", Target.All, v, mX, h, grounded);
18.                 tno.SendQuickly (9, Target.All, v, mX, h, grounded);
19.  
20.         }

I use the above code to control my character.  The host struggles to move on any of the clients after the update.  On the device of the host, the character moves fine.  However, on the clients he doesnt move at all.  It seems he only moves based on the updates of tnsyncrigidbody.

If I change the above code to tno.send everything moves, but extremely choppy.  Thats one of the reason I use tno.SendQuickly.  Tno.send was choppy even before the update.

Was there anything in this recent update that affected tno.send and tno.sendquickly?  I am hoping to resolve this issue, but I am not certain where to start since there no errors show up.

Any thoughts at all? 

I attached a video of my issue. 

 http://youtu.be/m_I5kBjjbzU

Network usage

[ArenMook]

It's never a good idea to send packets in Update(). It's framerate-dependent, and you effectively flood the network with packets. If you have 300 FPS, that's 300 packets per second. You are overwhelming the network, which is why it ends up buffering your crazy number of calls and sending them in batches instead. You need to stagger out your sends. Send X times per second. Start a coroutine instead.

1. StartCoroutine(MyNetworkUpdate());

1. IEnumerator MyNetworkUpdate()
2. {
3.     for (;;)
4.     {
5.         yield return new WaitForSeconds(0.1f);
6.         if (tno.isMine) tno.Send(...);
7.     }
8. }

Also note that it's best to send things that actually change, not simply sync often. Did the input actually change since last frame, for example? Only then send.

[voncarp]

Yes.  But my game only works on iOS devices running around 30 FPS.  That's not too bad is it?  Framerates on iOS devices are capped at 60.

All of the movements of the clients work perfectly using tno.sendquickly.  They move and sync on all devices.  Its just the host who doesn't move on any device except his own.  And this is only after the most recent update. On the client devices on the video on my prior post, it seems he only moves based on the updates of tnsyncrigidbody.

From what I've read, if there is no UPD then everything gets sent by TCP.  On all my network usage tests, there is never a remote UDP address and there are no in Bytes from UDP.  I don't think I have been successful establishing any UDP connections.  So, if there is no UDP shouldn't tno.sendquickly work exactly like tno.send?

When I use tno.send the host and clients all move and sync properly.  Its just choppy.  Thats why I have been using tno.sendquickly.

1.         IEnumerator MyNetworkUpdate()
2.         {
3.                 for (;;) {
4.                         yield return new WaitForSeconds (0.2f);
5.                         if (tno.isMine) {
6.                                 hc.rotatePublicY = rotate.AxisY;
7.  
8.                                 mX = rotate.AxisX;
9.                                
10.                                 h = move.AxisX;
11.                                 v = move.AxisY;
12.                                
13.                                 tno.SendQuickly (9, Target.All, v, mX, h, grounded);
14.                         }
15.                 }
16.         }

I did attempt your suggestion, but the problem still exists using tno.sendquickly.  It just seems odd.  Maybe what I was doing wasn't right, but worked.  And whatever you updated, made what I was doing obsolete.  Perhaps, I'm going to have to redo my controller.

Beforehand, do you have any other suggestions?

Edit:

Curiously, I use the multipurpose starter kit with tnet integration for my starting point.  I've updated tnet several times over it.  I noticed the starter kit hasn't been updated in 18 mos.  Do you think there may be any potential conflict because it hasn't been updated in awhile?

[ArenMook]

UDP traffic may not function properly, that's true -- but TNet falls back to TCP in that case, or "should" anyway. Is it only specific device that does it (the computer)? Have you tried hosting on other devices?

Also note that you are using Target.All. This bounces the packet over to you as well. Not sure if this is something you intended or not, but generally it's best to use Target.Others, as you are sending your own value to others. No point in sending it to yourself.

The multi-purpose kit should work as expected with the latest TNet.

[voncarp]

I found the solution in my case.  For it to work properly as it was before, I had to remove StartUDP().  Specifically, I removed StartUDP(5128).  I used this because on my server, I only opened port 5128 for UDP.

It works now and the host moves properly and smooth on all devices, but this issue likely is case specific.  I am certain everyone sets up their games differently.

For the record; however, I am still using tno.sendquickly.  And if switch to using tno.send it goes back to being choppy.  Why tno.sendquickly shows better performance, I'm not certain.  Like I mentioned before, in all my network usage tests, they never show any working remote UDP address or bytes received.

Additionally, I haven't been testing on LAN.  I've only been testing with an outside server.