- added extra bindings
- reworked the view axis (usually bound to the hat); to move at a better rate.
- trim to elevator position. When selected this will remember the current position and when the joystick is centered it will apply this as the trim. Very useful for carrier approaches; and also it helps to do something that is much easier with loaded controls when you can feel the pressure being reduced by the operations of the trim switch
Checklists now support grouping by placing a group of checklists
under a <group> node.
e.g. /sim/checklists/group/checklist
The group can have a <name>, which is used by the checklist dialog
and can be used by other interfaces, such as the FG1000.
- 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
