Re: [Flightgear-devel] CVS: source/src/Instrumentation mag_compass.cxx, 1.6, 1.7
On Mon, 8 Nov 2004 01:41:18 +0100, Roy Vegard Ovesen <[EMAIL PROTECTED]> wrote: > I thought (or rather hoped) that preferences.xml, *-set.xml or command line > would set properties after the source code did. IIRC I added this to most > instrumentation modules and system modules, so that has to be removed then. FlightGear maintains a central property tree, a single database of information. Individual modules may end up being initialized before or after options and config files are read. > I still feel that the setting of the serviceable property for instrumentation > and systems should be removed from preferences.xml into the *-set.xml files. I'd like to see them moved into their own individual config files, just as we have config files for individual planes. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: source/src/Instrumentation mag_compass.cxx, 1.6, 1.7
On Monday 08 November 2004 00:22, David Megginson wrote: > If the source code modules force the property to true, it will > override any settings provided by the user at startup or in a > configuration file. I see. > It needs to be possible to start FlightGear with > the mag compass U/S for some scenarios, just as we can start with the > vacuum pump or alternator U/S. Yes, that makes sense. > Making the compass serviceable should be part of that. If the setting > is in preferences.xml (or a separate startup config file), it can be > overridden on the command line; if it is hard-coded in the C++, it > will be set after the options have been read, and cannot be > overridden. I thought (or rather hoped) that preferences.xml, *-set.xml or command line would set properties after the source code did. IIRC I added this to most instrumentation modules and system modules, so that has to be removed then. I still feel that the setting of the serviceable property for instrumentation and systems should be removed from preferences.xml into the *-set.xml files. Consider the cub for example when it gets it's own instrumentation and systems configuration files, most likely the adf, dme, gps, dg, vsi, vacuum system, and probably more would be removed. Having preferences.xml set the serviceable property would then lead to cluttering of the property tree with lots of subdirs that would only contain the serviceable property. I assume that such cluttering is undesirable, or else my argument would fall apart ;-) -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: source/src/Instrumentation mag_compass.cxx, 1.6, 1.7
On Sun, 7 Nov 2004 12:32:41 +0100, Roy Vegard Ovesen <[EMAIL PROTECTED]> wrote: > My motivation for setting the serviceable property to true in the source code > was that now that the instruments are configureable they can have an > arbitrary name in the property tree. The compass could for example be > named /Instrumentation/magnetic-heading-indicator-thingy. As I understood it > the serviceable property used to (actually still does) be set to true in > preferences.xml, where it is set for all instrumentation. If the source code modules force the property to true, it will override any settings provided by the user at startup or in a configuration file. It needs to be possible to start FlightGear with the mag compass U/S for some scenarios, just as we can start with the vacuum pump or alternator U/S. > So setting it to true in preferences is would not be a good solution when (not > if) aircraft designers decide to change the name of the instrumentation, > remove instrumentation that are not applicable to that aircraft, and add more > instrumentation for for example redundancy. Making the compass serviceable should be part of that. If the setting is in preferences.xml (or a separate startup config file), it can be overridden on the command line; if it is hard-coded in the C++, it will be set after the options have been read, and cannot be overridden. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] CVS: source/src/Instrumentation mag_compass.cxx, 1.6, 1.7
I see that the setting of the serviceable property has been removed:
***
*** 77,82
fgGetNode("/accelerations/pilot/z-accel-fps_sec", true);
_out_node = node->getChild("indicated-heading-deg", 0, true);
-
- _serviceable_node->setBoolValue(true);
}
My motivation for setting the serviceable property to true in the source code
was that now that the instruments are configureable they can have an
arbitrary name in the property tree. The compass could for example be
named /Instrumentation/magnetic-heading-indicator-thingy. As I understood it
the serviceable property used to (actually still does) be set to true in
preferences.xml, where it is set for all instrumentation.
So setting it to true in preferences is would not be a good solution when (not
if) aircraft designers decide to change the name of the instrumentation,
remove instrumentation that are not applicable to that aircraft, and add more
instrumentation for for example redundancy.
I also thought it made sense for the instrumentation to be initially
serviceable.
I say we remove the setting of the serviceable property from preferences.xml
instead of removing it from the source code. This also applies to systems.
--
Roy Vegard Ovesen
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
