GrantSP

If I may offer a word of advice, pick either NMM or MO and use just that one. Using them both together WILL cause you a lot of pain. As you correctly figured out MO doesn't install anything into the Data directory so there is NO CHANCE of irreversibly stuffing something up. This means though that anything you do in MO will now be at odds with the installed mods from NMM. To get the greatest benefit MO should have a clear vanilla Data directory. Now as to conflicts. Like @hishutup said, they aren't really 'conflicts', more like decisions that need to be made. Let's say you have ModA installed that has an esp, some textures, meshes and maybe a MCM menu. Then you install ModB and MO says you have a conflict. ModB only has some textures that are similar, but better than those in ModA. Moving ModB to a greater priority in the left-hand pane means ModA will load and function perfectly but it will use the better textures from ModB. No conflict, just a decision about assets. Of course if ModB also had an esp then you would have to decide which one to use in the right-hand pane. If they both do the same thing it's a case of either/or, not ordering them. Deselect the one you don't want. Again, the terms here used don't have the same import as they do in NMM. 'Installing' in MO is just a matter of unpacking the mod to be ready for use. No files are overwritten anywhere. This is where the beauty of MO comes to the fore. The left-hand pane contains all these 'Installed' mods and they can be ordered to load their assets (textures, meshes, sounds, etc.) by simply dragging them around. Lower in the window, or by assigning them a greater priority, means the assets they contain will be used. If you later find that the game doesn't quite look right, just reorder them. Remember 'no files have been lost, overwritten, destroyed or otherwise been damaged'. In NMM you would have to un-install the mod, restore the previous mod, check the game, cry when it didn't work, re-install Skyrim, re-install the mod(s) and try again. Additionally, if you enabled MO to handle bsas then you can reorder these also to even get around the Skyrim manner of using 'loose files' over bsas. Again it is all just a case of assigning the higher priority in the left-hand pane.

You don't have to sign up to pastebin. Doing so just means you can edit and delete anything you paste. Although there really isn't any reason to not signup, it's not like you are handing over any money or personal details that aren't already on other sites. If your TES5Edit.log is greater than 500K, which it probably is, just paste it into 2 or more pastebin pages.

I have just now received a copy of Fallout NV after all these years (I know, don't judge me ) and I want to know which version of the GECK to use. As I understand it the GECK that comes with FalloutNV is later and is also compatible with Fallout3 mods. Is this correct? That being the case I could remove the Fallout3 version and just use the New Vegas version for both games? Thanks in advance. Edit: It would appear I was wrong. Closely related but nontheless different tools needed. Oh well.

hook.dll is the file that is shipped with MO and it is the heart of the whole vfs operation. This image shows the version details and size that it needs to be: @sutex Something has gone awry with your installation. Either do a purge of MO, backing up the necessary folders like "downloads, mods & profiles" or if you like just reinstall over the installed version with the latest copy. Perhaps also do a system wide security check for malware or viruses or even just for other 'hook.dll' files on your system. Something is terribly wrong if your hook.dll is 64 Mb in size. These steps are in no way impugning wrong-doing on the part of MO. It has been checked by numerous sources as clean.

This may be a bit off-topic, but isn't Skyrim Mod Combiner the sort of tool that does this? To be honest I'm not at the stage yet where I am looking at adding in textures and such, not until I get a better rig at least. I did see this in the Nexus though and was intrigued by it.

This whole discussion is probably a moot one now, as it seems MO can, with a bit of coaxing, handle fomods acceptably. Up till the point of my posting this I could never get MO to handle C# style fomods correctly. Now it appears to do so. Having said that. Yes, where possible guides to installing mods should provide manual instructions, when the preferred option throws curveballs. I guess what I'm trying to advocate is an agnostic view of installation for mods. If we can avoid the concept of: fomod == FOMM or bcf == Wrye Bash MO is so much more advanced than all the tools I've used before for so many reasons which I won't go into now except for saying this. It makes the contents of installed mods much more important rather than just being the tool that unwraps the contents and shields the user from them. This, IMO, is needed to show users how the mod is doing what it does. It's one thing to install a mod that provides A, B, C & D. It's another thing to SEE how all that is done. This is what users need to know. If users had to unpack the fomod and see the structure of the mod, which files go where etc.. They might gain insight in how to fix common problems mentioned in forums. That may be 'harder' in the first place but much easier in the long run. I would say there are users that have followed, 'to-the-letter', installation guides, like those here in S.T.E.P., and they have no idea why they did what they did. Install modA before modB but only if you don't want modC etc. Those steps can be followed, but surely they need to be shown why. That way when they come upon a new mod that isn't explicitly covered they may be able to deduce the steps needed based on what they learnt previously. Does this make me sound patronizing or arrogant? Possibly. I would like to think I'm not though. I learnt over many years from more skilled users that didn't tell me what to do, but showed me what to look for. It also is the way I operated as a teacher way back when I was still working. More instruction -- less hand-holding

Although a bit 'off-topic', I have further found that the loadorder.txt is ONLY re-generated IF you actually change the load order by drag-drop, not just un/checking. Drag-drop changes both the plugins and load order texts. Now if I can find a way to get LOOT to save the results as a list with CR/LF after each esp like MO does!

You know I'm learning more and more about MO as I do this. De/activating esps/esms in the right-hand pane modifies the plugins.txt, AND the loadorder.txt, and the files listed in it, plugins.txt, are a more accurate depiction of what is actually loaded. Have a look at a stripped down profile I have to see what I mean. The 'Plugins' button shows the data from the plugins.txt. Loadorder.txt seems to be a bit of a misnomer as it doesn't actually display the 'load order'. This is a list of files that the engine sees, I think, as it lists esms/esps that aren't 'loaded', according to MO, but ordinarily they would be. Things like esps that load the Hi-Res Textures. The LOOT results also include those files as 'loaded' and sorted. The plugins.txt shows what is actually checked in the right-hand pane. The 'ModList' button shows the modlist.txt which is a list of the "installed" mods, even if they aren't activated. As you can see they are a few there that I am experimenting with as they do much the same thing. Night-eye being the current experiment. Perhaps the two lists are needed to sync how MO and outside tools, LOOT, Wrye Bash, etc., see those files?

Make sure you aren't confusing a checked mod in the left hand pane with a loaded *.esp in your load order. This is not actually what that means. Esp/esm files are activated and sorted in the right-hand pane and LOOT will show those results correctly and they will correlate with what MO has shown, and vice versa. The left-hand pane is showing which MODS are loaded. Note I said "mod" not "esp". Mods, as you are aware, contain resources like meshes, textures, menus, etc. When a MOD is checked in the right-hand pane it is merely showing those resources are available for use in the game. So you may have installed a mod that is only providing textures, like the Hi-Res DLC, that doesn't need an esp to be used. That means it is unchecked in the right-hand pane but checked in left-hand pane. The mods you bashed probably still provided resources to be useful and they will still need to made available, ie checked, in the left-hand pane.

The loadorder is saved in MO as a *.txt file called loadorder.txt in your Mod OrganizerprofilesDefaultloadorder.txt or if you have set up a profile, substitute 'Default' with the profile name. e.g. Mod OrganizerprofilesGrognak the Barabarianloadorder.txt. Actually there are more useful saved options in each of those files in your 'Profiles' folders. Another useful tool that is being developed now is Modwat.ch. It uploads your loadorder, plugins list and your ini files so you can just post a link.

While technically that is true, there is a C# installer, I have never been able to get it to correctly work, hence my assertion that we should look at the situation as though there isn't one. I will refrain from offering this advice any further if you wish. Edit: Just to get my facts clear on this I went to my MO installs and re-checked how the c# fomod installer fairs. Looked for a few mods with C# installers in my downloads folders to test them again. Apart from a couple of quirky messages, like asking for 'archive invalidation to be activated' they seemed to install just fine. So as of now I will keep my mouth shut. :O_o: I guess I will now have to revise my installation recommendations from now on. Has the NCC plugin been updated in the last few releases? I didn't think so. I'll put it down to my error.

Those scripts are there so the user, if they are using FOMM, can install the mod with any options the author provides. Mod Organizer at the moment lacks a good plugin to handle that particular type of script, hence the failure. As far as the actual mod is concerned, that fomod folder and all it contains mean nothing. The game engine never sees it and knows nothing of its existence. At one stage you could choose between FOMM, Wrye Bash, NMM and a few minor tools to install mods in all sorts of games. Mod Organizer is a recent, but superior, addition to that bunch of tools. Despite it not yet having a C# installer script plugin, it is head and shoulders above all the rest.

As MO becomes more and more popular, mod users are probably going to face the issue of installing fomods that use C# as the installation script, and the resultant error from no suitable plugin in MO. I have seen mentioned here in S.T.E.P. the method of invoking FOMM from within MO and creating a new mod package that is then installed. While I understand the rationale behind doing so, and in fact I laud those that have written installation guides to assist mod users, I feel this is in fact making the task of assistance harder. Let me see if I can elaborate on that idea. Forum members that write these guides or answer questions about installation probably have a great deal of knowledge about what mods are and how they work, perhaps even creating a number of mods themselves. They know the easy way to do things and can cut through the hardship of installation and provide a quick fix. Therein lies the problem. They know these things because they had to figure it out for themselves and are now aware of what is needed. The vast majority of posts in forums like this or other sites where mods are hosted are from users that have little understanding of what a mod is or how they work. Without wanting to sound patronizing a great deal of mod users see that a mod does such-and-such and they go all: "oohh, shiny. must have it", thinking that it will magically transform their game by some strange method. That's fine if all they are wanting is to do something simple. How many times though have you read posts from users that haven't even read the description or readme and are expecting the mod to just work wonders? Have you not seen the pain in the mod author's comments as they handhold them through it or perhaps dismiss them entirely? The problem is the majority of mod users just don't know what mods are and how they work. Most of the installation/setup issues could be solved by themselves IF they knew how the mod operates. Now I'm not decrying tools that are used to manage mods, far from it. I have used Wrye Bash and its derivatives for ages and am now a MO advocate. I know their worth. These tools are great because they speed up or automate repetitive or tedious tasks or give access to areas previously hard to reach. Which brings me back to topic: FOmods. Your average user has no idea what these files are that they just downloaded. To them they could be little armies of robots that somehow construct a new world in their game. *.rar, *.zip, *.7z mean very little to them, let alone what *.OMOD, *.FOMOD or for that matter *.esp/esm or *.bsa are. They should! So, asking them to use another tool to handle a file they have no, or little, understanding of only obfuscates the reality for them. They need to know what are inside those files. It helps in so many ways. Isn't there an ingame menu supposed to show?Where is that icon for X feature?What textures/meshes are inside it?Are they loaded before or after another mod with the same files?Is this mod compatible with X or Y?What does it contain that needs precedence? Those sort of questions become much, much easier to understand if we show users how to look at what these packaged mods contain. That means encouraging users with FOmod issues to unpack them and either remove the fomod folder or check if it can be tweaked in some way. Quite a lot of the problematic mods are actually very easy to install in MO since there is no chance of overwriting anything. This alone makes MO a fantastic tool. If the user then opens the archive and sees it is just a collection of folders and a few files they will start to see where it all fits in the game's file structure. Some are even easier since they are just an *esp/esm and a *.bsa. Two files to place! What is hard about that? Doing this gives the mod user, not only a working mod but, a sounding in what to check for in maintaining a good load order or even in taking the first steps towards merging files or making bashed patches! The extra couple of steps they do with just one tricky mod may mean less steps in the future. Just in case it wasn't made clear in the preceding paragraphs: I am not criticising the knowledgeable forum members that have posted guides here, they are to be lauded for all the work they do.

This is a well documented shortfall of MO at the moment. All fomods that use C# as the install script fail as there isn't currently a working installer plugin for MO. The workaround is as you have done, remove the fomod folder and install manually. In my opinion this is preferable to the method sometimes proffered here in S.T.E.P. of invoking FOMM from within MO to handle these types of mods. As you no doubt can see, you have gained knowledge of the workings of this mod, and also other mods like it, because you had to manually work with them. This is better than adding another level of abstraction between the player and the mod. IMO. Having said that, the errorcodes you are seeing are, I believe, not related to fomods.

MO "installs" all of the mods into a virtual file-system. Because of this nothing in the FalloutData folder is modified. The 'menu' folder exists in the place-holder folder in the MOmods folder, in this case: Fallout3Mod OrganizermodsDarnUI - Fallout3menus When MO starts it builds the file structure in memory, so you won't actually see anything in your default Fallout folder unless you start a file manager via MO. (must be a 32bit program) What exactly are you seeing/not seeing after installing DarnUI?

This is how my mods are ordered.

The first decision you will face is which version to use; fomod or 7z? I strongly suggest you use the 7z version as it will not prompt you with options that you imagine will be set but actually don't. To clarify, using the fomod version I get prompted as to whether I want the Fonts changes added to the ini. Regardless of whether I answered yes or no they weren't added correctly. So... use the 7z version. After downloading it from here, along with the hotfix, simply install them using MO. All the resources necessary for the UI facelift are now available. The only thing that needs to be fixed is the fonts. Open the 'Information' window for the newly installed DarnUI by either double-clicking or right-click -> 'Information'. On the INI-Files tab right-click in the Ini Tweaks tab and 'Create Tweak' and name it "Darn Fonts", or anything you like. In the main edit box to the right add the Fonts section from either the description on the download page or from the pdf file that is installed with the mod or from the code box below. On my system the pdf was placed here: C:GamesFallout3Mod OrganizermodsDarnUI - Fallout3DocsDarNified UI F3DarNified UI F3 ReadMe.pdf The whole section can be placed, including the lines with the commented out fonts, this is needed to ensure no duplication. It should look like this: [Fonts];sFontFile_1=TexturesFontsGlow_Monofonto_Large.fntsFontFile_1=TexturesFontsDarN_FranKleinBold_14.fnt;sFontFile_2=TexturesFontsMonofonto_Large.fntsFontFile_2=TexturesFontsDarN_FranKleinBold_16.fntsFontFile_3=TexturesFontsGlow_Monofonto_Medium.fnt;sFontFile_4=TexturesFontsMonofonto_VeryLarge02_Dialogs2.fnt;sFontFile_4=TexturesFontsDarN_FranKleinBold_Otl_12.fntsFontFile_4=TexturesFontsDarN_Sui_Generis_Otl_10.fntsFontFile_5=TexturesFontsFixedsys_Comp_uniform_width.fnt;sFontFile_6=TexturesFontsGlow_Monofonto_VL_dialogs.fnt;sFontFile_6=TexturesFontsDarN_PetitaMedium_Outline_18.fnt;sFontFile_6=TexturesFontsDarN_Forgotten_Futurist_Otl_18.fntsFontFile_6=TexturesFontsDarN_Sui_Generis_Otl_13.fnt;sFontFile_7=TexturesFontsBaked-in_Monofonto_Large.fntsFontFile_7=TexturesFontsDarN_Libel_Suit_Otl_24.fnt;sFontFile_7=TexturesFontsDarN_Klill_Outline_20.fntsFontFile_8=TexturesFontsGlow_Futura_Caps_Large.fntThe Ini Tweaks should have a small check box with "Darn Fonts", enable this. This adds the font changes to the [Fonts] section of you ini. [You could also spice this up a bit and make separate entries for different sets of fonts and enable or disable them as you desire.] Install the hotfix in the same manner and ensure it has a higher priority than the main mod and activate them both. You should now have DarnUI installed into your Fallout 3 game. Further mods that change the UI, like FWE or iHUD can also be added succesfully but they too need a bit of tweaking. I have all those mods installed via MO and they work just fine.

The file 'hook.dll'. Can you verify it exists in the: C:GamesMod Organizer folder and not in: C:SteamLibrarySteamAppscommonFallout 3 gotyDataFOSEPlugins folder? If that is the hook.dll that ships with MO, then it shouldn't be in the plugins folder, it needs to be in the MO folder. Looking again shows it being checked in the plugins folder, unless it is an unrelated plugin from some mod I am unaware of. Relocate it and see if that helps. The game will stumble from MO if that dll isn't where it should be and starting it from outside MO means the fose.dll will just skip it if it isn't an actual plugin, thus the game will start. At least that is what my latest theory is!

Yeah anywhere near the top, or at the very top, of the list is good. They need to placed so that any and all mods that update those resources can have priority. Keeping mind the patches and any optimised versions need to have the greater priority.

Okay lets take the Populated Cities mod. I haven't got that mod, but looking at the Polish translation of it (Nexus looks to have removed the English version) the packaging isn't set out in the best manner. I am assuming you let the FOMOD installer take control and therefore the *.esp used to activate the mod isn't being copied across properly. The best way to install it is by using the 'Manual' option and set the Data directory yourself and check/uncheck files/folders as necessary. From what I can see, and again this is only going by the file preview pane in Nexus of the Polish version, there are two options, "Full" or "Redux". Choosing which ever *.esp, enables the 'Populated Cities Towns Villages.esp' that is installed by default. Those two *.esps however are in sub-folders called "FULL esp" & "REDUX esp" and they will need to be moved during installation to be in the 'Data' folder. It might also be possible, if all the files were copied but placed in the wrong location, to move them using the 'Filetree' tab. Simply look for the *.esp that matches your choice and move it to the correct place with drag/drop. Try that first and see if the install can be resolved. Possibly the other mods are structured similarly. As to SMIM, I haven't reinstalled it under MO 1.2.14 so I have no idea, still works fine for me from a previous install.

Well... I'm all out of ideas. Hope you get it sorted.

@EssArrBee I think with Flickr you have to first of all visit the page, probably to generate a cookie or something like that and then reloading loads the image. At least that is what happened with me. Which meant i could see the images and they do look like the ones associated with that NMM version error. Although the error numbers weren't 101 or 202? It could also be from general server faults either on Nexus's end or with the user's end.

There is another way of doing that that doesn't involve editing the esp/esm. MO has the 'Filetree' tab that shows all the resources that a specific mod provides, meshes, textures that sort of thing. You could open the 'Filetree' tab for the mod that contains the unwanted resource and after navigating to the file(s) you don't want, right-click them and from the menu choose "Hide". That should mean those specific files are no longer considered available and whichever mod that has the next priority will load their files instead. At least that is what I think should take place.

Some of your 'bizarre' issues do sound a bit like conflicting installations of your mods. ie. you at one time were using Wrye Bash or another manager and now you have installed MO but the previously installed mods are still existing in your Skyrim data folder. Certain tools like TES5Edit appear to see them, depending on where you started that tool from, but they aren't really there since MO hasn't "installed" them into its virtual file system. MO and all other mod managers are completely different with regards to mod installation. MO should have two folder that have a great deal of importance to your setup. Downloads & Mods. The downloads folder contains the archives you probably got from Nexus and the Mods folder is setup by MO when you "install" them. There should be no mods existing in your data folder other than the vanilla. If there are then they are from your previous setup and need to be removed.

Sorry to say it but from what those logs indicate, FOSE is installed and running. Any issues you have with the game not starting from MO correctly don't appear to be related to FOSE, as far as I can tell. Barring the differences with file locations, your logs look the same as mine, whether from inside or outside MO. Have you done anything else to your installation? Running an ENB? Patched the code to access 4Gb? Any other patchers that you may have run? Lastly I suggest you add these logs to the report you filed in the Bug Genie, that way Tannin will definitely see them. Sorry, that's all I got.