Ideas how to resolve the manual load order/forced loot/meta rules problem

[csabati2]

I am not as smart as the rest of you so bare with me a second.

I have been using Vortex for a couple days now and trying several things, including manually ordering plugins.

That said:

 

You have

a. esp

b. esp

c. esp

d. esp

 

you want:

b. esp

c. esp

a. esp

d. esp

 

In Vortex to accomplish this you -

Grab the dependencies icon for a. esp and drag it to c.esp

A window will open giving you the rule a.esp "Must Load After c.esp

you can either confirm that or cancel it. If confirmed, that rule will stand until you manually remove the rule from a.esp.

 

It is simple fast and stays in place even after re-running LOOT.

 

Ok. Now start yelling and tell me what I missed. :smile:

 

This is pretty much my experience. I didn't like it at first, but it's not too bad after getting used to it. Not as easy as MO drag and drop, but also not as annoying as using the arrows from NMM.

 

EDIT / P.S.:

 

One thing I would like to see is a little automation for rule changing. As it stands, I need to remove rules in order to change them or risk errors when I try to sort. I would like to just make the new rule I want and the application to automatically remove any redundant or contradictory rules.

[Oblitus]

I am not as smart as the rest of you so bare with me a second.

I have been using Vortex for a couple days now and trying several things, including manually ordering plugins.

That said:

 

You have

a. esp

b. esp

c. esp

d. esp

 

you want:

b. esp

c. esp

a. esp

d. esp

 

In Vortex to accomplish this you -

Grab the dependencies icon for a. esp and drag it to c.esp

A window will open giving you the rule a.esp "Must Load After c.esp

you can either confirm that or cancel it. If confirmed, that rule will stand until you manually remove the rule from a.esp.

 

It is simple fast and stays in place even after re-running LOOT.

 

Ok. Now start yelling and tell me what I missed. :smile:

Remove "c" and you'll get "abd" instead of "bad", since you don't have a rule that "a" loads after "b".

 

Also, adding e.esp between c and a would require two rules - e.esp loads after c.esp and a.esp loads after e.esp. More you add, more complicated ruleset becomes. It's because that rules don't reflect your real intentions. You don't want "a" to be loaded after "c". You want "a" to be loaded after "b", "c" and any other mod that would be added before "a" in future, but before "d" and any other mod which woudl be added after "a" in future.

[cortex56]

Removing a rule is a two click process.

Click the dependencies icon, a small window opens showing the rules you have set for that esp.

each rule will have a (-) next to it, just click that and the rule is removed.

 

Changing rules is simple and fast.

You can set as many rules for one esp as you need.

 

In fact several esp's have rules already set that the user is unable to remove, set by the author or the mod I presume.

Some have 10 or 11 rules.

 

So yes in the example below, you would have to set two rules for a. esp to load it below b. esp and loading more esp's that you want to manually order will require moving them into position and adding that rule.

 

The nice thing is, once you set this rule or rules, they do not change position.

And the drag and drop makes it very fast, and the window auto pops up with the rule already there, all you have to do is click the ADD button.

 

I don't know about MO, I never used it. But with NMM, moving esp's up or down the list, then running LOOT, you would have to move them again.

I used LOOT to set my rules prior to Vortex so Vortex is a God send for me.

 

It is fast, easy to use and does almost everything I want a MO to do.

 

Take time to work with it a bit when you get the opportunity, the more I work in it the more I like it.

 

Yes it is missing a few things, although reading through the forums I see Tannin has a todo list of those things, so... Great!

[kamikatze13]

If we regard 'finding a satisfactory load order' as a mathematical constraint-satisfaction problem, I think it becomes a little clearer where the differences of opinion are arising from. There are two types of constraints in the mathematics: inequality constraints (which translate into loads before and loads after) and equality constraints (which translate into loads at). A general solving method would take both types into account. You've implemented a solver that allows inequality constraints (although you might not be thinking of it in those terms) but doesn't provide for equality constraints. So it's incomplete. People wanting drag and drop positioning are effectively asking for equality constraints (I want this plugin there) to be supported as well.

 

Does this make any sense?

I would never have expected to see someone mention CSPs in a wild nexus thread. Color me impressed.

[VaultBoyAM]

You're saying equality constraints translate to "loads at", we already have kind of a "loads at" in the form of global priority, don't we? However if we tell it to load a mod at say pos. 10, it should automatically change to pos. 9 when a mod before it is removed, rather than load the mod previously at 11 to load at 9, which could break our original mod.

We could have an expanded inequality constraint, tell it to load mod D after mods A through C that are already LOOT ordered, it would reduce the number of individual dependancies that we have to set. It would also remove the problem in which you add or remove anything between A and C and have to make additional rules.

It could be a "soft dependancy", kind of a secondary ordering once all masters and dependants are sorted by LOOT and only if it wouldn't go against one of the primary, required ordering.

At this point I'm just wondering out loud though, this kind of thing might be hard to make fool-proof.

 

Oh and isn't CSP a high school level topic? If it's not, it should be.

[Deleted3897072User]

You're saying equality constraints translate to "loads at", we already have kind of a "loads at" in the form of global priority, don't we? However if we tell it to load a mod at say pos. 10, it should automatically change to pos. 9 when a mod before it is removed, rather than load the mod previously at 11 to load at 9, which could break our original mod.

 

We could have an expanded inequality constraint, tell it to load mod D after mods A through C that are already LOOT ordered, it would reduce the number of individual dependancies that we have to set. It would also remove the problem in which you add or remove anything between A and C and have to make additional rules.

 

It could be a "soft dependancy", kind of a secondary ordering once all masters and dependants are sorted by LOOT and only if it wouldn't go against one of the primary, required ordering.

 

At this point I'm just wondering out loud though, this kind of thing might be hard to make fool-proof.

Yes, global priority can be used to achieve it, but not trivially (I've tried it). Suppose I have an automated test script that expects ModA to be at position 82. To be absolutely sure of getting it there and staying there after possible subsequent re-sorts, I can assign it a definite priority (1, say), choose 81 mods and give them each a lower-numbered priority (0) and give all the other mods a higher priority (>=2). Then, if I subsequently add another mod, I can give it 2 or higher or swap out one of the zeroes and slip it into that place. This is possible, obviously, but requires a lot of clicks in Vortex because the UI design in Vortex isn't optimised for doing that, and it requires me to count down the list by eye to check that it's right (which is itself error-prone) because the positions are not numbered in the display. It could equally be done by rules with 80 loads-before rules and N-80 loads-afters. But again, this is tedious to do and, since I already have software (NMM) that does it much more easily, I'm going to use that instead and uninstall Vortex (which I've done).

 

Now the response is, I shouldn't want to be fixing my mods at definite positions, it's badwrongthink and I should only want define them relative to other mods because that's all the game cares about. It's quite true that that's all the game cares about when it's running mods, but it's not true that it's all that I have to care about when I'm testing mods, for reasons that I've posted elsewhere.

Oh and isn't CSP a high school level topic? If it's not, it should be.

I don't know. It's so long since I was in school, I don't think it had even been invented then :wink: But I sort of assumed that Tannin would be familiar with it and would recognise what I was saying ( even though he doesn't have to agree :D )

[Ethreon]

~

 

You missed the part where understanding how to manage mods in vortex and their dependencies is clearly understood, but not desired by some of us. Whether someone else makes a plugin doesn't matter much - I can now do all I need the way I need it using basic mod managers, therefore Vortex will serve no purpose for me. Just like OldMansBeard I don't expect Vortex to change anything, and I'll happily continue using NMM with it's good and bad parts.

[AL12]

To me the problem seems pretty simple Tannin.

New users and casual users dont want to care about load order, you saw this correctly and included automatic Loot sorting.
As these users start to get bigger setups, loadorder problems may arise so adjustments might be needed. You saw this too and implemented the loot rule system integrated in the gui.
But then there are good number of modders by now (considering Skyrim was released in 2011) that are veterans, have complicaed setups and are well versed in the modding knowledge. These obviously comprihend the mod creators themselves.
These people will also need a manager bu not for the goal of running the game without problems but to develop things. Adopting the Loot system as a primary system is a very good idea since it's the correct way of doing things and many users wan it to be like that (something that they don't have to care about if not in rare cases). But for the veteran modders and mod creators having to set individual rules just to move a plugin in determined spot to test somethig, then removing thise rules and set up new ones to move it again, its just not convenient enough. Now you have said different times that there is no reason to move a plugin in a particular spot because the underlaying problem is a conflict not the position that matters, you are right and you then argued that rules is the right way to go because they are the appropriate answer to the underlying problem which is a conflict. A agree to that, but what if I have a plugin that has conflicts with 15 other plugins? The correct way of doing it for an end user is to setup 15 rules and he would never have to worry after that, but for the mod creator or the advanced modder that wants to change that to test things, he needs to track down the rules he set up, disable them and put up 15 new rules just to try a different configuration. Using positioning for a plugin in a list of 100 plugins is the equivalent of instantly setting 99 rules. You make a really valid argument saying that probably 80 of those rules are redundant, but you can't argue againts how much this is more convenient and fast. Also as true as it is that rules solve the underlaying problem, they are not what the game recieves in imput: the game expects a sequenatil list of plugins. People can counter argue that Vortex is complicating something that is simple and sequential with rules that are not simple and sequential. It is just much easier to think of a list than a set of rules. There are many occasions where putting a plugin manually somewhere is simpler, as an example, somebody creates his own plugin and wants to quickly test it. Does he first look what kind of conflict he has with what mods and sets all the rules accordingly just to test it a moment, of course not. He just wants to put it somewhere he knows won't make problems, drag and drop will let him do that without even having to think. It is not the right thing to do, but he is not looking to resolve conflicts at this moment, he is looking to test if his plugin without having others overwrite it. Yes you can use the rules to give it a global priority or make it load after the last but these are not correct rules, they are saying that that plugin needs to alwasy load after the others or after waht happend to be the last one at that moment, which is not reflecting an actual conflict solution. The guy is forced to create a rule that is not true just to make a quick test. In that case those rules are jsut as imporper as imposing 99 rules with positioning, but positioning is just way more convenient and fast.

The way I would personally want to manage my loadorder is to let Loot order things by itself for the most part. If I know that a mod is misplaced by loot I would add a rule for that plugin and then be glad to let loot do its thing. If I need to test plugin or I need to be sure something is laoded correctly I would momentarely enable manual ordering put the mod I want where I want it and run my tests. Once I ended my testing I will then disable manual ordering and procede to add the appropriate rules.

Summarizing my points:
Integrating loot is a great idea and will make life easier for a lot of end users.
The rules system is a good system, it will help improve Loot and you can do everything with it.
But it is not convenient for creator or advanced users that need to move around stuff and rappresent an ulterior abstraction to what is actually being handled, which is a sequential list of plugins.

What people would like to hear is that Vortex will allow in future for drag and drop plugin ordering as a secondary (or even hidden) option.
This way new or casual users will be satisfied with the easy auto ordering, more advanced users can fully utilize the rules system to resolve their conflicts and even more advanced users and creators don't have to sacrifice convenience or ease of use. Everybody would then be happy. I know this means more work but since people won't shut up about it I hope it will be considered.

[Lazybob1]

I'm in agreement with al12rs. That is the best summary of why there should be drag and drop. I've seen a lot of people upset about the absence of drag and drop but most don't bother to explain the exact issue with not having it. They either don't understand how vortex works yet, argue that taking control away is bad, or argue that because all other managers have it vortex should too without explaining why having drag and drop is a good thing. The issue is that while yes you can still move mods around for testing with Vortex but it is far less convenient then drag and drop and will drive advanced users and creators away unless its added or someone makes an extension for vortex that allows it. It could be argued you could just run wrye bash or something when you need drag and drop for that purpose but then you may as well use wrye bash as your mod manager anyway.

[VaultBoyAM]

I can assign it a definite priority (1, say), choose 81 mods and give them each a lower-numbered priority (0) and give all the other mods a higher priority (>=2).

I didn't know the global priority worked like that (I hadn't tried it yet). That sounds way more painful than it has to be. It'd only be good for load-first or load-last situations.