Auto-sort based on rules

[Doc0160]

I apologize in advance for the tone.
I have debated for some time if I should open a feature suggestion or not, given it as been refused a number of times.
But I always come back to it because of frustration.
The text below has been written in multiple waves of frustrations and is a bit of a mix between a feature suggestion and a "frustration rant".
I've tried to edit it to be less of a rant without removing necessary details.

My use case

I sometimes forget to properly sort my mods, or verify load order on the mod page and I accidentally mess up my load order way too often : sort load order by mod name, accidental drag and drop, click on wrong arrow, and other user caused issues.
Dyspraxia and trying to "make precise movements in reasonable timeframe" don't mix well in any context (and the frustration of messing up the load order while trying to fix the previous mess up doesn't help with that problem either).
I'm eternally thankful for the undo/redo and import/export features, but auto-sort would more or less resolve the friction I experience with load order management for me.

Feature

An auto-sort that doesn't require community-wide/community-driven initiatives or constant management/moderation on the IronModManager side to exist.
An auto-sort as a quality of life UI feature and not a perfect technical mod conflict resolving machine.

Simply a "Sort" button, and a configuration window to define sorting rules, and import/export it to a file.
Perfect for making "UI Overhaul Dynamic - Dark UI" load after "UI Overhaul Dynamic", and other similar cases, but not smarter than that.

"Sort" would be the broad stroke approach of mod conflict resolution, leaving the "Conflict Solver" button or other tools to be the detailed approach.

The sorting algorithm would documented in detail on the wiki.
And the sorting rules are completely left to the user.

I think a naive algorithm, where each rule is executed in order, without care of the other rules, would be good enough in most cases.
This would be easy to implement, fast to run and converge to a semi-stable load order after a few runs of the algorithm (given no rules conflict with each other).

(See last section for detail on what I think the configuration screen should be)

As someone who heavily mods Skyrim, Rimworld, Minecraft and Factorio, I can say :
Sorting mods doesn't magically solve mod conflicts in any game.
It only helps manage how that conflicts occurs, hopefully for a better result (like putting the Dark UI submod after UI Overhaul)
It doesn't help if mod A add things to a crafting table and mod B removes that crafting table for example.
That is where merges and patches happen in theses games, and the FIOS/LIOS question in Stellaris also is.
Auto-sort deals only with load order, not the content of the mod itself (order is a higher level abstraction for mod conflict resolution, not a mod specific implementation of a conflict resolution, and that is the case in any game).
(We should also be thankful that, to my knowledge, Stellaris doesn't have .dll executable type mods like some of the game I mentioned : having to manually patch an executable, deal with arbitrary time delays before the mod inject itself, game becoming a webserver, completely rewrite part of the game engine and other such fun but insane things. It's a whole other type of mod conflict.)

Evolutions

• Configuration option to download/update rules from link : that would allow for a community-made repo of rules as-is.
• Suggestion: Optional mod provided metadata #416, with user defined rules applied after or with higher priority, overriding the descision.
• Better sorting algorithm, with an option to switch between algorithms.

Configuration window (feel free to skip that part and do it differently)

The configuration window would have table with columns Order, Mod Name, Rule Type, Other Mod Name.

Order would be a priority/preference for rules conflict resolution (ex: two mods want to be at top, "mod a before mod b" and "mod b before a" situations and others).
Mod Name would be the mod the rules applied to and that will be moved by the sort.
Rule Type would be the type of check to determine if the mod needs to move, and where the mod should be moved to. The options would be :

• Always at top (No Other Mod Name needed)
• Always at bottom (No Other Mod Name needed)
• Before Other Mod Name
• After Other Mod Name
  Other Mod Name would be the point of reference for the check and move operation.

[bcssov]

This is actually a problem space I've been thinking about for years, and there have been multiple suggestions around it. They were just approached from a different angle.

Instead of a rule/constraint-based sorter, the idea here was to group related mods into parent/submod relationships so they move together and preserve relative ordering. It's an old suggestion, and I made a mockup for it a long time ago.

For example:

• UI Overhaul Dynamic
• Dark UI
• compatibility patches

Moving the parent mod would also move the children while keeping their internal order stable.

The intention was more of a UX/QOL solution for maintaining consistent load order structure rather than a smart LOOT-style resolver.

Would something like this cover most of the workflow you described, just solved differently?

[Doc0160]

Partially.

My preferred workflow is : add mods, auto-sort, patch for things auto-sort doesn't and can't handle.
So no matter how messed up my mod list is, if I have the same mods, I can click auto-sort and be back to 80-90% of where I was before things got messed up, and I just need to re-add or remake patches.
It creates a clean base to start patching mods (and resolves mod conflicts completely in simple mod lists).
It's very difficult to have that level of instant usefulness outside of a rule-based sorter, especially with heavy modding where the granularity of individual mod relationships can snowball issues really fast.

The group idea is good for simple submods (especially if groups can be reused between collections).
But it leaves mods with multiple dependencies and weird cases of unrelated mod conflicting when not in the right order.
You could technically make those cases fit in that style of grouping, but you risk ending up with half the modpack in the grouping and having to extract those to the main list later because of dependencies.
Technically "Conflict Solver" is the tool for unrelated mod conflicts, but a bit excessive when changing the order does what you want.
Groups don't always scale well when dealing with heavy modding : 1000+mods, multiple tiers of submods and the tapestry of relation types that emerge because of that, especially with multiple dependencies per mod in mind.
I'm not at that level of modding in Stellaris, but that is what I do with other games, so give me time.

If the group idea is still preferred, a version without the parent/submods relation would also be good to have.
That would fill the niche of separators on some mod managers with the additional benefit of preserving load order : one group for "Essentials", "UIs", etc. ; it's not smart for mod conflicts, but nice UX/QOL nonetheless.
(And even better if groups can be reused between collections ; that would be a time saver when making new collections or updating old ones.)

So groups would help for my current usage, but will be less and less useful as I keep modding.

[bcssov]

Adding help needed tag if someone wants to tackle this. I don't have much spare time.