Real Time manual
This page is intended to help setup FlightGear to use the real time lag compensation in multiplayer, following the work in the Mp-patch.
The CH-53E, the tanker and the UFO taking the screenshot are all multiplayer pilots.
How it works
Previously we tried to manually set a lag value, usually the mpserver ping, and use that lag correction to display the planes in the future.
Now, we will trust the computer clock, and use the same time to display all the multiplayer planes if the times they show are close enough.
The advantage is that the pilots do not need to do anything in most cases.
As a way to investigate network issues, there are now the lag and pps (packet per second) values available for each multiplayer pilot. A dedicated page is included in pilot list. Just click on the unit to get it.
Step by step
|Note This will probably change :)|
First, set the master switch and apply to close multiplayer to on in the lag correction menu.
Next, open pilot list and display the "lag" page (by clicking on the unit (IM => lag => SI).
- Is the number of packets received per second. If all pilots are sending at 10 (which work quite well for the public mpservers) they should have 10 or quite close for this value. Something equal or inferior to 1 pps usually show that a different mpserver used, that do not properly relay the traffic, letting only the "lazy rely" at 1 pps work.
Change the mpserver you are on to have a solid 10, if that still do not work, there are sometimes pilots with bad Internet connection dropping too much multiplayer traffic.
- Is the time in milliseconds between our FlightGear clock and the time present in the packet received from the multiplayer pilots. If negative multipayer pilots are late. This is basically the travel time from the computer of the multiplayer pilot to our FlightGear, a bit pessimistic because of delay waiting to be processed at the next iteration.
From recent multiplayer session, I get in the -50 ms to -70 ms range for lag of multiplayer pilots who have a clock synchronized to the Internet time servers (probably European pilots like me).
- If the values are nearly the same from each side, our clocks are in synchro, and all left is to fly. Different fps lead to a bit better or worse lag displayed so 10 or so ms difference is not a big deal.
- For high lag values, it can be a very bad internet connection (for example between Australia and Europe), specially if both sides see something in the same range (and with the same "-" sign :) )
Or it can be simply a clock not synchronized over internet.
You can add an offset to the multiplayer clock (the clock offset in the lag menu). Beware, this value is in seconds, and the lag in milliseconds!
If a player using NTP have 15260 ms lag in pilot list, using 15.320 s in the offset should give -60 ms lag and if the value is in the same range on his side you should be good.
The other solution is to use NTP, which should do the job permanently, install NTP on Linux, similar on Mac?? And there is a NTP program from Meinberg for windows users (need confirmation on this).
Result and limitations
Video of a multiplayer session where the tanker move the drogue to the refueling probe of the plane: mp planes refueling
The flight is now very smooth for the speed and altitudes used by the planes.
I have tried it with the UFO at high speed and altitude, which is not good enough, so this not to be used for space rendez-vous. :( The tip in this case is for the chasing space vehicle to tune the offset to avoid prediction, for example have an ISS lag in the 150 ms range (positive value).
The very obvious advantage is that if you are using NTP nothing is needed to have a perfect sync, and the offset allow you to easily tune your clock. Note that this works well for clocks having the same speed. We had a case with a pilot who was playing with the NTP settings a drifting lag over time, but this was the only one case (though older FlightGear versions before the change in the multiplayer clock behave like that too).