sea tile, and finally process the objects. This guarantees that all objects
are placed relative to a valid tile center, rather than to the origin (0/0/0).
This is important for objects in sea tiles, and allows to display objects
of *.stg files that came sooner in FG_SCENERY.
This was the reason why some people (especially SuSE10.0/gcc 4.0.2
users) couldn't see others in MP. I don't even know why I'm committing
that. It's less important than taxi lights ...
metar fetcher. Effectively this caused the metar thread and the main
thread to both attempt to fetch weather data. This could lead to long pauses
when the main thread decided to fetch the weather, and introduced a race
condition that could cause a segfault/crash.
Investigating this issue, I discovered that even longer ago, someone confused
#defines and #ifdef symbols with C/C++ variables. If I #define XYZ 0 it is
defined so #ifdef XYZ is true, not false like a variable. Our thread
detection made this mistake and there were follow up patches to work around
it.
So I fixed the configure script (ahhh, reading the autoconf manual is highly
recommended excercise for people editing the configure.ac file.) I also
discovered that we were hardwiring with_threads=yes with no way via configure
options to disable threads from the build so I fixed that.
Then I patched up the #ifdef's scattered through the code to match the
configure script changes, oh and by the way, I stumbled upon a past typo
that led to the race condition in the metar fetching thread and fixed that.
Here's a fix for a bug I introduced when I updated the AIStorm with
turbulence. The change I made to the FGAIEntity struct was overriding the
thermal <strength-fps> data.
You'll find attached the modified fgadmin that takes care of
'Objects' and 'Terrain' if they exist. I also implemented the
'Check all' / 'Check none' feature you suggested several months
ago.
too old (wrong system time or broken proxy): stops after 10 stale reports
were fetched in a row. This should simply stop further fetching, but due
to a bug in the threading system(?) it does currently lead to abortion,
just like any other exception in the fetcher.
