More about extended mod support

Friday, 13 May 2011 Written by 

I'd like to give some more technical background info to people interested in modding about the upcoming extended modification support that we'll include with Fleet Operations (as if it wasn't enough to read the last time).

In the last two weeks i made good progress working on that feature and inspired by some comments from users in my last news post about modification support, i've now added something i think modders will very like it.
As i have explained earlier, modifications can be "chained". That means you can create a "sub" modifications that are based on another modification. The other modification can again be also a "sub" modification.
A annoying problem when creating and distributing modifications always has been that if you want for example only add a single ship to Armada you had to not only include your ship's definition file, model and texture. To make a new ship working you also have to include a modified copy of the definition file for the shipyard and the whole tech tree file (with only a single line about your ship added). This is only the simplest example and especially gets much more annoying if you create a "sub" modification for a regularly updated mod (like Fleet Operations). Your mods will begin to either stop working or break other parts of the game as soon as the modification you have made your new ship for gets an update.
Though that can not be entirely fixed with the stuff i am working on, in large part you'll have it a lot easier if you are a modder with it
If you know how the #include instruction works in files like techtree, ODFs, rts_cfg.h, dynamic_localized_strings.h and so on, you should be surprised about the usage of the instruction in the following screenshot.

The #include parameter usually allows to include another file in a configuration file, however pointing it to itself would lock up the game when started. This is still true with the extended modding support unless you use that command in a modification using files of a parent mod. What you see there is a folder called sta2campaign. Now this is a "sub" mod for another mod which is "sta2".
In my case "sta2" is a stock Armada 2 installation running on Fleet Operations i have called "Star Trek Armada II Classic". This "mod" only contains the multiplayer part of Star Trek Armada 2.
"sta2campaign" is the campaign part of Star Trek Armada 2 and is a "mod" based on my Multiplayer STA2 "mod". As you see only files important for the campaign are included like graphics for the singleplayer shell, Picard & friends singleplayer babble and all the mission maps and files,
The RTS_CFG file of my campaign mod only requires a change to a single line. Usually i would have to copy&paste the whole file again, however with the improved #include instruction, i only have to add what i really want to change from the parent mod. In the example this is the command to display the Singleplayer button on the main screen.
For comparison i have launched both my "sta2" and my "sta2campaign" mod. On the left you see the "sta2" installation running, while in the right you see the "sta2campaign" instance with the overriden rts_cfg command working and displaying the "Singleplayer" button.
Again, this works for all files that can handle the #include instruction: Techtree, ODFs, RTS_CFH.h dynamic_localized_strings.h and others.
This should make it a lot easier to add or modify just a few lines of the techtree files, add new build items to shipyards, add new weapons and much much more with only the info included that has really changed.