[Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Instrumentation kt_70.cxx, 1.1, 1.2
Curt, See this discussion between David M. and me about setting property values in source code vs. setting them in config files. http://baron.flightgear.org/pipermail/flightgear-devel/2004-November/031882.html After this I removed all set serviceable property to true from instrumentation and systems source code. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Instrumentation kt_70.cxx, 1.1, 1.2
Roy Vegard Ovesen wrote: Curt, See this discussion between David M. and me about setting property values in source code vs. setting them in config files. http://baron.flightgear.org/pipermail/flightgear-devel/2004-November/031882.html After this I removed all set serviceable property to true from instrumentation and systems source code. So what's the solution? We can't initialize any number of arbitrary serviceable properties in the preferences.xml and I've always been nervous about doing htat anyway. If we also can't do it in code, then were are we supposed to initialize these properties so that the instruments will work? Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Instrumentation kt_70.cxx, 1.1, 1.2
On Wed, 05 Jan 2005 08:01:49 -0600, Curtis L. Olson [EMAIL PROTECTED] wrote: So what's the solution? We can't initialize any number of arbitrary serviceable properties in the preferences.xml and I've always been nervous about doing htat anyway. If we also can't do it in code, then were are we supposed to initialize these properties so that the instruments will work? One option is to initialize only if the property is not set. There's no problem having a C++ fallback, as long as it does not override any user-specified value. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Instrumentation kt_70.cxx, 1.1, 1.2
On Wednesday 05 January 2005 15:26, David Megginson wrote: On Wed, 05 Jan 2005 08:01:49 -0600, Curtis L. Olson [EMAIL PROTECTED] wrote: So what's the solution? We can't initialize any number of arbitrary serviceable properties in the preferences.xml and I've always been nervous about doing htat anyway. If we also can't do it in code, then were are we supposed to initialize these properties so that the instruments will work? One option is to initialize only if the property is not set. There's no problem having a C++ fallback, as long as it does not override any user-specified value. Something like this in the init() method of instrumentation and systems does just that: serviceableNode = node-getChild(serviceable, 0, false); if( !(serviceableNode) ) { cout serviceableNode doesn't exist\n; serviceableNode = node-getChild(serviceable, 0, true); serviceableNode-setBoolValue(true); } As you can see it only creates the serviceable property and initializes it if it does not already exist. I think that similar kind of checking should be applied to other input properties as well. For example the altimeter instrumentation module needs a static pressure input, usually taken from the static port system module. If the property that the altimeter wants to use does not exist, then the altimeter should not create that property (this is the way it works now), it should rather complain about it not existing and consequently initialize the altimeter's serviceable property to false. This would also make life a bit easier for instrumentation/systems config file writers. If they try to use nonexistant properties it complains rather that silently create a new (dummy) property. I'll add this idea to my TODO list, unless someone else already is busy solving this issue. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d