This concerns a single character inside a comment, so won't change the
behavior of the Nasal code in any way. Beside using the favored encoding
in FlightGear, this little change allows scripts/python/nasal_api_doc.py
(from the FlightGear repository) to work again without having to teach
it to ignore encoding errors nor to play at guessing the encoding of the
files it reads.
- Transfer encoding rewritten to handle negative numbers properly and fix scaling.
- Change the "no receive method" to be just a warning as it is unwise rather than
being wrong.
Emesary MP bridge fixes from Nikolai
OutgoingBridge:
- When transmitting queue, make sure transmitted
messages cannot remain in the queue when not completely emptied, and
thus be sent again, and eventually fill up the queue.
- Also allow smaller messages to sent even though there was not room for
a larger message (the removal of the 'break' command).
- To prevent coding the same message again with the 'break' removed,
store an already coded string that was rejected due to too little room
inside the message so when there is room for it, it was coded only
once.
- Stop recalculating MessageExpiryTime when there is no
room for a notification. If it has asked to expire after expire time,
let it expire.
IncomingBridge:
- Make sure listeners on emesary[x] properties are
removed when a mp aircraft is invalid, otherwise a hidden bridge will
sit in background and process same notifications a new bridge is
already processing.
- Change order of setting IncomingMessageIndex to ease
debugging in reciever.
- Since a bridge class can handle multiple emesary
properties on same aircraft, use a vector per aircraft to store the
bridge instances in, to make sure Remove can be called on all
instances listening to same aircraft.
Make listeners for MP properties only fire when properties changes.
Enherit the notification before propagating to avoid StartMessageIndex being shared and thereby messages can get held back.
Some improvements to logging.
When more than one message type being transmitted on the bridge only one of the types would be reliably received. Bug caused because the message index is per notification type (on MP bridge outgoing) but was being treated as per incoming bridge (rather than notification).
By separating out the bridges this could be used in the future to transmit Emesary properties at a different rate. It is one of the future possible methods to improve MP communications and dual/multi controls
A GeoEventNotification can be used to notify all other MP craft (that are connected to the bridge) of AI objects or ballistic items that are present on the local player's machine. For example tankers, dropped payloads, missiles, carriers.
Changes
- Fix transfer string encoding for bridge. If the string contained untransmittable characters the length was wrong. Change to use the valid characters from BinaryTransfer.
- Fix bug transferring negative numbers.
- Add method to notification to provide the type key to be used to decide if a non distinct message should be added to the queue; rather than relying on the simple type.ident. This allows multiple notifications of the same type to be non distinct but also be transmitted
- Allow the maximum size of the mp string to be defined per bridge; rather than a system wide value. This allows the bridges to have their size tuned to match expected requirements; for example a bridge that is transmitting GeoEventNotification may need a lot more space than a bridge that is transmitting property sync notifications.
- Improve error message when out of space (due to the maximum string length)
- add trace option to bridges to aid debugging of transmitted values. This will produce verbose output.
- Add UniqueIndex to GeoEventNotification; to allow for multiple non-distinct notifications to be transmitted concurrently. This overrides the GetBridgeMessageNotificationTypeKey to include the UniqueIndex
The primary goal of this work is to provide a alternative to multiplayer property transmission, one that is more efficient and event driven. By using notifications in the model bindings these control messages can be bridged and do not require extra code to implement dual controls.
Using this alternative permits the modeller much greater control of which properties are transmitted, how these are encoded, and how often the updates are needed.
Please remember that this is a use case for Emesary, it is not all that Emesary can provide and there are still many other uses for the event driven object oriented system that Emesary provides.
Briefly the changes are:
- New PropertySyncNotificationBase to permit property transfer between ownship and MP versions using notifications instead of the pre-defined MP messages. This gives a much more flexible way to seutp multiplayer property transfer - and can probably support more properties because of the more efficient packing. There is a corresponding parameter (/sim/multiplay/transmit-only-generics) that will only transmit the bare minimum of parameters; making more space for notifications.
- new AircraftControlNotification to allow for animation bindings in the model, these notifications can be easily bridged over MP thus adding a simple method to implement dual controls.
- more efficient packing of encoded notifications over MP saving roughly 30% (by using a much larger encoding space and also changing to use fixed length encoding). This breaks compatibility with previous MP bridges, however at this time I don't think anything is using the current code.
There can be different types of PropertySyncNotification (with unique ID's) sent at a different schedule (so you could have a 10 second update of very slow moving items). However bear in mind that the messages have a lifetime of 10 seconds to ensure receipt - so to optimise space would require > 15 seconds to make much difference, and that is very slow moving.
