Board index FlightGear Support Multiplayer

Visualizing Coordinated Maneuvers via Multiplayer Protocol

Trouble getting online, setting up a server?
Forum rules
In order to help you, we need to know a lot of information. Make sure to include answers to at least the following questions in your initial post.

- what OS (Windows Xp/Vista, Mac etc.) are you running?
- what FlightGear version do you use?
- copy&paste your commandline.

Please, also see Requesting Technical Help.

Note: If you did not get a reponse, even after 7 days, you may want to check out the FlightGear mailing lists to ask your question there.

Visualizing Coordinated Maneuvers via Multiplayer Protocol

Postby caged_bird » Thu Jan 28, 2021 5:59 pm

Hey fellow FG members!

Edit: Please check recent posts, as I've narrowed down my issue to the structure of mp protocol. Mainly looking for clarification on what properties need to be included in the Properties portion of the UDP packet. Thanks!

I'm fairly new to the community so forgive me if this post is in the wrong section of the forum. I'm undertaking a visualization project that involves rendering multiple planes based on historical simulation data. These planes do not have to be controlled in real time, but I would like for a program to read positional data from logs and tell a running FG instance where to render the planes. I already have one plane controlled via external fdm protocol and I would like to add more planes via the multiplayer protocol.

The trouble is, I'm having difficulties connecting to a running FG instance via custom mp protocol packets. When I launch an instance of FG from the command line using
Code: Select all
fgfs --fdm=null --native-fdm=socket,in,30,,5505,udp --disable-sound --aircraft=f16-block-20 --generic=socket,in,30,,5506,udp,f16 --multiplay==out,10,,5000 --multiplay==in,10,,5001 --callsign=plz

and then send custom mp protocol udp packets to via python's socket module, nothing happens. A little wireshark digging, and I see that the packets were being sent to the right port, but I'm getting a "destination unreachable" ICMP error. I decided to check port activity on my machine with
Code: Select all
sudo lsof -i -P -n

and got:

fgfs 12357 john 36u IPv4 206330 0t0 UDP *:5505
fgfs 12357 john 40u IPv4 206341 0t0 TCP> (ESTABLISHED)

So, despite launching the FG instance with multiplayer flags, it does not seem like FG opens a port to listen in on. This is kind of a problem haha :lol:

I'm reaching out for some help in diagnosing what the hang up is here. Perhaps there's some establishing connection between fgms and fg on launch that configures the multiplayer=in port that I'm missing? Perhaps my launch parameters are completely bunk. I'm open to suggestions :)

Some info:
OS - Linux Mint 5.4.0-64
FG - 2020.3.1

Any help would be greatly appreciated!
Last edited by caged_bird on Mon Feb 01, 2021 11:29 pm, edited 1 time in total.
Posts: 7
Joined: Fri Jan 22, 2021 10:12 pm

Re: Visualizing Coordinated Maneuvers via Multiplayer Protoc

Postby wkitty42 » Thu Jan 28, 2021 8:08 pm

remember that UDP is not stateful...

what is the format of your MP packets? AFAIK, they need to conform to the actual MP protocol... i'm not aware of any "custom MP protocol" capabilities...

you could maybe set --log-level=debug and watch the log file for the data traffic in there...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
Posts: 6960
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: Visualizing Coordinated Maneuvers via Multiplayer Protoc

Postby Johan G » Fri Jan 29, 2021 8:22 am

Though not directly related, the topic Jitter when having two flight gear instances on local machine might be worth skimming through as it touched similar subjects.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Posts: 6202
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: Visualizing Coordinated Maneuvers via Multiplayer Protoc

Postby caged_bird » Fri Jan 29, 2021 7:23 pm

Hey Fellow FG Peeps!

Thank you so much for showing interest in my project! I appreciate the support :)

Johan G: Thank you for the forum suggestion! I actually have already read through that forum as it was posted by ma15rysi, who was also attempting to render multiple planes in FG for visualization purposes. Unfortunately, much of that forum became talk about how to adjust the rate of received mp packets. Right now I think I need more info on structuring the mp packets.

wkitty42: Right, so UDP is stateless meaning that it does not require a stateful connection in order to send packets on a network (unlike TCP). So, likely not an issue with establishing a connection with FG...

I'm attempting to follow the format for mp protocol defined here: ... l#Messages . Sorry if "custom mp protocol" was confusing - I meant that I am trying to write a script to generate and send UDP packets that Follow mp protocol with custom positional and orientation values. That way I can read historical data, write it to a UDP packet, and send it on its way to FG.

So far, I feel confident that my script follows mp protocol for the Header and Positional data. I'm having trouble understanding the Properties data, however, which makes up a significant portion of the packet size - and is likely what I'm failing to follow properly. It seems that these are values that correspond to the property tree in some way (I don't fully understand the property tree implementation or how the Proporties portion of mp protocol maps to it). What's especially confusing to me is what values need to be included. The wiki page I linked above states: "A subset of the following properties are transmitted in the order below", referring to the list of properties that may be included in the packet. It also explicitly mentions that if all Properties were included, the packet size would far exceed the max.

So, my hacky solution was to simply append a sample of Property bytes from a mp protocol packet that I recorded with wireshark. If I had to guess, this is where we're running into troubles.

Especially after taking your advice and running FG with --log-level=debug and attempting to send mp protocol packets. A lot of print to comb through but I'll paste what I thought might be relevant below:

Code: Select all
    1.39 [INFO]:network    FGMultiplayMgr - have server
    1.39 [INFO]:network    FGMultiplayMgr::init-txaddress=
    1.39 [INFO]:network    FGMultiplayMgr::init-txport= 5000
    1.39 [INFO]:network    FGMultiplayMgr::init-rxaddress=
    1.39 [INFO]:network    FGMultiplayMgr::init-rxport= 5001
    1.39 [INFO]:network    FGMultiplayMgr::init-callsign= plz
    1.39 [INFO]:network    Multiplayer mode active

    0.23 [INFO]:general       option:fdm = null
    0.23 [INFO]:general    Channel string = socket,in,30,,5505,udp
    0.23 [INFO]:general       option:native-fdm = socket,in,30,,5505,udp
    0.23 [INFO]:general       option:disable-sound =
    0.23 [INFO]:general       option:aircraft = f16-block-20
    0.23 [INFO]:general    Channel string = socket,in,30,,5506,udp,f16
    0.23 [INFO]:general       option:generic = socket,in,30,,5506,udp,f16
    0.23 [INFO]:general    Channel string = out,10,,5000
    0.23 [INFO]:general       option:multiplay = out,10,,5000
    0.23 [INFO]:general    Channel string = in,10,,5001
    0.23 [INFO]:general       option:multiplay = in,10,,5001
    0.23 [INFO]:general       option:callsign = plz
    0.23 [DBUG]:general    Logging priority is debug
    0.23 [INFO]:general       option:log-level = debug

    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/protocol-version[0]
    8.41 [DBUG]:network    activating MP property:/surface-positions[0]/left-aileron-pos-norm[0]
    8.41 [DBUG]:network    activating MP property:/surface-positions[0]/right-aileron-pos-norm[0]
    8.41 [DBUG]:network    activating MP property:/surface-positions[0]/elevator-pos-norm[0]
    8.41 [DBUG]:network    activating MP property:/surface-positions[0]/rudder-pos-norm[0]
    8.41 [DBUG]:network    activating MP property:/surface-positions[0]/flap-pos-norm[0]
    8.41 [DBUG]:network    activating MP property:/surface-positions[0]/speedbrake-pos-norm[0]
    8.41 [DBUG]:network    activating MP property:/gear[0]/tailhook[0]/position-norm[0]
    8.41 [DBUG]:network    activating MP property:/gear[0]/launchbar[0]/state[0]
    8.41 [DBUG]:network    activating MP property:/canopy[0]/position-norm[0]
    8.41 [DBUG]:network    activating MP property:/gear[0]/gear[0]/compression-norm[0]
    8.41 [DBUG]:network    activating MP property:/gear[0]/gear[0]/position-norm[0]
    8.41 [DBUG]:network    activating MP property:/gear[0]/gear[1]/compression-norm[0]
    8.41 [DBUG]:network    activating MP property:/gear[0]/gear[1]/position-norm[0]
    8.41 [DBUG]:network    activating MP property:/gear[0]/gear[2]/compression-norm[0]
    8.41 [DBUG]:network    activating MP property:/gear[0]/gear[2]/position-norm[0]
    8.41 [DBUG]:network    activating MP property:/engines[0]/engine[0]/n1[0]
    8.41 [DBUG]:network    activating MP property:/engines[0]/engine[0]/n2[0]
    8.41 [DBUG]:network    activating MP property:/rotors[0]/main[0]/blade[0]/position-deg[0]
    8.41 [DBUG]:network    activating MP property:/rotors[0]/main[0]/blade[1]/position-deg[0]
    8.41 [DBUG]:network    activating MP property:/rotors[0]/main[0]/blade[2]/position-deg[0]
    8.41 [DBUG]:network    activating MP property:/rotors[0]/main[0]/blade[3]/position-deg[0]
    8.41 [DBUG]:network    activating MP property:/rotors[0]/main[0]/blade[3]/flap-deg[0]
    8.41 [DBUG]:network    activating MP property:/controls[0]/flight[0]/slats[0]
    8.41 [DBUG]:network    activating MP property:/controls[0]/flight[0]/speedbrake[0]
    8.41 [DBUG]:network    activating MP property:/controls[0]/flight[0]/spoilers[0]
    8.41 [DBUG]:network    activating MP property:/controls[0]/gear[0]/gear-down[0]
    8.41 [DBUG]:network    activating MP property:/controls[0]/lighting[0]/nav-lights[0]
    8.41 [DBUG]:network    activating MP property:/controls[0]/armament[0]/station[0]/jettison-all[0]
    8.41 [DBUG]:network    activating MP property:/sim[0]/model[0]/livery[0]/file[0]
    8.41 [DBUG]:network    activating MP property:/environment[0]/wildfire[0]/data[0]
    8.41 [DBUG]:network    activating MP property:/environment[0]/contrail[0]
    8.41 [DBUG]:network    activating MP property:/scenery[0]/events[0]
    8.41 [DBUG]:network    activating MP property:/instrumentation[0]/transponder[0]/transmitted-id[0]
    8.41 [DBUG]:network    activating MP property:/instrumentation[0]/transponder[0]/altitude[0]
    8.41 [DBUG]:network    activating MP property:/instrumentation[0]/transponder[0]/ident[0]
    8.41 [DBUG]:network    activating MP property:/instrumentation[0]/transponder[0]/inputs[0]/mode[0]
    8.41 [DBUG]:network    activating MP property:/instrumentation[0]/transponder[0]/ground-bit[0]
    8.41 [DBUG]:network    activating MP property:/instrumentation[0]/transponder[0]/airspeed-kt[0]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/chat[0]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/string[4]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/string[5]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/string[6]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/float[0]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/float[2]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/float[3]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/float[4]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/float[5]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/float[6]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/float[7]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/float[8]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/float[9]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/float[10]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/float[11]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/float[12]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/float[13]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/float[14]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/float[15]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/float[16]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/float[17]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/float[19]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/float[20]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/float[21]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/float[22]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/int[2]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/int[9]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/short[5]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/short[6]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/short[7]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/bool[0]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/bool[1]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/bool[2]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/bool[10]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/bool[11]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/bool[12]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/bool[13]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/bool[14]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/bool[15]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/bool[16]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/bool[17]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/bool[18]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/bool[35]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/bool[36]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/bool[39]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/bool[40]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/bool[41]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/bool[42]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/bool[43]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/bool[44]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/bool[45]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/bool[46]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/bool[47]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/bool[48]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/bool[49]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/bool[50]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/bool[51]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/generic[0]/bool[52]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/mp-clock-mode[0]
    8.41 [DBUG]:network    activating MP property:/sim[0]/model[0]/fallback-model-index[0]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/comm-transmit-frequency-hz[0]
    8.41 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/comm-transmit-power-norm[0]

   11.65 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/emesary[0]/bridge[17]
   11.65 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/emesary[0]/bridge[18]
   11.65 [DBUG]:network    activating MP property:/sim[0]/multiplay[0]/emesary[0]/bridge[19]

   26.99 [DBUG]:network    activating MP property:/engines[0]/engine[0]/rpm[0]
   26.99 [DBUG]:network    FGMultiplayMgr::ProcessPosMsg - Position message with invalid data (NaN) received from test
   26.99 [DBUG]:network    FGMultiplayMgr::ProcessPosMsg - Position message with invalid data (NaN) received from test
   26.99 [DBUG]:network    FGMultiplayMgr::ProcessPosMsg - Position message with invalid data (NaN) received from test
   26.99 [DBUG]:network    FGMultiplayMgr::ProcessPosMsg - Position message with invalid data (NaN) received from test

The setup looks fine to me. I included the "activating MP property ..." lines on the off chance they have a hint as to which properties I should be sending in my mp protocol packets. It's also worth noting that the ProcessPosMsg errors were regularly spaced out in the logs after their initial appearance captured above.

Thank you for your time! Looking forwards to any additional advice :)
Last edited by Johan G on Sat Jan 30, 2021 6:44 pm, edited 1 time in total.
Reason: Added [code] tags. They can be added manually or with the [^_ ] button above the text editing box.
Posts: 7
Joined: Fri Jan 22, 2021 10:12 pm

Re: Visualizing Coordinated Maneuvers via Multiplayer Protoc

Postby caged_bird » Fri Jan 29, 2021 8:11 pm

I feel it would be good to add that my biggest confusion over the Properties portion of the mp protocol is how to structure the bytes. The wiki says its always ID|value, which makes some sense. Should I assume the ID is 4 bytes and the Value is the next four bytes? That would be congruent with the XDR encoding of the packet...

If that's the case, then I'm back to being stuck on which properties to actually include... As that might be aircraft model dependent, I should note that I am currently using the f-16-block-20.

Posts: 7
Joined: Fri Jan 22, 2021 10:12 pm

Re: Visualizing Coordinated Maneuvers via Multiplayer Protoc

Postby jano » Sun Feb 07, 2021 12:45 am

Hi caged_bird

ID is 4 bytes and the Value is the next four bytes?

I think it's more the value take as much bytes as defined for the ID in the mp protocol, different ID will have different lenght for their value.

Sadly the wiki is down at this hour and i'm far from home, so i can't be very precise, but i see different way to solve this case:

1) if you don't intend to animate the mp planes coming from logs with your python script (moving gear, control surface, airbrake, etc...) only send the props included in the basic block, and don't use any of ID:value props, then simplify the fg plane model to remove the animations from the model and you're done. with a timestamp, the position and orientation, the mp plane will be displayed (other basic props zeroed), you can add velocity as bonus (used only to predict plane position in the futur)

2) the hard way: find all the props you need to send to have the plane animated as you want it, and use a standard fg plane.

3) the intermediate solution you're trying: capture a mp paquet from the plane you want to use, and keep it as a base for your python script, only edit the part you're interested in.
the error message you got is coming from something wrong in the motion info, wich include the timestamp, the lag value , position ,orientation and their derivatives (1st and 2nd order). If you are compiling FG, you can remove the sanity checks in the multiplayermgr one by one to find wich one fail

If you want a very basic plane to make the script work, you can first try the ufo wich has a minimalist packet size on mp (beware it's only visible if you have one yourself).

Posts: 199
Joined: Thu Nov 29, 2007 11:32 pm
Location: france
Callsign: jano
Version: git
OS: debian SID

Re: Visualizing Coordinated Maneuvers via Multiplayer Protoc

Postby wkitty42 » Sun Feb 07, 2021 9:48 am

something else to remember: IIRC the updated MP traffic will only transmit the properties that have changed since the last transmission... this instead of transmitting all properties... this makes the MP faster, tighter, and cleaner... i'm not sure how much of a part Emessary plays in this, though, but it really should be looked at in this, too...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
Posts: 6960
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Return to Multiplayer

Who is online

Users browsing this forum: No registered users and 2 guests