Design considerations for a proposed extension to facilitate manual plugin ordering

[Deleted3897072User]

In another thread, a feeling was expressed that there could usefully be an extension to Vortex that makes manual adjustments to load order easier. Then, regardless of one's position about how load ordering should be done, other people would have a choice and the sum total of happiness in the world would increase.

It's too soon to cut code (we don't know how, yet, anyway) but software design is generally done before coding so we could get started on that.

Seems to me, that we could at least mull over these things:

• What do we actually want it to do? (a specification of requirements)
• How would we know if it was doing it correctly? (a testing protocol for functionality)
• What do we actually mean by easier? (usabilty criteria)
• How would we know if it really was easier (a testing protocol for usability)

And, last but not least,

• Who is going to volunteer to do it?

Please post constructively :smile:

 

[Deleted133263User]

Add another bullet point :

 

With this feature implemented, how do we expect the rest of the load order to behave in response to the Drag n drop placement of one plugin.

 

Explanation :

 

Do you want the whole LOOT Load Order management to be disabled ..

So no more automatic looking into plugins records and the amount of changes a mod makes to the game (in the case of an overhaul mod, this could potentially be placed last by a user stomping on all records and sub-records of all other mods before it, making all minor mods loading before it pointless for being installed),

No more Priorities for specific plugin placement (like the Bashed patch being last),

No more Load After rules to get A plugin to always follow B plugin no matter what else you do with the Load Order ..

 

.. Or - Do you want the plugin being drag n dropped to now be exempt from the rules .. But the rest of the Load Order to somehow shuffle around your decision to place a plugin where you have (trying its best to still apply the LOOT engine way of thinking in response). ?. In the case of the theoretical bad placement of the overhaul mod, then the LOOT engine would try to move all other mods after what you have just placed .. Defeating the objective of your placement

 

-----------------

 

I have a suggestion, that Vortex could have an advanced mode switch. LOOT Ordering, or Freestyle Ordering.

 

Because I dont think the two modes can be mixed. If you want Drag n drop placement, I think you would have to switch off the LOOT API entirely.

 

Which then adds another question - Is it even possible that the LOOT API could be disabled in Vortex

Edited February 11, 2018 by Guest

[MarchinBunny]

 

 

Which then adds another question - Is it even possible that the LOOT API could be disabled in Vortex

According to Tannin he mentioned that you can turn off autosorting. This means LOOT wouldn't play any part in it with that option off, unless you decided to do so manually.

[Deleted3897072User]

Thanks, yes I agree that does need to be decided.

 

<thinking aloud>

 

There is a button on the plugins page to enable/disable autosort, so theoretically that's not a problem. We could design the extension so that manual sorting was only enabled if autosorting was disabled, so they were mutually exclusive. Then the workflow would be:

1. optionally, enable autosort to get an approximate load order
2. optionally, disable autosort and do manual corrections

With autosort disabled, I can imagine having the autosort system putting up warnings if it detected rules being broken (with the option to disable warnings, perhaps), but not actively resisting the user.

 

Now, supposing the user has established a satisfactory load order and then installs a new mod. If autosort is disabled, we would need to define where its plugin(s) appeared. At the top? At the bottom? I don't think the choice is critical (it could even be a configuration option) but it needs to be defined for completeness.

 

This scheme would accomodate people who like to leave everything to the computer, people who don't trust the computer at all, amd people who think the computer isn't bad but they can do a bit better.

 

What it doesn't do, is to accommodate people who want to sort plugins by category and then sort within categories. To do that, we would need a mechanism for assigning categories to plugins (analogous to the one for assigning categories to mods), and an option to rough-sort by category without doing a full autosort, or, perhaps, to autosort with category priority. This is getting conceptually more complicated but I think it needs to be tackled.

 

I wonder: would it be conceptually simple if plugins inherited their categories from the mods that contain them?

 

Would it be possible to take a standard set of categories and assign each category its own global priority, then let autosorting do what it already does, which is to sort by rules within priorities? I have a hunch that might do the trick.

 

</thinking aloud>

[Deleted3897072User]

Picking up on my last point, The Load Order For Beginners and Advanced Users X1 Optimised Official Thread on the Bethesda forum lists around 27 categories in order. If we assigned a different (negative) global priority to each, spaced 3 apart to allow for later interpolations, they would occupy around 80 of the 127 available negative numbers. This might be a way forward.

 

Suppose we added a 'Manage Plugin Categories' (sub-)window?

Edited February 11, 2018 by OldMansBeard

[kamikatze13]

care to elaborate on why automatic and manual (i.e. drag'n'drop) sorting should be mutex'd?

 

IMHO the primary issue is usability and ability of quick adjustments.

 

<p> Then the workflow would be:

• optionally, enable autosort to get an approximate load order
• optionally, disable autosort and do manual corrections

Which would result in pretty much the same behaviour as with other mod managers when using LOOT. I like that.

 

As for how the rest of the load order should behave, when i thing about load order, i think of a priority queue - maybe treat it this way?

Edited February 11, 2018 by kamikatze13

[Deleted3897072User]

care to elaborate on why automatic and manual (i.e. drag'n'drop) sorting should be mutex'd?

 

Mainly because of the complexity of working out what should happen if there is contention. Suppose, by moving a plugin, I break a rule or violate a priority. Easily done. If autosort is active, what should it do? Refuse to move the plugin? Readjust all the other plugins to accomodate the change? Discard the rule? Change the priority? Make a rude noise? Keep quiet quiet and do it anyway? I fear there would be as many right answers as there are users. We would need to provide a menu of options for what the user wanted to happen under all possible circumstances. Well, okay, we might do that but it makes the whole thing far more complicated and complicated software is harder to use, harder to understand, and harder to maintain, all of which are, to my mind, undesirable.

 

My thinking is that it's so much cleaner and simpler to keep the two modes - auto and manual - distinct. We only need one button to toggle between the two, and that button already exists. Also, from a sofware engineering point of view, it partitions development between the core Vortex and this proposed extension - changes to one won't affect the other.

 

But, that's just my opinion and I'm not going to tell people that they have to do it my way :D This is the time, right at the outset, where everything is malleable and everyone's opinion is equally valid. Later on, when we start drilling down towards cutting protoype code, then it become harder to change these decisions.

 

Keep the ideas coming, folks !

Edited February 11, 2018 by OldMansBeard

[simsrw73]

Personally, I'm not in favor of this plugin, but what constraints does Vortex place on plugins/extensions? Can extensions modify the Vortex UI such that the current plugin list can be used for manual ordering? I'm assuming not. I'm assuming a well behaved extension will have to open up it's own UI, load plugins.txt, present a list to be ordered and let the user order it, and save it back to file and exit, allowing Vortex to pick things back up. I don't know enough to answer that but it will dictate your design to some degree.

[kamikatze13]

I like the idea of the rude noise =P

 

I agree with you, complexity should be kept at a minimum.

 

As for extentions, we'll have to wait for tannin to disclose documentation and api, but i'd expect seamless integration, at most via an additional tab, but certainly not a separate window. The goal is to facilitate manual load order management and improve usability - if we'll be forcing people into another window/UI element, we're forfeiting that goal, aren't we?

 

Also, do we know how the load order is stored? is vortex directly modifying a plugins.txt or does it maintain a separate data structure and only writes at deployment?

Edited February 11, 2018 by kamikatze13

[Deleted3897072User]

Yes, we will need to understand how Vortex works internally to be able to decide how to code whatever set of abstract requirements we settle on. We can't do that yet, but we will have to do it down the line, sooner or later.