This change automatically changes the view direction to look
at a <marker> if any is defined for a checklist item or tutorial
step.
Both the tutorial and checklist features support a <marker> element
which can be used by an aircraft developer to display a magenta
circle around an item of interest (typically a control in the
cockpit).
Previously aircraft developers had to add a <view> element to move
the viewpoint to look at the marker, while users of checklists had
to look for the marker manually.
Now:
- For checklists, pressing the "?" button on a checklist will pan the viewpoint
to the marker.
- For tutorials, if there is not a <view> element defined for a
tutorial step, the view will automatically pan to the marker.
Previously tutorials were generated from all checklists.
Now <auto-tutorial>false</auto-tutorial> can be set at
any level of the checklist heirarchy to disable generation
of tutorials for a given checklist, group, or for all
checklists.
Previously the front and side faces of random/OSM buildings
had identical texture coordinates. This resulted in the sides
of buildings texture mapping being squeezed or stretched.
This change generates a separate texture mapping for the sides
of the buildings.
Previously there was very limited texture variations
as a given texture index was used for both the wall
and ceiling. Now these can be specified separately,
allowing for more variation in both STG defined and
random buildings.
Requires simgear commit 053bda26a43314a91b01b08cd4617da82f7ab807
Replace random buildings with one using proper instancing.
Also implement more control over rendering of random buildings.
see README.scenery for details.
+ 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.
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.
For each add-on, the subtree of the global Property Tree starting at
/addons/by-id/ADDON_ID/addon-devel is reserved for the specific needs of
the add-on, where ADDON_ID stands for the add-on identifier.
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.
The '[addon=ADDON_ID]relative/path' syntax can be used in resource paths
handled by the SimGear ResourceManager, when one wants to target a file
from a particular add-on (see FG commit 8c82fca4 and following ones).
This commit documents this feature.
Note: when the resource path is prepared by Nasal code, prefer using
addons.Addon.resourcePath().
The property-rule configuration file was probably a bad example, because
I believe the path has to be specified inside a PropertyList file (so
far). It can thus be done with the '[addon=ADDON_ID]relative/path'
syntax so as to ensure the file is found by
flightgear::addons::ResourceProvider, however in this particular case,
addons.Addon.resourcePath() is probably not going to be very useful.
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.
With FlightGear commit 4d36082, the contents of /addon/authors (resp.
/addon/maintainers) in addon-metadata.xml files is now structured. It
may contain an arbitrary number of 'author' (resp. 'maintainer') child
nodes, each of which contains subnodes 'name', 'email' and 'url' ('name'
being mandatory, 'email' and 'url' being optional).
This commit updates Docs/README.add-ons regarding this change in the
syntax for addon-metadata.xml files, as well as the related
modifications to the add-on Nasal interface.
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.
