Mod loader?

[jam007]

As I thought about adding a dialog to my small gpx-script to make the filename, trackname and time between waypoints easier to change I realised that to use the dialog and script the user has to (as I understand it):
* 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.

Is there a modloader (a script that does the above steps based on a xml-file or similar provided by the developer) for FG or thoughts of creating one?

[Hooray]

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_Code
This 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.

[jam007]

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.

I agree.

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.

Just to see if I understand: With this do you mean that you have lets say the $FG_ROOT keyboard.xml and a $FG_HOME/Mod/mymod/keyboard.xml and they are merged at program start as the keyboard bindings are loaded in memory?

I'm interested but I have to familiarise my self with the internals of FG much more before I think I can contribute in a meaningful way. Right now I'm confused by all the properties, xml-quirks and have vague idéas of the general program design.

Maybe you could use the wiki and document your ideas, design suggestions - so that we can provide some more targeted feedback?

Ok. I will try to write something.

[Hooray]

re: "patching in memory":

We can load an XML file into the property tree and then dynamically modify the structure via the helpers in props.nas
And yes, it would also be possible to "merge" two XML files like that (procedurally, not on disk!) - simply by first loading menubar.xml and then appending any other XML files from a certain location.

Another (simpler) option would be to simply add a fixed "include" directive to files to be modded and then load stuff from the "mods" directory.
It would probably make sense to experiment a little here

[rico001]

EXAMPLE ALGORITHM FOR ADDON not mod. --Arcade Mode

I was thinking about how to make the project pick up and play.,, such as arcade mode.

addon advantage:
1. pick up and play
2. minimize learning curve

This had the following disadvantages:

1. take away/subtract from the simulator experience -- intelligently controlling a lifelike aircraft
2. how to reconfigure all of the aircraft while not breaking existing code.

I came up with at least one ideas how to implement mod addons
OPTION A check if addon folder in use or not and show in a menu

if not in use then don't do anything and run as normal
If use Addon then
1. this Addon directory should have files that re-use flightgear code without editing it.
2. Addons are a seperate program,
These addons can behave like a front-end launcher, but have access to flightgear code, and it's own code:
This way

BENEFITS
1. minimize data re-use
2. code for addons not directly dependent on flightgear program code
3. Flightgear code not altered.
4. Addons would be organized

DRAWBACKS
1. some code, re-use
2. Security/stability of programs would be independent of flightgear
3. efficentcy of code

MODS SO FAR
Bombable (could be made into addon)
Aircraft - not officially supported.
-- future arcade mode.



OPTION B: Code flightgear to specifically handle each mod, such as editing XML files as mentioned

[Hooray]

OPTION B: Code flightgear to specifically handle each mod, such as editing XML files as mentioned

That one is a particularly bad idea - it used to be the common mechanism to "mod" phpBB (the forum software).
But apart from that, it's not exactly difficult to come up with a modding framework that supports loading scripts, XML files etc from a configurable directory.
Something like that could be picked up automatically by adding a loader script to $FG_ROOT/Nasal, that will specifically look for "mods" in a certain location.
Like you say, bombable etc could then be turned into "mods", i.e. plugin based "packs" that must be put into a certain directory.
A prototype should not be difficult to come up with, and shouldn't require any C++ changes - in the mid term it may still be a good idea to specifically provide some native hooks to make this sort of thing feasible

For instance, for the time being there are many hard-coded assumptions about certain resources always being in a more or less standard location within the base package (think Nasal scripts, textures, dialog files, sounds etc) - it would make sense to get rid of such hard-coded assumptions

With the ongoing improvements in the online deployment area (catalog system, package manager, live GUI), this sort of thing is likely to be developed anyway over time

If anybody is serious about prototyping this, I can provide pointers (and code snippets) to get this going.
It would probably make sense to look at less complex addons for starters, i.e. much less complex than bombable (think fgcamera).
And you would specifically need to review each addon to determine its requirements.
Ideally, we would have a list of existing "addons" (fgcamera, bombable, tanker.nas etc) and someone would document their requirements via the wiki.
At that point it should be fairly straightforward to create an interface that can be used by most addons to provide modding functionality, so that this would be extended over time.

Obviously, one key aspect would be versioning the whole system properly, so that new features can be added and supported in a sane fashion.

In general, it would be a good thing for FlightGear's base package to be reviewed accordingly to better formalize such dependencies, because that's a common challenge that people are facing when cleaning up/maintaing the base package. A real package management, and modding system might actually be helpful.

http://wiki.flightgear.org/Howto:Creati ... _framework