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.
