Jump to content

MO Madness


garthand

Recommended Posts

I honestly wouldn't give up Bash for anything available ATM. Even with the "limited" Skyrim features. Even more so for Oblivion. 

It does what it says it does and does it darn well. 

 

Also, I personally think everyone should know how to manually install/uninstall mods (not like you need a Phd to learn how to do that).

With Skyrim and NMM, I see more and more people panicking when their preferred automated program fails somehow, just because they never went in the old fashion way. :P 

 

As for having multiple profiles and whatnot - I never found the need for it. I'm, very careful with my LO, even if I have a lot of mods, and if I want something gone, It's one click away with Bash too. 

For a test-bed, I keep another folder that is squeaky clean with only the basics (Project Patches and LAL) and can switch to that myself anytime.

Link to comment
Share on other sites

This is actually the beauty of MO, in that everything is modular.  It is quite easy to see if something was installed improperly, simply by double-clicking on a mod and going to the filetree view.  You can even look at your virtual "data" directory in the right pane, and it tells you what is where and what mod has priority.  If things are installed properly, then you can view your profile's settings, .ini files, or the program's settings (which really ought to be left at their default).  Yes, people can mess with things they shouldn't be, but I feel that goes for any mod manager.

I think you may have missed my point though. If something has gone wrong, and you're using MO, and you suspect MO is WHY something has gone wrong, you have no recourse. You can't simply say "Ok, turn MO off, launch this thing another way" - because there is NO OTHER WAY. Once you commit to using MO, you are for better or worse (usually worse IMO) stuck with it.

 

As I said, I was trying to help someone out earlier with a problem that is suspected to be caused by MO, but because everything is in MO, he can't simply start Skyrim from one of the other mod managers or from the official launcher, because none of his mods are where they belong. They're off hiding in unknown folders in the ether as far as the game is concerned. It makes attempting to distinguish between a real problem and something MO caused impossible.

I further submit that because of this, there's a large number of people who will refuse to accept MO could cause such a problem - because everyone ALWAYS goes back to "but your Data folder is clean" as a fallback answer. That's simply not helpful at all when these people show up on our mod pages blaming our mods for being broken when we can launch the game and prove otherwise in seconds without using MO. It has resulted in numerous hostile exchanges on the USKP thread alone that I really just want to see go away at this point.

Link to comment
Share on other sites

Yeah, I have been interested in MO occasionally. seriously considered installing it at least 4 times. Back on the Oblivion version comments I helped Tannin to understand a bit more about Wrye Bash in the early development so that he could consider an approach for building a bashed patch.esp from virtualised mods.

 

I still havent used it and prefer Wrye Bash, as Lorelai says even with its reduced capabilities for Skyrim

 

A ) MO offers Profiles as an extra - I dont need it

B ) MO offers many different setups you can switch between easily - So does BAIN

 

C ) MO offers a "virtualised and clean data folder" - For what purpose ? :
Your machine still has to store the mods zips or extracted data somewhere else on your hard drive, so it still has to load and decompress those files from your HD at another location, and so is also still prone to fragmentation of those files on your hard drive.

 

And the last ability has to be supported by running a further background process, MO needs to real-time feed all the files to Skyrim as Skyrim demands them

 

To me because of the extra background process taking up CPU time ( on really good machines this will not be noticeable, on my minimum specification laptop things like this matter ) .. But also if you have ever got into using Process Explorer, and used its filters so that you just end up watching a display of Skyrim.exe calls for files, and the multiple locations that are searched, for every single file .. There are thousands of them per second ..

Add to that all those calls need to be intercepted by MO, and then MO needs to feed the new and correct file location for every single one of them ( after determining out of all your selections which copies of those files to use where there are conflicts ) .. before Skyrim can load them

 

 

I have seen some ideas of the magic word virtualisation before, many years before in fact .. On Amiga OS enthusiasts created a Virtual Drive which would preload the whole AmigaDOS Operating System into ram, then it would reboot and VD0: drive in memory would become the system partition, the OS loaded from there and the OS became a lightning fast beast, powered by a 68030 processor with a piggy back 68882 maths co-processor, dedicated sound and graphics chips and plenty of ram bolted on .. The best PCs at the time could not compete for performance or multi-tasking capability.

 

 

MOs virtualisation though is just getting your files from another location on your HD, and as far as I can see logically its less optimal for having to do that, aswell as having to run another process to manage it all real time  = Less optimal loading system, not better.

 

 

And the decider is - I still need to do a bashed patch, so why have another tool with tricks I dont need, when wrye bash does everything i do need. I have no doubt it is very well programmed, Tannin is talented and dedicated. I just dont need anything it offers.

 

 

For my mods ( Kill the Orchestra, and Alt Navetsea UNP Seamless ) I made an effort to write dual scripted installers, Wizard for Wrye Bash and ModuleConfig.xml for NMMs FOMod scripting in the same mod archive, so no matter which of those two Mod Managers anyone uses installing is easier. The only reason I would install MO would be if I needed to support its scripting, but apparently it has the ability to use either of the methods I have implemented, so those will be refined as time goes on ( we can assume I think that Tannin will be making MO fully conversant with all the commands and functionality of those commands in both scripting methods ) and authors need not do any more scripting on top of what they do already.

( I dont know which script MO uses when it comes across any mods like mine with both scripts available :unsure: but I really dont want to go scripting for yet another mod manager if thats a problem ) 

Link to comment
Share on other sites

This is kinda feeling like a flamewar now. The purpose of this thread is not to determine the best mod organizer. That is a topic I am interested in, if it could stay civil, but it needs to happen ELSEWHERE, if it is going to happen.

Link to comment
Share on other sites

This is kinda feeling like a flamewar now. The purpose of this thread is not to determine the best mod organizer. That is a topic I am interested in, if it could stay civil, but it needs to happen ELSEWHERE, if it is going to happen.

Yeah I tend to post threads that get derailed pretty quickly. That said I think I've found that the biggest challenge in writing a guide for MO is the troubleshooting. If someone runs into a problem, it could be one of three things:

 

  1. The mod itself is causing the issue
  2. The mod is not compatible with MO (rare, but it happens)
  3. The user has borked their MO settings

Because of MO's virtualized file system, it's difficult to tell the difference between issues 1 and 3. If anyone has any tips on this, I would be grateful.

Link to comment
Share on other sites

Arthmoor,

 

Your concern is very valid, and all I can do is give you sympathy for having to put up with people who think troubleshooting equals flaming the mod author.  I agree, it does add a level of complexity that can only make matters worse when dealing with ignorance.  And you are correct in saying that your mods are "gone" if you attempt to play Skyrim without MO (the whole concept behind virtualization).  This is why I said before that MO is not for everyone.  The point I was trying to make is that any tool, whether it's MO, NMM, TES5Edit, or Wrye, can cause headaches for mod authors when the end-user is doing things with the tool that they are not supposed to.  I don't know how Fore is still sane from all the nonsense people come up with in FNIS.  Heck, I personally felt like it took me forever to learn what tags to use on which mods when Bashing in Oblivion.  I do feel, though, that it would be useful for you, or at least another team member, to familiarize yourself with MO, so that you could narrow down problems others might be having, such as installing a mod improperly by designating the Meshes folder in a mod install as the Data folder.  This is determined quite simply in MO if they even remotely know how to use the program.  If it comes down to an issue with the MO program itself, the user could then be directed to Tannin's bugtracker.

 

 

( I dont know which script MO uses when it comes across any mods like mine with both scripts available :unsure: but I really dont want to go scripting for yet another mod manager if thats a problem ) 

 

Fortunately, MO utilizes NMM's FOmod installation script by default (as far as I can tell), and it can also recognize a BAIN installation wizard, so you won't have to write another script. :D  Also, as an aside, I've now played Skyrim with MO on two different laptops, one of which was over 5 years old, and I never noticed any performance issues from MO.  I actually used it to test different setups with different texture packs to determine how to get the best FPS, and as a bonus for me, I did not have to reinstall Skyrim when I was done :P

 

My end goal in this discussion was to show the merits of a properly installed MO setup, and how useful a tool it can be.  I run 130+ mods in my setup, depending on my profile, ranging from huge game-changing mods to simple texture replacers.  I do not have a need for bashed patches, so I do not utilize Wrye for Skyrim, though if I did, I could do so through MO (I know, that probably sounds ludicrous to you).  I run all my tools within MO without problems, and even have multiple "mods" for animations and FNIS setups.  Sure, you could copy/paste your Data folder 3 times in Windows, or you could, like me, have 3 profiles in MO, each with its own ENB, FNIS, .ini, etc. configurations.  As I said before, to each his own.

Link to comment
Share on other sites

I do feel, though, that it would be useful for you, or at least another team member, to familiarize yourself with MO, so that you could narrow down problems others might be having, such as installing a mod improperly by designating the Meshes folder in a mod install as the Data folder. 

Literally what this thread is SUPPOSED to be. 

Link to comment
Share on other sites

I apologize for the double-post (again), but I wanted to offer whatever help to Garthand I could, since he asked.  From my own personal experience, I treat MO as an .ini.  The program itself has its own settings that could theoretically be screwed up, just like someone setting their uGridsToLoad to 10; it's going to end poorly.  If this is the case, NOTHING is going to work right, and Skyrim might not even start.  So I would start with: did you recently change any settings in MO?

 

Next would be to determine if they've installed a mod properly.  Because MO allows you to alter the file structure of a mod during installation, someone might think they're being cute and move the .esp into the Scripts folder.  MO automatically tries to detect a bad installation config, but this isn't 100% fool-proof.  This is again simply determined by asking if they installed the mod properly, and to check this by viewing the filetree, making sure any .ESPs, .ESMs, or .BSAs are on the top level.  MO also has the (really helpful) feature of telling you what is being overwritten.  All one has to do is look at the Conflicts tab of a mod, and it tells you what it's overwriting, what files are being overwritten, and by which mod.  This could be a real lifesaver in determining that, for example, something is overwriting DCO's dragon scripts.

 

If this is all good, I would then begin to look at requirements of the mod.  Is SKSE installed properly (as in, in the Skyrim folder and NOT in MO)?  Does the mod require another, such as USKP or a special skeleton?  Did the person run FNIS from within MO?  These are standard questions for the mods that need these things, but MO adds an extra consideration.

 

Finally, it is possible (like it was with SkyUI a long time ago), that there is something wrong with MO.  Tannin has been great at ironing out the kinks, but there have been bumps along the way.  This is when the user needs to be directed to Tannin for assistance.  Just like anything else, eventually the bugs get fixed and everyone is happy again.  I hope this is helpful, and if you need a specific example, I'll do my best to help.

Link to comment
Share on other sites

Because MO allows you to alter the file structure of a mod during installation, someone might think they're being cute and move the .esp into the Scripts folder.

I cringe at the thought that this is even a thing. Why would a utility author think this was a useful feature for anyone?

Link to comment
Share on other sites

MO automatically tries to detect a bad installation config, but this isn't 100% fool-proof.  This is again simply determined by asking if they installed the mod properly, and to check this by viewing the filetree, making sure any .ESPs, .ESMs, or .BSAs are on the top level.  MO also has the (really helpful) feature of telling you what is being overwritten.  All one has to do is look at the Conflicts tab of a mod, and it tells you what it's overwriting, what files are being overwritten, and by which mod.  This could be a real lifesaver in determining that, for example, something is overwriting DCO's dragon scripts.

To my knowledge Wrye Bash does that.

 

  • If an archive aren't recognized in Wrye Bash then the archive must have the wrong file structure and correcting the file structure in the archive are the only solution there is to fix that.  No need to use MO for that purpose.
  • Wrye Bash also allow you to view any BAIN-archive regardless if it's a simple or complex archive its file structure in the General tab via the Installers tab before installing a mod.  No need to use MO for that purpose.
  • Overwritten files can also be viewed in Wrye Bash as possible conflicts with other installed mod files before installing a mod IIRC.  No need to use MO for that purpose.

 

So your arguments about what features there is in MO has very little weight when comparing them to Wrye Bash.

Link to comment
Share on other sites

I apologize for the double-post (again), but I wanted to offer whatever help to Garthand I could, since he asked.  From my own personal experience, I treat MO as an .ini.  The program itself has its own settings that could theoretically be screwed up, just like someone setting their uGridsToLoad to 10; it's going to end poorly.  If this is the case, NOTHING is going to work right, and Skyrim might not even start.  So I would start with: did you recently change any settings in MO?

 

Next would be to determine if they've installed a mod properly.  Because MO allows you to alter the file structure of a mod during installation, someone might think they're being cute and move the .esp into the Scripts folder.  MO automatically tries to detect a bad installation config, but this isn't 100% fool-proof.  This is again simply determined by asking if they installed the mod properly, and to check this by viewing the filetree, making sure any .ESPs, .ESMs, or .BSAs are on the top level.  MO also has the (really helpful) feature of telling you what is being overwritten.  All one has to do is look at the Conflicts tab of a mod, and it tells you what it's overwriting, what files are being overwritten, and by which mod.  This could be a real lifesaver in determining that, for example, something is overwriting DCO's dragon scripts.

 

If this is all good, I would then begin to look at requirements of the mod.  Is SKSE installed properly (as in, in the Skyrim folder and NOT in MO)?  Does the mod require another, such as USKP or a special skeleton?  Did the person run FNIS from within MO?  These are standard questions for the mods that need these things, but MO adds an extra consideration.

 

Finally, it is possible (like it was with SkyUI a long time ago), that there is something wrong with MO.  Tannin has been great at ironing out the kinks, but there have been bumps along the way.  This is when the user needs to be directed to Tannin for assistance.  Just like anything else, eventually the bugs get fixed and everyone is happy again.  I hope this is helpful, and if you need a specific example, I'll do my best to help.

Thanks for the info here, (let's try to keep the discussion focused on troubleshooting MO and less on convincing people of its merits. I think most here have already made up their mind one way or another). Since SKSE is installed straight into the Skyrim folder and not through MO, I've noticed a few mods will panic upon installation and tell me they can't see SKSE. Is this a warning I can advise readers to safely ignore?

 

 

I cringe at the thought that this is even a thing. Why would a utility author think this was a useful feature for anyone?

I think this is in MO because it sometimes can't tell where the Data folder in a mod is, and sometimes it will incorrectly identify that folder. Usually it will just ask you, but, if I'm understanding mordecai right, it can sometimes make mistakes, where you would need to restructure the mod to be MO-compatible.

 

 

To my knowledge Wrye Bash does that.

 

  • If an archive aren't recognized in Wrye Bash then the archive must have the wrong file structure and correcting the file structure in the archive are the only solution there is to fix that.  No need to use MO for that purpose.
  • Wrye Bash also allow you to view any BAIN-archive regardless if it's a simple or complex archive its file structure in the General tab via the Installers tab before installing a mod.  No need to use MO for that purpose.
  • Overwritten files can also be viewed in Wrye Bash as possible conflicts with other installed mod files before installing a mod IIRC.  No need to use MO for that purpose.

 

So your arguments about what features there is in MO has very little weight when comparing them to Wrye Bash.

 

I think you might want to look at the first post in the thread again. I'm taking advice on how to help people troubleshoot MO, not holding a discussion on whether people like it or not. If you're trying to convince me to use Wrye Bash, you're preaching to the choir. I already use it.

Link to comment
Share on other sites

Since SKSE is installed straight into the Skyrim folder and not through MO, I've noticed a few mods will panic upon installation and tell me they can't see SKSE. Is this a warning I can advise readers to safely ignore?

 

The program list in MO functions much like Windows start menu; it's just shortcuts.  From my experience, if a mod is panicing because it can't find SKSE, then either I need to update SKSE, or I accidentally ran Skyrim instead of SKSE in the program list.  Users must have SKSE selected before hitting the "Run" button.  There is a setting in MO that can change the load mechanism, and changing that will cause problems, but IIRC Skyrim won't even start.  Other than this, I have never had a problem recognizing SKSE when running it within MO.  If this is happening to you, I can try to help figure out the problem.  Also, a bit off-topic but could be useful, if you try to start Skyrim through MO, and Steam is not running, then it will start Steam, and run Skyrim, but it won't load mods properly.  The solution to this is to have Steam running before you try to start Skyrim, then things will work as intended.

 

I think this is in MO because it sometimes can't tell where the Data folder in a mod is, and sometimes it will incorrectly identify that folder. Usually it will just ask you, but, if I'm understanding mordecai right, it can sometimes make mistakes, where you would need to restructure the mod to be MO-compatible.

 

This feature is useful when a mod author has structured their zip file incorrectly.  Rather than unzipping an archive, manually fixing the file structure, and then rezipping it, you can move files around in MO, much like in Windows.  If a mod author put his mod inside a folder, as opposed to zipping the "Data" folder, then when you open it, there's nothing there except a folder.  You have to go down a level in the filetree.  In my experience, MO is pretty good about detecting the true "Data" level of a mod, but on rare occasions user intervention is necessary.  This can also be useful when a mod author has put "optional" .ESPs or other content in other folders, as you can just move stuff around without having to manually remake the archive.

Link to comment
Share on other sites

 

 

 I'm taking advice on how to help people troubleshoot MO

Problem:  

Creation Kit screams at you whenever you try to work with scripts when the CK has been loaded through MO.  

 

Solution:  

Do not use the Creation Kit through MO.  MO is unable to launch 64 bit applications and that includes the papyrus compiler used by the Creation Kit.  Workarounds only introduce more points of possible error entry.  Better in the long run to keep the mod under construction completely within the original data folder of the game.

 

This is one of the reasons I chose to remove MO, myself.  I liked the ability to setup different testing profiles but the script compilation issue got to be too much of a nuisance.  Wrye Bash can do profile setups anyway (even if the mods were installed with NMM), I just have to take the tedious time to convert loose file mods into BSA mods.

Link to comment
Share on other sites

The merits of the Mod Organiser, either good, or bad as posted by devils advocates, do need to be aired though, some of its features as has been discussed are not conducive to authors troubleshooting problems. And as a guide the many new users who are being subject to being advised of its use as "the mod manager" I believe are ill informed. Manual Installation or NMM should be the first introduction experience, with MO ( and Wrye ) as advanced subjects to follow with more experience imho.

 

My post was due to reading :

 

Under Investigation

 

  • MO doesn't install mods directly into the Skyrim/Data folder and instead installs through a virtualized approach of some sort.

And although I highlighted its method as being sub-optimal, it was just an explanation of how I think it works ..

 

.. though I did go off topic somewhat and cast a negative vibe. The topic title is appropriate though, from my POV :P.

I do not get as many problem posts as Arthmoor gets, but I have had a fair share of the damned things via PM - "Problem x due to your mod" - Various troubleshooting replies for a few hours - Result = PEBCAC ( Problem exists between chair and computer ) using MO

 

Edit : In fact, I propose that as a new acronym, PEBCACUMO :D

Link to comment
Share on other sites

@Ishara

 

I have had a little bit of experience with using the Creation Kit inside MO, but from what I have seen, there are indeed issues.  I also ran into the scripting issue you mentioned, and I also suspect the CK has difficulty with the virtual file system, but I don't know for sure.  Since I don't know a work-around, I would also advise using the CK outside of MO for serious modding.

 

The merits of the Mod Organiser, either good, or bad as posted by devils advocates, do need to be aired though, some of its features as has been discussed are not conducive to authors troubleshooting problems. And as a guide the many new users who are being subject to being advised of its use as "the mod manager" I believe are ill informed. Manual Installation or NMM should be the first introduction experience, with MO ( and Wrye ) as advanced subjects to follow with more experience imho...

 

I agree with you on this, and have said before that MO naturally adds another level of complexity, which ought to be expected from using any tool when modding.  I also agree that new modders ought to "cut their teeth" on manual installation of mods, so that they can learn and understand how a proper file structure works.  I haven't used NMM in a few iterations, but from my experience, I wouldn't recommend a new user try it out until they understand at least simple concepts as well.  And I further agree that MO ought to be considered "advanced."  I hate to beat a dead horse, but as I said before, MO is not for everybody, nor do I think it is the "magic bullet" of modding.

Link to comment
Share on other sites

@Ishara

 

I have had a little bit of experience with using the Creation Kit inside MO, but from what I have seen, there are indeed issues.  I also ran into the scripting issue you mentioned, and I also suspect the CK has difficulty with the virtual file system, but I don't know for sure.  Since I don't know a work-around, I would also advise using the CK outside of MO for serious modding.

 

 

I agree with you on this, and have said before that MO naturally adds another level of complexity, which ought to be expected from using any tool when modding.  I also agree that new modders ought to "cut their teeth" on manual installation of mods, so that they can learn and understand how a proper file structure works.  I haven't used NMM in a few iterations, but from my experience, I wouldn't recommend a new user try it out until they understand at least simple concepts as well.  And I further agree that MO ought to be considered "advanced."  I hate to beat a dead horse, but as I said before, MO is not for everybody, nor do I think it is the "magic bullet" of modding.

Yeah I'd have to agree that understanding manual installation is probably important to understanding how modding tools work. NMM is a good beginner's modding tool, and Wrye Bash and MO both have a level of complexity that would probably overwhelm new users, (Bash's awful UI and lack of good documentation, MO for virtualizing and having few similarities with other mod managers).

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...