anything in the nav tree is valid or not.
- Fix an order problem between caching data values and searching for a new
station that could cause odd and unexpected and hard to reproduce results.
Added a convenience function to estimate the time to intercept the selected
radial give the current heading and speed. This can be useful to a flight
directory to compute the point to switch from armed to coupled mode at just
the right time so the pilot can roll out onto the desired heading on the
desired radial.
Add a first whack at estimating a ground track heading error (difference
between aircraft heading and ground track directon.) This needs more work
and testing.
* Use "const string&" rather than "string" in function calls when appropriate.
* Use "const Point3D&" instead of "Pint3D" in function calls when appropriate.
* Improved course calculation in calc_gc_course_dist()
* Safer thread handling code.
Vassilii Khachaturov:
Dont use "const Point3D&" for return types unless you're absolutely sure.
Erik Hofman:
* Use SGD_(2)PI(_[24]) as defined in simgear/constants.h rather than
calculating it by hand every time.
I have corrected a few bugs with the owner draw gauge, weather radar code and heat-haze effect.
- od_gauge.cxx :
corrected a rendering bug where the generated texture was only visible
from a certain angle or distance ;
corrected the search of textures inside the aircraft scene graph ;
- wxRadar.cxx :
the echo of clouds was lost when the pilot was not looking in the
plane direction ;
I had a quick view over the ssgBase::ref() calls in flightgear.
I made them all symmetric and used ssgDeRefDelete to dereference them.
This has the basic advantage that ssgDeRefDelete additionaly deletes the
memory instead of just decrementing the reference cound without deletion ...
This includes an incorrect deref instead of a ssgDeRefDelete in the placement
transform registration I introduced earlier. I believe that this causes the
problems with long flights (unverified, but with a big propability).
Changes
=======
- acmodel.cxx :
we now have an optional new property (/sim/model/texture-path) that is used
as the first path in wich aircraft textures are searched. If textures are not
found there then the usual texture path or model path is used ;
This allows to replace only needed textures for liveries ;
- options.cxx :
added a new --livery=xxx option for the user pleasure ;
this will just set the /sim/model/texture-path property with /livery/xxxx
- od_gauge.cxx, og_gauge.hxx, cockpit.cxx, cockpit.hxx,
generic-instrumentation.xml :
added an helper class that contain a rendering context for glass instrument
or any other opengl drawn instrument ;
- wxradar.cxx, instrument_mgr.cxx, wxradar.hxx :
first experimentation of a weather radar ;
This adds a TACAN instrument to the inventory. Range and bearing are calculated
to the TACAN or VORTAC beacon selected by means of the Channel Selector in the E
quipment/Radio pull-down menu.
A TACAN beacon has also been added to the aircraft carrier Nimitz (channel #029Y
).
Attached is a patch to the airport data storage that I would like committed
after review if acceptable. Currently the storage of airports mapped by ID
is by locally created objects - about 12 Meg or so created on the stack if
I am not mistaken. I've changed this to creating the airports on the heap,
and storing pointers to them - see FGAirportList.add(...) in
src/Airports/simple.cxx. I believe that this is probably better practice,
and it's certainly cured some strange problems I was seeing when accessing
the airport data with some gps unit code. Changes resulting from this have
cascaded through a few files which access the data - 11 files are modified
in all. Melchior and Durk - you might want to test this and shout if there
are problems since the metar and traffic code are probably the biggest
users of the airport data. I've also added a fuzzy search function that
returns the next matching airport code in ASCII sequence in order to
support gps units that have autocompletion of partially entered codes.
More generally, the simple airport class seems to have grown a lot with the
fairly recent addition of the parking, runway preference and schedule time
code. It is no longer just an encapsulation of the global airport data
file, and has grown to 552 bytes in size when unpopulated (about 1/2 a K!).
My personal opinion is that we should look to just store the basic data in
apt.dat for all global airports in a simple airport class, plus globally
needed data (metar available?), and then have the traffic, AI and ATC
subsystems create more advanced airports for themselves as needed in the
area of interest. Once a significant number of airports worldwide have
ground networks and parking defined, it will be impractical and unnecessary
to store them all in memory. That's just a thought for the future though.
- replay.cxx :
corrected a bug, now reinitialize the recording data when replay is
deactivated
- fgclouds.cxx :
cloud layers and weather condition are saved when choosing a weather scenario,
added a new scenario 'none' so we can switch back to standard flightgear
weather
- navradio.cxx :
force a search() on init to initialize some variables, preventing a nearly
infinite loop when delta-time == 0 on the first update()
- electrical.cxx :
uninitialized variable in apply_load() for FG_EXTERNAL supplier
- panel.cxx, panelnode.cxx :
added a property "depth-test" for 2.5D panels so that they update the depth
buffer and are no more visible from the outside of the aircraft when the
aircraft uses textures without an alpha channel
- panel.cxx :
moved the computation of the instruments diffuse color outside the
texturelayer code since this is constant during a frame, this is a big speedup
for 2D panels
Annexed an IVSI (instantaneous ertical speed indicator), which bypasses a
limitation with Concorde :
- the cruise at Mach 2 must be with a slow climb rate of 50/60 ft/min
(2h from 50000 ft).
- with /velocities/vertical-speed-fpm, the real climb rate (altimeter) varies :
One must constantly (every 5-10 minutes) change the vertical speed hold of
the autopilot between 10 ft/min and 200 ft/min.
This is very annoying because not a constant offset : that could be a lack of
sensitivity of /velocities/vertical-speed-fpm (FDM ?).
This new IVSI :
- Is an emulation with works with environment pressure : a real IVSI works with
static pressure (with lag) + accelerometers.
It is not forbidden to later upgrade to the real model.
- Doesn't require a tuning of the autopilot made with
/velocities/vertical-speed-fpm (also tested with 737, 747) :
Concorde's autoland works without update.
