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.
Make a single Cmake value to expose the build type to code, and use
this to default a run-time ‘developer-mode’ property, which can be
over-ridden from the command line.
Use this to drive the different warning levels. Policies subject to
review, especially whether nightly builds should default to
developer mode or not.
Uses TTF fonts, and displays more information textually including
the application version and current aircraft.
Also rename FGRenderer::splashinit to preinit, as was suggested
a long time ago.
On Mac it was visible as random strings displayed in the route manager
dialog for selected SIDs and STARs.
Depends on a SimGear change which introduces SGStringValueMethods.
1. Add support for scaled floats; most of the floats we transmit are small and thus can fit into a scaled short.
2. Change most properties to use scaled floats.
Support for short int encoded values (32 bits with 16 bit for ID and 16 bits for value)
Added extra debugging options
1. 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
2. Update property (/simwith packet
- configurable debug (loopback, packet trace (in,out), packet dump)
- prevent properties from being visible to V1 clients - to ensure reliable compatibility, with just the basic position message being processed. This allows more changes to the V2 protocol whilst giving basic V1 support
- add debug
Based on the comments in the list I think it is better to keep the type that was originally provided as a reference, take the address of it, and store that in a ref_ptr.
Possibly the problem was never compiler related rather OSG related; I'm using 3.5.x and it appears that there are better built in type conversions compared to the target version of 3.2 that we are currently using.
Whilst debugging I had a cannot increment nextIt - because it was at end(). No idea if this could ever happen in flight but it still seems sensible to protect against it.
Use pointers to allow compilation on Linux/Mac until this is fixed properly as OSG elements should always be accessed via the reference counting mechanism.
Change to use pointers rather than osg::ref_ptr<osg::Group> - based on http://andesengineering.com/OSG_ProducerArticles/RefPointers/RefPointers I think that it is not possible that the scenegraph can be modified between the visitor and the modify, provided that the methods are called after each other like this:
ReplaceStaticTextureVisitor visitor(name, new_texture);
branch->accept(visitor);
visitor.modify_groups();
return visitor.getPlacements();
The visitor would modify the scenegraph during the traversal by inserting groups; this is not valid when using vectors, and MSVC2015 debug RTL throws an exception when this happens.
The fix is to simply make a list of the textures that need to be modified and modify once the scenegraph traversal has finished.
This change is the logical counterpart of SimGear's change from commit
79f869a7f32910197be72b21f6489fbbba02c836 that moved the following files
from simgear/misc to simgear/io/iostreams:
gzcontainerfile.cxx
gzcontainerfile.hxx
gzfstream.cxx (formerly zfstream.cxx)
gzfstream.hxx (formerly zfstream.hxx)
sgstream.cxx
sgstream.hxx
sgstream_test.cxx
This is where the ID and the 16 bit value are transitted in the ID field; with no data field. The ID is in the highword - and this is detected by the client and processed as |ID |VALU|
/sim/multiplay/protocol-version is either 1 or 2
The properties defined in multiplaymgr define which version they are related to; however if these are in a more recent protocol than selected they will be transmitted in the selected protocol version.
The id property list now defines a "transmit as" - however this is not yet implemented.
This commit is intended to be a WIP towards changes for 2017.1 that will ensure any future protocol changes are compatible with this version (so this 2017.1 would be able to see a protocl V3 FG if one ever existed), key to this is to stop processing the property list as soon as an unknown ID is encountered.
This moves certain properties into a second part of the buffer that isn't visible to the first with the intention of making a backwards compatible MP protocol that can have more efficient encoding in a second part that is after MsgLen.
Unfortunately this doesn't work because the code ensures that MsgLen in the header matches the received byte count.
Each argument creates another log file, in the directory named. Symbolic
value ‘desktop’ creates logs on the user’s desktop.
Needs corresponding SimGear commit to build
The mirror protocol now sends the position for internal as well as
leaf nodes, and the group uses this data to sort when no explicit
Z-indices exist. This gets the extra-500 much closer to working!
For unknown reasons this seems to alleviate the word-wrap / min-height
bug on Windows. Committing so we can test and verify this is really
the case before the next release.
Requires FGData commit: 0565eaab10a5d466cd485766b17d1870936a0a57
(which actually renames the file).
Also disables the preferences-load command since I don’t believe it
would actually be safe to reload the defaults without doing a simulator
reset (aircraft -set.xml values would be overwritten, for example)
As discussed on the devel list, only require the major+minor versions
of FG+SG+data to match by default. If we encounter a situation on
a release branch where stronger checks are needed, it’s easy to
restore.
Essentially, adapt two places where options.xml was supposed to be found
in $FG_ROOT (in one of these, the comment was already incorrect way
before the recent change moving options.xml out of FGData).
$FG_INSTALL_PREFIX represents the FlightGear installation prefix, such
as /usr, /usr/local or /opt/FlightGear on Unix systems. Copying the
--help output and translated strings there avoids having to write to
$FG_ROOT when 'make install' (or some OS-dependent equivalent) is run
from the FlightGear build directory---that would be ugly when $FG_ROOT
points to the FGData Git repository.
In FGLocale::FGLocale(), Translations/locale.xml is loaded using
readProperties() and fatalMessageBox() (in case an error is
encountered). Note that it couldn't be loaded via fgLoadProps() in the
current state, because this function relies on guiErrorMessage() when an
error is encountered, which calls mkDialog(), which itself does
globals->get_subsystem("gui"). This last call can't be done from
FGGlobals' constructor---where the 'globals' pointer is still
NULL---hence the need for a different mechanism not relying on
FGGlobals.
For consistency, and also because it provides a better user experience[1],
load options.xml using the same method instead of with fgLoadProps().
[1] I.e., in case of an error, the user gets to see a graphical popup
window with an explanatory message before FG exits, assuming he is
either on Windows, or on Mac, or has Qt support built in FG, as
opposed to only an SG_LOG() call [because when options.xml is
loaded, guiErrorMessage() used by fgLoadProps() can't use the 'gui'
subsystem].
- Add an optional argument to flightgear::initApp(): doInitQSettings.
This argument defaults to true, preserving initApp()'s behavior in
this respect. If this argument is set to false, FGGlobals doesn't have
to be initialized.
- New function flightgear::initQSettings(), called by
flightgear::initApp() when its 'doInitQSettings' argument is true.
This allows initializing the QSettings exactly when it is needed.
- New function flightgear::checkKeyboardModifiersForSettingFGRoot().
The code it contains used to be run from initApp(), which is
undesirable because:
1) initApp() is not only called at FG initialization (fgMainInit()),
but also from QtMessageBox(), from QtFileDialog::exec() and twice
from Options::setupRoot(). However, checking the Alt and Shift
modifiers to set 'fg-root' in QSettings to the special value
"!ask" only makes sense in fgMainInit(), not in these other
places.
2) This code relies on the QSettings to be set up, and therefore on
FGGlobals. Thus, freeing initApp() of its dependency on FGGlobals
requires splitting this keyboard modifiers checking code out of
initApp().
This is likely to fix the problem preventing startup on Windows when the
username contains non-ASCII characters (cf.
<https://forum.flightgear.org/viewtopic.php?f=22&t=31320>). Thanks to
Headhunter76 for the useful report and to wkitty42 for doing the liaison
officer. ;-)
I can't actually test this, because I don't have Windows. Windows users
should report whether this works for them.
There is a Flightgear property called /sim/hitches/winch/automatic-release-angle-deg that can be used to simulate a safety feature built into modern gliders. If the cable angle gets too great during a winch launch, the hook will automatically release the cable. This usually happens when the glider gets almost on top of the winch at the top of the launch without releasing the cable.
Unfortunately winch launching has two separate implementations, one in Nasal for JSBSim, and another one in C++ for YASIM. The YASIM one does not implement this property so I wrote a patch to add this.
Previously timer objects defaulted to using wall-clock (real) dt which
does not reflect pause/speed-up. Keep this as the default for
compatibility but make it possible to request simulated time.
Special case handling when recently removed properties are re-added;
when this happens simply send a value change since it's much cheaper
over the wire and for the receiver. Poorly designed Canvas code does
this frequently (eg, every update)
- Handle file I/O and parsing errors. This allows current
<http://gateway.x-plane.com/navaids/LatestNavFix.zip> to be loaded
instead of failing in an endless loop.
Read the fields of a record with std::getline() followed by
simgear::strutils::split(), itself followed by calls to std::stoi(),
std::stof() and std::stod(). Stream extraction (>>) isn't very good
here, because it can read for instance an int *and* a float from the
string "3.14", i.e. extract 3 followed by 0.14 (thus falsifying the
number of fields found...).
Check the number of fields (not 100 % reliable since the last field,
the navaid name, typically contains spaces---but we can detect
some situations where the number of fields is definitely too low).
- Fix line numbering (sgstream.cxx's skipcomment() isn't fit for this
purpose, because it can gobble any number of lines without the line
number being increased).
- Don't use a hardcoded number of lines for the nav.dat loading
percentage indicator; rely on sg_gzifstream::approxOffset() instead.
- Make navDBInit() and loadCarrierNav() throw an sg_io_exception upon
I/O errors (not for parsing errors that only affect a record). They
don't return a bool anymore (which wasn't checked by their only
caller, anyway).
- Use the 'rowCode' variable name instead of 'rawType' for consistency
with the *.dat specs.
- Small change in tests: (elev_ft < 0.01) replaced with (elev_ft <= 0).
Doesn't change the behavior, since 'elev_ft' is an int. Can be
reverted if someone really prefers the float comparison, I don't mind
that much about it.
- Add missing headers and a few comments.
This commit does not change the contents added to the NavCache with
FlightGear's current $FG_ROOT/Navaids/nav.dat.gz, except for 4 bogus
navaids which are not added anymore (at LIBV, OPJA, RCFN and RCYU): see
<https://sourceforge.net/p/flightgear/mailman/message/35526617/>. They
are instead properly reported as coming from invalid nav.dat lines.
Since the Save function can be triggered from Nasal with an arbitrary
path, we must check this path before overwriting the file.
(also add a missing include that is directly needed for this commit)
Use a recursive listener to expose a property tree via a WebSocket.
Currently using a JSON-based encoding, will likely change to binary so
please don’t write code using this interface until the encoding
is stable and documented!
As discussed on the mailing list, make this more consistent with JSBsim.
We could still define common locations for these values as well, but
waiting on positive answer to that discussion on the ML.
