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
Document new fields:
authors
maintainers
license/{designation,file,url}
url/{home-page,download,support,code-repository}
tags
Add precisions concerning how fields are parsed, a bit more structure,
etc.
Mailing-list discussion:
around https://sourceforge.net/p/flightgear/mailman/message/36155660/
The explicit typing shouldn't change anything for the parsing code in
flightgear/src/Add-ons/AddonManager.cxx, because for each field, this
code knows the correct type and explicitly asks for it (and only once),
but external code might include addon-metadata.xml in some prop tree,
and then the explicit typing is likely to give better results.
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.
The instruments can now be enabled easily for testing purposes:
simply toggle their "serviceable" properties:
/instrumentation/mk-viii/serviceable or
/instrumentation/tcas/serviceable
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
