Repository navigation
Generate graphical display of difference between pre- and post- sort orders #377
Description
Back when LOOT was BOSSv3 beta 8, it could generate an image of the plugin graph used to sort the load order. This functionality was removed because rendering the graph image was slow, required the bundling of a separate executable, and the result too complex to easily glean useful information from.
An idea that came up was to save the graph data each time LOOT calculated a load order, and then use that data to produce an image that displayed the difference between the previously calculated load order and the newly calculated order.
As the difference would be much less to render than the whole graph, this should solve the performance problem, and the difference would be of greater benefit in informing users about what changes had occurred than the full graph.
Boost's graph library can output GraphVis files, and a quick search comes up with a bunch of JavaScript renderer libraries that could be used to produce images from them, which would be neater than using a separate executable (and could be done asynchronously with greater ease, so that the whole process was not slowed down).
Activity
Ortham commentedon Jun 15, 2015
Something else I just thought of: if this is done, then edges should have a "type" property, to distinguish between priority, conflict, etc. edges, and the edge types should also be displayed in the generated image.
MacSplody commentedon Sep 26, 2018
Taken from discord
https://cdn.discordapp.com/attachments/473543945188802580/494356108131958784/unknown.png
Just my thought on it, but something built into the
UIinstead of a generated image might work instead, but I'm not sure if that would be more costly than generating an image. I mean you already have pre and post sort load order when apply is showing.The second list might not even be necessary.
It would have to show which mods where moved, the direction and how far. While ignoring mods which moved relative to that change.
This could even be extended further to have labels for the rule type which caused the change.
Such as
Group,Load after,Master.lmstearn commentedon Dec 16, 2018
LO history sounds like a great idea tailoring to such parameters as:
pStyl3 commentedon Sep 4, 2019
Two months ago, we discussed this a bit more in Discord, and Ortham produced a couple more graphs. So let's post the discussion here as well, so that it doesn't get lost.
Ortham:
pStyl3:
Ortham:
Ortham:
Ortham:
Kerber
Ortham:
Ortham:
pStyl3 commentedon Sep 4, 2019
pStyl3:
Ortham:
Ortham commentedon May 9, 2026
I've edited pStyle3's posts above to include the original images that he was referencing inline, since the host he was using stopped serving the images.
Ortham commentedon May 9, 2026
I recently experimented again with displaying the plugin graph, by repurposing the groups editor's graph view. However, calculating a sensible layout remains a showstopper: with my 1630-plugin Skyrim SE install, opening the editor causes memory usage to spike over several seconds, and I have to kill the process when it goes above 50 GB.
With a 31-plugin Starfield install, opening the editor takes about 1 second and uses 80 MB of memory, but even with this small load order, the graph produced is busy enough to make it difficult to read:
zoomed in a bit:
So moving to the Qt-based GUI didn't solve the problems I'd seen before (not that I expected it to).
What has changed very recently is that LOOT now has a dialog for viewing the load order changes after sorting:
It shows what has changed in the load order, though it intentionally doesn't show how much a plugin's load order index has changed by, for two reasons:
The dialog doesn't explain the why of anything. There is more than one why question though, for example:
Why did plugin X's position change?
This can only really be answered by displaying a diff of the whole plugin graph since the last time LOOT sorted the load order, since the change may not be directly related to X. The change must be somewhere in one of the paths that go to or from X, but since every plugin is necessarily connected to every other plugin in the graph, that means the whole graph is in scope.
It's worth bearing in mind that this will only be possible if the current load order was produced by LOOT, otherwise LOOT won't have the graph data to explain it, and the diff will be against some other load order, so there would need to be handling for this case (probably just a "sorry, can't be done").
Why is plugin X sorted after plugin Y?
This can be answered by displaying the path in the plugin graph between X and Y, similar to what's done when there's a cyclic interaction error. Since that's just a linear sequence of plugins, that's easy to visualise.
Why is plugin X positioned where it is?
This is a vague question, but I see it as asking about X's context in the plugin graph. It might be answerable by showing the direct connections for X, but that might not be enough context.
You could show this by displaying a graph view to the side of the plugins list, and clicking on a plugin in the list would add it and its direct connections to the graph view. Clicking on another plugin (in the list or in the graph view) would also add it to the graph view, and so you could build up the plugin graph piece-by-piece until you had enough context. A bit like pStyle's images above, but without displaying the whole linear load order in the graph to start with.
The graph displayed would start off relatively small (though a .esp would load after all .esms, so there could be a lot of plugins even to start with, but only one line per plugin), so the layout shouldn't be too expensive, but that would change quickly as the context displayed in the graph view grows, and would probably soon hit the performance limitations I've seen with even quite small load orders.
This is similar to what's requested in Display plugin dependency graph #837, though I think that's limited to only the hard sorting rules (so no groups, overlaps or tie-breaks).
I'd like to do something in the area of this ticket, but first I think I need to understand which specific questions people have, and which would be most useful to answer.