Better mod management

Feedback on past, current, and future development.
Locked
User avatar
lgromanowski
Site Admin
Posts: 1193
Joined: 05 Aug 2011, 22:21
Location: Wroclaw, Poland
Contact:

Better mod management

Post by lgromanowski »

fallenwizard wrote: I thought about the mod management in Morrowind (And how horrible it was) and I got an idea: Organizing mods in packages instead of copy/pasting everything into the data folder. Maybe something like this:

"openmw/mods/Morrowind Visual Pack"

It'll make the mod in/uninstallation a lot easier. Deleting the folder is enough to get rid of the mod.

EDIT:
About the load order: The user should be able to set the load order ingame via GUI. I made a simple mockup in paint. (Excuse me)
http://ompldr.org/vNWtzOQ/loadorder.png
sir_herrbatka wrote: funny but we was discussing about it at the mailing list. Additional compression (7zip was suggested) and voila.
fallenwizard wrote:
sir_herrbatka wrote:funny but we was discussing about it at the mailing list. Additional compression (7zip was suggested) and voila.
I don't think compression will work without getting very long startup times. Especially with huge mods and texture packs. Folders will be better.
Chris wrote: Some kind of BSA+ESP combo would be fairly nice to have. I know it's kind of a pain to get Oblivion to use extra BSAs, but they can be very useful for keeping files from getting spread out all over (and considering filename case sensitivity, would make it easier to avoid somemesh.nif/SomeMesh.NIF conflicts), although it would be time consuming when you want to mix-and-match resources from various mods.

I would say something like a pk3 (zip file, essentially), that has a specially-named text file in the root that describes the mod, and mentions any esp/esm files it should load. When such a pk3 is "enabled", OpenMW would load the named esp/esm files, if any, and the rest of the archive would be for resource replacements. When disabled, it would be ignored completely.

Compression wouldn't be an issue, since you can specify to not compress a zip. Alternatively, we could use (non-compressed) tarballs instead of zips.
Star-Demon wrote: So, you guys want mods to be MOMO'd?

MOrrowind MOd format - very similar to FOMOD and OBMM?
Chris wrote: I was thinking something a little simpler than OBMM. No scripting, dialog selections, or installation.. just a regular, well-support archive format (like tar or zip) that can be enabled and contains esm/esps that are auto-loaded, with a bunch of resources that are used in place of/in addition to the default resources. OpenMW would read from the archive directly, no extracting to disk.
mots wrote: Consider adding dependency/conflict handling (similar to .deb packages).
Star-Demon wrote:
Chris wrote:I was thinking something a little simpler than OBMM. No scripting, dialog selections, or installation.. just a regular, well-support archive format (like tar or zip) that can be enabled and contains esm/esps that are auto-loaded, with a bunch of resources that are used in place of/in addition to the default resources. OpenMW would read from the archive directly, no extracting to disk.
I like the scripting elements since they make installs much easier to handle, especially when dealing with conflicts or overwrites, which commonly happen.
Chris wrote:
Star-Demon wrote:I like the scripting elements since they make installs much easier to handle, especially when dealing with conflicts or overwrites, which commonly happen.
I think OpenMW itself should avoid "installing" mods. Just like how you enable an esp and it "just works", you'd enable a pk3 (or whatever) and it "just works". Drop it in the appropriate directory, enable it, run OpenMW. Any higher level management (options, conflict checking, etc) should be handled in a separate app.
Star-Demon wrote:
Chris wrote:
Star-Demon wrote:I like the scripting elements since they make installs much easier to handle, especially when dealing with conflicts or overwrites, which commonly happen.
I think OpenMW itself should avoid "installing" mods. Just like how you enable an esp and it "just works", you'd enable a pk3 (or whatever) and it "just works". Drop it in the appropriate directory, enable it, run OpenMW. Any higher level management (options, conflict checking, etc) should be handled in a separate app.
There's no way for it to "know that". How do we know we want a mod package that overwrites the meshes for potions and swords when we have another mod that overwrites swords and cups? How does the program know what the user wants other than load order?

This is a big problem with mods for all of these games. Things are constantly overwriting records and resources, and a computer has no way of knowing what to do when the best it can manage is to "do this one first", and then down the line it's done again, and again, and again.

The logic required for it to just work would require user input, is all I'm saying. Might as well make FOMOD packages, because too many resources need to be overwritten. To simply package a BSA and ESP or ESM in a file and call it a new kind of file - I can't see the actual use in it.

What does it actually do for me to manage the internal chaos?
Chris wrote:
Star-Demon wrote:There's no way for it to "know that". How do we know we want a mod package that overwrites the meshes for potions and swords when we have another mod that overwrites swords and cups? How does the program know what the user wants other than load order?
It can't know beyond load-order, nor should it. How could it? Having OpenMW itself try to handle such conflicts would be a very messy and inefficient, hence a separate app would manage it.

What I could imagine is that the description text in the root of the package can contain a list of files/resources to ignore when enabled. It would help prevent filling up the resource mapping table with non-resource files, and a mod manager can play with that list to manage resource overwrites. The only other option I can think of would be some kind of meta-package, that just describes which mods to pull which resources from.. I can't imagine that being very nice to handle, though, as mods are enabled/disabled.

But ultimately, OpenMW would just be told what to load or not load. Configuring which resources to load should be done externally. Utility functionality like that should be kept external, as it's been shown since time-immemorial that a game's built-in utility is almost always eventually out-classed by independently made alternatives. Having a default utility built-in would just make things confusing for the user and problematic for potential alternatives.
To simply package a BSA and ESP or ESM in a file and call it a new kind of file - I can't see the actual use in it.
The use is to prevent filling up the Data Files folder with individual resources, as it quickly becomes unmanageable. And on file systems where there's case-sensitivity, the packages will prevent duplicates that differ only with casing (leaving you guessing as to which will take precedence, since it won't even be last-installed-wins). It also can help against needing to store the mod twice.. once for the archive, and again unpacked.. since it can load the archive/package directly.
amos wrote: I agree with this, letting OpenMW only care about loading of files from the filesystem and/or archive files. Dependencies can be placed inside the archive and used by another tool to organise the mods. OpenMW only needs to know which files to look in and the order.

Now this tool could easily be shipped with OpenMW using the same code base. If it was an external tool then I would at least like to have some cooperation between it and OpenMW.
Not to mention a better integration between mod sites and the tool, having to download files separately is a bit annoying at times.

The best thing would be define the whole process and the involved file formats and protocols.
EmbraceUnity wrote: There is a very hackish solution here:

http://code.google.com/p/mlox/wiki/Mlox
Greendogo wrote: I haven't read through everything, but I'd like to say that even though packaging (i.e. - zipping, or what have you) puts everything in a neat little package, the only difference between it and just putting the files into a regular folder is that it makes it harder to get to. People put their mods into some type of package when they upload it to a mod site anyways. It won't make it more convenient, it will only make it more difficult to swap out files and to further customize mods.

I believe on the Mailing list I was either one of the guys who suggested or supported using a packaging system, but upon reflection, I think it would make things more complicated and inflexible.

This doesn't mean I don't support better support for mod management.
amos wrote: I don't get it , why would it make it more difficult?
With this approach you would just have to download the zip file and copy it to the mod folder, ie. it skips the unzipping part you normally have to do (one less step).

Why do you need to swap out files or customize mods unless you intend to create your own mod, in that case you would have to unzip the file in any case with the original approach.
sir_herrbatka wrote: Yup. You won't be forced to packing your mods anyway (unless your players will keep up bothering you - you can't blame them).
Locked