In the thread at
<https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/87tw7sm5uw.fsf%40frougon.crabdance.com/#msg35673402>,
it was decided that alignLocaliserWithRunway() was a bad idea overall,
and should just be removed. The feature was already disabled by default
in recent releases via defaults.xml (since FlightGear 2017.1, precisely
FGData commit ea76305e42fd245e79a2b5bb569c8c61161f5721). Remove the code
entirely now.
The properties /sim/navdb/localizers/auto-align and
/sim/navdb/localizers/auto-align-threshold-deg have no effect anymore,
you may remove them from your configs if you somehow set them.
This goes with FGData commit 6dd9f6e8d962b00a1ccddc6af487c404cc935b92.
In case someone wanted to reuse the removed code, please consider
Szymon's proposed change at
<https://sourceforge.net/p/flightgear/flightgear/merge-requests/76/>,
which was:
,----
| Fixed bug in alignLocaliserWithRunway when building NavCacheDb
|
| The position of the localizer was converted to a distance from
| the displaced threshold, and then back to the posistion on the
| centerline, but the origin of the second computation was
| non-displaced threshold.
|
| --- a/src/Navaids/navdb.cxx
| +++ b/src/Navaids/navdb.cxx
| @@ -104,8 +104,8 @@
| void alignLocaliserWithRunway(FGRunway* rwy, const string& ident, SGGeod& pos, double& heading)
| {
| assert(rwy);
| - // find the distance from the threshold to the localizer
| - double dist = SGGeodesy::distanceM(pos, rwy->threshold());
| + // find the distance from the (non-displaced) threshold to the localizer
| + double dist = SGGeodesy::distanceM(pos, rwy->geod());
|
| // back project that distance along the runway center line
| SGGeod newPos = rwy->pointOnCenterline(dist);
`----
There was a couple of typos in the routine. This code will be used by the AI wake feature.
Also added a test for the matrix code to make sure they will be no regression.
External moments can now be specified in addition to external forces. This feature is needed for the AI wakes.
Headers clean up to reduce the amount of recompilation when modifying an header file.
Print an error message and exit if --{enable,disable}-enhanced-lighting
or --adf are used (those deprecated options will be removed in a future
version of FlightGear).
As spotted by Thorsten, reduce user annoyance by asking about FGData
when the built-in data is acceptable. (Advanced users can use the
launcher or other options to change FGdata as normal).
* Skip the gears when located over water. They will be skipped by the ground reactions anyway making the trim irrelevant.
* Ignore the ground bumpiness during the trim. The trim algorithm seems not to
be robust enough to handle that. This does not make much difference to the
converged solution anyway since the bumpiness is generally low.
* Fixed the WOW status for contacts over water (was 'false' is now 'true').
* All the gear/contact data are now properly reset when WOW==false. The reset
code is now common to all the case where WOW is false.
When the user specified an MP server without providing a port, the
launcher would pass a malformed command line, leading the the simulator
bailing out.
(Should go to the release branch)
Add defensive logic to ensure that a null pointer isn't dereferenced. This happened to me once or twice during a reinit (Location/Position In Air to the current position). It may be related to the model, but in any case the code needs to ensure that the static cast failure is handled correctly.
2017.2 in compatible mode was not compatible with 2017.1.x because the V1 packet had V2 properties in it; the protocol version and the new launchbar encoding - both of which should not be transmitted. This only affected 2017.1 because it discards the rest of the packet once an unknown property is encountered (to increase reliability).
Add support for per property encoding.
- encode_for_transmit - method that will convert from and to the packet for the value.
- decode_received - decodes received data
The options.cxx code is not ready to handle recursive use of --config
(for config files). Instead of failing in an ugly way, abort with a
clear error message in such situations. See discussion at
<https://sourceforge.net/p/flightgear/mailman/message/35838852/>.
Note: it *is* possible to load XML PropertyList files from config files,
so --config is not entirely "banned" from config files.
+ add missing include
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).
Some buggy *.groundnet.xml files (as KSEA currently on TS) define the
pushback hold point for some parking positions as a node on a runway.
In this case, this the pushback hold point for parking
'North_Cargo_Ramp', defined as node 5344 in
Airports/K/S/E/KSEA.groundnet.xml, which is defined twice (second error),
first as:
<node index="5344" lat="N47 27.774559" lon="W122 18.465257" isOnRunway="1" holdPointType="PushBack" />
and then as:
<node index="5344" lat="N47 27.725747" lon="W122 18.159649" isOnRunway="1" holdPointType="PushBack" />
(due to code in flightgear/src/Airports/dynamicloader.cxx, it should be
the second one that wins, which is not on a runway but on apron in the
north cargo area)
As a consequence, when this gate is selected for an AI aircraft, the
pushback route has only one node (since the pushback hold point is then
the closest point to itself supposedly on runway!), and the
corresponding FGTaxiRoute instance has an empty 'routes' member
variable, which FGTaxiRoute::next() doesn't handle gracefully
(segfault).
It may be that an additional check/change could be desirable in
FGTaxiRoute::next() in such a case (one node and obviously no route in
the FGTaxiRoute instance), however I'm not sure how Durk wants this case
to be handled, since FGTaxiRoute::next() seems to iterate on nodes.
This fixes the bug reported at:
https://forum.flightgear.org/viewtopic.php?p=308397#p308397 and
https://sourceforge.net/p/flightgear/mailman/message/35776552/
Thanks to yanfiz and wkitty42 for the report, and to gooneybird for
inspecting the groundnet file.
This is because FGTaxiNode::ident() is generally (always?) an empty
string for FGTaxiNode instances. This concerns the:
unreferenced groundnet node: ...
warning. Also remove one tiny use of boost.
We now show paths in ‘view command line’ and set them through the
standard mechanism. Re-ordering the paths also notifies the rest of
the system correctly.
Code and tests to demonstrate migrating of older auto-save files, with
blacklisting support to exclude properties. Disabled pending agreement
on the required blacklisting values.
Some pieces of code such as fgMainInit() and, by cascading effect,
fgInitHome(), were careful to return a meaningful value indicating
success or error, however the main() function in src/Main/bootstrap.cxx
ignored it royally so far.
main() now returns:
- EXIT_FAILURE if fgMainInit() or fgviewerMain() throws an exception;
- whatever said function returns otherwise.
- Rename fatalMessageBox() to fatalMessageBoxWithoutExit(). This should
prevent the kind of bug that prompted this set of changes: someone
calling fatalMessageBox(), assuming the program would stop at that
point, whereas in reality it did not.
- Add new function fatalMessageBoxThenExit(). This is not vital of
course, but allows one to spare one line here and there and to apply
the DRY principle for such fatal exits.
- Replace every existing call to fatalMessageBox() with one or the other
of the two new functions. Improve formatting along the way. This
fixes a few bugs of the kind explained above.
This reverts commit 9e6a3ebc6b ("Make
fatalMessageBox() end with std::abort() and declare it [[noreturn]]").
After reflexion, it seems better to let fatalMessageBox() return,
because there is existing code that appears to be relying on this aspect
to do some work after having called fatalMessageBox() (cf. main() in
bootstrap.cxx). Also, the way of exiting from fatalMessageBox() after
commit 9e6a3ebc6b (std::abort()) was probably too brutal for a
controlled exit---as opposed to a terminate handler.
Basically, this is because fatalMessageBox() is only safe to call from
the GUI thread, however it seems fg_terminate() can be called from any
thread (according to C++11 semantics). Additionally, fatalMessageBox()
typically requires some work to happen in the GUI thread (event loop) in
order to display something, but we can't realistically expect this while
running a terminate handler just before the program dies.
See messages around
<https://sourceforge.net/p/flightgear/mailman/message/35775803/> for a
discussion of this subject.
+ Minor header cleanup (<locale.h> replaced with <clocale>, etc.)
/sim/multiplay/protocol-version is either 1 or 2 and controls how packets are sent. V2 packets will only have the (motioninfo) basic properties visible to older clients.
New string encoding that is efficient.
Support short int encoding (pack a property and value into 4 bytes).
Allow properties to be transmitted using a different encoding to the property type in the tree.
Support scaled floats; most of the floats we transmit are small and thus can fit into a scaled short.
V2 protocol uses transmit so most properties are either scaled floats or short ints.
Allow the client to request a larger visibility range by setting /sim/multiplay/visibility-range-nm. This will transmit in the repurposed header field ReplyAddress - which has been renamed to RequestedRangeNm. This will require support from fgms to actually do anything.
Extra debugging options. The most useful (for aircraft developers) is the loopback bit, as this allows model multiplay testing without running two instances.
Update property /sim/multiplay/last-xmit-packet-len with the size of the packet transmitted
Debug level bits in property /sim/multiplay/debug-level
bit 1 - loopback (show your own model as an MP model)
bit 2 - dump outgoing packets
bit 3 - dump incoming packets
bit 4 - hexdump outgoing packets
/sim/multiplay/protocol-version is either 1 or 2 and controls how packets are sent. V2 packets will only have the (motioninfo) basic properties visible to older clients.
New string encoding that is efficient.
Support short int encoding (pack a property and value into 4 bytes).
Allow properties to be transmitted using a different encoding to the property type in the tree.
Support scaled floats; most of the floats we transmit are small and thus can fit into a scaled short.
V2 protocol uses transmit so most properties are either scaled floats or short ints.
Allow the client to request a larger visibility range by setting /sim/multiplay/visibility-range-nm. This will transmit in the repurposed header field ReplyAddress - which has been renamed to RequestedRangeNm. This will require support from fgms to actually do anything.
Extra debugging options. The most useful (for aircraft developers) is the loopback bit, as this allows model multiplay testing without running two instances.
Update property /sim/multiplay/last-xmit-packet-len with the size of the packet transmitted
Debug level bits in property /sim/multiplay/debug-level
bit 1 - loopback (show your own model as an MP model)
bit 2 - dump outgoing packets
bit 3 - dump incoming packets
bit 4 - hexdump outgoing packets
We probably need a warning for cross-aircraft paths, but leaving that
for a separate change since I’m worried it will warn on MP aircraft.
Maybe better checked in the Python scripts than in the app?
Compile a useful subset of FG as a shared library, and add two basic
uses of this to exercise some Flightplan / RoutePath / navaid
functions.
The test framework can/will be expanded incrementally from here, this
is just a starting point.
As part of this, add the ability to distinguish default vs explicit
airport selection via a new /sim/presets/airport-requested flag. This
enables us to more cleanly handle different combinations of startup,
especially the case where the user requests an airport but no runway
(wants auto selection), ensuring we don’t look for the default airport’s
runway (from location-presets.xml) in that case.
This renders sgGMTime obsolete, it will go away shortly. Thanks to
Ron H for help tracking this down and Richard Harrison for his
knowledge of Windows APIs in confirming the issue.
Read all values as floating point before applying a factor, then
convert to the target type (int, byte or short). Suggested and
implemented by Oliver Kroth.
As suggested by Chris, these are normalised and account for the logo
size after scaling, so 0.5 will centre, 1.0 is the right/bottom edge.
E.g. (in /sim/startup)
<splash-logo-x-norm>0.5</splash-logo-x-norm>
<splash-logo-y-norm>0.9</splash-logo-y-norm>
Many values will overlap with other text, so use with care!
When adding a scenery path in the built-in launcher, accept folders
containing any of the new directories populated by osm2city. Also try to
improve the message that is displayed when the sanity check conditions
for the added scenery path aren't met (cf. discussion around
<https://sourceforge.net/p/flightgear/mailman/message/35716946/>).
* Propeller required power now accounts for the engine tilt
* Fixed a division by zero in FGLGear::GetSteerNorm for non steerable gears
* Fixed a bug reported by Ron H. and Rebecca N. Palmer on the FG mailing list: the 'length' parameter passed to gethostbyaddr in FGFdmSocket was erroneous.
- Declare 'datTypeStr' and 'defaultDatFile' as public member variables
of NavDataCache ('defaultDatFile' is not *required* for this commit,
it just seems to make sense to treat both members the same way/keep
them together in the source code).
- New keys under "navigation data" in the JSON report: "fix.dat files"
and "nav.dat files".
The frequency field is always an integer, so reading it as a float to
convert it to int doesn't make sense. I've probably been confused by
field indices when I introduced this in commit a2bf424118.
This clarifies things, but shouldn't change the code behavior in any
way (unless with bogus nav.dat files, of course).
This allows using NavXP1100-formatted nav.dat from gateway.x-plane.com.
The skipped field types are:
14 Final approach path alignment point of an SBAS or GBAS approach path
15 GBAS differential ground station of a GLS
16 Landing threshold point or fictitious threshold point of an SBAS/GBAS
approach
We don't have SBAS/GBAS in Flightgear.
This change also includes duplicate detection for multiple nav.dat files
support.
