Norman Vine writes:
> But there are many "Fixed Lists" of properties for example
>
> PitotSystem::init ()
> {
> _serviceable_node = fgGetNode("/systems/pitot[0]/serviceable", true);
> _pressure_node = fgGetNode("/environment/pressure-inhg", true);
> _density_node = fgGetNode("/environment/density-slugft3", true);
> _velocity_node = fgGetNode("/velocities/uBody-fps", true);
> _total_pressure_node =
> fgGetNode("/systems/pitot[0]/total-pressure-inhg", true);
> }
>
> and I can't add to this list without creating another 'C' variable
You will soon, however. We need to be able to support multiple
systems (like vacuum pumps), so once we have all of the initial
versions running, you'll be able to specify what input and output
properties each instantiation of a system (or instrument) uses.
> We should have documentation as to what these HARD CODED terms are.
> Using the 'property browser' is a great way to inspect a running
> instance of FGFS but is a poor excuse for the 'Official
> Documentation' of the 'properties'
I think that's a great idea, as long as we recognize that it will be
perpetually a work in progress. Is anyone willing to become the
maintainer of a FlightGear property bible? This is a great area for a
non-programmer who wants to contribute.
Note, however, that we may be facing a major reorg when we move to
supporting multiple vehicles in a single FlightGear instance; for
example, we might have
/vehicle[0]/position/latitude-deg
/vehicle[1]/position/latitude-deg
and so on, or we might just create an entirely separate property tree
for each instance. The new subsystem manager is getting us much
closer to multiple-vehicle (or multiple-context) support; depending on
my free time (and that of others), it may be only a few months away.
> I have done some experimentation but have yet to come up with a
> 'good' method of documenting these hard-coded properties.
Personally, I'm fond of including them in the doxygen comments, as in
the following example following from src/Systems/vacuum.hxx:
/**
* Model a vacuum-pump system.
*
* This first, simple draft is hard-wired to engine #1.
*
* Input properties:
*
* /engines/engine[0]/rpm
* /environment/pressure-inhg
* /systems/vacuum[0]/serviceable
*
* Output properties:
*
* /systems/vacuum[0]/suction-inhg
*/
However, not all properties are so neatly handled by a single, central
piece of C++ code.
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
