This object is in archive! 

[187] Huge input lag on DS in same PC as client

Digi shared this bug 13 months ago
Not a Bug

I'll repeat, the DS is on the same PC as the game that connects to it.

World is empty, just 2 tiny grids that I use to test.

Simspeed, FPS and etc are perfect.


Printed ping amount (Shift+F11) is all over the place, ~80ms when controlling character then drops to ~40ms when I enter a cockpit, both are pretty huge for the connection context.


But the main problem is that input lag from non-predicted grids (grids with pistons/rotors/wheels) is insanely noticeable, most noticeable with rotating, but it's also noticeable with thrusters and with wheels control.


Steps to reproduce:

1. Start a DS on your PC

2. Join that DS from the same PC as the DS

3. Place a cockpit, battery/reactor and several gyros.

4. (optional) Enter it, confirm it moves nicely.

5. Place a rotor or piston or suspension on it.

6. Enter it and rotate it with mouse.


Here's a video of me showing the difference with a plugin that shows my mouse inputs:

https://streamable.com/6kjsc

Best Answer
photo

I've been asking about this in the office and it was told me it is caused by the way how we process network communication and packet sending on Dedicated server. It is not really desired behavior but it is direct consequence of our current implementation.

Since it is expected behavior it is not a bug. If you want, feel free to create an idea on this site instead.

Thank you.


Best Regards

Comments (7)

photo
1

I have a similar issue while connected on a dedicated server in the same Local network ping on the selection screen is 1ms and in game it's 90ms.

photo
1

Same, my locally hosted DS sometimes has over 100 ping as well which is odd

photo
1

Also with multigrids, using a vehicle that uses mouse input to control rotors, it is noticeably slower to respond to inputs than it did pre-patch. Feels like upwards of .25 seconds of delay.

photo
2

I did a test recently with modAPI packet sending with the same setup (DS on the same machine as client).


The script sent a 64bit (a ulong) packet to server and then server sent a different ulong number back to client, here's the logs from both:


(client's log)
[06:43:10 368] BEFORE send to server
[06:43:10 369] AFTER send to server
[06:43:10 436] RECEIVED client side
(server's log)
[06:43:10 395] RECEIVED server side
[06:43:10 396] BEFORE send to client
[06:43:10 400] AFTER send to client
So that's like 26-36ms, what is taking so long? :|

The code used for the time:

$"{DateTime.UtcNow.Hour}:{DateTime.UtcNow.Minute}:{DateTime.UtcNow.Second} {DateTime.UtcNow.Millisecond}";
I also tested how accurate DateTime.UtcNow is on my machine with a separate program printing it in a literal while(true) as fast as it could and the largest gap was 2ms.

photo
2

Hello,


thank you for reporting the issue. It will be passed to our dev team for investigation.


We will change status of the topic and will further inform you here about the progress as soon as we have any new informations. With amount of currently reported bugs it can take some time to go through all of them.


Kind Regards

Keen Software House: QA Department

photo
1

I've been asking about this in the office and it was told me it is caused by the way how we process network communication and packet sending on Dedicated server. It is not really desired behavior but it is direct consequence of our current implementation.

Since it is expected behavior it is not a bug. If you want, feel free to create an idea on this site instead.

Thank you.


Best Regards

photo
1

Comments have been locked on this page!