New Nasal method get_cart_ground_intersection
Returns where the given position in the specified direction will intersect with the ground. Returns whether or not a certain position and direction pair intersect with the ground, and if so the intersection point.
Useful for radars, terrain avoidance (GPWS), etc.
Input parameters:
1. vec3d(x,y,z) position
2. vec3d(x,y,z) direction
Returns nil or geod hash (lat:rad,lon:rad,elevation:Meters) intersection
Example Usage:
var end = geo.Coord.new(start);
end.apply_course_distance(heading, speed_horz_fps*FT2M);
end.set_alt(end.alt() - speed_down_fps*FT2M);
var dir_x = end.x() - start.x();
var dir_y = end.y() - start.y();
var dir_z = end.z() - start.z();
var xyz = { "x":start.x(), "y" : start.y(), "z" : start.z() };
var dir = { "x":dir_x, "y" : dir_y, "z" : dir_z };
var geod = get_cart_ground_intersection(xyz, dir);
if (geod != nil) {
end.set_latlon(geod.lat, geod.lon, geod.elevation);
var dist = start.direct_distance_to(end)*M2FT;
var time = dist / speed_fps;
setprop("/sim/model/radar/time-until-impact", time);
}
-----------
Nasal method aircraftToCart : This allows easily computing offsets in aircraft-relative coordinates, and converting to global cartesian (ECEF) reference frame.
This has the advantage, according to my testing on Linux, that core
files obtained after a crash now point to the crashing thread again,
when one starts 'gdb' on the core file and runs the 'bt' command.
Apparently, when using kill(), the signal is seen as coming from the
outside and gdb's 'bt' command points to the wrong thread in general
when debugging using a core file (when debugging "live", gdb intercepts
the signal even before FG's signal handler is started).
See discussion starting at
<https://sourceforge.net/p/flightgear/mailman/message/35833221/>.
Add an additional visibility flag to the menubar implementations,
conditional on whether or not the menubar overlaps the window content.
(I.e for PUI but not Cocoa). This flag is linked to a new property
/sim/menubar/overlap-hide, which the renderer drives off the splash-
screen visibility.
On Windows, use:
- QtFileDialog if FG was built with Qt support;
- PUIFileDialog otherwise.
Behavior on other platforms is unchanged. This change is motivated by
the fact that some Windows users have reported[1][2] weird,
non-deterministic behavior of WindowsFileDialog and unfortunately, no
one seems to be willing and able to fix the problem. The Qt
implementation comes for free and should be quite robust. Of course, if
someone wants to maintain the WindowsFileDialog class again, the change
can be reverted.
See discussion at [3].
[1] https://forum.flightgear.org/viewtopic.php?f=25&t=31945
[2] https://sourceforge.net/p/flightgear/mailman/message/35761650/
[3] https://sourceforge.net/p/flightgear/mailman/message/35759819/
This fixes handling of non-ASCII splashscreen text for me (Debian
GNU/Linux). The XML input files don't technically *have* to be encoded
in UTF-8, as long as they properly declare the encoding and it is
supported by Expat. Of course, we prefer UTF-8 nowadays.
With this commit, startup tips and splash screen progress strings
("Loading scenery", "Initializing subsystems", etc.) can at last be
written correctly in languages that need non-ASCII characters.
The Expat doc is unfortunately unclear on its *output* encoding, saying
the following (expat.h):
The characters are passed exactly as they were in the XML document
except that they will be encoded in UTF-8 or UTF-16.
The only relevant header I can see in SimGear is
3rdparty/expat/sg_expat_external.h, which has interesting stuff around
XML_UNICODE, however it doesn't seem to take position.
I fear that whether UTF-8 or UTF-16 is used for Expat's output (and thus
for what easyxml.cxx gives us) depends on how it was compiled. Let's
hope everyone has it compiled for UTF-8 output...
In commit 15525aab58, a layer with
lapse=0.0 was added to ISA_def (atmosphere model). However, the last
layer *must* have lapse == -1.0, otherwise the code in PT_vs_hpt()
doesn't know when it's on the last element of ISA_def, and does an
illegal memory access with (pp+1)->height. This is why -1.0 is the
default value for lapse ('l') in the ISA_layer constructor.
Fix: add the -1.0 terminator to the last element of ISA_def.
When the test:
if (i == activeTraffic.end() || (activeTraffic.empty()))
was true, the iterator named 'current' was uninitialized and later
dereferenced.
Fix:
- when the previously-mentioned test is true, return;
- initialize 'current' only when it is really needed (i.e., later and
after the test), and since we don't need it for iterating, make it
an FGTrafficRecord&.
- Don't ignore pushbackRoute="0".
- Stricter parsing with precise log messages when the input is
incorrect.
- Add missing includes in src/Airports/dynamicloader.cxx.
See <https://sourceforge.net/p/flightgear/mailman/message/35788373/> for
the discussion about this change.
Before SimGear commit a962c90b30f36575d01162b64471fa77473237a0,
SGPath::pathListSep was a char in static memory that was not necessarily
followed by '\0'. As a consequence, using &SGPath::pathListSep as a
C-style string could result in a string containing the correct separator
*plus* whatever followed in memory until the first null byte...
SimGear commit a962c90b30 changes this situation by making
SGPath::pathListSep an array of two const chars: the path list separator
followed by a '\0'.
This commit simply adapts FlightGear to this change, which fixes a
couple of bugs where the separator was used, mainly unneeded NavCache
rebuilds due to the "apt.dat", "fix.dat" and "nav.dat" properties in the
SQLite database containing the correct paths separated by a possibly
incorrect separator string (there was no alteration of the cache
contents as far as I can tell, since the db property is only used to
check if the lists of apt.dat, fix.dat and nav.dat files have changed).
