OpenMW support

[benjaminwinger]

I've been working on Portmod, a mod manager for OpenMW, and would love to include support for TES3Merge, however TES3Merge doesn't currently have any way of specifying alternative locations to look for plugin files. While I could work around this, I would rather get support included upstream, particularly as it would help all OpenMW users.

[NullCascade]

This could certainly be done, though OpenMW support isn't something I'm terribly familiar with. Does text encoding per-file work any differently for OpenMW? Right now text encoding support is global, not per-file.

We would need to reproduce the VFS checks for content files. Then we'd just load the OpenMW config file and read what content files to load and check the folders in reverse order. I think our INI parser may have issues with duplicate keys, as it will complain about that in Morrowind.ini if a user has a messed up config file. From what I remember OpenMW likes using duplicate keys with order mattering.

What would the output file be? We'd need a OpenMW section in the ini file to specify what folder to put the output file, since we wouldn't want to put it in the main data folder.

Does OpenMW's load order match Morrowind's? We would have to change how we build the sorted masters list too.

Finally, the underlying library we use does not support .omwaddon files. This will be a problem as the format continues to deviate from Morrowind's. The only currently big deviation is the handling of script records AFAIK, which shouldn't be an issue for now.

That's a bit of consideration, and I don't really work with Linux or OpenMW to have a strong investment in getting it working. It probably wouldn't be hard to get working but I don't want to go figuring out how OpenMW handles all these things, I'd rather be fixing issues in general. But if you or someone else wants to do a PR with OpenMW support I'd happily merge it.

[benjaminwinger]

I'm not sure how successful reading openmw.cfg with an ini parser will be, as it's not really the standard format, however you can also parse it line by line and split on the equals signs.

For storing the output file, tes3merge could do what omwllf does: there's a data directory which is automatically added to the load order that is used by the openmw construction set where you can put plugins. See omwllf for the paths.

I don't know how openmw handles text encoding. As far as I know the load order is the same.

For supporting omwaddon files, I'm not that familiar with the differences, but from what I've seen (I've done a little work on omwllf and have worked with esplugin) they can be parsed at the moment like an esp. If that changes in future obviously something will need to be done, but that's also an issue that can be solved when it materializes.

I may consider implementing this myself at some point, however I have other priorities at the moment working on Portmod. Mainly I wanted to let you know that there was interest, and the information you've given on the necessary changes is helpful.

An intermediate step to getting this implemented that may also be worth considering is to abstract away how tes3merge collects the plugins and support passing a list of plugin paths on the command line (or alternatively in the tes3merge.ini) as well as an output location. That would be enough to work nicely with Portmod, as Portmod already works with OpenMW's vfs and config files, and would be a step towards working with OpenMW.

[NullCascade]

Sounds like we're in a similar boat re: having other priorities at the moment. I'll leave this here if anyone wants to tackle it:

• This section needs to be pulled out to a few functions, one for TES3, one for OpenMW, and a couple for some shared logic. Check for this should be done by reading the ini file to check for OpenMW compatibility. The functions should fill sortedMasters, mapTES3ToFileNames, and recordMasters.
• The OpenMW function needs to find and parse the OpenMW config file and find all content files. This needs to be done in a way that respects overrides in later data folder definitions. Instead of searching the Data Files folder for content files, and filtering based on ini, it can just look for and use the order of entries in the OpenMW config file. Note: This needs to be tested, but I don't think OpenMW uses file timestamps for sorting.
• Some extra exception handling may need to be put on loading files, in case OpenMW changes the file format further, so that the underlying loader fails.
• Once sortedMasters and some helper data maps are filled, everything should work as normal.

These are fairly simple tasks when broken down.