Change /sim/multiplay/transmit-only-generics to /sim/multiplay/transmit-filter-property-base, which can be 1 to transmit only generics, or a number greater than 1 to indicate the start index to transmit (e.g. 12000 for new emesary mp bridge properties)
ConfigStore for storing and retrieving config settings (needs XML import/export)
Header display with 4 different header fields (all configurable)
Publisher for ADC and FMS.
The addons.Addon instance (ghost) is much more interesting than its base
path. The base path is immediately accessible from the addons.Addon
instance using its 'basePath' attribute. The addons.Addon instance
allows main() to easily access essentially all of the add-on metadata,
including the add-on identifier, which makes it possible to write
main.nas without hardcoding the add-on id at all.
This is an incompatible change of course, so better do it now than
later.
- Add new Emesary notification type for NAV/COM data
- Create Update/Publish interfaces using Emesary from properties
- Use interfaces to drive updates to EIS and NAV/COM frequencies
- Change the PageGroupController to a "proper" MFD page
- DTO MapStructure layer to provide a DTO line to a lat/lon
- Support for scrolling lists in the PFD/GroupElement
- Support MAP (NavigationMap) and ENGINE (EIS) soft-keys from other pages.
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
Also:
- use the namespace __addon[ADDON_ID]__ when loading an add-on's
main.nas file (previously, the namespace used was __addon[i]__ where
i is 0 for the first registered add-on, 1 for the second one, etc.);
- use logprint() instead of printlog(), because the former writes a
more helpful source file and line number for the log call in
fgfs.log (i.e., not always src/Scripting/NasalSys.cxx...);
- remove the listener once it has been fired;
- add documentation in Docs/README.add-ons.
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
Allow a MFD to be controlled via Emesary notifications (notifications.PFDEventNotification);
Notification needs to be constructed with the following parameters;
1 - MFD designation (text; name of MFD)
2 - MFD identity (int, id of the MFD within the model). Default 1; same as used when creating the MFD
3 - Event type (PFDEventNotification.SoftKeyPushed, notifications.PFDEventNotification.ChangeMenuText
4 - Event parameter.
a) for PFDEventNotification.SoftKeyPushed an int identifying the button
b) for notifications.PFDEventNotification.ChangeMenuText a hash array containing the menu ID and the new text (e.g. [{ Id: 1, Text: "NNN"}])
Method obj.PFD.RegisterWithEmesary(emesary.GlobalTransmitter) need to be called to connect the MFD to a transmitter
Change fonts; make use of the new feature to allow fonts to be specified using property from dialog xml.
Ensure that all fonts are defined within the style.
Manage updates when a value has changed more than a predetermined amount. This makes updating displays (e.g. canvas), or performing actions based on a property (or value in a hash) changing by more than the preset amount.
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.
