Jump to content

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


kojak747

Recommended Posts

I think we should try and find a way forward with this issue and see if we can come up with a solution.

 

I'm not going to profess to be highly knowledgeable about it, but rather than me explaining why it's wrong for me, here's one idea I had.

 

Allow us to manually sort load order via drag and drop. At the same time, when moving a plugin, write to a text file that the user wants the plugin they moved to have a dependency on whatever other plugins are deemed necessary. Use that text file to accumulate data to send back to loot. That way loot servers can get useful data whilst we can manually sort. After a while you will have thousands of possible rules that can be punched into the loot algorithm. Then, suggest(not force) to the user that collected data thinks you should put this plugin here...or not.

 

Just my 2cents

Link to comment
Share on other sites

Sorry, I must have missed a piece of discussion about the Load Order, what is actually the problem with the load order on Vortex? (I'm not sarcastic: I don't understand)

 

I mean: Between manage dependancies (that should [iMO] be renamed in "Manage Order Rules") and the double click to open the Priority sub tab I managed to put almost everything where I want to...

 

Did I miss something?

 

 

About the Drag&Drop: Tecnically is doable but is inefficient and also a bit useless:

Or simply you say "no matter what A should stay in position X"? then if the load order isn't enough long you'll have another problem.

If A goes After C and Before D, what if you remove C or D? What if you move one of them? Did you move the whole block? And what if you move D over C (loop).

Link to comment
Share on other sites

 

What rule do you write?

What rule would i have to write into LOOT to get this result, given the current state of Vortex?

 

I think that's the point of the Tannin's question. If you drag & drop and want Vortex write the rule, what is the rule? Vortex has no idea what you are trying to accomplish with that one drag & drop move. It's ambiguous. This is why rules are better. They are non-ambiguous.

Link to comment
Share on other sites

 

 

What rule do you write?

What rule would i have to write into LOOT to get this result, given the current state of Vortex?

 

I think that's the point of the Tannin's question. If you drag & drop and want Vortex write the rule, what is the rule? Vortex has no idea what you are trying to accomplish with that one drag & drop move. It's ambiguous. This is why rules are better. They are non-ambiguous.

 

 

Thank you.

That's exactly the point: You need rules to resolve conflicts with a rule you not just set a position for a mod, you declare that those two mods are somehow in conflict and that information is available months later.

You can translate rules into a serial load order but not the other way around because rules contain more information.

 

And if you step away from your game for a few months and then get back the rules will still be there to tell you which plugins/mods you had to rearrange manually but you will have no idea why you set up a load order in MO the way you did.

It becomes this magical thing that somehow makes the game work if you don't touch it but you don't know why.

Link to comment
Share on other sites

I guess i see it now.

 

The "new way", if you allow, is less of a "`sorting` a fixed-lenth priority queue" mindset and more of a "set of rules on conflict resolution", but for the entire loadorder instead of just the edge-cases. Somewhat of a new, and arguably better, if more tedious, approach, so to speak?

 

That's a bold strategy, tannin, forcing people to their luck. Let's see if it pays off.

Link to comment
Share on other sites

You have

a.esp

b.esp

c.esp

d.esp

 

You drag a.esp down two slots so you get

 

b.esp

c.esp

a.eps

d.esp

 

What rule do you write?

a #= 3.

 

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?

Link to comment
Share on other sites

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. :)

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...