Visualizing and resolving mod rules containing cycles

[oaabdellatif]

Note: I'm referring to loose file rules in this post, not LOOT rules.

 

So, I ran into a bit of an issue while setting up my mod list in Vortex for Skyrim. In setting up the mod rules in the proper order, I had created a rather difficult cycle between four different mods: SMIM, ELFX, RCI, and NSM. The problem is that Vortex's description of the cycle is completely useless. It only lists the mods involved, and doesn't give any indication of where the cycle is and how to resolve it. To address the issue, I had to draw out the rules and see what was going on.

 

 

Each node or circle represents a mod, and the arrows represent a rule. The direction of the arrows represents the overwrite order, so the mod being pointed to loads after the previous mod. The cycle is very easily seen in this graph; there is one between SMIM, ELFX, and RCI, and another between ELFX, RCI, and NSM. To resolve the cycle, I reversed the rule between ELFX and RCI.

 

 

Problem solved. Now there is no circular dependencies between any of the mods.

 

Essentially what I'm asking is for a better visual representation of issues like this. The average user would've been pulling their hair out to figure out how to fix it. In MO, when I encountered a cycle like this, I would've noticed while trying to set up the priority that there was no way to arrange them to satisfy the first graph.

[HadToRegister]

This is the one thing I wanted to warn everybody about using LOOT.
It's Sooooooo so insanely easy to make a circular reference, that EVERYBODY will do it at least once, and the longer the load order, the bigger the odds of it happening.

Thanks for the graphic though, that helps visual people like me understand what's going on.

[MarchinBunny]

This is the one thing I wanted to warn everybody about using LOOT.

It's Sooooooo so insanely easy to make a circular reference, that EVERYBODY will do it at least once, and the longer the load order, the bigger the odds of it happening.

Thanks for the graphic though, that helps visual people like me understand what's going on.

To be honest, I always use LOOT and I have never actually managed to do this regardless of the size of my load order. For example, from the graph, it looks like more rules are being set up then is actually needed.

If I am understanding this correctly.

RCI comes before NSM, SMIM, and ELFX

SMIM comes before NSM, and ELFX

NSM comes before ELFX

 

What appears to be 6 rules in total.

 

But could you not just set it up in the same order with these 3 rules?

RCI before SMIM.

SMIM before NSM.

NSM before ELFX.

 

Or am I misunderstanding something here?

 

Edit: Also, keep in mind if LOOT's automatic sorting puts it in the correct order by itself, you don't need to create rules. So just in case, I would always check to see where LOOT places things first before creating rules and only create the rules that are absolutely necessary while doing it in the least amount of rules. Obviously, if RCI needs to load before SMIM and SMIM needs to load before NSM, that means RCI can never load after NSM anyway because that would be contradictory, so you don't need a rule. The more unnecessary rules you create the more likely you will accidentally create a cycle.

 

I suppose for the average user this could be a problem, but I would reckon for the average user, they probably wouldn't be creating rules in the first place unless absolutely necessary. Granted, I do think there needs to at least be a way to track these things down more easily. It would be nice if Vortex can point out specifically which mods are the issue.

[oaabdellatif]

 

This is the one thing I wanted to warn everybody about using LOOT.

It's Sooooooo so insanely easy to make a circular reference, that EVERYBODY will do it at least once, and the longer the load order, the bigger the odds of it happening.

Thanks for the graphic though, that helps visual people like me understand what's going on.

To be honest, I always use LOOT and I have never actually managed to do this regardless of the size of my load order. For example, from the graph, it looks like more rules are being set up then is actually needed.

If I am understanding this correctly.

RCI comes before NSM, SMIM, and ELFX

SMIM comes before NSM, and ELFX

NSM comes before ELFX

 

What appears to be 6 rules in total.

 

But could you not just set it up in the same order with these 3 rules?

RCI before SMIM.

SMIM before NSM.

NSM before ELFX.

 

Or am I misunderstanding something here?

 

Edit: Also, keep in mind if LOOT's automatic sorting puts it in the correct order by itself, you don't need to create rules. So just in case, I would always check to see where LOOT places things first before creating rules and only create the rules that are absolutely necessary while doing it in the least amount of rules. Obviously, if RCI needs to load before SMIM and SMIM needs to load before NSM, that means RCI can never load after NSM anyway because that would be contradictory, so you don't need a rule. The more unnecessary rules you create the more likely you will accidentally create a cycle.

 

I suppose for the average user this could be a problem, but I would reckon for the average user, they probably wouldn't be creating rules in the first place unless absolutely necessary. Granted, I do think there needs to at least be a way to track these things down more easily. It would be nice if Vortex can point out specifically which mods are the issue.

 

 

My original post refers to loose file rules, not LOOT rules. Apologies if that wasn't clear. I imagine it would be much more difficult to create a cycle like this with LOOT rules.

[Tannin42]

I've actually proposed a visualisation like this to our focus group just saturday, their reaction wasn't great because they worried that with a large number of mods and rules
involved the graph it could get excessively large.
I don't see this as a great argument though since any form of visualisation of the rules will become hard to manage if it's too many but that won't usually be the
case and with a graphical one you could at least zoom and rearrange nodes to get a better overview.

Another thing that will probably happen (hopefully for both LOOT and mod load order) is grouping so you could have rules like "load texture replacers after patches" and then you'd only need individual rules for the mods within those groups.

[oaabdellatif]

I've actually proposed a visualisation like this to our focus group just saturday, their reaction wasn't great because they worried that with a large number of mods and rules

involved the graph it could get excessively large.

I don't see this as a great argument though since any form of visualisation of the rules will become hard to manage if it's too many but that won't usually be the

case and with a graphical one you could at least zoom and rearrange nodes to get a better overview.

 

Another thing that will probably happen (hopefully for both LOOT and mod load order) is grouping so you could have rules like "load texture replacers after patches" and then you'd only need individual rules for the mods within those groups.

 

Being able to see a list or some visual representation of all the rules you've set would definitely be a useful feature, since as of now you would have to check each mod that have conflicts to see them. I was thinking of having a graph like in the original post just showing the mods involved in the cycle be shown in the error messages, rather than making the user search through a graph of all their rules, although I would like to see both included.

[simsrw73]

I've actually proposed a visualisation like this to our focus group just saturday, their reaction wasn't great because they worried that with a large number of mods and rules

involved the graph it could get excessively large.

I don't see this as a great argument though since any form of visualisation of the rules will become hard to manage if it's too many but that won't usually be the

case and with a graphical one you could at least zoom and rearrange nodes to get a better overview.

 

Do you mean show a graph of dependencies for a given mod? This seems the most helpful scenario and one that would rarely grow that large. I would love that feature, especially if it can flag or highlight certain types of errors, cycles, etc. I'm not sure a multi-graph of the entire load order would be helpful.

 

Another thing that will probably happen (hopefully for both LOOT and mod load order) is grouping so you could have rules like "load texture replacers after patches" and then you'd only need individual rules for the mods within those groups.

 

Isn't that essentially what global priorities are? Or is this something more formal?

[HadToRegister]

I've actually proposed a visualisation like this to our focus group just saturday, their reaction wasn't great because they worried that with a large number of mods and rules

involved the graph it could get excessively large.

I don't see this as a great argument though since any form of visualisation of the rules will become hard to manage if it's too many but that won't usually be the

case and with a graphical one you could at least zoom and rearrange nodes to get a better overview.

 

Another thing that will probably happen (hopefully for both LOOT and mod load order) is grouping so you could have rules like "load texture replacers after patches" and then you'd only need individual rules for the mods within those groups.

 

A visual representation might be useful, but it would have to be customizable by the user.

For instance, for me, it would be easier to visualize the mod relationships in a stack, like a load order, with the dependency arrows along the outside, of course, having the mods in the actual order they are loaded helps too

[Tannin42]

Isn't that essentially what global priorities are? Or is this something more formal?

 

It's very similar and afaik it would replace global priorities in loot.

The main difference from the user pow is that you work with names instead of numbers.

From the technical side though the way it currently is is that rules override priorities so if you have plugin a with prio 0 and plugin b with prio 50 and set a rule a after b then a loads after b, the priority becomes irrelevant.

With groups if group 1 is set up to load after group 2 and plugin b which is in group 2 is set to load after plugin a which is in group 1 then that would be an error as it would create a cycle.

 

Also, loot currently has a fairly intransparent system of priority inheritance. Say you have an esm with a priority of 50 then all esps (non-masters) have a minimum priority of 50 as well. Setting a prio of 30 on an esp has no effect then.

This would become a lot clearer with groups. Plus easier to visualise.

[Maxsdad]

So how do us "mere mortals" (including those of us over 60) who don't understand half of what was just said, fix this problem?