For fgValidatePath(), I don't see any use because it should be called after path resolution IMO (fgValidatePath() validates paths, it is not a path resolver).
resolve_maybe_aircraft_path() already works with add-ons by using the syntax documented in
README.add-ons, cf. section
Resources under the add-on directory:
- Code: Select all
[addon=ADDON_ID]path/relative/to/the/addon/directory
Such resource paths are precisely what
- Code: Select all
addon.resourcePath("path/relative/to/the/addon/directory")
produces, when
addon is an addons.Addon instance (i.e., an “add-on ghost”). BTW, this is what allows the Oscilloscope add-on to display its picture, and property-rule configuration files to be loaded from inside an add-on dir (as used in Slawek's experimental addonized version of FGCamera).
For the same reason, the 'loadxml' FGCommand and therefore io.read_properties() also work with add-on resource paths:
- Code: Select all
io.read_properties(
"[addon=org.flightgear.addons.FooBarAddon]some/subdir/test.xml",
props.getNode("XXXtest", 1));
Edit: in such a case however, I'd rather recommend this:
- Code: Select all
io.read_properties(
addon.basePath ~ "/some/subdir/test.xml",
props.getNode("XXXtest", 1));
because this way, FG doesn't have to crawl through all of SimGear's ResourceManager instances in order to resolve the path. addon.basePath is readily available, so this method should be faster. This recommendation would apply to every place where you have addon.basePath accessible (i.e., potentially all Nasal add-on code) and you are calling an API[1] that accepts absolute paths.
Regarding files to be written, I mostly agree, but maybe rather $FG_HOME/Export/addons/ADDON_ID in order to keep add-ons together, and separate from other stuff directly in $FG_HOME/Export.
[1] Nasal function, FGCommand...