MO for some mods but not others? Which ones?

[AtomicJukebox]

I understand that some mods from this site don't work well or at all with MO. Previously when I had the game installed, I finally got everything up and running but I never could get a penis on the MNC creatures. They wouldn't show up when the animations began either. Anyway, I just put together my new rig and am currently installing Skyrim again with a buttload of HD textures and cool mods and I was wondering which mods from this site I should be installing with MO and which ones I need to install manually. Here are a list of mods I plan to download from this site:

• Sexlab Framework
• More Nasty Critters
• Creature Framework (or is this included with MNC?)
• Schlongs of Skyrim
• TDF Aggressive Prostitution
• Skykids

[swmas]

They all work with MO. Pretty much any mod that goes in the Data folder should work with MO. A version of Creature Framework is included in MNC but you should install the latest one and let it overwrite the one included in MNC.

[Guest]

All that MO does is create a Virtual Data folder with the mods, which I think is genius and less troublesome when installing and uninstalling mods. Also all mods should work.

[Wolborg]

I understand that some mods from this site don't work well or at all with MO. [---] I was wondering which mods from this site I should be installing with MO and which ones I need to install manually.

 

I have played, like, 400 hours with SexLab Framework and Schlongs of Skyrim installed with MO and working properly. I couldn't get a SoS plugin (that was supposed to create a different-looking penis) to work. Was it MO's fault, I don't know.

 

I haven't used any other mods on your list.

 

MO sometimes does things it's not supposed to do, but I don't see how manual installation of mods could be of any advantage (unless, of course, they require files to be copied into the Skyrim root folder instead of Data).

[Morferous]

MO does not really "do things that i it's not supposed to do." These problems are usually related to wrong order of mods in resource priorities, which is managed through the left panel.

Skyrim does not know where the content comes from. Records in plugins expect that relevant scripts are being ran in correct order from resource files. If you encounter a problem that looks like it is caused by MO, then sorting both load order and resource priorities again are usually keys to fix it.

Of course, there is a matter of fiddling with archive invalidation rules in MO. That rarely comes to play, but some players have managed to mess up their games by misunderstanding how it works. It does not look that this is the case here though.

[srayesmanll]

MO works fine will all mods I've used (my active mod list runs around 210-240 esps per character - I've used everything you listed except SkyKids).  The only "special" cases are the "mods" (really "apps") like FNIS, WryeBash (for creating bash patch), tesVEdit/XEdit, etc.  If you follow the instructions for these special cases laid out in the STEP page for ModOrganizer (see the link in my sig) then you'll have no issue.

[Barzing]

 

I understand that some mods from this site don't work well or at all with MO. Previously when I had the game installed, I finally got everything up and running but I never could get a penis on the MNC creatures. They wouldn't show up when the animations began either. Anyway, I just put together my new rig and am currently installing Skyrim again with a buttload of HD textures and cool mods and I was wondering which mods from this site I should be installing with MO and which ones I need to install manually. Here are a list of mods I plan to download from this site:

• Sexlab Framework
• More Nasty Critters
• Creature Framework (or is this included with MNC?)
• Schlongs of Skyrim
• TDF Aggressive Prostitution
• Skykids

 

 

Wrong thinking, MO is better than any other way to manage your mods. With MO you have enough granularity to manage your plugins (esp/esm) order and your other "mod files" order independently (textures, meshes, interfaces, ...). So it's impossible to think that some mods can work w/ MO sometimes, but not other time. MO is the best way to organize your modifications.

[Wolborg]

MO does not really "do things that i it's not supposed to do." These problems are usually related to wrong order of mods

 

 

Yes it does. It allows patchers to physically overwrite configuration files from their old overwrites which flies totally in the face of the Mod Organizer's most basic principle that nothing is supposed to be physically overwritten.

 

Order of mods hasn't got anything to do with it.

[Morferous]

 

MO does not really "do things that i it's not supposed to do." These problems are usually related to wrong order of mods

 

 

Yes it does. It allows patchers to physically overwrite configuration files from their old overwrites which flies totally in the face of the Mod Organizer's most basic principle that nothing is supposed to be physically overwritten.

 

Order of mods hasn't got anything to do with it.

 

You should never have any files in Overwrite folder. That is the first rule with MO. You should make mods out of tool Outuput data and not leave them lingering around.

 

As such, running tools do not never physically overwrite anything. They are being ran through MO, managed directly from Overwrite by the player, who then decides if they will physically overwrite content of output mods, make an alternative mod out of the content (for example for other profile), or clear it as obsolete.

 

Nothing is being physically overwritten, unless player intentionally does so.

 

Edit: If you meant that they are overwriting Skyrim.ini and SkyrimPrefs.ini files, then that is true. However, most tools actually ask about that. If they do not, then they would not ask about it in NMM either, which is pretty much a problem of the mod author and not MO itself. Every patching tool that generates any content will send it to Overwrite folder and not directly to mod folder.

 

Only exception is BodySlide, if you are working zaps. BodySlide initially prompts meshes to Overwrite folder though, so changes to zaps can be isolated as profile specific with that as well.

[Wolborg]

 

You should never have any files in Overwrite folder. That is the first rule with MO. You should make mods out of tool Outuput data and not leave them lingering around.

 

As such, running tools do not never physically overwrite anything. They are being ran through MO [---].

 

Congratulations. You are a true master of platitude.

 

Of course I don't leave files lingering in the Overwrite directory. The old overwrite I was referring to means a mod created earlier from the contents of the Overwrite directory by right clicking on "Overwrite", selecting "create mod" and entering a name.

 

 

I apologize to the OP for digressing from the actual topic, but evidently someone needs to be spoon-fed her.

 

 

This is how you can quickly and easily see how an executable run through MO does physically overwrite a mod's file.

 

1. Assume you have ran FNIS before, as a result of which there is a mod "FNIS overwrite" in the left pane of MO, corresponding to the subfolder ...\Mod Organizer\mods\FNIS overwrite on the hard disk. The mod was created by you from the files in MO's Overwrite directory (displayed in the left pane of MO as a pseudo-mod with its name in italics) in a way I just described. At this moment, the Overwrite directory (pseudo-mod) is empty.

 

Note that the mod "FNIS overwrite" (and, correspondingly, the folder ...\Mod Organizer\mods\FNIS overwrite on the hard disk) contains, among other things, a file tools\GenerateFNIS_for_Users\MyPatches.txt .

 

2. Select FNIS from the list of executables on the upper right part of the MO window and click "Run". A window titled "Generate FNIS for Users" opens.

 

3. Click "Exit". The "Generate FNIS for Users" window closes.

 

4. Look at the mod "FNIS overwrite", the subdirectory tools\GenerateFNIS_for_Users (or the corresponding folder on the hard disk). The file MyPatches.txt is no longer there!! It has been physically deleted. An executable run through MO has deleted a file in one of the mods.

(You can even keep that subfolder open in your file manager and see the file MyPatches.txt disappear the moment you click "Exit".)

 

THIS IS PROOF THAT MOD ORGANIZER ALLOWS AN EXECUTABLE TO DELETE A MOD'S FILE.

 

If you doubt this, I can do it again right now, take screenshots and post them here. But the learning process would be more efficient if you got into the habit of actually trying things out yourself before pretending to be an expert.

 

 

Before you let loose your next volley of obvious and irrelevant – yes, of course I know that that file is created anew and is located in the Overwrite pseudo-folder, so nothing is really broken. I am merely talking about a violation of the Mod Organizer's basic principle of mod files being protected from physical overwrites.

 

The fact that, from the perspective of the user, the mod "FNIS overwrite" and the FNIS executable are logically connected, is completely irrelevant. From the computing point of view, "FNIS overwrite" is a mod like any other mod. When an executable is executed through MO, MO is (of course) supposed to let it SEE the files in the virtual Data folder, but it is not supposed to let an executable physically delete a mod's file. At least that's what I used to believe.

 

This is not merely a theoretical issue. It has practical implications too. One would think that when you accidentally launch an executable which you actually don't want to run, then close it and then empty the Overwrite pseudo-folder, you are back where you were before. Unfortunately that is not the case. By launching and exiting an executable, a file you believed to be safe has been erased.

 

In the case of FNIS it is not a problem, but with other executables a configuration file that is deleted without informing the user might contains tens of settings. Mod Organizer gives no warning to the user about a mod file being deleted. The user is supposed to guess that it has happened and that the Overwrite pseudo-mod contains files that are necessary and no files that are unnecessary. But is that the case every time? Can I be certain that an unsuccessful execution won't generate something superfluous or harmful in the Overwrite pseudo-mod? I still don't know. But I certainly have learned my lesson to not trust the claim that MO won't let mod files be overwritten.

[Morferous]

 

 

You should never have any files in Overwrite folder. That is the first rule with MO. You should make mods out of tool Outuput data and not leave them lingering around.

 

As such, running tools do not never physically overwrite anything. They are being ran through MO [---].

 

Congratulations. You are a true master of platitude.

 

You writing is extremely incoherent and hard to follow. It looks like you write out of temper and do not stop to read what you actually wrote at all. That was true in your previous post and that was true in this post.

 

Your net rage attack is uncalled. I did not make any insult, or used a hostile tone in my post above. You are acting like someone just pulled your pants down from behind.

 

What you described does actually happen. MyPatches.txt  is removed from FNIS Output folder. This is not done by MO, but FNIS generator, which means it acts exactly as it should. That file contains FNIS generator patch data, which becomes obsolete in the second you run FNIS again. Basically generator is pulling obsolete file out of FNIS Output folder, while it is creating a new one for it's own use. That file has 0 effect on your gameplay. It manages is the list of selected patches in FNIS generator.

 

I admit that MO allows FNIS to pull obsolete generator file from output folder, meaning that generator works as intended.

[prinyo]

 

[ .. ]

 

I'm curious how does FNIS know where the file is located in order to delete it? 

Maybe MO is designating the mod that you create from the Overwrite as a working directory for the tools going forward? But then after running FNIS it's files are in the Overwrite again. Hmm....

[Morferous]

 

I'm curious how does FNIS know where the file is located in order to delete it? 

Maybe MO is designating the mod that you create from the Overwrite as a working directory for the tools going forward? But then after running FNIS it's files are in the Overwrite again. Hmm....

 

Some tools can locate their own files. For example, if you make mod out of BodySlide output, then zaps set for that output do not prompt new content to Overwrite folder.

 

Edit: Well, that was badly explained by me. As far a tool being ran through MO are concerned, all the information is going directly under Skyrim\Data and MO treats them as that way. As such, BodySlide is checking meshes folder, which is treated as one folder, despite being scattered under several MO folders.

 

FNIS does the same. It only looks for it's own folder and does not "know" it is not exactly in the physical location.

[prinyo]

 

FNIS does the same. It only looks for it's own folder and does not "know" it is not exactly in the physical location.

 

 

Hmm, I understand now. As far as the tool is concerned everything is where it should be as MO is creating the "real" file structure and this is what the tool sees. Thanks!

 

Added: From what I can understand MO is "intercepting" the file creations and is putting them in the Overwrite but is not "intercepting" deletions. This way when FNIS deletes a file it is deleted directly from the mod's folder, but when it creates one it is "intercepted". I can see how implementing a delete interception can be problematic - how do you overwrite existing file with an nonexistent :-)  

[ousnius]

All that MO does is tell the executable (the game Skyrim, or BodySlide) the location of all of the files with the highest priority inside of the Skyrim\Data folder (even if they're not there) by hooking the Windows API in the running process and rebinding file path A to file path B in the MO directory.

 

If you install CBBE through MO and run BodySlide through MO, then proceed to build a body mesh, there will be nothing in your overwrite folder. Everything that tools run through MO do will be on the original files in any of the real mod folders in MO, not overwrite, because that is not where they are.

 

The only thing where the files DO get modified in the overwrite folder, is when they're already there and haven't been moved to their own mod, or if the files didn't exist at all, in which case they get created in the overwrite folder.

 

FNIS is actually kind of a messy example to inspect how MO works, because FNIS deletes files and then creates them again, which deletes them from the mod folder and right afterwards creates them from scratch in the overwrite folder again. Tools like BodySlide don't do this, they overwrite the files in the mod folder instead of deleting and creating them again.

 

MO has good use, virtual folders for each mod and a virtual data load order is amazing. However, the way it was implemented from a technical side (hooking the Windows API to rebind every single path) is horrible, and I hope their new mod manager that's in the works will do it better and more reliably.

From what I can understand MO is "intercepting" the file creations and is putting them in the Overwrite but is not "intercepting" deletions. This way when FNIS deletes a file it is deleted directly from the mod's folder, but when it creates one it is "intercepted". I can see how implementing a delete interception can be problematic - how do you overwrite existing file with an nonexistent :-)  

 

This is true and why FNIS files are always created in overwrite instead of properly overwriting your "FNIS Overwrite" mod.

[Morferous]

MO has good use, virtual folders for each mod and a virtual data load order is amazing. However, the way it was implemented from a technical side (hooking the Windows API to rebind every single path) is horrible, and I hope their new mod manager that's in the works will do it better and more reliably.

 

Oh, I agree 100%. I am really hoping that Tannin and the two NMM devs can come up with better solutions than what both MO and MO2 now have.

[fore]

FNIS is actually kind of a messy example to inspect how MO works, because FNIS deletes files and then creates them again, which deletes them from the mod folder and right afterwards creates them from scratch in the overwrite folder again. Tools like BodySlide don't do this, they overwrite the files in the mod folder instead of deleting and creating them again.

 

MO has good use, virtual folders for each mod and a virtual data load order is amazing. However, the way it was implemented from a technical side (hooking the Windows API to rebind every single path) is horrible, and I hope their new mod manager that's in the works will do it better and more reliably.

From what I can understand MO is "intercepting" the file creations and is putting them in the Overwrite but is not "intercepting" deletions. This way when FNIS deletes a file it is deleted directly from the mod's folder, but when it creates one it is "intercepted". I can see how implementing a delete interception can be problematic - how do you overwrite existing file with an nonexistent :-)  

 

This is true and why FNIS files are always created in overwrite instead of properly overwriting your "FNIS Overwrite" mod.

 

The problem with FNIS is that it does not create most of the files itself. All hkx files are created by hkxcmd, which is called by FNIS as a seperate process. And there are no (documented) return codes.

 

Because of that I have different SEVERE problems getting things properly to work, especially under MO. Under MO, for example, I cannot immidately check if a file is created. Because when the hkxcmd process is terminated, the created does not exist yet, because MO has still to copy the resulting file to the overwrite. 

 

The biggest problem is that FNIS can't rely on what hkxcmd has done. For example, I don't know if a file exists simply becasue the user doesn't have the right to remove the old one, or if the resulting file is really the result of a proper execution.

 

So therefore I had no choice but make an execution chain of check - delete - create - "wait by doing something else" - check.