Only the selected channel will now be used for PTT; however the bindings still selected the appropriate channel prior to setting PTT.
This provides a compatible solution that can also easily be bound to the (joystick) controls.
PTT now in
/controls/radios/comm-ptt as an int; non zero indicates which comm radio to use
/comm-radio-selected is the default comm channel to use. This should usually be the same as will be set by PTT into /controls/radios/comm-ptt
NOTE: that PTT will switch the FG comm inbound and outbound frequency to whichever radio was PTT'd.
+ After discussion with Henning:
- orig_setlistener() and orig_maketimer() were not intended to be
public -> prefix the function names with an underscore;
- clear the add-on's lists of tracked listeners and timers in
remove() (load() does that too, but it's a bit late).
+ Little rewording in Docs/README.add-ons.
Without this it will cause a nil dereference resulting in
Nasal runtime error: non-objects have no members
at D:/Program Files/FlightGear 2018.2.2/data/Nasal/canvas/map/WPT.lcontroller, line 57
called from: D:/Program Files/FlightGear 2018.2.2/data/Nasal/canvas/map/WPT.lcontroller, line 79
called from: D:/Program Files/FlightGear 2018.2.2/data/Nasal/canvas/MapStructure.nas, line 1088
called from: D:/Program Files/FlightGear 2018.2.2/data/Nasal/geo.nas, line 384
called from: D:/Program Files/FlightGear 2018.2.2/data/Nasal/canvas/MapStructure.nas, line 1051
called from: D:/Program Files/FlightGear 2018.2.2/data/Nasal/canvas/MapStructure.nas, line 1059
called from: D:/Program Files/FlightGear 2018.2.2/data/Nasal/canvas/map/WPT.lcontroller, line 26
called from: D:/Program Files/FlightGear 2018.2.2/data/Nasal/globals.nas, line 119
Trigger sets /controls/armament/trigger - typically for a gun, but can be used (model side) to launch anything
Pick sets /controls/armament/pickle - typically to release something (e.g. missiles), but could be bound model side to act as a trigger.
Definitely problems in aar.nas, seaport.nas; as these were hanging off a fdm-initialized.
The others have timers that are started from a listener and as such are more suited to use maketimer rather than settimer
The modules that use the loopid technique are probably fine, but these are also more suited (and easier to understand) using a maketimer
- modify to work with JSBSim aircraft when reloading the fuel based on the payload (e.g. external tanks selected)
- add property sim/gui/dialogs/payload-reload that when set will cause the payload dialog to reload (to support a second dialog that modifies the payload)
- fix so that the window retains its position (close handler) and window Z order when reloading.
- 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.
