List all mods conflicting with each mod in mod collection table or Conflict Solver.

[Hasselshoff]

Is your feature request related to a problem? Please describe:

(More of a major nuisance than a problem with Irony Mod Manager.) Irony's Conflict Solver is amazing for resolving conflicts & creating a custom patch. Making a comprehensive custom patch with the Conflict Solver prevents any & all load order issues; as long as the user resolves every single conflict, the loaded file/key will always be the one the user wants.

But making a custom patch isn't & shouldn't be always necessary when adding a new mod. That would be tedious. Of course, a custom patch will always be the most surefire way of guaranteeing the loaded files are the intended files. But even a short mod collection can have thousands of conflicts, creating an intimidating factor that deters new mods. So a method of approximating conflicts would be most welcome.

Most of the time, a satisfactory solution would be to just move mods in the load order so they are before/after conflicting mods, as appropriate to ensure the intended mod is loaded. But how does one know what load order to use without knowing what mods are conflicting with that one? Most mods don't have that many conflicts, so a lot of the time, it really is that straightforward & simple. This is the principle guiding how both Vortex & Mod Organizer 2 deal with mod conflicts & load order.

As it is now, I have to resort to making a custom patch with the Conflict Solver for every new mod collection and at times even have to painstakingly compare & write down what mods my major mods conflict with. And, yes, as bad as that sounds, that is still significantly less work than making a comprehensive custom patch.

Describe the feature solution you'd like:

FEATURE REQUEST: conflict summary for each mod in Irony's modlist, listing all the mods conflicting with that mod.

BONUS FEATURE: plus the specific files conflicting for that mod).

Vortex & Mod Organizer 2 both have conflict icons next to each mod in the modlist that has conflicts with other mods (see image 1 below). Hovering on the conflict icon produces a tooltip listing the other mods conflicting with that mod. Clicking on the mod opens a menu listing all the conflicting mods & the specific files which conflict (see image 2 below).

As a bonus feature, Vortex uses rules to dynamically & automatically generate a load order, rather than manually moving one mod to be after the other. For every mod conflict detected, the user can specify the load order relationship of the two mods (which one should come before/after, i.e. mod A is always supposed to be after mod B). This rule-based approach to the load order truly shines with large modlists, where manual load orders would be highly time-consuming, especially as mod relationships start to chain (i.e., mod A has to be after mod B, but mod A also has to be before mod C).
Obviously the rule-based load order is too much to ask, but a conflict summary for each mod in Irony's modlist, listing all the mods conflicting with that mod, would be my number 1 feature request.

Describe the implementation & alternatives you've considered:

1. Icon in mod collection table shown next to each mod with a conflict.
Hovering/clicking this icon would lead to a tooltip or new menu showing the conflict summary for that mod, ideally listing both the conflicting mods & the specific files, but just knowing the conflicting mods would be huge on its own for enabling the user to make an informed decision on their load order.

2. New column in mod collection table listing the names of all mods conflicting with the mod in that row.
An alternative to a conflict icon would be a whole new column in the modlist UI, where each row in this column contains the names of mods conflicting with the mod in that row. To avoid this information contributing to clutter, this column could be hidden/shown with the click of a button. For mods with tons of conflicting mods, it’s not feasible to display the names of all conflicting mods, so each cell can be capped at 5 mod names or whatever value. That cap value could even be user configurable possibly.

3. New field in Conflict Solver menu listing all conflicting mods of the current search.
Another viable alternative is adding a new field or dropdown option to the Conflict Solver where all mods that conflict in the current search are listed in one place. Combined with the existing mod filter functionality, this list would comprise all mods that conflict with the filtered mod. The Conflict Solver’s mod filter can already show all file conflicts for a given mod, but making an exhaustive list of which mods conflict currently requires manually browsing all file conflicts and keeping track by hand. Given the mod differential infrastructure is already in place, compiling this list would be as easy as adding together the names of the conflicting mods from all file conflicts. Compared to the minimal effort of this solution, the former two possibilities appear a bit more involved; for starters, Irony only calculates definitions & conflicts after the user opens the Conflict Solver, so showing conflicts on the main menu would require adding the ability for Irony to calculate conflicts on launch or on demand (in either case, it would be outside the Conflict Solver).

4. Allow load order to be modified while Conflict Solver is open.
A crude but effective band-aid is to allow the load order to be modified while the Conflict Solver is open. Basically, if we can’t show the conflicting mods on the load order, we bring the load order to the conflicting mods, which are already sort of shown in the Conflict Solver when using the mod filter, just discretely instead of exhaustively. Even without any of the other proposed features, this would have at least some impact. The user would get a sense of what mods are conflicting immediately, which is useful even if incomplete. The user would have to browse all file conflicts to get a full list of conflicting mods, but since not every mod is going to have dozens of conflicts, in many cases this could be done fairly quickly. Plus, this method retains the minimal UI of Irony’s main menu. On its own, this feature is still an improvement on the current situation & probably tied with the 3rd proposal (list of conflicting mods added to a new field in the Conflict Solver menu) for the cheapest solution to develop. A combination of these two would be best, if either are to be developed.

Additional context

Irony already has a built-in difference tool, so I doubt it's necessary, but WinMerge or other external tools could be leveraged to make things easier. It's also worth considering that Vortex & MO2 are both open source, if you're curious about their mechanisms.

[Hasselshoff]

I reviewed all open feature requests before posting, but I somehow missed one that is referencing the same concept of mod conflicts. In #20, an idea is posited of highlighting conflicting mods while a mod is selected in the mod collection table.

This would be a poor solution on its own but perhaps not without value. Obviously, any large playset would require scrolling to see the highlighted conflicting mods. I definitely would not prioritize this mod conflight highlighting proposal over any of my more comprehensive implementations.

EDIT: I have changed my mind on this matter. For modlists of average size (<100), the amount of scrolling required isn't bad at all. After simulating the work on my biggest modlist, the extra scrolling is definitely cumbersome, but I definitely wouldn't let it stop me from using the feature. The user can just move the conflicting mods closer together before fine tuning the load order when using a large modlist (>300 mods). Since Irony has the ability to tell a mod to jump to a load order position - instead of dragging clicking up/down - this really isn't as bad as I thought.

[bcssov]

You're mixing 2 different ways of how Mod Organizer and Vortex operate vs Irony. Vortex\Mod Organizer (never used them myself please note) detect filename conflicts Irony does a deep analysis of scripts and detects conflicts regardless of filenames.

For Irony to do that it must do a deep analysis which is slow and not as fast as just simple filename checking. Having said that this blows your initial proposal out of the window, or I could just go along with feature suggestion #20 and be done with it or use a mix of the 2 feature suggestions altogether. However filename conflict detection does not cover everything and at best can maybe cover 20-50% of reports. Depending on the type of mods you got. Giving a detailed overview on the mod page is impossible as the deep analysis takes too much time.

The only viable solutions to this would be in the alternatives you recommended that is 3 or 4.

Irony already has a built-in difference tool, so I doubt it's necessary, but WinMerge or other external tools could be leveraged to make things easier. It's also worth considering that Vortex & MO2 are both open source, if you're curious about their mechanisms.

Irony already supports external editors.

Also both of these tools are written in different languages:

• Vortex in typescript (I believe it's an electron app)
• Mod Organizer in C++
• Irony in C#

So, I guess given this new information you might want to revise your proposal? Or just recommend 3 or 4 that are the in the alternatives section.

[Hasselshoff]

TL;DR: Yep, just 3 & 4 would be by recommendation. Highlighting conflicting mods would be just as good but possibly more work to implement. More details below but that's the gist of it.
---

Thanks for the information. I was actually aware of the distinction between the filename detection & Irony's existing deep analysis method, and I'm not sure where exactly I went wrong in explaining myself to give off the idea that I didn't.

I think it's partially my fault for not being clearer, but I'll clarify now:

• I only referenced Vortex/MO2 to provide a topical introduction to the idea of listing conflicting mods & their UI implementation. I never said anything about some kind of code copy/paste between programming languages or anything like that.
• All my proposed implementations would leverage Irony's existing conflict analysis mechanism. I definitely did not propose adding a new filename-parsing conflict detection scheme for Irony or anything of the sort. I'm not too sure where exactly I went wrong here, but I have two guesses. The first being: when I mentioned the conflict detection on the main menu, I left it implied that the main menu options (1 & 2) would use the existing conflict analysis mechanism, but reading this again I see that the reader could assume these main menu conflict detection be filename-based. The second guess is my best guess; when I proposed listing all the conflicting files, I assumed that this was possible using the existing deep analysis conflict detection. By my estimation, all the conflicting files (and mod names) are already enumerated individually in the dropdown on the left side of the Conflict Solver menu, so I thought it would be feasible to take those filenames & mods and simply compile them into a list. That assumption might be flawed, though, and gauging your reaction it sure seems like it. Of course, since these proposed main menu implementations (1 & 2) rely on the existing deep analysis conflict detection, as I stated in my original request, there would have to be a trigger to perform conflict analysis on the main menu for options 1 & 2

Compared to the minimal effort of this solution, the former two possibilities appear a bit more involved; for starters, Irony only calculates definitions & conflicts after the user opens the Conflict Solver, so showing conflicts on the main menu would require adding the ability for Irony to calculate conflicts on launch or on demand (in either case, it would be outside the Conflict Solver).

• For the same reason (the conflict calculation is slow & doesn't run all the time or at launch, only triggered by entering the Conflict Solver), I specifically noted in my original feature request that options 3 & 4 are more viable alternatives, because they would exist in the Conflict Solver menu, after conflict analysis is complete.

just recommend 3 or 4 that are the in the alternatives section.

• You mentioned "the alternatives section" but honestly I just wrote this as 4 different suggestions. In retrospect, I should have led with my best or most viable proposal, which is 3/4. I can see that's confusing now, since I went off from the format and just wrote a bunch of options rather than a dedicated followed by alternatives (which probably contributed to the overall confusion of my post). So, yeah, 3 & 4 are my best foot forward. That would be my ideal combination in terms of being the easiest to develop and retaining the simplicity of the main menu.

For what my opinion is worth, I like the 'highlight-conflicting-mods' idea a lot, even more than my best proposals adding text lists. I would be satisfied if the only implementation was 'highlighting' rather than a text list. My topical knowledge of Irony, limited as it is, hints to me that doing something inside the Conflict Solver menu is naturally going to be easier, though. But I could certainly be wrong. And I am probably over-estimating the difficulty of adding a trigger to the main menu for the highlighting implementation. A simple button to trigger conflict calculation would suffice. The other more convenient options are unreasonable. Triggering the deep analysis on a timer &/or every time a mod is added would be ridiculous with any more than a handful of mods, and calculating at launch could lead to other issues, like startup failures. Even if that calculate-on-launch option were user configurable, it could be problematic. A button is simple & works.

All that being said, I really appreciate you releasing Irony to the wild. It really has made modding Stellaris so much easier. No one is entitled to your work or time, so I'm just thrilled to be able to make use of it. I don't expect anything to come of any request I make, to be honest, just wanted to bounce ideas and see what comes of it. So no worries if this isn't what floats your boat, I get it.

[bcssov]

You seemed to misunderstand my reply (somewhat).

I never said anything about some kind of code copy/paste between programming languages or anything like that.

Neither did I to be honest. You merely got a reply about studying the source code of these tools. You did suggest one can study the mechanisms of these tools; while their programming languages are incompatible which is what I mentioned.

All my proposed implementations would leverage Irony's existing conflict analysis mechanism.

My response is merely from a technical standpoint. We want to go with 1 or 2 we use filename detection as proposed in task #20; just a different UI. Or we go with 3 and 4 and do it in Conflict Solver.

Your format indicated one proposal, and others that were considered. You got a reply of why it would be problematic in the main menu and what's only possible there. Then got asked which ones do you recommend after a brief explanation of all options.

In the end this feature is accepted, it will be either 3 or 4. The other ticket being closed in favor of this one.

Do note that highlighting conflicts would probably only be filename based same as suggestions 1 and 2.

[LordOfLA]

one should keep in mind that Vortex can have its load after/before setup because Skyrim loads files as-is. Stellaris also has the nuisance that is FIOS/LIOS depending on which directory a file is being loaded from, so straight file a in mod b overrides file a in mod d are not fully effective in helping a user sort mods optimally.

Further mod a can have file c and mod d can have file z and they both conflict based on what they contain, but because the file names are different they won't show up on a file-name only comparison. I envisaged the filename-only comparison akin to what mod organiser 2 shows purely as a way to place mods with conflicting textures/sounds.

Code conflicts could only be realistically resolved with the conflict solver of irony.

Edit: plus for sorting my 300+ mod collections I don't even bother using the up/down arrows or specifying a number to jump to. I just export to clipboard, sort mods in vscode and import from clipboard. The visual feedback of which mods have conflicting textures/sounds would just aid in that sorting and potentially in alterations to my ignore rules for the solver so I could cherry pick textures/sounds as necessary.

[bcssov]

The feature will not show file conflicts, but take into account all conflicts when presenting in the UI (in the conflict solver).