snip
altimeter-datum-mb1013.25/altimeter-datum-mb
I assume that this is the setting for the WGS-84 datum.
It is the pressure setting on the altimeter, that can be
adjusted by
turning the knob on the altimeter.
I assume that it is in mm of Hg?
No, it is in millibar (mb) as
altimeter-datum-mb1013.25/altimeter-datum-mb
I assume that this is the setting for the WGS-84 datum.
It is the pressure setting on the altimeter, that can be adjusted by
turning the knob on the altimeter.
I assume that it is in mm of Hg?
It is in milibars ie 1mb=100 Pascal
On Tuesday, March 19, 2002, at 05:19 PM, Julian Foad wrote:
unitsfeet/units
I believe this primarily affects the interpretation of other command-line
options.
model-hz120/model-hz
This specifies the rate at which you want the Flight Data
Manager to run...
I believe FDM =
Cameron Moore writes:
I'm not familiar with our XML parser, but could we get away with using
this instead?:
has-gs-needle/
In other words, you'd like
foo/foo
to be the equivalent of
footrue/foo
or
foo1/foo
I'm not sure if that's a good idea -- I'd be more inclined to
Jon Berndt writes:
I've had some thoughts along those lines, too. Note that I am not so
familiar with proper XML, but I wondered if this might be legal or
advisable,
Instead of:
POSITION
X24.5/X
Z-49.0/Z
/POSITION
we could use:
POSITION X=24.5 Z=-49.5/
Right
David Megginson wrote:
I'm not sure if that's a good idea -- I'd be more inclined to default
to 0/false/empty-string. What do other people think?
Actually, thinking about this more, I'm starting to like this idea.
As you say, it's really the same thing as changing the default value
for a
Andy Ross writes:
sim
fooA/foo
fooB/foo
/sim
This already works as you would expect. Multiple children with the
same name are automatically numbered sequentially when there is no n
attribute, so the above is synonymous with
sim
foo n=0A/foo
foo n=1B/foo
/sim
I tend
Andy Ross writes:
POSITION X=24.5 Z=-49.5/
This is more readable to my eyes too, which is why the YASim parser
uses attributes.
If it's any comfort, this is a general problem in XML: the more
general we make a format, the less we can use optimizations like
these, but the more
--- David Megginson [EMAIL PROTECTED] wrote:
Andy Ross writes:
This would require changing the defaulting
semantics, though. The
default value you fill in at parse-time should
be true, but the
default you fill in when a non-existent
property is queried should
be false. I'm
If I may add my US$0.02. I prefer to have the more verbose preferences
file as well. From the perspective of someone who does not want to look
through the code (not me, but those to whom I will be giving FlightGear),
it would be nice if they can see all configurable options (without
10 matches
Mail list logo
