David Megginson
> 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.
Sure, but I am willing to bet that each of those systems will have
a 'hardwired' set of 'possible' nodes and that there will be a vector<>
of the system's instances so will still be a 'C' interface definition.
> > 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.
In what way is this any different then the 'C' code ??
Norman
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
