/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.
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.
