Announcement: Mod Organizer 1.3b (the b is for beta) and the future of MO - UPDATED 1.3.5 is out to the public

[Tannin]

UPDATE

 

New beta version 1.3.1 available on Sourceforge.

This should fix all reported problems. The only thing I couldn't make any sense of is the report of load order being reverted, could someone please work out reliable steps to reproduce it?

 

 

I just uploaded a beta of MO Version 1.3 to sourceforge: https://sourceforge.net/projects/modorganizer/files/?

 

Before I go into the changes, let me first advice against using this version as your primary installation. While it seems to be relatively stable and I've been using it on my own system for a few weeks now I will refuse to even feel bad if this ruins your setup.

Still, I would appreciate any feedback.

 

Right, features.

• Integration of loot 0.7 beta
• the integrated loot can now be updated without a new release of MO. (1)
• the mod list now has a new column that displays icons based on the content of the mod so you can quickly see if a mod contains, say, esps or textures or skse plugins or ...
• the mod list can be filtered by their content
• When you click a mod that has conflicts, the conflicting mods now get a colored highlight in the list.

Apart from this there have been a couple of changes under the hood:

• MO is now based on the current version of Qt (5.4 instead of 4.8). Unfortunately this also leads to a 4MB bigger archive.
• Windows XP is no longer supported.
• more game-specific functionality has been factored out into plugins. While this won't suffice to support non-gamebryo games right now it may be possible for someone (not me) to write a Morrowind plugin.

 

(1) To update loot, get the "loot api" download from the loot github page at https://github.com/loot/loot/releases/ and copy the loot32.dll contained within to the loot directory of MO.

 

---

 

Since I already have your attention I'd like to also announce that this is probably going to be the last feature-release of MO, at lease for a while.

This is not saying that I'll stop working on MO but the project has become too large for a single person to work on effectively in their very limit spare time and since it doesn't look like an active development community is forming around MO I decided to focus my time on very specific topics.

This will allow me to work on those things more effectively while allowing me to keep a shred of sanity.

 

So what I'll continue to do is:

• Fix bugs in the core application
• Fix severe bugs in the virtualisation library and plugins
• Add plugin interfaces on demand
• Work on a new virtualisation library that is more flexible and supports 64 bit
• Anything that I deem enjoyable. ;)

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

 

The reason I will only fix severe bugs in the vfs library is that this lib will hopefully be replaced anyway when the new one is working.

The reason I will only fix severe bugs in the plugins is that I believe those plugins are sufficiently simple that others could easily work on those.

 

If you don't know, the features implemented in plugins is: all the installers, the tools below the "tools" menu, the diagnostic messages (exclamation mark) and now parts of the functionality specific to gamebryo games.

 

 

Known issues with MO 1.3 beta:

• right now filtering by the mod list by "checked, unchecked, update, ..." doesn't work.

[pStyl3]

Screenshot #1 - Screenshot #2

 

Please have a look at the two screenshots above. Each of the following mods, which contain the two files ..

cuirasslight.dds

cuirasslight_n.dds

 

.. are present in my left pane:

test1
..
Unmanaged: HighResTexturePack01
HRDLC1 Optimized
..
aMidianBorn Book of Silence - Armors
..
test2

 

 

I noticed, that if I open the 'Conflicts' tab of 'test2' (screenshot #1) all mods above 'test2' are correctly being displayed in the 'The following conflicted files are provided by this mod' window. However, if I open the 'Conflicts' tab of 'test1' (screenshot #2), it is not the case that every mod under 'test1' is going to be displayed in the 'The following conflicted files are provided by other mods' window .. only the very last one.

 

Was this a design choice, or would this rather be a bug?

[Tannin]

This is intentional. There is one mod that actually provides the file and 0-n mods that get overwritten.

In the mod providing the file MO displays all the mods that get overwritten whereas in the mods that get overwritten in shows only the one mod that provides the file.

[TechAngel85]

Hmm...I just seen this, but posted a bug report before doing so about something similar with the conflict flags. I suppose the behavior I described could be intentional as well, but if it is it's confusing users and I think the grey lighting bolt icon is more informative than the +/- flag in cases where mods are being completely overwritten.

[Tannin]

The behaviour you described in the issue report isn't intentional. The mod in your case does indeed overwrite others, gets overwritten AND is redundant all at once, so technically it should have another icon (gray with +/-) but I think that would be confusing as well.

I'll rewrite the code to give the "redundant" icon priority over "mixed".

[pStyl3]

This is intentional. There is one mod that actually provides the file and 0-n mods that get overwritten.

In the mod providing the file MO displays all the mods that get overwritten whereas in the mods that get overwritten in shows only the one mod that provides the file.

Alright, that is understandable. That said, the current behavior can lead to a certain, small confusion aswell. Let's say you have three mods.

Mod A

Mod B

Mod C

 

All three contain the same file, thus the file from Mod C wins. If I view the conflict tab of Mod C, I will see that the files of Mod A and Mod B will get overwritten. If I look at Mod A's and/or Mod B's conflict tab, I will see that the winning file is provided by Mod C. The thing is, the new conflict colors will always provide me with the information of all conflicting mods, if I click of Mod A, Mod B and Mod C will be highlighted red .. but if I then go into the conflict tab of Mod A, I will not necessarily be told, which file of Mod B conflicts with Mod A.

 

I experienced that today. I was (finally) cleaning out all the redundant files between my different 'Optimized Textures' mods. Through the conflict colors I could see, that there was one pair of conflicting files left between 'Vanilla Optimized' and 'HRDLC1 Optimized', but neither checking the conflict tab of the one, nor of the other, revealed to me, which files were conflicting (since aMidianBorn was winning the conflict). Since both 'mods' contain a lot of files, it took me a couple of minutes to manually find the conflicting files. I managed it, but yeah.

 

A possible way to handle this, could probably be to show all files that are winning over the currently viewed mod and making the actual winning mod bold (or something similar). But I understand your reasoning aswell Tannin (and thus you're desire to let it be as is), clearly pointed out conflict winners are very valuable information.

Edited June 10, 2015 by pStyl3

[Tannin]

I'll have to check how much work it would be to display the other conflicting mods but no promises.

[pStyl3]

Alright. Just installed 1.3.7, found no major quirks so far. I think, there might be some oversights regarding the changes to the portrayal of the redundant flag, though. First, when MO 1.3.7 launches, it will look like this for the moment. That changes (at least it seems so to me) when the modlist.txt is saved, so it's no big deal, but it looks a bit funky nonetheless. Second, was it intentional, that mods that are disabled in the left pane are also getting flagged as 'redundant'?

 

Aside from that, nothings going wrong for me so far, LOOT, xEdit and PatchusMaximus work. Thanks!

Edited June 13, 2015 by pStyl3

[gator91]

Having an issue with M.O 1.3.8 Sort no longer showing results. Can anyone help?

[alt3rn1ty]

On behalf of a nexus user of the UnOfficial Patches, can anyone answer what his possible problem is ..

 

Richardo11 in this post https://forums.nexusmods.com/index.php?/topic/456679-unofficial-skyrim-patch/page-972&do=findComment&comment=26994914

 

 

I am having a strange issue, LOOT does not place USKP after Update.esm but at the bottom of all USKP's, in fact after TKchildren.esm, it places it after all .esm's and another thing is that all the USKP (D,D and H) and all the .esm are shown in bold and only USKP is in normal style, MO does not allow me to place it above all the other .esm and USKP's manually either.
I have just updated MO to the latest version in order to install all the USKP's and avoiding the 32 bit integer issue, in the previous installation of MO (which i have a backup) the order was sort properly, I have no idea why this is happening, the game launch, looks that without problems, but i do not want to progress my character further with this "bad" load order
Any ideas?

Thanks

 

I will tell him to watch this post for replies, but this one seems odd in that he has updated MO and is now having load order problems, whereas the reverse would ordinarily be the case ( Old versions of MO not coping with the new unofficial patches header data size ).

 

Maybe he updated to the newest version of MO which applies for his system ( if constrained by Win XP or something similar ), so will not be updated to the newest MO which actually fixes the problem ?, and has also recently updated USKP from an older version which did not have such a heavy header data and therefore was not causing problems for the older MO that he had installed before .. Just guessing here because the above quote is all the information we have so far.

 

( And apologies for my ignorance if this would be better posted elsewhere - I still just use Wrye Bash )

Edited July 16, 2015 by alt3rn1ty

[Neovalen]

If he is on XP then there is not currently a version of MO that will work with the latest USKP. MO 1.3.8 works but not on XP.

[TechAngel85]

Yes, latest versions of MO work okay. XP users with MO v1.2.18 will have issues. Also, if the user didn't do a clean install of MO, they'll need to.

[Greg]

I can confirm... I had exactly this issue when using Mod Organizer 1.2.18. If you look closely at the output pane (the one on the bottom) while working with Mod Organizer, you'll see messages saying it's unable to parse Unofficial Skyrim Patch.

 

The only way to fix it is to update to latest Mod Organizer 1.3.x version on Nexus.

 

If he does a clean install of Mod Organizer, keep a good copy of the existing ModOrganizer.ini, along with download, profile, and mods folders. I initially did a clean install then copied the downloads, profiles, and mods folders back in. When I ran Mod Organizer, my profiles were all out of whack. I ran Beyond Compare on the old and new ModOrganizer.ini and found part of the mod setup in the bloody ini file so I had to merge to get Mod Organizer to behave correctly. If I remember correctly, this is selected_profile, mod_list_state, and plugin_list_state in [General].

 

EDIT: In fact, I recommend renaming the existing Mod Organizer folder to Mod Organizer.old and keeping it in pristine condition until the new Mod Organizer is setup and behaving correctly.

[GrantSP]

This user is using 1.3.8, I've seen a few posts in the MO Nexus forum from him. There is something other than the norm going on here, what that is though is not yet determined.

[Greg]

Did he install Mod Organizer fresh or overwrite on top of an existing install? I'm just wondering if there could possibly be some remnant left over from the old install that might be causing this.

 

I just tried unsuccessfully to reproduce this with Mod Organizer 3.1.8 and both 2.1.1 and 2.1.2 versions of the unofficial patches.

[GrantSP]

Not sure, the instruction given him by a couple of users was to do a fresh install in a new directory. I can only assume he followed that advice.