> Jon S. Berndt wrote:
> > I haven't been following this thread very closely. Can someone
> > concisely recap what is wanted, here? It's most likely a very simple
> > addition for us if it's something we don't now model.
> Actually, YASim uses a Nasal-based fuel system that was designed to be
> FDM-independent.  It doesn't handle the stuff internally at all.
> Instead, each engine sets an /engine/engines[n]/fuel-consumed-lbs
> property.  Each iteration, it adds its newly consumed fuel (that is,
> just flow rate * timestep) to this property. The Nasal script then
> comes around in a polling loop, sucks this stuff out and subtracts it
> from the tanks according to the fuel selector properties.
> YASim then just uses each tanks level-lbs property as a pure input
> property to set weights on the tank objects.

This is good for YASim. However, the Nasal approach won't apply for other 
which use JSBSim, and JSBSim also needs its own fuel management for batch runs 
operation) outside of FlightGear. The downside to that requirement is that 
somehow we have
to all learn to play nice together in a sensible way. This has been kind of an 
to me, that there are probably going to be items in our (JSBSim) configuration 
spec which
are ignored or overwritten by FlightGear, which leads to user confusion and 
headaches (I'm referring to fuel quantities and weight and balance issues).

> FWIW, another cool thing this dialog gets you is automatic weight
> management.  You can assign "named" weight objects in your -set.xml
> file and use sliders to control their sizes at runtime.  Not many of
> the YASim aircraft are doing this yet (I did the pa28-161 and a4, I
> know).  It's a much cleaner interface than having separate FDM
> configurations for each aircraft loadout.

This points out a headache for FlightGear, too: how to manage different 
capabilities in
different FDMs and not leave users scratching their heads: "why can I do this 
with this
aircraft and not that one?" Some of the features can be added to the various 
FDMs without
much trouble, I'm guessing, and made more "common" through the FGInterface 
class. With
JSBSim, though, we have to be careful and make sure new features don't break 
people's apps and continue to work with standalone operation. Anyhow, we support
specification of named mass objects in the configuration file. There are static 

We might consider writing up a list of common features that we'd like to see 
supported by
all FDMs, so the user has a more homogenous experience with the various 

Innis has written that all that is really needed from us it to provide a "total 
property. That's very simple to do.


Flightgear-devel mailing list

Reply via email to