- Engines control now use the same axis methods as the flight controls; which allows for these to have an inverted checkbox.
- Change the axis combo boxes to instead show a popup dialog (much like the button config). This is better because the items can be grouped sensibly.
- Changed the way that the "all engines" controls work - the dialog binds these to a "engines/XXXX-all" for which there is a listener in controls.nas which propogates over all engines.
- Added extra bindings to both the buttons and the axis dialogs.
- moved the "None" button to the bottom and renamed it to the more comprehensible "Remove assignment"
The add-on framework now uses the following files in each add-on
directory:
- addon-config.xml (previously: config.xml)
- addon-main.nas (previously: main.nas)
This is consistent with the addon-metadata.xml file that is already part
of the interface between FG core and add-ons. The goal is to make it
clearer, when browsing an add-on directory, which files belong to the
"FG core <-> add-on" interface and which files belong to the add-on
proper. This will be beneficial also when more files are added to the
"FG core <-> add-on" interface, such as possibly addon-events.xml in the
future.
This change is incompatible, thus it is the right time to do *before*
2018.2.1 is out, especially considering that this upcoming release
already has incompatible changes in the add-on API, namely the
requirement of the addon-metadata.xml file and the type of the argument
passed to each add-on's main() function. We'll try harder not to break
compatibility in the add-on API once 2018.2.1 is out. For now, it is
still a good time to try to get the API as clean as possible.
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.
<message> tags can now contain sprintf() format
strings (%d, %.2f etc), with
<message-param>
<property>/some/prop</property>
</message-param>
used as the substitute value. Could be extended
in the future with perhaps Nasal evaluation?
Don't use the built-in SVG/rect parser, since this bypasses creating
coordinate / command properties which some Canvas users rely upon.
This reverts commit 57a2d21ddf.
- properly referencing the canvas namespace, so that the ND module can be separately included via io.include()
- moving the initialization of aircraft specific SVG elements into the navdisplay.styles file, and the corresponding Boeing/Airbus entries there (see initialize_elements())
Emesary is a simple and efficient class based interobject communcation system to allow decoupled disparate parts of a system to function together without knowing about each. It allows decoupling and removal of dependencies by using notifications to cause actions or to query values.
Emesary is all about decoupling and removing dependecies, and improving the structure of code. Using Emesary you can more easily define the what rather than the how. By using what is essential an event driven system it is easy to add or remove modules, and also for extra modules to be inserted that the rest of the aircraft knows nothing about (e.g. FGCamera or the Walker).
see: http://chateau-logic.com/content/emesary-nasal-implementation-flightgear
The AN/SPN-46 is an ACLS implementation using Emesary. ACLS is the Navy's version of ILS.
---------------------------------------------------------------------------
There is also support for transmitting messages over MP which allows models to communicate with each other in a decoupled method using notifications. What happens is that bridged messags simply arrive at the Receive method of recipients in other models on other running instances without the need to do anything special.
This links together the generic MFD and the NavDisplay; it allows a fairly easy method to add a Map page to an MFD device.
----------------------
See: http://wiki.flightgear.org/Canvas_MFD_Framework
----------------------
Instantiate parameters:
1. pfd_device (instance of PFD_Device)
2. instrument display ident (e.g. mfd-map, or mfd-map-left mfd-map-right for multiple displays) - used to map to the property tree
3. layer_id: main layer in the SVG
4. nd_group_ident : group (usually within the main layer) to place the NavDisplay
5. [optional] switches - used to connect the property tree to the nav display. see the canvas nav display.
To add a canvas nav display page simply do
me.some_page = PFD_NavDisplay.new(me.PFD,"Situation", "mpcd-sit", "ID", "jtids_main");
