The "expected/intuitive way" depends on the perspective of the user. That may be why I have been getting confused and seeing mixed messages.
We are sooo going in circles here... There are no mixed messages in MO
. There are mixed messages between posts on the internet that don't discuss MO
at all and what MO
You are confused because you desperately try to apply knowledge that is completely unrelated no matter how often I tell you "MO
doesn't work like Lojack said when he wasn't talking about MO
works like MO
tells you how it works!"
has a conflicts view. There it tells you which files conflict in which mod. And it gives you a warning if something you configured makes the conflicts view display wrong information. One line. And this is the truth, this is the reality and NOTHING you have ever read outside of MO
is relevant to how asset ordering works in MO
. There is one single line of information you have to read and comprehend to know everything you need to know.
In standard Skyrim asset priorization you have to know
which types of asset-containers are applied in what order, you have to know
your installation order and you have to know
your plugin order, all of which lojack documented in a lengthy post and from that information you can deduce which assets get used.
you don't have to know this stuff, you just look at the conflicts view. And therefore, since there is no need to "know" technical details to understand what happens we don't need a lengthy documentation.
All it could ever do is confuse the users, make them think there is something complicated to necessitate hundreds of lines of documentation, make them believe there is difficult stuff they need to know when there really isn't.
This is effectively like not installing the mod; however, the BSA could still be registered in Skyrim.ini, but as I understand it, MO does not effectively register BSAs via INI tweaks, right ... ?
When did ini tweaks become a part of this discussion? Forget ini tweaks, they have nothing to do with anything.
virtualizes the ini file as well as FS. When you allow MO
to manage a bsa that bsa will be loaded through the (virtual) ini file but this is a technical detail, you don't care about it
And please stop talking about "registered BSAs"! That is a term lojack used and is explained as "BSAs that have priority lower than plugin-loaded BSAs and loose files". This is not how BSAs work with MO
. They are loaded in the same way but that is a technical detail, you don't care about it
If I understand correctly from your explanation above, the standard load mechanism and prioritization are in effect when the plugin is checked but the BSA is not: The BSA is loaded with the plugin, and the BSA assets override other plugin-loaded BSAs loaded previously (as well as registered BSAs), but loose assets still override the assets within this BSA, regardless of the install prioritization of the loose asets (this is the standard behavior outside of MO). Is that correct (if it is, I will propose a better info text to avert confusion).
Yes it is correct, no it's NOT a better info text because it explains how MO
isn't supposed to work! Why would I document inside MO
This is another big point of confusion for me. Are you saying that MO adds an INI tweak to Skyrim.ini to register the BSA? I assume NO. I assume that MO loads this BSA according to the install prioritization as described above and that BSA registration is not even involved ... ?
What I'm saying is: that is a technical detail, you don't care about it
OK, so NONE of the Skyrim BSAs' assets (including the official DLC) are exposed within the conflict resolution of the mod Information dialog box.
And why would they? IF the vanilla BSAs were exposed then every single asset that replaces something in the game would be in conflict! And, since you can't modify the "installation order" of the original data directory you couldn't do anything about it.
But removing elements of control punnishes those that understand the functionality (or those that want to, are trying to, and are wise enough not to bother mod authors for their own lack of understanding).
While true, I do this in my spare time, I don't get paid for my work on MO
. Satisfying the users, while important to me it is NOT my primary concern. And while user groups usually find reasons why they should be more important to the dev than others, they aren't right. If a feature is mildly useful for user A but a major annoyance for user B I'll remove/replace it, no matter how much user A thinks he is more important.
Certainly, your testers (the MO and STEP staff among them) need to remain wary of what happens if things are not working correctly and to recognize any signs of problems. And we need to boldly emphasize certain talking points that address anything controvercial or not well understood.
"not working correctly" means "working different from how it was designed" not "working different from how someone expected it to work".
Testers, like regular users primarily need to understand how MO
is supposed to behave so they can recognize a deviation but they don't need to know how it is implemented.