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
[email protected]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
