OpenMW-Launcher: Separate configuration files based on content list profile.
This is a bug report on a hypothetical situation that arises from the current way the OpenMW-Launcher handles data directories.
The root cause is that currently openmw.cfg does not attach a data= entry to a specific content list profile. This is quite logical because that information cannot be extracted automatically if the data directory does not contain an ESP/Omwaddon or the ESP does not have a GameFile set, (e.g. a modders resource). Another reason is that OpenMW has been developed primarily as a replacement engine for a single game, where even with different content list profiles, the user would generally share the data files. I actually don't and ran into this issue already, you cannot maintain a Morrowind install with vanilla textures and meshes and one with replacements side-by side and switch using the content list. This is actually a rather common use-case when you're trying to debug/evaluate/compare mesh/texture replacements.
Additionally, this may cause problems if, by chance, a resource used in one game shares the name/path with one in another game.
Imagine that in the OpenMW Example Suite we have a mesh that has a path that coincides with a mesh in Morrowind (or a mod). In this case the mesh that would be loaded, would be the one that is last in the VFS generated from the data= entries, even if the games are entirely unrelated.
Especially if OpenMW is intended to be used as a fully independent game engine in the future, this may mean that people will install multiple games using the OpenMW engine, and get very strange errors where resources from a different game they own are suddenly shown in another. This would be extremely confusing to the average user who has no underlying comprehension of games, game-engines, and their mechanisms.
In a sense, we already provide a (not very user friendly) way to solve this issue. Any program can call the openmw executable directly (bypassing the launcher) and pass the --data and --data-local options. However, I would like to see a more user-friendly approach.My suggestions:
- Rework the configuration file management, so the launcher loads individual configuration files per content-list profile.
- For example in launcher.cfg instead of a lot of [Profilename]/content=xyz.esp, there would only be a single line [Profilename]/config=[Profilename].cfg per content list profile.
- Rework the launcher UI to allow users to select data directories for a given content list profile, and only afterwards let them choose the mods (See attached mockup picture)
Note: Because this can cause real issues that are non-trivial to the average – non-developer – user, I reported this as a bug, even though it could be considered a feature request. I set this to low priority and target openmw-future, since this is clearly not all that relevant yet.
#1 Updated by Gijsbert ter Horst over 1 year ago
Related issues are: #197, #206 and most importantly #988.
The latter is why I set the target to openmw-future.
Zini there says: “... but fiddling around with the data paths is not the way to go.”
I assumed that he envisioned problems by fiddling with the data= entries in openmw.cfg, hence my proposal to split off configuration files for each profile.
#2 Updated by Gijsbert ter Horst over 1 year ago
- Remove the drop-down under content , and simply include the primary game file (e.g. morrowind.esm) in the list of game files. It is no longer necessary to distinguish between lists of selectable mods by a primary gamefile, because:
- This is insufficient to avoid problems when deciding which resources to load (it only works for ESP/ESM and omwaddon files), as this issue describes.
- The distinction is already made by splitting the configuration files, and is now made at content-list profile level.
This leaves the possibility for the user to select a single profile with data files for multiple primary game files. However in my personal opinion, this is either a case of deliberate misuse by the user, or the user has so little understanding of what they are doing, that they would need guidance either way, no matter how it is implemented.