"Potential Mod order problem" recommendation conflicting with STEP recommendation

[venlaflaxine]

I'm a long time MO user and I've always used the built-in "fix" when getting the "potential mod order problem" error. I decided to try out a STEP install for my most recent playthrough. It has almost all the core mods and a few of the extended mods.

 

I'm receiving the "potential mod order problem" error and the recommended changes conflict with the order recommended by the STEP instructions. Here are the MO recommends:

• Move Thieves Guild Requirements after Even Better Quest Objectives
• Move Traps Make Noise after Thieves Guild Requirements
• Move When Vampires Attack after Traps Make Noise
• Move aMidianBorn Book of Silence - Content Addon after When Vampires Attack
• Move aMidianBorn Book of Silence - Weapons after aMidianBorn Book of Silence - Content Addon
• Move Complete Crafting Overhaul Remade after aMidianBorn Book of Silence - Weapons
• Move The Paarthurnax Dilemma after Complete Crafting Overhaul Remade

Should I apply the "fix"? If not, is there any way for me to clear this message?

 

Thanks!

[Xaviien]

Ignore the warning.

 

The option to switch off the warning is described on the MO mod page:

Click the wrench icon in the toolbar...

...

Go to the Plugins tab and click "Basic diagnosis tool" on the left and doubleclick "true" next to "check_modorder" and change it to "false".

[venlaflaxine]

I'd rather not disable the tool entirely as I'm used to using it to check my mod order. Is there any way for it to ignore this one error message, but continue functionality?

[Xaviien]

Yes, you need to ignore it within yourself.

You'll either need to follow what it says there, by applying the "fix" (which will mean you're no longer following the STEP guide) or you'll need to do a little work yourself, such as researching mod order via mod pages etc or following a detailed guide, like STEP.

 

The advice you'll get from everyone on this forum, besides Tannin (the author of MO) is switch the warning off.

[venlaflaxine]

Fair enough.

[TechAngel85]

The idea of the PMOP is sound; however, its design is premature in its current state. All the feature does is compare the script names between mods and tosses out a warning if the install order (left pane) doesn't match the plugin order (right pane) between the two mods. This is a very basic implementation. In STEP, we check all this out and make sure everything is good for you so you can ignore the warnings. For the feature to be really useful, it needs to compare the script files themselves and not just the names. If the files differ and the file with added lines come before the other conflicting script, then throw a warning. If the scripts are the same or the script with added lines comes after the conflicting script, then the feature should just ignore them. This, of course, is easier said than done or Tannin probably would have done it already. As time goes on, the feature is becoming less and less useful since authors are including default scripts with their mods now. In fact, installing STEP will cause an infinite loop with this feature because two mods from the same author having the same identical script included with them. No matter how you move the files, you'll always have a warning between those two mods in STEP. This is why we're now recommending the feature be turned off.

[Tannin]

Sorry Tech but this is a load of bull.

You can not determine if one script is newer or better than the other automatically by checking which has more code, that's not how programming works.

Let me rephrase that: You can not automatically determine if one script is newer or better than another. period.

 

Which is why the current implementation of PMOP (baring bugs of which there are no reports right now) is the best that can be done without a manually curated list of mods which is completely impractical.

While the changes suggested by PMOP may very well be unnecessary I have no reports of cases where it is producing an order that works worse.

The practical approach would therefore be to adjust step (which is already a curated list but infinitely shorter than what MO would require) to not produce a PMOP warning in the first place.

 

Since the STEP Guide only covers those mods covered by STEP and not the other 50000+ mods users might end up using, disabling this feature is not a good idea. If the step wiki continues to make suggestions like this I'm not sure I can continue using this as the official MO wiki because I don't stand behind it.

At the very least mention that this suggestion is controversial. Mention that this advice is only sound if users install nothing but STEP.

 

If you feel an MO feature is not good enough then help improve it instead of disabling it altogether because that only ensures the feature will probably never get to a point where you like it.

[Razorsedge877]

Maybe some of the active mod authors need to combine some of their bigger mods into one esp or at least have the option to get them all merged and that will help improve on Tannins feature.

[TechAngel85]

Sorry Tech but this is a load of bull.

You can not determine if one script is newer or better than the other automatically by checking which has more code, that's not how programming works.

Let me rephrase that: You can not automatically determine if one script is newer or better than another. period.

Didn't mean "newer" script. I meant different as in added lines of code. This would be as easy as a file size check (in bytes) to check against a smaller list of default scripts. If the file size is the same, then the author has included a default script and it can be ignored. If the file size is larger, then this is probably an edited script which the author has added code to. This means it would be different from the default and thus a warning would be produced if the install order of the mod is before the conflicting default script (meaning the larger file size script would lose the conflict resolution and not be loaded in-game). Granted this is not ideal and you couldn't be 100% positive it would be correct 100% of the time; however, it would be at least a check to eliminate most false positives on default scripts which mod authors include in their mods.

 

Which is why the current implementation of PMOP (baring bugs of which there are no reports right now) is the best that can be done without a manually curated list of mods which is completely impractical.

While the changes suggested by PMOP may very well be unnecessary I have no reports of cases where it is producing an order that works worse.

The practical approach would therefore be to adjust step (which is already a curated list but infinitely shorter than what MO would require) to not produce a PMOP warning in the first place.

We've tried doing this in the past and it doesn't work due to file conflict resolution and breaking the workflow and having to redesign the categories we have now. This would be a bigger dev project for us and not something we can do right now as our main developer (S4N) barely has any time to work on the wiki as it is. We'd also have to instruct users to hide more files which is just opening the door for more and more user errors. That would not be an ideal for STEP.

 

Since the STEP Guide only covers those mods covered by STEP and not the other 50000+ mods users might end up using, disabling this feature is not a good idea. If the step wiki continues to make suggestions like this I'm not sure I can continue using this as the official MO wiki because I don't stand behind it.

At the very least mention that this suggestion is controversial. Mention that this advice is only sound if users install nothing but STEP.

 

If you feel an MO feature is not good enough then help improve it instead of disabling it altogether because that only ensures the feature will probably never get to a point where you like it.

I want to make something clear. If we instruct user to disable the feature, this would be for STEP-only users because we have checked the files out ourselves and they are all false positives for the STEP Guide. This would be a STEP-only instruction and not one we'd knowingly recommend to non-STEP users. As far as I'm aware, this advise is not being presented on the MO Guide itself on the wiki. That Guide should remain neutral. STEP would use the MO mod page because those pages are specifically for STEP use; not public use like the Guides. If I'm wrong about the MO Guide, please direct me to where it says this in the Guide and I will remove it because it shouldn't be there. I repeat...this advise will only be for STEP-only users.

ANY USER going deciding to go beyond the mods in the STEP Guide is beyond the scope of STEP and it will be the user's responsibly for turning the feature back on or for checking any conflicts with mods not included in the STEP Guide. STEP only tests and designs the STEP Guide for those mods in the Guide.

 

As far as improving it, I would take a crack at it; however, I'm not a programmer. My language knowledge doesn't go beyond HTML, XML, CSS, and a bit of Javascript. I doubt you want me poking around at anything. Haha!

[Xaviien]

I've corrected the link label in my post above. It is only the MO mod page which suggests to turn this feature off, PMOP is not mentioned, at all, in any of the official MO Wiki pages.

[Tannin]

Didn't mean "newer" script. I meant different as in added lines of code. This would be as easy as a file size check (in bytes) to check against a smaller list of default scripts. If the file size is the same, then the author has included a default script and it can be ignored. If the file size is larger, then this is probably an edited script which the author has added code to. This means it would be different from the default and thus a warning would be produced if the install order of the mod is before the conflicting default script (meaning the larger file size script would lose the conflict resolution and not be loaded in-game).

It simply doesn't work that way. The amount of code says nothing about the "desirability", it could simply be more obsolete code was removed than new, desirable improvements made.

The size of the code doesn't need to change at all, changing a "x y" can make all the difference and that's not even a difference in file size.

 

When I do a bugfix in MO that is as likely to reduce the amount of code as it is to increase it. The same would be true for scripts so all we can determine is if one script is different from the other, we can't determine which is better unless mod authors introduce and all adhere to a versioning system. How likely do you think this is?

But even determining if two scripts are different is a problem because one version of the script may be loose, one unpacked in a bsa and one packed in a bsa. The only way to determine the difference is to extract the scripts and compare but that would cause an inacceptable performance hit.

 

Also, the PMOP advice doesn't really need to order scripts, the point of the feature is to order mods after esps because we already have a plugin ordering system in loot and there is very little reason to order assets separate from plugins. Remember: If it weren't for MO BSA-based mods couldn't have a separate asset order at all and loose files would be ordered by installation order so following the PMOP advice really only takes a slight amount of the freedom away you wouldn't have had without MO in the first place. The mod authors can't plan with separate asset and load order because they have to plan for NMM and manual installs.

It's solely STEP that is imposing a specific, artificial asset order. How necessary is this order really?

 

Granted this is not ideal and you couldn't be 100% positive it would be correct 100% of the time; however, it would be at least a check to eliminate most false positives on default scripts which mod authors include in their mods.

But 99% positive I already have! What we're talking here is already the missing 1% that needs to be fixed. A half-assed may-work-may-not-work won't suffice.

 

We've tried doing this in the past and it doesn't work due to file conflict resolution and breaking the workflow and having to redesign the categories we have now. This would be a bigger dev project for us and not something we can do right now as our main developer (S4N) barely has any time to work on the wiki as it is. We'd also have to instruct users to hide more files which is just opening the door for more and more user errors. That would not be an ideal for STEP.

Well, STEP is a community project, MO is pretty much a one man show so if we're in a contest who has less time I can almost guarantee I'll win.

 

I want to make something clear. If we instruct user to disable the feature, this would be for STEP-only users because we have checked the files out ourselves and they are all false positives for the STEP Guide. This would be a STEP-only instruction and not one we'd knowingly recommend to non-STEP users. As far as I'm aware, this advise is not being presented on the MO Guide itself on the wiki. That Guide should remain neutral. STEP would use the MO mod page because those pages are specifically for STEP use; not public use like the Guides. If I'm wrong about the MO Guide, please direct me to where it says this in the Guide and I will remove it because it shouldn't be there. I repeat...this advise will only be for STEP-only users.

That's ok then, as long as users are made aware that the advice is only for a step-only installation I have no objections.

 

As far as improving it, I would take a crack at it; however, I'm not a programmer. My language knowledge doesn't go beyond HTML, XML, CSS, and a bit of Javascript. I doubt you want me poking around at anything. Haha!

Well, coding is not the only way to help, giving detailed bug reports is an enormous help. The quality of bug reports can make the difference between 15 minutes of work and hours.

If the PMOP suggestion indeed doesn't work like intended (like cyclic fix instructions) a report containing a minimal set of mods to replicate the problem would go a long way towards solving it.

 

If this is an unsolvable problem for STEP maybe I can add a quick&dirty blacklisting mechanism where when you hit "Fix" you can select to either execute the mentioned moves or ignore them forever.

 

What's important to me is that you talk to me about these problems and we try to find a common ground that can work for all users (of Step and MO both) instead of giving advice - stuff people might find via google without knowing the context - that is simply bad for a large part of my user base.

[TechAngel85]

It simply doesn't work that way. The amount of code says nothing about the "desirability", it could simply be more obsolete code was removed than new, desirable improvements made.

The size of the code doesn't need to change at all, changing a "x y" can make all the difference and that's not even a difference in file size.

 

When I do a bugfix in MO that is as likely to reduce the amount of code as it is to increase it. The same would be true for scripts so all we can determine is if one script is different from the other, we can't determine which is better unless mod authors introduce and all adhere to a versioning system. How likely do you think this is?

But even determining if two scripts are different is a problem because one version of the script may be loose, one unpacked in a bsa and one packed in a bsa. The only way to determine the difference is to extract the scripts and compare but that would cause an inacceptable performance hit.

 

Also, the PMOP advice doesn't really need to order scripts, the point of the feature is to order mods after esps because we already have a plugin ordering system in loot and there is very little reason to order assets separate from plugins. Remember: If it weren't for MO BSA-based mods couldn't have a separate asset order at all and loose files would be ordered by installation order so following the PMOP advice really only takes a slight amount of the freedom away you wouldn't have had without MO in the first place. The mod authors can't plan with separate asset and load order because they have to plan for NMM and manual installs.

It's solely STEP that is imposing a specific, artificial asset order. How necessary is this order really?

The biggest reason for ordering them differently would be for proper conflict resolution within the textures and meshes without having to hide a ton of textures. Most of these mod are in the Conflicting Graphics section for STEP. When we were first attempting to resolve the PMOP messages in STEP, we thought about restructuring the categories in the Guide; however, this would cause several issues due to the way the wiki infrastructure is built. It would require a massive amount of work to do it and though most of the Staff could help with some of the work, there is only one main staff member that does that does the actual dev work and his time is more sparse than even yours as the dev on the wiki has been at a standstill for months now.

 

But 99% positive I already have! What we're talking here is already the missing 1% that needs to be fixed. A half-assed may-work-may-not-work won't suffice.

Which is why it probably would be best if I stayed out of it. I have the idea in my head on how it could be done for loose assets; however, implementing that is another story and is probably beyond the scope of MO. In a nut shell, MO would basically open the scripts, use a compare against the conflicting files (like the compare feature in Notepad++). If there aren't any differences, then you're good to go. If there are, then a warning will be produced. At that point, the user would have to investigate the conflicting files. This would all be for eliminating false positives when the scripts are exactly the same. However, as I mentioned, I'm no coder and would have no idea how to implement anything like that.

 

Well, STEP is a community project, MO is pretty much a one man show so if we're in a contest who has less time I can almost guarantee I'll win.

The public side is community. The back end where dev is concerned is basically a one man show as well for us. Stoppingby4now is the only one that is fully equipped to do the actual dev work. Z can do the basic stuff but that is it for our wiki environment from which the STEP Guide runs off of.

 

 

Well, coding is not the only way to help, giving detailed bug reports is an enormous help. The quality of bug reports can make the difference between 15 minutes of work and hours.

If the PMOP suggestion indeed doesn't work like intended (like cyclic fix instructions) a report containing a minimal set of mods to replicate the problem would go a long way towards solving it.

 

If this is an unsolvable problem for STEP maybe I can add a quick&dirty blacklisting mechanism where when you hit "Fix" you can select to either execute the mentioned moves or ignore them forever.

 

What's important to me is that you talk to me about these problems and we try to find a common ground that can work for all users (of Step and MO both) instead of giving advice - stuff people might find via google without knowing the context - that is simply bad for a large part of my user base.

The main reason we haven't filed any reports is because of your announcement,

 

What I will no longer do is:

•     Add any features (unless I deem the implementation fun)
•     Answer any requests for help (be it PM, mail or on the forums) unless it's "I want to help out with MO but I need advice" or something like that
•     Do the german translation
•     Fix "minor" problems or "medium" problems in the vfs system and plugins
•     Maintain "lists" like the categories mappings, configurator settings file,...
•     Work on the tutorials in any way

We basically took this as you'll only be working on the main dev of MO and not any of the plugins and smaller features. Therefore, we haven't bothered you with any ideas that we may have thought up since that announcement. We can provide you with a list of the PMOP warnings in STEP if you're thinking a quick "blacklist" feature for PMOP will work.

[jbvertexx]

My perspective as a STEP user is that the STEP order makes sense from an organization standpoint.  The "Potential Mod Order Problem" has caused a tremendous amount of heartache for me, but I actually don't blame MO.  I blame LOOT.  To me, LOOT does not allow enough flexibility to provide a specific mod order.  If it did, then wouldn't it be easy for STEP to provide a specified load order that would be consistent with the mod order?  It seems like Loot relies on some more loose logic in ordering plugins, so that the results are very unpredictable.

 

I've read a number of recommendations, specifically users of Perma, who are increasingly recommending to not use Loot and to instead manually arrange load order.

 

I would actually like to do that, but MO doesn't allow for an easy manual organization of plugins like it does for mods in the left-hand pane.

 

I'm in a dilemma right now trying to figure out whether I want to (1) attempt to manually maintain my plugin order, (2) letting the potential mod order problem error fix mess up my mod organization, or (3) ignoring the error, which is going to have risks because I do add a decent number of mods beyond STEP.

 

Before I run LOOT, things are pretty well in order, with only a few recommended mod order problem fixes.  Once I run LOOT, then it's completely hosed up.

Edited May 15, 2015 by jbvertexx

[GrantSP]

My perspective as a STEP user is that the STEP order makes sense from an organization standpoint.  The "Potential Mod Order Problem" has caused a tremendous amount of heartache for me, but I actually don't blame MO.  I blame LOOT.  To me, LOOT does not allow enough flexibility to provide a specific mod order.  If it did, then wouldn't it be easy for STEP to provide a specified load order that would be consistent with the mod order?  It seems like Loot relies on some more loose logic in ordering plugins, so that the results are very unpredictable.

 

I've read a number of recommendations, specifically users of Perma, who are increasingly recommending to not use Loot and to instead manually arrange load order.

 

I would actually like to do that, but MO doesn't allow for an easy manual organization of plugins like it does for mods in the left-hand pane.

 

I'm in a dilemma right now trying to figure out whether I want to (1) attempt to manually maintain my plugin order, (2) letting the potential mod order problem error fix mess up my mod organization, or (3) ignoring the error, which is going to have risks because I do add a large number of mods beyond STEP.

LOOT manages plugins, ie. the right-hand pane. MO's PMOP plugin handles mods, ie. the left-hand pane.

The two are unrelated in the method in which they operate.

 

It is entirely possible to not use LOOT and manually order your plugins and still have a PMOP!

 

The list of mods that need 'fixing' may be long in each PMOP, but in my experience you can usually remove the error by moving just one or two mods. Though I am not 100% certain of the process employed in the code that determines these 'problems', I am sure that you can fix them with other means than those that are suggested. Generally, if you add a new mod you should check the positioning and handle any problems then, it is only when a number of mods are added, or one or two moved around, that it occurs and then you should have some idea of what took place.