The error properly belongs to the enclosing scope, not the called
(non-)function. This bug was fixed a few months back in my private
tree, but Melchior just discovered that the new Concorde scripts
tickle it. I really need to re-synchronize SimGear with my own Nasal
tree...
this is the animation code that do randomisation of the spin animation. The XML tags are modified to support the syntax below :
<use-personality type="bool">true</use-personality>
<factor>
<random>
<min>1.8</min>
<max>2.2</max>
</random>
</factor>
<starting-pos-deg>
<random>
<min>0</min>
<max>360</max>
</random>
</starting-pos-deg>
instead of usual :
<factor>1.42</factor>
<starting-deg-pos>42.0</starting-deg-pos>
1. Remove the dependency on alut which (on certein platforms) might pose
some restrictuons on commercial use.
2. Create a sound source just prior to playing the sound and destroy it
again when the sound has stopped. This should greatly reduce the
error reports from Windows users.
The following patches to SimGear & FlightGear ...
- create an FGMetar abstraction layer, whose purpose is:
* provide defaults for unset values
* interpolate/randomize data (GREATER_THAN)
* derive additional values (time, age, snow cover)
* consider minimum identifier (CAVOK, mil. color codes)
- add rain/hail/snow/snowcover support on the METAR side
- add max age of METAR data handling (currently set to
- add support for an external METAR cache proxy server
- add CAVOK handling
- set missing year/month in regular METAR messages
- fix a small bug in metar.cxx (wrong return value)
- In sky.cxx blend low density cloud layers (few/scattered) into nothing (but
don't touch visibility distance) as we approach them so we can fly through
clean.
- For high density cloud layers (broken/overcast) we do not fade the layers
out, but we fade visibility to nearly nothing as we approach the layer.
capability to slowly fade a cloud layer in or out.
We use this effect in combination with lowering visibility as we approach
a cloud layer to hide the fact that it is simply a 2d textured polygon being
drawn across the sky.
cloud layer (i.e. <50% coverage). This is a quick hack rather than a
proper fix, but it will at least make it possible to get above a
scattered layer VFR.
It comes to me that the bulk of all problem reports, especially from Windows users, have it's cause in an obsolete sound driver. These messages should direct them to the right solution before complaining.
My recent fix for the load/save fgfs.sav feature was a bit too ambitious.
While aliases lead to abortion before, I tried to copy them properly,
although this wasn't a requirement. Unfortunately, this seems to have
worked for absolute aliases only, not for relative ones, and hence broke
several panel instruments. The attached patch backs most of the previous
patch out again, and goes a simpler route: just ignore aliases.
fgLoadFlight() loads a property file ("fgfs.sav") to a new property tree,
and then copies that over to the main tree. copyProperties() didn't know
how to handle type SGPropertyNode::ALIAS and hence threw an exception that
made fgfs abort.
The attached patch adds support for ALIAS to copyProperties(): aliased
nodes are created in the target tree if necessary, and then linked like in
the source tree. It seemed useful to add an optional argument to
props.[ch]xx/getType() that would indeed return the property type "ALIAS"
for aliased nodes, and not the type of the node that it refers to. The patch
also fixes a bug in writeNode() that caused extra lines after alias entries.
If there's resistance to the change to getType() (David?) I can easily use
isAlias(). This just makes copyProperties() a tad uglier, but I can live with
it. It's useful for scanning a tree, though, if an alias node can be treated
exactly like all other nodes, without automatic redirection.
At last I've found the reason why fgfs crashed routinely for me. When I still
used KDE's artsdsp (preloads lib with OSS replacement functions) I saw
this crash only occasionally. After letting OpenAl communicate with artsd
directly (by means of ~/.openalrc setting), I got the crash always when
I left fgfs.
This bug may also have crashed fgfs when running with sound daemons other than
aRts.
but it doesn't. Trying the apple approach to fixing isnan results in an
infinite loop (making me wonder what happens on OSX?) This is an alternative
approach to checking isnan() on freebsd ...
