Inspiration
I've been thinking about the next big thing OpenMW can bring to the table, there is a lot! One feature in particular that I think would be immensely powerful is a dedicated format for mod packaging. This idea has been brought up in many a casual conversation but the talk never seems to have any direction or intent. A standardized mod packaging system is something everyone wants, yet I don't see a plan for it in the foreseeable future, if anything it can't hurt to discuss possible implementations. From now on I will reference such a package as an omwpack, from this doc.
A mod package needs to be both friendly to modders and friendly to the people installing the mods. The current system in place is friendly to neither if only for the fact that there is zero standardization.
Overview
Essentially, I envision mods to be standalone files, think BSAs on steroids. Every mod is its own omwpack and is loaded in the standard OpenMW way. These would of course need some precedence over loose files such as BSAs, plugins, and data directories but this is a minor issue at best.
Code: Select all
mod=rainbows.omwpack
Core Features
The following are some features which I think would be absolutely necessary to have for any initial design. The list is short, but I think I touch on the core aspects of such a system.
- Context aware activation. When activating an omwpack it should be fully aware of the users load order. Here would be the place to spit warnings such as overwriting existing files (potentially from other omwpack), errors regarding missing dependencies, etc.
- Configurable installation. Mods have options, so there needs to be a way to provide options. The option to blacklist arbitrary files is an important feature as well. With pluginless replacers especially it is sometimes desirable to not want to use a handful of specific files. This is not so simple as selecting from a checklist as options are conditional on previous choices (see GiTD). Thus, a wizard of some kind is mandatory (GUI, CLI, or both). I believe this part might be a bit controversial as you'd need some manner of writing these conditionals, presumably in a standardized script (potentially use existing langauge with restricted API). There are a few formats such as OBMM and FOMOD which allow wizard-like installations through programs such as Wrye and MO2.
- Stateful Installation and Re/Un-installation. The side-effect of a configurable installation is needing to track extra state to know how to either reinstall or uninstall the mod package. I don't think it's a good idea to install contents of omwpacks somewhere else. With that method it means you need to keep a copy of the original omwpack around if you want to reinstall. Reinstalling is incredibly useful when trying out new options or needing to check a new compatibility patch.
Example Structure
Putting everything together I'd imagine an omwpack to be a simple archive with the following structure:
- meta.cfg : Version, author, contact info, etc...
- wizard.script : Install script of some sort, supporting conditional options
- data/ : Plugins and standard loose files such as sounds, meshes, textures, lua, etc...
- .install : May or may not be part of archive, determines how OpenMW loads the omwpack on game launch. Following this structure, it would be generated from the wizard.script when run. Necessary for uninstall or reinstall.
You'd expect to be able to do the packaging entirely in OpenMW-CS. That is, boot up a new project and have everything you need in an isolated environment for packaging. With the current state of OpenMW-CS I do not see this as an option, at least for now. There is no reason, however, that we cannot go ahead and have our own package structures as integration can always be added. I may be off here but I don't believe OpenMW-CS should ever be an essential ingredient for the creation of an omwpack.
Mod Repository
I see this as an end-goal, opening up the OpenMW mod store browser and clicking the install button on all your favorite mods. While this is something that might happen far into the future it will be much simpler to do if we already have a mature packaging system.
A note on compatibility: I think the great thing here is that we don't have to worry at all about backwards comparability, the standard way of loading mods is here to stay for foreseeable future and adding a new packaging system will not break this.