Hi,
there's no such thing as a standardized interface/way to "mod" FlightGear.
Some of our most complex "mods" were the local weather system and the bombable addon - while the LW system has meanwhile been merged into main line, neither of these ever used a "standard" infrastructure.
This is not to say that this could not be added to FG via a Nasal script that resides in $FG_ROOT/Nasal - it could automatically check certain folders for certain files, and parse some PropertyList-encoded XML, including embedded Nasal sections.
A while ago, we talked about loading Nasal code embedded in PropertyList XML files procedurally. Some of this is covered at:
http://wiki.flightgear.org/Howto:Making ... erved_CodeThis section of the tutorial is all about dynamically loading Nasal code from PropertyList XML files served via HTTP.
Obviously, there's tons of other stuff possible.
* Add a entry to menubar.xml
* Add the dialog xml-file to the dialog directory
* Add the script-file to the Nasal directory
* Add a binding to the keyboard.xml
Quite a few steps for the user who might enjoy flying more than development and the internals of FG.
All of these could/should be done procedurally - a Nasal script could "patch" XML files in-memory, before being loaded.
Alternatively, the current menubar could be read from the property tree, then augmented via the property tree - and then reloaded from the property tree.
Loading custom script files is also possible without copying stuff - all that is needed is a Nasal file that uses io.load_nasal()
Not sure about keyboard bindings, but these would ideally also be "patch-able" at runtime.
I would vote against literally copying stuff to various places, because that would make maintenance increasingly difficult.
It would seem far better and more scalable to simply introduce a "mods" directory in $FG_HOME and then simply use a single Nasal file in $FG_ROOT/Nasal to load stuff from the "Mods" directory.
Literally patching an FG installation would be pretty error-prone in my opinion - so I would find it preferably not to touch $FG_ROOT, and only load extensions from a custom location that can be easily wiped/reset.
A while ago I talked to TheTom about some things related to this, the idea was to automatically download updated Nasal modules via the xmlhttprequest fgcommand().
So if you are interested in this, I'd suggest to go for it - but not to modify $FG_ROOT. We should instead implement all the building blocks so that XML files can be easily "patched in-memory" and applied without reloading from disk.
After all, this is a common need - the menubar is already extended with aircraft-specific stuff.
Maybe you could use the wiki and document your ideas, design suggestions - so that we can provide some more targeted feedback?
I'm sure that Philosopher & Macnab would also like to contribute some ideas to this, because they have done similar "mods" in the past.