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 10: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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: "Out of Fuel" message with networked Flightgear

Postby Hooray » Tue May 26, 2020 10: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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: "Out of Fuel" message with networked Flightgear  

Postby stuart » Sat May 30, 2020 4: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: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: "Out of Fuel" message with networked Flightgear

Postby wlbragg » Sat May 30, 2020 9: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 and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7586
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: "Out of Fuel" message with networked Flightgear

Postby WoodSTokk » Sat May 30, 2020 11: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: 1077
Joined: Tue Oct 17, 2017 3:30 pm
Location: Milky Way/Sol/Earth/Europe
Callsign: SX-W57
IRC name: WoodSTokk
Version: 2020.4.0
OS: Debian Bullseye

Re: "Out of Fuel" message with networked Flightgear

Postby Hooray » Sun May 31, 2020 12:06 pm

stuart wrote in Sat May 30, 2020 4: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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: "Out of Fuel" message with networked Flightgear

Postby specky » Fri Jul 17, 2020 12:37 am

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 4:32 am

Re: "Out of Fuel" message with networked Flightgear

Postby Hooray » Fri Jul 17, 2020 4: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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: "Out of Fuel" message with networked Flightgear

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

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

Re: "Out of Fuel" message with networked Flightgear

Postby Hooray » Sun Jul 19, 2020 6: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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: "Out of Fuel" message with networked Flightgear

Postby aricjoshua » Thu Sep 16, 2021 4:37 pm

One of my worries, though, is whether or not there are currently procedures in place to deal with these sorts of problems. For example, we have a structure for MP that is hidden from the casual developer. I'm not trying to invent something new.
cookie clicker 2
aricjoshua
 
Posts: 2
Joined: Thu Sep 16, 2021 4:25 pm

Re: "Out of Fuel" message with networked Flightgear

Postby wkitty42 » Thu Sep 16, 2021 6:19 pm

the source code for the current MP server is freely available... anyone can set one up for FG users to use... in many cases, they are or can be added to the default list in FG (by asking on the devs' mailing list)... some stay private and have to be manually entered in your FG... https://wiki.flightgear.org/FlightGear_Multiplayer_Server
"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
wkitty42
 
Posts: 9146
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: "Out of Fuel" message with networked Flightgear

Postby egdorf » Sun Nov 26, 2023 9:18 pm

This is a very useful discussion. The ability to network multiple computers into an extended flight simulator is an important feature.
I am fairly new to FlightGear, and am experimenting with a three-system setup mostly to gain familiarity with how the system works. The primary sits off to the side with fairly normal GUI for a flight engineer or instructor or something. The two secondary systems are in front of the pilot/controls and provide a control panel just behind the yoke and a big-screen sort-of up on the cowl for the terrain. The instructions in the manual work well and the basic setup is working.
However I am getting the "out of fuel" pop up and console messages as described above.

This is as of version 2023-3-19 running on Fedora-39 with FlightGear loaded from the Fedora repositories.
With the info in this post and a lot of browsing the documentation, I fired up the property browser on the secondary systems and played with the consumables.
It turns out that nothing much seemed to change until I hit the fuel density. Setting the fuel density gets rid of the out of fuel messages.
So now my fgfsrc file for the secondary systems includes:
--prop:/consumables/fuel/tank[0]/density-ppg=6.02
--prop:/consumables/fuel/tank[1]/density-ppg=6.02
and everything runs without the error.

This is not a FIX, rather a workaround for anyone else who stumbles across the "out of fuel" message.
It seems that the data sent with the
--native-fdm=socket...
--native-ctrls=socket...
do not include the density. I guess we multiply fuel by a zero density and get zero fuel.

Could someone give me a hint where to look for the protocol used by the sockets? I can't find it in the protocols sections.
In any case, I think this feature is an important, although old, part of FlightGear. i would be glad to help in any upgrade, maintenance, re factoring of the capability.

Thanks to everyone for a great project. Hope this helps a little.

Skip
egdorf
 
Posts: 2
Joined: Fri Nov 24, 2023 6:47 pm
Version: 2020.3.19
OS: Fedora Linux

Re: "Out of Fuel" message with networked Flightgear

Postby polly » Mon Nov 27, 2023 12:58 pm

Um More guesses than a hint, it looks to me that file: flightgear/src/Network/net_fdm.hxx defines the interface structure, which ought to contain density_kg_pm3

However, if the message is literally string "Out of fuel!" ( shouty with upper case 'O') then it comes from engine.nas in fgdata/Aircraft/c172p/Nasal/engine.nas, the message seems to depend on fuel level-gal-us.

Can you confirm you see the issue with c172p ? It loos as if, somewhere, fuel tank level is derived from ppg when it ought to be from kg_pm3.
User avatar
polly
 
Posts: 956
Joined: Thu Nov 04, 2010 3:45 pm

Re: "Out of Fuel" message with networked Flightgear

Postby egdorf » Mon Nov 27, 2023 3:13 pm

polly wrote in Mon Nov 27, 2023 12:58 pm:Can you confirm you see the issue with c172p ? It loos as if, somewhere, fuel tank level is derived from ppg when it ought to be from kg_pm3.


I have been using the default c172p. I will eventually want to look at other aircraft, but have kept the default while getting up and running.

Skip
egdorf
 
Posts: 2
Joined: Fri Nov 24, 2023 6:47 pm
Version: 2020.3.19
OS: Fedora Linux

Previous

Return to Interfacing

Who is online

Users browsing this forum: No registered users and 4 guests