- changed all sound file properties to end in /path for pathname, and
added /sound and /pitch (with current values as defaults)
- don't activate the stall horn if CAS is less than 30kt (this needs
to be refined somehow)
- declarations to support changes to cxx file
- delete table in destructor
** src/FDM/flight.cxx
- bind engine properties in FGInterface::bind, and publish properties
for all engines rather than just engine 0
** src/Main/fg_props.cxx
- removed all engine properties; now bound in FGInterface::bind
** src/Sounds/fg_fx.cxx
- support multiple engine and cranking sounds
** src/Sounds/fg_fx.hxx
- support multiple engine and cranking sounds
What was happening was that we screwed up and scheduled tiles for
(lon,lon) rather than (lon,lat) ... note the typo. This generated
bogus tile id's which the system happily accepted, put into the tile
cache system, and attempted to load. The problem was that these bogus
tile id's were negative where as all valid tile id's should be >= 0.
These negative tile id's up the logic used to remove tiles from the
cache. When identifying tiles for removal, we look for the furthest
tile away from us by starting out the furthest id at -1 and if we find
something further, we update the furthest tile id. Then at the end we
check if the furthest tile id >= 0 to see if we found anything we
could remove. However, the furthest tile id was these bogus tiles
with negative tile id's so the system always assumed there was nothing
appropriate for removal. This made it impossible to ever remove a
tile from the cache meaning it quickly filled up and no more tiles
could be loaded.
I fixed the one instance of scheduling tiles for a bogus location, and
added a sanity check so if it ever happens again we'll bomb with an
appropriate error message.
