In this article we will discuss how to check a mod installer (also know as a FOMOD) for errors. When the XML configuration file does not comply with the schema that defines the structure of the document, some tools may reject it.
¶ Why does this happen?
There are several legitimate reasons why a mod installer could end up non-functional. While the FOMOD installer format is widely used in the modding community, it is often assumed that there is no defined standard. This means that some applications designed to create them may not output a valid XML or the mod author has written the document by hand, without using an IDE to validate the configuration.
¶ My installer works in some apps, why should I fix it?
In development, standards are created so that both users who create content in a particular format and applications that use (consume) the format both know what to expect. Otherwise we end up with an inconsistent "wild west" scenario where each tool uses its own interpretation of the format which would mean that the standard isn't really a standard at all. Supporting invalid installers should be considered a quirk of the software and it is not in the best interests of the modding ecosystem for applications to replicate each others quirk to remain compatible.
¶ Applications supporting ModConfig5.0 installers
| Application | Support type |
|---|---|
| Vortex | Full support |
| NMM - Community Edition | Loose support* |
| Mod Organizer 2 | Loose support* |
| Wrye Bash | Full support** |
| Kortex | Loose support* |
* Loose support indicates that these tools can parse a valid ModuleConfig.xml file but will also attempt to make a "best guess" at ones that are invalid.
** Wrye Bash will validate FOMODs before running them and shows a popup warning for invalid ones. Advanced users can bypass this popup, at which point WB will attempt a "best guess" interpretation similar to other mod managers (see above).
¶ How can I fix it?
You can read about the ModConfig5.0 schema here. However, fixing the issues with a mod installer does not require you to be intensely familiar with the format. We're going to use an IDE to guide us through the fixes. You can use any IDE that supports XML validation, but in this example we'll use VSCode.
¶ Tools required
¶ Getting the XML plugin
Once you have installed VSCode, open the "Extensions" section by using the icon in the left navigation. Then enter "XML" in the search. The extension is simply called "XML". Click the install button to add it to the app. If prompted, you may need to restart VSCode.
¶ Open the ModuleConfig.xml file
The ModuleConfig.xml file controls how installer options are presented to users who install the file. It should always be located inside a fomod folder inside the mod archive. Open this up in Visual Studio Code. You should now see that the ModuleCofig.xml tab is red, with a count of the errors next to it. Click the errors icon in the bottom left of the window to open the "Problems" panel.
VSCode will also hightlight the sections with problems using a red-squiggly underline, similar to how typing errors are displayed in word processors.
¶ Resolving the issues
You can now scroll through the errors in the "Problems" panel. Clicking each problem will automatically scroll you to where it exists in the document. Generally, the error messages will give you some indication of the issue, but we'll run through an example. We have the following <plugin> in our example XML that has an issue:
<plugin name="Default Wood Texture">
<description>Default dark wooden texture for the shield</description>
<image path="fomod\images\TCC Shield.png" />
<files>
<folder source="05 TCC Shield" destination="" priority="0" />
</files>
<typeDescriptor>
<dependencyType>
<defaultType name="Optional"/>
<patterns>
<pattern>
<type name="Optional"/>
</pattern>
</patterns>
</dependencyType>
</typeDescriptor>
</plugin>
VSCode will highlight that there is an error inside the <pattern> tags and give us the following message:
Invalid element name:
- type
One of the following is expected:
- dependencies
What this is saying is that the schema expect the <pattern> tags to contain a sub-tag <dependencies>.
In cases like this, you may not need to include any data inside the tag, so you can simply put in a self-closing tag. <dependencies />.
So our resulting <pattern> tag would look like this:
<pattern>
<dependencies />
<type name="Optional"/>
</pattern>
Note that the order of the tags is explicitly required and an error would still be reported if the tags are arranged incorrectly.