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.
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.
simgear::ResourceProxy has been renamed to
simgear::EmbeddedResourceProxy in SimGear commit
2200fad30ebfd68cefd461d5443b8612621b4643[1]. Adapt
Docs/README.embedded-resources accordingly.
[1] This was done in order to avoid confusion with the unrelated classes
simgear::ResourceProvider and simgear::ResourceManager.
This document (Docs/README.embedded-resources) explains how to use the
embedded resources system and presents SimGear's CharArrayStream and
ZlibStream families of classes, as well as the ResourceProxy class.
<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?
Forum thread: http://forum.flightgear.org/viewtopic.php?f=72&t=25119
The documentation compiler will iterate over all Aircraft and generate
LaTeX files for each aircraft. It will then compile them to a pdf. Please
refer to the forum thread for an example of such a pdf file.
It will also generate a separate pdf file just for the checklists.
Currently, the compiler uses the checklist files and additional files in a
Docs/ subdirectory of the aircraft.
To use this script, you need python > 2.7 and a recent version of pdflatex
with hyperref support installed.
This is a sample for the new httpd and it's JSON capability.
Need to run fgfs with --httpd=<YourHttpPort> and point your browser
at http://localhost:<YourHttpPort>/gui/radio.html
This is a document Hooray and I have been working on for a while. Its
focused on the internals, and very likely in a messy state and very
weird, but hopefully some others will want to contribute. There's some
empty sections, random "test" code snippets, and lots of \todos in
there. Also, lines aren't wrapped at all, but it does generate a nice
PDF that contains, I hope, something that will be useful.
The PDF was rendered by writeLaTeX.com
All tree texture sheets now contain 4 different texture sets for
different conditions. See Docs/README.materials for details.
Also retire the -summer and -winter variants of tree textures, which
are now redundant.
Checklists may now be split into individual sections made up
of <pages> containing the <item> tags. Each page is displayed
individually with Previous/Next buttons to allow navigation.
Checklists items also support <marker> tags. These display
a marker when a ? button is pressed next to the checklist item.
The format is identical to that of the tutorial system.
Checklist items now support a <condition> element that evaluates
when the checklist item is complete, and is used to provide color
coding in the checklist dialog.
Switch c172p and concorde glass effects to the new effect.
Docs/model-combined.eff/: Updated transparent effect template.
From now on Effects/model-combined should not be inherited from directly.
Use either Effects/model-combined-deferred
or Effects/model-combined-transparent
Signed-off-by: Emilian Huminiuc <emilianh@gmail.com>
model-combined & model-combined-deferred effects: improve Rembrandt behaviour, and provide better effects for transparent
surfaces under Rembrandt.
This change breaks current effects using normalmaps when inheriting from model-combined-deferred under
Rembrandt.
Aircraft developers please change the technique numbers in the "normalmap include" part of your effects file from
<technique n="8"> to <technique n="7"> (again, only if inheriting from model-combined-deferred, and using normalmaps)
Effects inheriting from model-combined do not neeed any adaptation.
Sorry for the nuisance caused by this change.
Signed-off-by: Emilian Huminiuc <emilianh@gmail.com>
Effects/model-combined.eff fix techniques numbering. Make active under rembrandt too. add model-combined-deferred as a stub for now for specific
Rembrandt use.
Users of model-combined with normalmaps should change the technique number to 9, and duplicate that entry for technique 8.
Fix some longstanding png warnings. Provide null_reflectdir.png for model-combined
This should fix part of bug #726
Signed-off-by: Emilian Huminiuc <emilianh@gmail.com>
Provide templates for various aircraft components or complete aircraft
types. Better to have this stuff available/adaptable than hard-coded
somewhere inside fgfs.
- Replaced link to getstarted.html with pdf version
- Updated mailing list info
- Added link to FG forum
- Added logo & GPL info
- Corrected link to (missing) css
Thanks to Toshi for reporting dead links and other issues.
fixes for a couple of issues, some improved textures/cloud model changes,
smooth instead of hard visibility transitions, updated documentation.
Also removed 'Test' entries from the menu.
(ThorstenB: Also cleaned-up Docs/ folder, moving local weather
documentation images to sub folder).
