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