[Flightgear-devel] Simple API for creating FlightGear addons/plugins

[Torsten Dreyer]

Hi,

we now have a simple API to add addons to FlightGear without the need to
mess around with FGData/Nasal or FGHome/Nasal directories.
FlightGear now accepts the command line switch --addon=/path/to/some/addon
(note: command line switch is just that: a command line switch - not an
option to be entered into the launcher).

fgfs (through options.cxx) takes care of
- creating a property under /addons/addon[n]/path=/path/to/some/addon
- adding /path/to/some/addon/config.xml as a config file (same as
--config=/path/to/some/addon/config.xml)
- adding /path/to/some/addon to the list of allowed directories (same as
--fg-aircraft=/path/to/some/addon)

The addon may be installed anywhere on your hard disk and it needs at least
two files:
* config.xml - a standard PropertyList to be used to populate or modify the
property tree. (Same as to be used in --config=foo.xml)
* main.nas - the Nasal hook for the logic. This file needs a function
called main() which will be called from the global addon initializer
(FGData/addons.nas)

It is pretty simple but does it's job nicely with our two addons we
currently have in FGAddon (ATCChatter and SpokenATC).

There is a /very/ simple Skeleton addon available to be used as a
boilerplate here:
https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Addons/Skeleton/

As always: feedback is much appreciated.

[James Turner]

Post by Torsten Dreyer
As always: feedback is much appreciated.

Very interesting - thanks for doing this!

James

[Thorsten Renk]

We now have a simple API to add addons to FlightGear without the need to
mess around with FGData/Nasal or FGHome/Nasal directories.

Thanks, that looks neat!

Do we have any guidelines/ideas when a feature should become an Addon and
when it should be merged into next? There's plenty of interesting stuff
floating around in the forum (several view managers for instance) so the
question is of some relevance for what I do with stuff I see there or get
asked to commit.

* Thorsten

[Torsten Dreyer]

Post by Thorsten Renk
Do we have any guidelines/ideas when a feature should become an Addon and
when it should be merged into next?

Not that I am aware of. Addons are cheap now and are strictly opt-in.
I'd say: build an add on, let it become mature and if there is a need for
having it in the base package, put it into FGData.

[Thorsten Renk]

Post by Torsten Dreyer

Post by Thorsten Renk
Do we have any guidelines/ideas when a feature should become an Addon and
when it should be merged into next?

Not that I am aware of. Addons are cheap now and are strictly opt-in.
I'd say: build an add on, let it become mature and if there is a need for
having it in the base package, put it into FGData.

Maybe I'm the only one seeing this, but in a way this represents a shift
in our development paradigm. It used to be to merge all useful
developments into main in order to not create a host of potentially
mutually exclusive/ conflicting add-ons and an FSX mess.

Do we now require addons to be mutually compatible, do we not care, do we
aim at selecting an maturing one of the addons solving the same thing, do
we see addons as a way to store stuff that is interesting but is not
compatible with main, or as satisfying rare use cases?

Sorry to make matters complicated, but personally I'd like to have a short
discussion so that we're all on the same page what to do with this (very
useful) API.

* Thorsten

[Torsten Dreyer]

Post by Thorsten Renk
Maybe I'm the only one seeing this, but in a way this represents a shift
in our development paradigm. It used to be to merge all useful
developments into main in order to not create a host of potentially
mutually exclusive/ conflicting add-ons and an FSX mess.

Yes, probably. This might lead to a add-on mess of incompatible plugins.
I hope this will not happen, though. What I do hope for is, that this
lowers the
barrier for - probably incomplete - contributions that otherwise gets lost
somewhere in the forum or behind a dead link.
On the other hand this helps us to more carefully select what gets included
in the base package.

Post by Thorsten Renk
Do we now require addons to be mutually compatible,

I would not think so. At least we could act a lot more relaxed compared to
the
base packages requirements.

Post by Thorsten Renk
do we not care,

We certainly should care :-)

Post by Thorsten Renk
do we aim at selecting an maturing one of the addons solving the same
thing,

As long as they live in FGAddon, I could live with keeping both
implementations

Post by Thorsten Renk
do we see addons as a way to store stuff that is interesting but is not
compatible with main, or as satisfying rare use cases?

Absolutely!

Remember: those addons live in FGAddon (IIRC that was the original idea
behind
this repository). We don't pack or ship them - we just tag the releases in
SVN.

And: there is nothing really new here. People already created addons. This
just
provides a standard for the implementation and a user-friendly way to
install
and use them.

Post by Thorsten Renk
Sorry to make matters complicated, but personally I'd like to have a short
discussion so that we're all on the same page what to do with this (very
useful) API.

No worries, this discussion is more than welcome.

[Edward d'Auvergne]

Post by Torsten Dreyer

Post by Thorsten Renk
Maybe I'm the only one seeing this, but in a way this represents a shift
in our development paradigm. It used to be to merge all useful
developments into main in order to not create a host of potentially
mutually exclusive/ conflicting add-ons and an FSX mess.

Yes, probably. This might lead to a add-on mess of incompatible plugins.
I hope this will not happen, though. What I do hope for is, that this lowers
the
barrier for - probably incomplete - contributions that otherwise gets lost
somewhere in the forum or behind a dead link.
On the other hand this helps us to more carefully select what gets included
in the base package.

Post by Thorsten Renk
Do we now require addons to be mutually compatible,

I would not think so. At least we could act a lot more relaxed compared to
the
base packages requirements.

Post by Thorsten Renk
do we not care,

We certainly should care :-)

Post by Thorsten Renk
do we aim at selecting an maturing one of the addons solving the same
thing,

As long as they live in FGAddon, I could live with keeping both
implementations

Post by Thorsten Renk
do we see addons as a way to store stuff that is interesting but is not
compatible with main, or as satisfying rare use cases?

Absolutely!
Remember: those addons live in FGAddon (IIRC that was the original idea
behind
this repository). We don't pack or ship them - we just tag the releases in
SVN.
And: there is nothing really new here. People already created addons. This
just
provides a standard for the implementation and a user-friendly way to
install
and use them.

Post by Thorsten Renk
Sorry to make matters complicated, but personally I'd like to have a short
discussion so that we're all on the same page what to do with this (very
useful) API.

No worries, this discussion is more than welcome.

I wonder if this works with more complex, pre-existing addons such as
Bombable [1], where the file layout is a replica of the old FGData
layout [2]? These types of mature addons might be better as
SourceForge FlightGear sub-projects rather than being copied into
FGAddon. Maybe the config file and nasal script could be used to
automate the installation process [3].

Regards,

Edward


[1] http://wiki.flightgear.org/Bombable
[2] https://github.com/bhugh/Bombable
[3] http://wiki.flightgear.org/Howto:Adding_Bombable_to_FlightGear_Aircraft

[Torsten Dreyer]

Post by Edward d'Auvergne
I wonder if this works with more complex, pre-existing addons such as
Bombable [1],

I have played a bit with FGCamera yesterday. It dit not work as a drop in
replacement, mostly because of some Nasal namespace issues.
(FGCamera adds some variables and functions to the "global" namespace but
most of the implementation lives in "fgcamera" namespace.
The plugin loader itself loads each plugin's main() method into it's own
namespace to avoid conflicts). Also, I had to change the hard coded
installation path to FGData/Nasal to use the provided installation path. It
needs some more fiddling to detangle this but it is already basically
working. Loading of XML files, custom dialogs, menubar extensions work.

For personal reasons stated earlier, I will not touch the Bombable addon
but I don't see any technical reason why it should not work.

What I have learned so far for new addons is:
- Don't rely on absolute path names to look up files from the addon (
getprop("fg-root") ~ "/Nasal/myaddon/config.xml" --> bad )
+ Construct the path names with an installation prefix instead ( addon_root
~ "/config.xml" --> good )

- Don't mix namespaces in Nasal. At least, don't add to global namespace.
+ Use well known namespaces.

[Edward d'Auvergne]

Post by Torsten Dreyer

Post by Edward d'Auvergne
I wonder if this works with more complex, pre-existing addons such as
Bombable [1],

I have played a bit with FGCamera yesterday. It dit not work as a drop in
replacement, mostly because of some Nasal namespace issues.
(FGCamera adds some variables and functions to the "global" namespace but
most of the implementation lives in "fgcamera" namespace.
The plugin loader itself loads each plugin's main() method into it's own
namespace to avoid conflicts). Also, I had to change the hard coded
installation path to FGData/Nasal to use the provided installation path. It
needs some more fiddling to detangle this but it is already basically
working. Loading of XML files, custom dialogs, menubar extensions work.
For personal reasons stated earlier, I will not touch the Bombable addon but
I don't see any technical reason why it should not work.

The same reasons I have no interest in using Bombable. But it is one
of the most popular addons out there, and a large number of aircraft
in FGAddon have bombable support [1], so I think it is worth not
forgetting about. Especially if the addon system one day becomes
automated through a catalog.xml type system ;)

Regards,

Edward


[1] 79 out of 526 aircraft, or 15%:

$ grep -rIl bombable /flightgear/flightgear-fgaddon/Aircraft/ | sed
"s/.*Aircraft\///g" | sed "s/\/.*//g" | sort -u
A-26-Invader
AirCrane
Antoinette
Antonov-An-12
ASK21
Avro-Lancaster
B-24-Liberator
BAe-125
Bell-222X
Bleriot-SPAD-S.510
Breda-B.Z.308
Bugatti
BV-141
C130
C460
C561
Campini-Caproni-N1
Caproni-Ca3
Carreidas
Commonwealth-Ca-12
D510
DH-88
DH-89
Douglas-Dolphin
Dunne-D.5
EV55
F-106-dart
f-14b
Fairey-Gannet
Farman-IV
Focke-Wulf-F19-ente
Gloster-Whittle
Gotha-G-V
H4-Hercules
Handley-Page-Halifax
Harrier-GR1
Harrier-GR3
Heinkel-He-177
HS-P-75
JA37
Jaguar
Junkers-Ju-390
Junkers-W34
K-7
Ka-50
Ka6
Lockheed-P38
Lockheed-SR71
Lockheed-U-2S
Macchi-Castoldi-MC72
ME-262
Messerschmitt-Libelle
Messerschmitt-P1101
MiG-15
MiG-21bis
Mirage-2000
MirageIII
MQ-9
Nord-2502
North-American-T28D-Trojan
p51d
Percival-Mew-Gull
Piaggio-Pegna-Pc-7
Polikarpov-I16
Ryan-PT22
Saunders-Roe-Princess
Short-Stirling
Skyvan
Stampe-SV4
Starship
Super-Etendard
TBM-Avenger
Tigre
TU-95
UH-1
XB-70
Yak-18T
Yak-36
Zlin-50lx

[Richard Harrison]

Adjust that to 78

The F-14 once had basic bombable support but that is now largely
removed, however there is a Nasal module that is still there that isn't
loaded and this is what refers to bombable.

[James Turner]

Post by Edward d'Auvergne
The same reasons I have no interest in using Bombable. But it is one
of the most popular addons out there, and a large number of aircraft
in FGAddon have bombable support [1], so I think it is worth not
forgetting about. Especially if the addon system one day becomes
automated through a catalog.xml type system ;)

BTW there are ‘feature tags’ in the catalog system to allow for this, I already did one for ‘bombable’ I think, happy to consider suggestions for other ones (Dual-MP-controls is another, so is the glider-tow one). I didn’t do anything in the UI with these tags yet but would be very easy to add!

Kind regards,
James