Board index FlightGear Support Interfacing

"Out of Fuel" message with networked Flightgear  Topic is solved

Connecting two computers, using generic protocol, connecting with Matlab?

Re: "Out of Fuel" message with networked Flightgear

Postby Hooray » Tue May 26, 2020 9:12 am

I did understand what you mean - but when you have fdm=null (/sim/flight-model), you can obviously check the /fdm tree - but that's all a hack that would work implicitly, we have people using a null fdm without them running a master/slave setup, i.e. those replaying pre-recorded flights for instance.

Here's native-ctrls and native-fdm respectively:

https://sourceforge.net/p/flightgear/fl ... ve_fdm.cxx
https://sourceforge.net/p/flightgear/fl ... _ctrls.cxx


And given how this is integrated in options.cxx, it's obvious that master/slave setups have never been properly formalized

So, the best way would be to introduce a corresponding property at that level, or by wrapping all master/slave handling via options.cxx so that fgfs instances know about their master/slave mode: https://sourceforge.net/p/flightgear/fl ... .cxx#l1787

For now you can simply use the workaround discussed above, and then try to get this discussed / formalized on the devel list
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11835
Joined: Tue Mar 25, 2008 8:40 am

Re: "Out of Fuel" message with networked Flightgear

Postby Hooray » Tue May 26, 2020 9:15 am

master/slave setups are very common and important in the professional flight sim industry, so the feature just isn't well-developed/maintained for the time being.

Any of the workarounds above will do, but I would definitely suggest to raise this on the devel list, there are people like Richard who have a background in professional use, so he'll certainly agree that the feature needs to be better formalized - there's a whole plethora of subsystems and feature that could benefit from something like that, and the code base could also be simplified by identifying common use-cases and explicitly supporting those

Equally, Curt will likely remember the details of his original work, and will surely appreciate it being picked up/revamped and modernized again ?
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11835
Joined: Tue Mar 25, 2008 8:40 am

Re: "Out of Fuel" message with networked Flightgear  

Postby stuart » Sat May 30, 2020 3:57 pm

(cross-post from the -devel list)

Hi Folks,

Coming to this topic very late, for which I apologize.

I think the best way to solve this would be use use the --generic protocol to pass any additional properties (e.g. /consumables/fuel/tank[0]/level-gal_us) from the master to the slave.  README.IO and README.protocol provide the details.

https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Docs/README.IO
https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Docs/README.protocol

(I should say that I haven't used them in probably 10+ years, but I see no reason why they wouldn't still work)

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1553
Joined: Wed Nov 29, 2006 9:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: "Out of Fuel" message with networked Flightgear

Postby wlbragg » Sat May 30, 2020 8:06 pm

I think the best way to solve this would be use use the --generic protocol to pass any additional properties (e.g. /consumables/fuel/tank[0]/level-gal_us) from the master to the slave.

I think the problem in this instance is that we really don't need the messages at all in the client or remote sides. They should only be displayed on the host screen.
I think we still need to be able to have the FG instance recognize whether or not it is host or client so you can condition the code accordingly.
I didn't even check to see if the fuel gauges report fuel or any instruments are working correctly on the remote side, which is what your recommendation would indeed support.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
Intel i5 3570K AMDRX480
User avatar
wlbragg
 
Posts: 5591
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/AMDRX480

Re: "Out of Fuel" message with networked Flightgear

Postby WoodSTokk » Sat May 30, 2020 10:44 pm

On the client side the instruments shows nothing. The source of the server/client protocol came from multiplayer and up to 2018.x.x the protocol transmit only values that animate something so that audiences see moving parts.
If you use 2020.x.x on multiplayer and switch the view inside a cockpit from another plane, it looks like the aircraft is cold and dark.
No instrument values will be transmitted.

In this case, it should be possible to detect if you are a client by looking if a FDM is running or not.
No FDM == Client --> suppress messages.
WoodSTokk
 
Posts: 536
Joined: Tue Oct 17, 2017 2:30 pm
Location: Milky Way/Sol/Earth/Europe
Callsign: OE-WST
IRC name: WoodSTokk
Version: 2020.3.0
OS: Debian Buster

Re: "Out of Fuel" message with networked Flightgear

Postby Hooray » Sun May 31, 2020 11:06 am

stuart wrote in Sat May 30, 2020 3:57 pm:I think the best way to solve this would be use use the --generic protocol to pass any additional properties (e.g. /consumables/fuel/tank[0]/level-gal_us) from the master to the slave. README.IO and README.protocol provide the details.


That is indeed what I was alluding to when I asked:
Subject: "Out of Fuel" message with networked Flightgear
Hooray wrote:without a proper solution, why don't you simply sync/copy the relevant set of properties to the slave or disable the message altogether ?


But the issue remains that the "master/slave" feature is poorly documented/formalized and that it could benefit from being reviewed and updated slightly.
We have now heavily overlapping functionality in different parts of FlightGear, and with a proper review, the use-case could definitely be formalized to become even more useful.

For instance, think about how multiplayer is all about selectively replicating state across multiple fgfs instances.
Next, think about the instant replay/flight recorder subsystem, which is about selectively sampling/serializing and replaying Property state inside a single fgfs session.
And then think about how Emesary as a messaging mechanism can be used to send arbitrary messages across multiple fgfs instances.
And finally, look at the implementation of the original master/slave code - which is using hard-coded C++ structs that are sent over UDP.

Which is to say, FlightGear has meanwhile grown much better APIs and framework to implement such functionality in a much more generic fashion.

In other words, with SGSocket bindings, Emesary could be used to directly send arbitrary messages to different fgfs instances.
With access to the multplayer system, we have existing helpers to serialize properties using XDR (tiny_XDR), this just isn't available currently.
And the flight recorder system is all about formalizing which state is relevant to replay a portion of a flight. Whereas the multiplayer system is all about replicating the same state across multiple fgfs instances.

So, there is heavily overlapping functionality implemented now without any kind of code reuse at all.

If these systems were reviewed and better integrated, we could have an XML configuration for each aircraft that would support flights being replayed/replicated and serialized across an abitrary number of fgfs instances.

Also note how this is touching on saving/loading and resuming flights at run-time, which has been the "holy grail" in FlightGear for the last 2 decades.

Just some food for thought :wink:
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11835
Joined: Tue Mar 25, 2008 8:40 am

Re: "Out of Fuel" message with networked Flightgear

Postby specky » Thu Jul 16, 2020 11:37 pm

Hi everyone, thank you for your input.

After reading through this thread and the devel mailing list it is apparent that there is no standard way to indicate to a Flightgear session that it is a slaved/follower instance.

This lack of clarity dissuaded me from hacking at the aircraft files, e.g. wrapping the messages in conditions.

After a bit of grepping around the Flightgear source and trial and error, I was able to define a Generic Protocol which transfers fuel tank selection, capacity, usable capacity, density, level and cabin temperature.

Given this protocol file in $FG_ROOT/Protocol, the commands to start each system becomes:

On the master/leader:

Code: Select all
FG_ROOT=/usr/share/games/flightgear FG_HOME=/home/chris/.fgfs /usr/games/fgfs \
    --aircraft=c172p \
    --enable-auto-coordination \
    --timeofday=morning \
    --enable-fullscreen \
    --disable-terrasync \
    --native-fdm=socket,out,60,192.168.1.71,5510,udp \
    --native-ctrls=socket,out,60,192.168.1.71,5511,udp \
    --generic=socket,out,2,192.168.1.71,5512,udp,fgo \
    --httpd=8080 \
    --fg-aircraft=/home/chris/.fgfs/Aircraft


On the slave/follower:
Code: Select all
FG_ROOT=/usr/share/games/flightgear FG_HOME=/home/chris/.fgfs /usr/games/fgfs \
    --aircraft=c172p \
    --enable-auto-coordination \
    --timeofday=morning \
    --enable-fullscreen \
    --disable-terrasync \
    --fov=66.7 \
    --prop:/sim/view[0]/config/heading-offset-deg=-70 \
    --prop:/sim/view[0]/config/pitch-offset-deg=0 \
    --fdm=null \
    --native-fdm=socket,in,60,,5510,udp \
    --native-ctrls=socket,in,60,,5511,udp \
    --generic=socket,in,2,,5512,udp,fgo \
    --fg-aircraft=/home/chris/.fgfs/Aircraft


The ability to run Flightgear for free across multiple heterogeneous computers in concert is a killer feature and it is a shame that it is broken out of the box and such an unloved capability.

The Native-FDM protocol does transmit fuel quantity for each tank, however this quantity is ignored by the client in the absence of the other values listed above.
specky
 
Posts: 3
Joined: Sat May 23, 2020 3:32 am

Re: "Out of Fuel" message with networked Flightgear

Postby Hooray » Fri Jul 17, 2020 3:50 pm

It would be pretty easy to fix this "properly" - for that, it would make sense to file a feature request, so that we can discuss if/how this is best addressed - but the C++ changes would be pretty basic/minor actually.

For the feature request, see: https://sourceforge.net/p/flightgear/codetickets/
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11835
Joined: Tue Mar 25, 2008 8:40 am

Re: "Out of Fuel" message with networked Flightgear

Postby specky » Sun Jul 19, 2020 1:14 am

I have filed a Ticket and created a PR.
specky
 
Posts: 3
Joined: Sat May 23, 2020 3:32 am

Re: "Out of Fuel" message with networked Flightgear

Postby Hooray » Sun Jul 19, 2020 5:57 am

Thank you, that's looking pretty good. Let's see what the devs are going to say ;-)

BTW: If you are interested in a more generic long-term solution, you might want to review the so called "instant replay/flight recorder" subsystem - which has a way to use an XML configuration way to specify if/how and when certain properties are to be recorded/replayed, it would seem pretty straightforward to use the same mechanism/idea to also synchronize/replicate relevant properties across multiple inter-linked fgfs instances, i.e. not specific to any particular use-case, just a generic property replication mechanism.

I guess, you will immediately see the potential behind this by briefly looking at README.flightrecorder in $FG_ROOT/Docs

The other feature you might be interested in is the so called "Emesary" messaging system:

The flight recorder/instant replay system has recently received some major updates by Julian Smith, and Emesary is maintained by Richard Harrison (both are active core developers).

Again, this will only be relevant if you are interested in working on a more generic scheme to sync arbitrary property lists across multiple fgfs instances, without it being specific to any particular use-case - the main benefit would be that such a scheme could be easily made to work for arbitrary aircraft, without requiring hard-coded changes, i.e. the setup would work via conventional PropertyList XML files.
Speaking in general, it would make sense to discuss the merits of this with the key people involved in the corresponding subsystems - for instance, Richard has not only come up with Emesary, but also has made major contributions to the multiplayer system, which is obviously networking related, and which is already using XDR encoding internally.

In other words, don't start any work related to this, if you haven't talked to the potential reviewers (devel list/issue tracker)

All of this is just to say, the original master/slave feature is a legacy feature, and many of the remaining core devs are unlikely to be aware of it, let alone be familiar with - and that applies particularly to aircraft developers, whose aircraft will rarely support the feature (which is also named somewhat unfortunately ...) Which is why it might be a good idea to revisit the underlying idea, and look at what else we have already, and see how this could be generalized/reused to accomplish the same thing, without hard-coding property lists.

The instant replay/flight recorder system is actively maintained, and also used by aircraft developers, so that a corresponding list of relevant properties can be easily determined at runtime, provided the aircraft has a corresponding configuration (which is otherwise easy to create).

Again, best to make up your own mind and discuss this with others interested in this aspect of FlightGear.

http://wiki.flightgear.org/Instant_Replay
http://wiki.flightgear.org/Emesary
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11835
Joined: Tue Mar 25, 2008 8:40 am

Previous

Return to Interfacing

Who is online

Users browsing this forum: No registered users and 1 guest