Clarification on Mods with INI Configurations

[z929669]

1 hour ago, DoubleYou said:

I feel that both solutions have drawbacks, and I wish MO2 had more intuitive controls for this situation, but I feel the issue here is simply that the instructions are not as clear as they could be. This is how I would suggest it be written:

1. Double-click Overwrite and navigate to the SKSE/Plugins folder.
2. Drag and drop the Fuz Ro D'oh.ini file onto the Fuz Ro D-oh - Silent Voice mod.

Yes, these instructions make sense, but only after doing the "first launch", so I think the instructions on this mod page and others like it should be omitted and essentially moved into the First Launch area of our guides.

It sounds like you might be advocating that these configs be stored under the SKSE mod, but I do see the wisdom of using an SKSE Output mod just to partition things as Tech alludes. But then there's a difference with SKSE mods that don't ship with a config file versus those that do. Those that do will have such files in the source mod, while those that don't will have them in Overwrite (or an existing mod for those of us that set that up). The instructions really depend upon the user experience. We don't really set things up from scratch but rather build upon existing builds, so many of the little 'gotchas' get overlooked.

I plan on rebuilding everything from scratch to get a better feel for what we tend to take for granted. This also pertains to cleaning the vanilla masters and such.

So @Brambleshire, I'm hoping there's enough info here such that you get the idea about how there's potential variation in how to organize mod assets and leverage some handy MO features. There's really no one 'correct' way. Nevertheless, we should be as consistent and clear as possible in our instructions. It will all be (re)polished in the not-so-distant future.

[Mousetick]

I use a single 'Configuration' mod with highest file overwrite priority, in which I place all user-editable configuration files, whether they come from mods when they are installed or they're created at runtime. I typically keep a copy of the original configuration in its respective parent mod folder, as a 'default configuration' reference. This eliminates all risk of losing my changes when updating mods and keeps everything in one easily found place.

As this involves a lot of manual file & mod management, I wouldn't suggest it as an approach for the STEP Guide.

I'd like to suggest another approach for the guide, derived from it: provide a ready-made 'STEP Configuration' mod, containing all the configurations for the mods used in the guide, to be installed like the STEP Patches.

Pros:

• Mods are already configured as they should be for the Guide.
• Eliminates a bunch manual of mod/file management/editing at installation time, and dealing with stuff appearing in MO2 Overwrite at runtime.
• Eliminates a bunch of associated documentation describing how to perform the previous.
• Streamlines documentation and support, removes ambiguities when referring to configuration files and their expected location.

Cons:

• Needs to be installed early in the Guide, in order to perform the 'Game-Launch Smoke Test', and then sorted to bottom of mod list before performing the 'Performance Tuning', and then sorted again to bottom of mod list after installing the 'Post-Processing' group. These extra steps can be easily explained to, and achieved by, the user with MO2 UI (right-click mod -> Send to... -> Highest Priority), but they could be missed (as any other extra step).
• May need to be maintained to keep up with mod updates making not backward-compatible changes to their configuration. Though nowadays a lot of "modern" mods are well-behaved - particularly those that create their configuration at runtime if it doesn't exist, and update it dynamically if needed and it already exists.
• An existing user updating the 'STEP Configuration' mod to a later version downloaded from Nexus, would lose their custom edits if they made any.

This would not completely eliminate the need for manual editing of some mod configuration files (e.g. SSE Display Tweaks), but it's not worse than other approaches in that regard.