Norman Vine wrote:
> Grrrr......
> One of those variables that only lives in the 'ether world'
> A VERY GOOD REASON for these things to live in a real 'C'
> variable ......
I think you misunderstood. It *does* live in a real C variable
(FGInterface::Tank1Fuel). That variable never got initialized, and
isn't set by the FDMs, so it contains garbage. In this case, the
"pure" property manager was bypassed by "tying" the value to an actual
memory location. That's the bug -- had this been an actual property,
the value would have been zero.
The core points here are:
1. Not every FDM or every aircraft model will set all properties.
2. There is no way for clients of the information to know, a priori,
whether or not a value is valid or not (starting up a "generic jet"
panel on the 172, etc...).
3. Reading information that the FDM hasn't set shouldn't cause a crash.
That's very hard to guarantee in C space, as this bug evidences. With
a soft-coded property system, you get it for free.
There's also a tangential advantage, which is that it makes evolution
of the interface much easier. If I decide that I *really* want to
export, say, /yasim/consumables/gun[0]/rounds, I can Just Do It. No
need to coordinate an update with Jon, Tony and David. I just set the
property, and get someone to write panel code to display an ammunition
counter. Running that against the JSB X-15 will just show zero
instead of blowing up or failing to compile.
Now, at some point we'll want to "canonize" this property and move it
out of the /yasim tree and into the core. But now, that can happen
_after_ the development has been done, instead of having to be
designed-in beforehand.
Andy
--
Andrew J. Ross NextBus Information Systems
Senior Software Engineer Emeryville, CA
[EMAIL PROTECTED] http://www.nextbus.com
"Men go crazy in conflagrations. They only get better one by one."
- Sting (misquoted)
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
