the current timestamp used in mp protocol and in AImultiplayer is not a good one:
it can pause, or even change speed if we change warp value.
we want it to be used for network protocol lag and jitter estimation, and
a time flowing linearly on both side is needed, here's a first introduction
of this timestamp relates to real elapsed time.
here it's initialised to the system clock, then follow the monotonic clock.
in future improvement, it will allow time synchronisation betwen mp players,
to have a very good close formation flight experience.
- /sim/multiplay/transmit-filter-property-base can now filter based on property index; or have the previous mode of transmitting only generics by setting to 1.
- Move emesary MP bridge property base index to 12000 - to allow filtering of all except these (to reduce packet size).
- The Emesary MP bridge can use any string property; however it seems sensible to separate the properties out into a distinct block.
- There is a now a type property for each bridge. This is to allow the bridge to identify its type based on what it can transfer based on function. This will allow rapid filtering of unrequired notifications within the bridge (NYI)
Change fgcommand to take an optional property tree root element.
This fixes the animation bindings to use the defined property tree root - to support multiplayer (or other) model that can bind to the correct part of the property tree.
Requires a corresponding fix in sg to allow the command methods to take an optional root parameter.
What this means is that when inside someone else's multiplayer model (e.g. backseat, or co-pilot), the multipalyer (AI) model will correctly modify properties inside the correct part of the property tree inside (/ai), rather than modifying the properties inside the same part of the tree as the non-ai model.
This means that a properly setup model will operate within it's own space in the property tree; and permit more generic multiplayer code to be written.
This is probably responsible for some of the pollution of the root property tree with MP aircraft properties.
Ground-bit is set manually (via the transponder GND knob position) or
automatically using a property referenced in instrumentation.xml.
Aircraft will only transmit these new properties when using the
multiplayer v2 protocol.
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
/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
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
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.
and using speed up time to allow a fine displayed predicted position
when time accelerated (no more jumping planes accelerated using the mp patch)
tell me if it's not the good pace to do such things ;)
Also adapt MP and traffic module to enable the AI module when required.
This makes /sim/ai/enabled an internal property: it can default to false
(in future), and can be enabled as soon as any user-level feature (traffic,
MP, local weather, ...) requires it.
