[Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Instrumentation kt_70.cxx, 1.1, 1.2

2005-01-05 Thread Roy Vegard Ovesen
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

2005-01-05 Thread Curtis L. Olson
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

2005-01-05 Thread David Megginson
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

2005-01-05 Thread Roy Vegard Ovesen
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