You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The whole "disable patches first" thing is proving to be very difficult for at least some subset of users, either due to confusion over what constitutes an "overhaul patch" or just general difficulty with the mechanics of it, especially in Vortex.
In some interim version, probably 0.3, the detection on overhaul mods was improved so that overhauls themselves could never be detected as default plugins. The detection uses some heuristics (% of faces, % of only faces, etc.) but seems to be quite reliable.
One thing that was never looked at as a follow-up to that was extending this into patches. It just hadn't come up as a major issue at the time. However, if a visual overhaul should never be selected as default, then it logically follows that a patch for that overhaul should not be selected as the default either.
I doubt the detection here is perfect... but it might be just good enough to drop the whole "no patches" thing if it catches 99% or 95% of the problem-plugins. The whole reason for anti-patching is just to prevent them from ending up as defaults, and if we can prevent it a different way that doesn't require any manual work, then the process can be made a lot easier. Which is of course the whole idea.
If the detection is almost perfect but not quite, a few broad-targeted manual overrides could help smooth over the rest. For example, in addition to implementing #17, add a feature somewhere to "remove from defaults" that would cut out an entire plugin from all NPCs using it. Or, some type of "soft reset" feature that could allow users to identify patches in the load order or just any mods they want removed - i.e. rather than doing it one at a time. It's not good if these hack-fixes become a core part of the workflow, but if they just deal with a few strange edge cases, they're more palatable design-wise.
The text was updated successfully, but these errors were encountered:
Adding one refinement to the detection: check if the "master overhaul" actually edits the specific NPC before passing over it. Some mod authors are referring to actual mod expansions as "patches" - i.e. extending overhauls to game expansions and new followers. They are giving themselves too little credit. More importantly, this will confuse users being asked to disable patches. So if a mod happens to depend on an overhaul, but is editing an entirely new NPC, don't think of it as a "patch".
Now includes comparisons to all (explicit) masters, which is important for the new profile creation algorithms. Also adds an explicit scale comparison, so height/weight aren't simply ignored. Changes previous name "Master" to "Base" so it's no longer ambiguous with the plugin's masters.
#49#51
This is the minimum required to display and interact with a profile based on the new analysis and mod repository code, not counting the XAML changes to the main Profile page. Most of the WPF components are just extracted from the original Profile page, but made standalone in order to provide better view/viewmodel encapsulation.
Not "fully" tested but all of the basic flows seem to work when integrated with the main app (TBD in a later commit).
#85#64#61#51#49#37#26#22 (doesn't complete any of these, but advances all of them)
The whole "disable patches first" thing is proving to be very difficult for at least some subset of users, either due to confusion over what constitutes an "overhaul patch" or just general difficulty with the mechanics of it, especially in Vortex.
In some interim version, probably 0.3, the detection on overhaul mods was improved so that overhauls themselves could never be detected as default plugins. The detection uses some heuristics (% of faces, % of only faces, etc.) but seems to be quite reliable.
One thing that was never looked at as a follow-up to that was extending this into patches. It just hadn't come up as a major issue at the time. However, if a visual overhaul should never be selected as default, then it logically follows that a patch for that overhaul should not be selected as the default either.
I doubt the detection here is perfect... but it might be just good enough to drop the whole "no patches" thing if it catches 99% or 95% of the problem-plugins. The whole reason for anti-patching is just to prevent them from ending up as defaults, and if we can prevent it a different way that doesn't require any manual work, then the process can be made a lot easier. Which is of course the whole idea.
If the detection is almost perfect but not quite, a few broad-targeted manual overrides could help smooth over the rest. For example, in addition to implementing #17, add a feature somewhere to "remove from defaults" that would cut out an entire plugin from all NPCs using it. Or, some type of "soft reset" feature that could allow users to identify patches in the load order or just any mods they want removed - i.e. rather than doing it one at a time. It's not good if these hack-fixes become a core part of the workflow, but if they just deal with a few strange edge cases, they're more palatable design-wise.
The text was updated successfully, but these errors were encountered: