I don't know if this has been thought of and/or already is on the list for future development but I did not see it in the post 1.0 document.

Would it be possible to upon starting a game in openmw to scan any/all mods loaded for conflicts? I know that that may sound like a large undertaking but what I meant is like this, scan mods and check if any mods modify the same record (object/GMST/Leveled list, etc) and report the mods and the object ID in a log somewhere. I do not want this to throw errors on screen, but I think that output of multiple changes to same object should be written out somewhere which a user can find and work on fixing

I know that that may sound like a large undertaking but what I meant is like this, scan mods and check if any mods modify the same record (object/GMST/Leveled list, etc) and report the mods and the object ID in a log somewhere.

That will basically end up listing every modded record. A lot of mods work by redefining records from other game files, so that the replacement shows up instead of the original. Mod conflicts arise because one mod changes some records in a way that another mod doesn't work right with, not that the record changed at all, and a compatibility patch changes those same things in a different way that works better with that other mod, or by combining certain records of the mods in a certain way (and maybe a few additions to glue it together better) that couldn't be done with a last-one-listed-takes-all method.

At best I could see it logging when a mod replaces a record that wasn't last replaced by one of the mod's listed masters. But even that could have a number of false positives.

I know that that may sound like a large undertaking but what I meant is like this, scan mods and check if any mods modify the same record (object/GMST/Leveled list, etc) and report the mods and the object ID in a log somewhere.

That will basically end up listing every modded record. A lot of mods work by redefining records from other game files, so that the replacement shows up instead of the original. Mod conflicts arise because one mod changes some records in a way that another mod doesn't work right with, not that the record changed at all, and a compatibility patch changes those same things in a different way that works better with that other mod, or by combining certain records of the mods in a certain way (and maybe a few additions to glue it together better) that couldn't be done with a last-one-listed-takes-all method.

At best I could see it logging when a mod replaces a record that wasn't last replaced by one of the mod's listed masters. But even that could have a number of false positives.

Honestly, false positives are fine. Sometimes I just really need to know what all is affecting a record or area, and it's an absolutely massive pain to try to go through each of my mods one by one to see what could be doing it. Especially with the loadouts I like to make. Helping us narrow things down would be huge. I wholly support ST's idea here. Hell, I'd be actually quite happy to have a list of all the records changed by a file that didn't create them and all the files that changed them, because even with dependent mods and so forth, it's possible to end up accidentally altering something that didn't need to be altered. Keep in mind this isn't so we can completely automate mod conflict resolution. I don't think any of us are naive enough to think that could be done. But right now, doing it manually, we potentially have way too much data to sift through and have to do it in probably the single most labor-intensive way possible.

Honestly, false positives are fine. Sometimes I just really need to know what all is affecting a record or area, and it's an absolutely massive pain to try to go through each of my mods one by one to see what could be doing it.

It would similarly be a massive pain to go through dozens or hundreds of false positives to find the one legitimate record you're interested in. Especially if it lists every time a particular record is overridden (e.g. ModA overrides a base game record, ModB overrides that same record, and ModC also overrides that record, means the same record would get listed two or three times), and even worse if you don't know the exact record name.

Honestly, false positives are fine. Sometimes I just really need to know what all is affecting a record or area, and it's an absolutely massive pain to try to go through each of my mods one by one to see what could be doing it.

It would similarly be a massive pain to go through dozens or hundreds of false positives to find the one legitimate record you're interested in. Especially if it lists every time a particular record is overridden (e.g. ModA overrides a base game record, ModB overrides that same record, and ModC also overrides that record, means the same record would get listed two or three times), and even worse if you don't know the exact record name.

Because you would see the output (theoretically in the order that the mods are loaded in) to see which mods are making changes to what entries - both which ones made changes, and which one was the last modification and hence the (theoretically) active one. While this then may report a massive bunch of information that is essentially false positives but it would also show when a mod is unexpectedly changing something that you didn't realize or conflicting with something that you didn't think it would.

I think it would help with making patches for a situation where you have multiple mods changing the same record

ST
PS- I am not a dev so I am unable to make this myself, but I also understand that this may be out of the scope of the plan to get us to 1.0

There's a pretty good chance that xEdit is going to get basic Morrowind support pretty soon. The guy working on it has actually come to the OpenMW discord to ask us about the guts of the ESM format (as it's very different to all the later, FormID-based, games) recently. That'll be able to do everything discussed here. Based on my experience trying to resolve mod conflicts with FO4Edit and TES5Edit, I can confidently say that about 90% of records in all mods are going to be overrides of something else and a load of mods will have swathes of completely benign conflicts with each other. It's definitely not something you want to analyse from a text file.

There's a pretty good chance that xEdit is going to get basic Morrowind support pretty soon. The guy working on it has actually come to the OpenMW discord to ask us about the guts of the ESM format (as it's very different to all the later, FormID-based, games) recently. That'll be able to do everything discussed here. Based on my experience trying to resolve mod conflicts with FO4Edit and TES5Edit, I can confidently say that about 90% of records in all mods are going to be overrides of something else and a load of mods will have swathes of completely benign conflicts with each other. It's definitely not something you want to analyse from a text file.

Better analyzing from a single text file than analyzing from thirty or more CS or OpenCS windows, which is what we're currently stuck with. But yes, if xEdit gets Morrowind support, and especially if it gets Linux support and OpenMW support, this won't be needed.

Only lines in a mod that conflicts with lines in another mod are going to count as conflicts. I am not seeing where conflicts have to be analyzed as much as noted.

There are a couple of scenarios to consider.

Users - if a mod conflicts with another, choose which you want to use. Users can't analyze conflicts and if they could, could not fix them. Pick mods which don't conflict with each other.

Authors - are more complicated. They may be interested in what the conflicts are. They can only modify their own mod. However they may choose not to, taking an attitude that the user just has to choose.

That said a mod author needs to avoid conflicts with game structures. But the cs should handle that side of things. So we are back to collision between mods.

Only lines in a mod that conflicts with lines in another mod are going to count as conflicts. I am not seeing where conflicts have to be analyzed as much as noted.

There are a couple of scenarios to consider.

Users - if a mod conflicts with another, choose which you want to use. Users can't analyze conflicts and if they could, could not fix them. Pick mods which don't conflict with each other.

Authors - are more complicated. They may be interested in what the conflicts are. They can only modify their own mod. However they may choose not to, taking an attitude that the user just has to choose.

That said a mod author needs to avoid conflicts with game structures. But the cs should handle that side of things. So we are back to collision between mods.

I find comments that simply state problems without suggested solutions to be unhelpful. Yes, a massive list of collisions to sort through is less than optimal. But OTOH it is better than no list of collisions.

I'm proposing a real database to load the mods in and a program wrapper that allows the user to search, sort and display the collisions.