Board index FlightGear Development New features

New Feature: Addon - "API"

Discussion and requests for new features. Please note that FlightGear developers are volunteers and may or may not be able to consider these requests.

Re: New Feature: Addon - "API"

Postby slawekmikula » Mon Oct 02, 2017 5:23 pm

Torsten wrote in Tue Jul 18, 2017 9:47 pm:
Hooray wrote in Tue Jul 18, 2017 8:34 pm:I think that FGCamera would make for an excellent "testbed" to see how complete the current framework really is.

Challenge accepted. What's the current license state of FGCamera? I found a statement here in the forum that it is "license free". I need it to be GPL (compatible).

Hi all, maybe i'll add something to discussion. I've been learning nasal/propertytree and best way for me is to learn by working on something useful. I've taken fgcamera latest code (201706) from fgcamera thread: viewtopic.php?f=6&t=21685&start=135#p314678

I've ported most of the code to addon api but with the newest code Anders is using property rules (viewtopic.php?f=6&t=21685&start=135#p314678). Right now they cannot be loaded. Error comes from the flightgear code autopilotgroup.cxx:

Code: Select all
void FGXMLAutopilotGroup::addAutopilotFromFile( const std::string& name,
                                                SGPropertyNode_ptr apNode,
                                                const char* path )
{
  SGPath config = globals->resolve_maybe_aircraft_path(path);


respective code for loading property rule in fgcamera config.xml is:

Code: Select all
<systems>
         <property-rule n="150">
            <path>/Nasal/fgcamera/property-rules/fgcamera.xml</path>
         </property-rule>


When fgcamera was transferred directly to fg-root there was no problem. Problem with finding it is in options.cxx where we load addon:

Code: Select all
p->propertyFiles.push_back(config_xml);
        globals->append_aircraft_path(path);
        fgGetNode("addons",true)
          ->addChild("addon")
          ->getNode("path",true)
          ->setStringValue(path.str());


This code in globals put paths into :

Code: Select all
fg_aircraft_dirs.push_back(dirPath.realpath());
extra_read_allowed_paths.push_back(dirPath.realpath());


but autopilot when loading property rule is searching for path with: resolve_maybe_aircraft_path(path) and in simgear it is looking in ResourceManager.cxx in:
Code: Select all
SGPath ResourceManager::findPath(const std::string& aResource, SGPath aContext)
for code in main sgpath and in providers.

Soo for my understanding one should somehow implement loading property rules (files) from addon directories in such way that this could be possible. This can be done either with adding addon path to base paths or to implement another resource provider as in globals.cxx for AircraftResourceProvider ? All solutions are waay beyond my grade and I would like to ask for some solution/proposition to this issue.

I think, when this is implemented fgcamera should be working as addon.
slawekmikula
 
Posts: 128
Joined: Sun Feb 19, 2017 10:31 am

Re: New Feature: Addon - "API"

Postby Hooray » Mon Oct 02, 2017 6:42 pm

Just briefly, and sorry if I am missing something, but why can't you simply use a relative path without the leading slash ?

Also, see Torsten's original comments:

Subject: Spoken ATC
Torsten wrote:back on topic: the new addon "API" lets you add a config.xml to override the settings in defaults.xml.
That easily allows to
  • Override key bindings (as in the spoken atc addon)
  • Add or override autopilots and property rules
  • And of course introduce XML-statemachines
Unless your really want to add/change/remove those at runtime, this should cater for most use cases.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: New Feature: Addon - "API"

Postby slawekmikula » Tue Oct 03, 2017 7:47 am

Hooray wrote in Mon Oct 02, 2017 6:42 pm:Just briefly, and sorry if I am missing something, but why can't you simply use a relative path without the leading slash ?


That was my first attempt :) but nothing works:

Code: Select all
Cannot find property-rule configuration file '/Nasal/fgcamera/property-rules/RND/RND-main.xml'
Cannot find property-rule configuration file 'property-rules/fgcamera.xml'.
Cannot find property-rule configuration file './property-rules/fgcamera.xml'.


This is not xml include directive, but only declaration for autopilot/property-rule execution code.

From my knowledge problem lies with addon registration "as an airplane". In addon option we have

Code: Select all
if( config_xml.exists() ) {
        p->propertyFiles.push_back(config_xml);
        globals->append_aircraft_path(path);
        fgGetNode("addons",true)
          ->addChild("addon")
          ->getNode("path",true)
          ->setStringValue(path.str());
    }


but in reality when "aircraft" is registered there is new AircraftResourceProvider (from globals.cxx) inserted into simgear ResourceProvider and it looks for (/sim/aircraft-dir) as a resource . This way autopilot code (responsible for property-rules) can find xml definition in "aircraft" folder. In addon there is no such implementation.

Of course I may implement workaround/hack in order to get things going but best thing (IMHO) is to ask if this addon implementation is OK and maybe I might get something wrong from the code :)

My best guess will be to implement AddonResourceProvider and do it analogous to AircraftResourceProvider to look into /addons/addon[x]/path for resources.
slawekmikula
 
Posts: 128
Joined: Sun Feb 19, 2017 10:31 am

Re: New Feature: Addon - "API"

Postby Hooray » Tue Oct 03, 2017 8:50 am

It's good that you have been looking at the underlying C++ code - I am only a little surprised because Torsten stated in several places that this should "just work", but I have never tried this personally - mainly because I have little use for pre-defined and static autopilot or property rule configurations.

I guess it would be best to wait until Torsten can take a look - maybe it's just a misconception, but also because he said that he was interested in porting fgcamera to become an addon eventually.

If there is an issue, I do agree that it would be good to get this fixed - some of the more complex addons (think fgcamera or Bombable) could actually have a positive influence on the evolution of the addon framework - but for that, we need to review what's needed and incrementally add missing bits.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: New Feature: Addon - "API"

Postby slawekmikula » Tue Oct 03, 2017 9:55 pm

Ok, i've found what was wrong. Simply (right now, but i think this should be corrected/changed) relative paths for resources in addon directory have to be prepended with "/Aircraft" text. e.g.

Code: Select all
<systems>
         <property-rule n="150">
            <path>/Aircraft/property-rules/fgcamera.xml</path>
         </property-rule>


Fgcamera addon is right now published (see other thread). I'm sending info to devel list.
slawekmikula
 
Posts: 128
Joined: Sun Feb 19, 2017 10:31 am

Re: New Feature: Addon - "API"

Postby Hooray » Tue Oct 03, 2017 9:59 pm

Your analysis is still spot on, I ran into a similar issue when I tried to load other addon-specific XML resources from the addon directory - e.g. GUI dialogs.
So good job there. It would make sense to grow a list of such issues and file corresponding feature requests.
From a coding standpoint this is trivial to fix, like you say - so even if Torsten is too busy, it should be possible to come up with patches to get this reviewed/committed - which is something that would undoubtedly benefit all addons.

EDIT: To see for yourself, try to load/show an addon-specific dialog from your addon directory using gui.nas - e.g. by copying exit.xml from $FG_ROOT/gui/dialogs, changing its name to "exit2.xml" and editing its name to match that.

I ended up using this:

Code: Select all
var dlg = gui.Dialog.new("/sim/gui/dialogs/exit2/dialog", addon_root~"/exit2.xml");
dlg.open();
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: New Feature: Addon - "API"

Postby slawekmikula » Tue Oct 03, 2017 10:08 pm

Hooray wrote in Tue Oct 03, 2017 9:59 pm:I ended up using this:

Code: Select all
var dlg = gui.Dialog.new("/sim/gui/dialogs/exit2/dialog", addon_root~"/exit2.xml");
dlg.open();


Yes, this is doable. What was/is wrong right now that in pure xml (config.xml) there is reference to property-rule paths. And this was main problem. Nasal can cope with this because we have root path in main.nas.
slawekmikula
 
Posts: 128
Joined: Sun Feb 19, 2017 10:31 am

Re: New Feature: Addon - "API"

Postby Hooray » Tue Oct 03, 2017 10:31 pm

yeah, if everything else fails, we can also resolve the addon specific path using a lookup via /addons/addon[n]
But there is still remains quite a bit to do be done to support more complex addons in a sane fashion, which would be good to work towards, because that also means that more and more Nasal stuff can be made entirely optional, so that people can easily exclude Nasal based features for troubleshooting purposes

EDIT: Once overriding mice.xml (or any input system) actually (keyboard/mouse and joystick), it would probably be a good idea to document how to do this by adding to Torsten's skeleton addon to illustrate how to load custom bindings (or property rules) using the system
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: New Feature: Addon - "API"

Postby rominet » Wed Jan 10, 2018 11:30 pm

Hi,
slawekmikula wrote in Tue Oct 03, 2017 9:55 pm:Ok, i've found what was wrong. Simply [...] relative paths for resources in addon directory have to be prepended with "/Aircraft" text. e.g.

Code: Select all
<systems>
         <property-rule n="150">
            <path>/Aircraft/property-rules/fgcamera.xml</path>
         </property-rule>

This workaround is not necessary anymore, starting from FlightGear commit 717fdfec394 (Janauary 10, 2018, FG 2017.4.0). You can now specify resources by relative path under a specific add-on directory using the special syntax:
Code: Select all
[addon=ADDON_ID]relative/path

In the case quoted above, assuming that the FGCamera add-on has been given the identifier a.marius.FGCamera, you would thus use:
Code: Select all
<systems>
         <property-rule n="150">
            <path>[addon=a.marius.FGCamera]property-rules/fgcamera.xml</path>
         </property-rule>

Under the hood, these special paths are handled by an add-on-specific subclass of simgear::ResourceProvider.

If you need the resource path for use in Nasal code, there is another way which is probably better (since FlightGear commit 5f50e25535):

Code: Select all
var myAddon = addons.getAddon("a.marius.FGCamera");   # for example
print(myAddon.resourcePath("property-rules/fgcamera.xml"));

This will print "[addon=a.marius.FGCamera]property-rules/fgcamera.xml", so you don't have to hardcode the add-on identifier in your resource paths. You just use myAddon.resourcePath() with relative paths and all is neat.

Finally, since FGData commit a57aed195e, the add-on ghost is passed to the add-on main() function instead of the add-on base directory, therefore if you pass this value along wherever you need it, the line:
Code: Select all
var myAddon = addons.getAddon("a.marius.FGCamera");

is not needed either.
rominet
 
Posts: 605
Joined: Sat Nov 01, 2014 2:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: New Feature: Addon - "API"

Postby rleibner » Mon Feb 12, 2018 9:37 pm

Hi,
After config.xml was renamed as addon-config.xml, their properties are not charged into the tree.
However, it do works if I rename the file to its former name.
What am I missing?
Rodolfo
*************************
Non-shared knowledge is lost knowledge
User avatar
rleibner
 
Posts: 269
Joined: Fri May 19, 2017 8:17 pm
Location: Uruguay - SUMU
Callsign: CX-BEX
Version: next
OS: Ubuntu 18.04.4

Re: New Feature: Addon - "API"

Postby rominet » Mon Feb 12, 2018 9:46 pm

It seems you didn't update FG. :wink:

I successfully tested the new YASimDevel add-on which adds its menu via the addon-config.xml file, so for me it works (and I also tested the Oscilloscope, at least bringing it up).
rominet
 
Posts: 605
Joined: Sat Nov 01, 2014 2:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: New Feature: Addon - "API"

Postby Hooray » Mon Feb 12, 2018 9:47 pm

you need to "git pull next" (SG&FG & fgdata) and then rebuild the whole thing
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: New Feature: Addon - "API"

Postby rominet » Mon Feb 12, 2018 10:20 pm

I think that's rather:
Code: Select all
git pull

in each repository, assuming you were already on branch 'next' (otherwise, run 'git checkout next' before each 'git pull' command)

(actually, what 'git pull' does depends on how you configured your Git remotes in each repo; the long form would be 'git pull origin next', assuming you didn't change the default where 'origin' is the repo you initially cloned from—which in this case should point to the upstream FG/SG/FGData, respectively for each repo)

But if you use download_and_compile.sh and don't pass '-d n', it should automatically do that for you (see the function _gitUpdate()).
rominet
 
Posts: 605
Joined: Sat Nov 01, 2014 2:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: New Feature: Addon - "API"

Postby Hooray » Mon Feb 12, 2018 10:21 pm

Yes, sorry - giving out instructions like this is unlikely to work without knowing specifics about the local setup - which is why I tend to use "git pull origin next"
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: New Feature: Addon - "API"

Postby ThomasS » Mon Jun 11, 2018 9:29 am

Hello,

I have an administrative question related to addons:

now that the addon infrastructure demonstrated its ability I wonder whether there is a common understanding or expectation where the code of addons should be located. Obviously every addon developer is free to use its own repositiory (like I do for GroundServices), but there also is https://sourceforge.net/p/flightgear/fg ... unk/Addons which appears to be a central location for addons. Using this however requires write permission for each addon developer (merge requests aren't possible because it is a subversion repo). I'm not sure whether path/directory based permissions can be used in SourceForges subversion.

So, does anybody know about a access/control idea for maintaining addons in trunk/Addons? If I'm going to create a new addon, should I ask for write permission to trunk/Addons? Or a subdirectory like trunk/Addons/mynewaddon?

Best Regards

Thomas
ThomasS
 
Posts: 94
Joined: Sun Sep 11, 2016 2:21 pm
Location: West of EDDK
Version: 2018.2.1
OS: Linux,MacOS,Windows

PreviousNext

Return to New features

Who is online

Users browsing this forum: No registered users and 0 guests