Mp-patch

From FlightGear wiki
Jump to navigation Jump to search

visual

Mp formation flight, two sessions on the same pc:


exemple of mp formation flight lag-free

mp refueling session video (with recorded planes):

victor refueling two lightnings

and the first video with two mp pilots, one from canada, the other from france:

F-4N in the sunset

a bit of history

Long time ago, we were recording some refueling action, and it became evident that the lag was affecting our respective position, the refueling planes were very close to the tanker , but the tanker saw them quite far, as can be seen in this vidéo taken from the tanker.

then started an attempt to compensate for the lag, and smooth jitter problems (rubber band effect).

Where it can be helpfull is when we need to flight close , with no rubber band effect, eg :
- refueling with a mp tanker
- towing a glider, without broking the rope because of rudder band effect
- having an aerobatic patrol

currently this work well locally (with 127.0.0.1 as server) very smooth with yasim planes and a little less with jsbsim, for predictive time in the 0.2 s.

the code

The patch is now working again with next, after the commit 948aa70af786, you need the patch from the 15aout13 or later.

For who want to give it a try, The current code available as a patch for flightgear and fgdata, here. (mpdataxxxxxx.diff and flightgearxxxxxxx.diff).

and pierre compile on a weekly basis the windows binary, wich should work with the jenkins builds, just replace the binary, they are here.

2.10 version

if you're interested in the 2.10 patched version, there's some matérial here:

  • fgdata_2.10_addon_mp.tar.gz : contains only the files modified for the patch in the 2.10 datas
  • fgdata_2.10_mp.diff : the diff for the data 2.10
  • fgfs32_2.10_mp.7z : the patched 32 bits fgfs.exe for windows
  • fgfs64_2.10_mp.7z : the patched 64 bits fgfs.exe for windows
  • flightgear_2.10_mp.diff : the diff for flightgear 2.10
  • flightgear_2.10_mp.tar.gz : the full flightgear patched sources
  • simgear_2.10_mp.diff : the diff to patch simgear
  • simgear_2.10_mp.tar.gz the full patched simgear sources

windows quick patching

As some part of the code is done in flightgear sources, you have to replace the fgfs.exe binary, with a patched one. take the "fgfsXX_2.10_mp.7z" file, where XX is 32(bits) or 64(bits), depending your FG installation, and extract fgfs.exe with 7zip or any working archiver. save the fgfs.exe from the 2.10 installaion somewhere, and put the extracted in it's place.

next, take fgdata_2.10_addon_mp.tar.gz, it contains the modified files from the data, extract the folder (you should have a nearly empty fgdata, and replace the files in your flightgear data folder by the files provided. don't forget to save the removed files somewhere, in case...

2.12 version

the patch for 2.12 is here for the moment there are only the diff for simgear flihtgear and the data, the full patched source for simgear and flightgear, and the modified fgdata files in a tar.gz. there will be 32 and 64 windows binary after the release for the few interested :P

how to use it

start the patched fgfs, with the patched datas, and use the multiplayer=>lag-adjust menu to set it working. you need to have the master switch checked, and "apply to close mp" to have the close mp plane put in the futur
both the time and distance sliders allow you to play with a general delay offset, and the distance within the mp planes start to be displayed in the futur.

In the Nasal/lag-adjust.nas, you can find a table with pilot callsigns, they have the lag correction applied if you allow it in the menu, and there is a table with a server list, and the corresponding ping, this has to be adapted to match your ping values to the servers (just put the min value of a "ping" to the server).

for a starter, start fg with 127.0.0.1 as server, start the patch (with the "apply to close mp" checkbox, and play with the time slider to see the result on yourself as mp plane.

pilots using this patch

If you want to try the lag correction, or just see the result on a formation flight. Here are the callsigns of testing pilots:

  • jano
  • tempura

the flights are not planned in advance, and take place mostly on saturday or sunday evening. Any pilot is welcome, and needed to improve the lag setting ;) . you can get in touch on the us forum, for informations or test request.

parts involved

In order to compensate for the lag, one need to predict the plane position ahead of time, for that you need to address somehow the jitter issue, find a way to know the lag between the players, and to send plane fdm parameters wich allow the prediction to be done.

predictive system

the existing predictive system was used in very few case, most probably only when a player quit, and fg continued to interpolate 5s, then keep the last position 5s more before removing the plane. i firt tried to use the existing code, and the "few euler steps" were quite good if the speed vector tag along the plane longitudinal axis, but degrade then we got sideplip, or big alpha. for now i separated the position, and the orientation, having only position, speed and acceleration used for determinate the position in the futur, with a simple trajectory equation, and using the rotation termes to guess the current orientation (for now i keep the old equation for this, but i'm not satisfied with the result.)

in case of jitter the old code was coping fast with the new lag value to keep the plane in the time between packets, causing the "rubber band effect", so in the current code, the response to jitter is very slow, with "jump" if we exeed 1s, this is part of what need some tune from real mp flight. I did some test using the timestamp from mp players and assuming the clocks were sync, but the result were not so smooth as the current code.

fdm properties

the properties used by the mp code are:

  • a timestamp, telling the time from the sender's side
  • the position, in ECEF coordinates
  • the speed, what i use is the speed in ecef, expressed in body coordinates, for yasim i needed to remove the wind component (bug 201)
  • the acceleration vector: initialy not sent, the result was a good behaviour in straight flight, but a jumpy plane when taking "g". the yasim one seems to be quite fine, but for jsbsim, i need a better acceleration, seems i don't have the ecef acceleration for now.
  • the plane's orientation
  • the angular velocity
  • the angular acceleration (didn't check if it was sent)

fps

after some tests, the time needed to have mp plane in sync with the main aircraft depend of fps (it's done using 127.0.0.1 as server, then using the slider to adjust the lag correction). I think that the mp position is taken from the precedent frame, while the current main aircraft position is from the current frame.

this make the "in the futur" plane vibrate if the fps are not steady, and this will need something in the code.

mp transmission's rate

the same as above, a change in speed rate from the sender, change the lag correction needed, i tried to adjust this by using a "0.48lag" coeff, taken from a rough interpolation.

time acceleration

something i saw just a few days ago is that in case the mp player is using time acceleration, we need to change the speeds and accelerations acordingly, otherwise the mp plane will be seen jumping between factor 1 speed portions.

server ping

her's the most crutial part, we have to somehow know the time travel to and back from the server. for now, i just give some ping value in the nasal file (lag_adjust.nas), so before the flight you need to ping the server to set the value.

a better idea should be to have time information exchange between the mp pilots and the server, so as to have a real time lag value, and a good guess of the jitter.

jitter

jitter is when the lag value change. it can be seen as the difference between the sent timestamp and our clock change, for now this is addressed by a slow response to the drift, and a jump if the value is to big, it allow the sender's clock to drift a little, and make the rubber band phenomen far less noticeable, but still a little when in very close flight.

inter server lag (and jitter)

We have a simple way to know the lag to the server we are connected to, but no simple way to know the inter server lag. In case the mp pilots are on 2 different mp server, we should compensate for the inter server lag, as it's far for be done , it's best to flight on formation using the same server.

currently we don't even know on wich servers are the mp pilots connected!

VRP plane position

utility

individual wingman offset

In lag_adjust.nas, the table "wingmen" got a value affected to each name, this values is to add an offset to the lag applied to that callsign (in second).
This is mainly to allow correction to a recorded formation flight, depending where the record was done. eg: one of the team's member capture udp packets of the fg traffic (wireshark is a good candidate for this), then you can replay again the flight to yourself, this time with an ufo to make different video pass. The offset should be used here to delay a little the player who recorded the flight, as he was recorded just out of FG, contrary to the others who were taken after lots of internet travel.

This is a way to make your flight without concern about screens or video, and then make a video from the flight with multiples takes.

This can be used too if one pilot don't use the patch, other pilots can compensate for his lag, so that he see the others without lag.

spectator mode

here we try to completely avoid doing prediction, by displaying the others further in the past.
this can be used when no interaction is needed, like in case of an ufo filming.

known bugs

  • the behaviour is strange if some mp pilots are using time acceleration (doing jump each new packet).
  • yasim planes are dancing on the ground :) with predictive system on (fast changing acceleration value).
  • As the plane animation are updated each time a packet is received, depending the future or past offset used, you will see the animation before or after the effect (eg the plane turn and then the aileron move if you set the mp in the futur)
  • it make you addict to the patch :D (but it's a feature)

TODO list, with no time limit :)

fg menu integration

spectator mode

the idea is to display the mp planes "very late", with a strong jitter annulation, to stay in the "interpolation between packets" zone.
This can be used when you don't need to interact with others mp pilots, and need very smooth mp behaviour:
- camera plane in a mp session
- linux tag demo ;)

lag and jitter

  • lag: find a way to have the server ping from fg, instead of a prefilled nasal file.

jsbsim

  • acceleration vertor suitable for the task: partially done. Currently the acceleration provided make the plane in the futur "shaky", except if i head east or west , in wich case mp display is very smooth. Got to use east-west oriented runways for aerobatic demos :). This could be caused by a biased velocity vector , so more investigation needed!
  • bug 901: hacked, this allow as a side effect a trajectory marker working as expected in the hud :)

yasim

  • bug 202: hacked ,introduced velocities/uBody_wind-fps, and made yasim report both /wind and ecef speed.
  • find acceleration suitable: done

bonus

as a bonus you'll have a working trajectory marker in the hud (maybe too perfect :) ), even in knife edge flight with jsbsim planes.

FG integration

For now it's only available as a patch or a patched windows binary. I'd like to have it reach FG someday, if it raise some interest among the devs, but first we need to have some coherent fdm properties :)