Real Time manual: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(Copy editing; +cat: Multiplayer)
Line 1: Line 1:
This page is intended to help setup FlightGear to use the '''real time lag compensation in multiplayer''', following the work in the [[Mp-patch]].


Following the work in the [[Mp-patch]], this page is intended to help setup fg to use the real time lag compensation.
[[File:707-TT refuelinfg a ch53e.jpg|799px|thumb|left|Multiplayer session où le ch53e se ravitaille dérrière le 707-TT, qui a des tuyaux qui se déplacent au point de contact.]]{{-}}The CH-53E, the tanker and the UFO taking the screenshot are all multiplayer pilots.
<br />


[[File:707-TT refuelinfg a ch53e.jpg|799px|mp session où le ch53e se ravitaille dérrière le 707-TT, qui a des tuyaux qui se déplacent au point de contact.]]
== How it works ==
<br />
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.
the ch53e, the tanker and the ufo taking the screen are all mp pilots.
<br />


== how it works ==
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.


préviously, we tried to set manually a lag value, usually the mpserver ping, and use that lag correction to display the planes in the futur.
The advantage is that the pilots do not need to do anything in most cases.


Now, we will trust the pc clocks, and use the same time to display all the mp plane, if the times they show are close enough.
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.


The advantage is that the pilots don't need to do anything in most the case.
== Step by step ==
<br />
{{note|This will probably change :)}}


First, set the master switch and apply to close multiplayer to on in the lag correction menu.


As a way to investigate network issues, there are now the lag, and pps (packet per second) values available for each mp pilots, and a dedicated page is included in pilot list, just click on the unit to get it.
Next, open pilot list and display the "lag" page (by clicking on the unit (IM => lag => SI).


== step by step ==
; lag-pps:  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.


(will probably change :) ): first, set the master switch and apply to close mp to on, in the lag correction menu
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.


; lag-ms:  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.


Next is to open pilot list, and display the "lag" page (by clicking on the unit (IM => lag => SI)
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).


- lag-pps is the number of packets received per second. if all pilots are sending at 10 (work quite well for the public mpservers) they should  have 10 or quite close for this value, something equal or inferior to 1 pps show usually a different mpserver used, wich don't properly relai the traffic, letting only the "lazy relai" at 1 pps working.
* 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.
Change the mpserver you're on to have a solid 10, if that still don't works, there are sometimes pilots with bad internet connexion dropping too much FG traffic.


- lag-ms This is the time in ms between our FG clock, and the time present in the packet received from the mp pilots, negative is mp pilots are late. This is basically the travel time from the mp pilot's pc to our FG, a bit pessimistic because of delay waiting to be processed at the next iteration.
* 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 :) )
From recent mp session, i get in the -50 ~ -70ms range for mp pilots lag, 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 is left is to fly. Different fps lead to a bit better or worst lag display so 10 or so ms difference is not a big deal.
Or it can be simply a clock not synchronized over internet.
- For high lag values, it can be a very bad internet pipe (eg australia <=> europe) specially if both side see something in the same range (and with the same "-" sign :) )
Or it can be simply a clock not synchronised over internet.
You can add an offset to the mp clock, (the clock offset in the lag menu)
beware this value is in seconds, and the lag in ms !
If a player using ntp have 15260 lag in pilot list, using 15.320 in the offset should give -60ms lag and if the value is in the same range on his side, you should be good.


The other solution is to use ntp, wich should do the job permanently, install ntp on linux, similar on mac ?? and there's a ntp program from Meinberg for windows users (need confirmation)
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 ''milli''seconds!


== result and limitations ==
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.


Video of a mp session, where the tanker move the drogue to the plane's refuel point:
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:
[https://www.youtube.com/watch?v=qIRI8glSl7s mp planes refueling]
[https://www.youtube.com/watch?v=qIRI8glSl7s mp planes refueling]


the flight is now very smooth, for the speed and altitudes used by the planes.
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).


I tried it with the ufo at high speed and altitude, and that's not good enough, so this not to be used for a space rendez-vous :( the tip in this case is for the chasing space vehicule to tune the offset to avoid prediction, eg have a iss lag in the 150ms 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).


the very obvious advantage is that if you're using ntp, nothing is needed to have a perfect sync, and the offset allow you to tune easily 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 case (Older FG version before the change in the mp clock behave like that too).
[[Category:Multiplayer]]

Revision as of 18:51, 18 March 2020

This page is intended to help setup FlightGear to use the real time lag compensation in multiplayer, following the work in the Mp-patch.

Multiplayer session où le ch53e se ravitaille dérrière le 707-TT, qui a des tuyaux qui se déplacent au point de contact.


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).

lag-pps
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.

lag-ms
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).