GrantSP

@pistachioman25 This topic is specifically for issues relating to FNIS & MO, please post your query in the correct place.

Actually only the main header needs to be checked, neither of those two sub-menus need to be explicitly selected. On my system neither of them are and I have never had any .NET issues with MO.

Running SKSE from the desktop or from MO will show exactly the same thing. All MO is doing is tricking the game into seeing the installed mods from its 'mods' folder, there is no functional difference between running the game with or without MO, even the memory impact is minuscule. Can you just clarify for us, this is also happening when you start a new game, not a game from a previous save?

Start button -- Settings -- Accounts -- "Sign in with a local account instead"

In that case disable and then re-enble it to restore the Fallout - Invalidation.bsa file, or make another check that it is present. Also make sure ALL your profiles have that enabled in case changing to another removes the file.

So are you calling FOSE or the launcher from MO after using this tool to enable Steam overlays? It sounds like you are loading MO by means of this mod/tool but then calling it again and then trying to start FOSE. I believe you should just start FOSE from MO once it is up and running.

.NET should not have to be installed as it is a part of every Windows installation. It may however need to be activated via the 'Turn Windows features on and off' tool in Settings. Upgraded to Win 10 last night and all my current .NET framework settings are still the same and FNIS runs without error from MO for me.

*.esp files, or plugins, don't actually contain any files, they are simply a form of database with records that point to the assets used by the game, amongst other things. These files can be edited by either the Bethesda supplied tools, Creation Kit, Construction Set or GECK depending on which game you are editing. Or by 3rd party tools such as xEdit. This one tool handles all the games and is often referred to by the renamed format: TES5Edit for Skyrim editing or FNVEdit for Fallout New Vegas etc. I don't recommend you try these tools until you become more familiar with the way the game is put together, or you are strictly following a guided process such as running a script to merge plugins or generate LODGen.

How have you determined Archive Invalidation is enabled? It won't be if there is no Fallout - Invalidation.bsa file listed in the 'Archives' tab.

That's the first time I've seen anything mentioned about a Steam renamed Fallout launcher. Wow! Okay, where does that file sit in scheme of things? Is it in the Fallout folder, Steam folder? If you create an executable setting in MO and point it to that exe what happens? Oh wait, is that this mod?

Other than what we've discussed in that topic, sorry, I've got nothing for you.

Can you check that the BSAs are managed by MO and they are checked in the 'Archives' tab? Also you haven't stipulated which MO version you are using.

Have you 'patched' or otherwise modified the Fallout executable in any way? The log is saying Fallout Launcher is being called, it shouldn't be, and that it is a 64bit file, it isn't. Aside from that the logs show all your mods are loading correctly. There is one point though. As most of those mods will need FOSE to work you will need to be calling the FOSE loader from MO, not the vanilla Fallout game and especially not the launcher. The first few line sof the log should be like this: INFO (21:24:59.0661): Windows 6.2 (workstation) INFO (21:24:59.0661): hook.dll v2.7.5 INFO (21:24:59.0661): Code page: 1252 INFO (21:24:59.0661): injecting to F:\SteamLibrary\steamapps\common\Fallout 3 goty\fose_loader.exe assuming you have FOSE installed correctly.

The "cleaning" you do to your DLC plugins has no bearing whatsoever on the assets provided by those mods. If you look at the 'Data' tab and examine the listing you will see the DLC's plugins with the 'Mod' that provides them listed in RED and when you mouseover that, the tooltip will say something like: Also in: Unmanaged: Dragonborn.esmThis indicates the 'dirty' esm(s) provided by Bethesda, and residing in the Data folder, are being overwritten by your 'clean' ones in the mods you created.

I will put good money on this NOT being a plugin conflict.

Keep in mind a very often misunderstood concept with MO mod management: Mods consist of two distinct things - plugins and assets. Plugin order is managed in the right-hand pane and is independent of the left-hand order Assets (textures, sounds, menus, scripts, etc.) are handled in the left-hand pane and need to placed correctly to ensure the correct conflict resolution takes place.

Let's answer one point first as it has bearing on a lot of your other questions. The Hi-Resolution Texture Pack plugins (*.esp) are only placeholders to load the associated BSAs. They contain no records that overwrite the actual game plugins, (Dawnguard.esm, Hearthfires.esm, etc.) That is why the small 'broom' icon is shown in the MO UI with the tooltip indicating they can safely be de-activated if you have MO manage your BSA management. This is also why you can safely disable (uncheck) those plugins in the right-hand pane, thus saving three slots. So, with that established, you have no need to worry about not seeing conflict resolution information or overwritten files in MO with those plugins. Now regarding your cleaning of the DLC. It is best practice to put back the 'dirty' plugins into the Data folder, Steam will only complain about them being missing and restore them anyway if you "verify your game cache" via the Steam client. That's why you create those new 'cleaned' mods and place the cleaned versions inside and then order them so the cleaned mods are directly placed after their 'dirty' versions in MO's left-hand pane, as you have in example 1. Now there is a misconception here that also needs to explained. You say: This is not correct. The left-hand pane shows "mods" which are comprised of plugins (Dragonborn.esm) and assets (textures, sounds, menus, scripts, etc.) What is shown as over-written is not the cleaned plugin but some assets such as textures. If you are following the STEP guided install then you should explicitly follow those instructions about BSA extraction with the purpose of optimising those textures. If this is just your own modding then there is very little need to extract BSAs. I'm not sure if you have ever used other mod management tools but it needs to be established that MO does things VERY differently and the process is both more complex but equally more fulfilling. If you remember that a mod is made of BOTH plugins and assets and MO manages these two distinct things separately you should be good to go. Please feel free to read through the wiki and watch the tutorial videos and ask any questions here.

You're close to the right answer, just another piece of information is missing in your understanding. Yes, the plugins need to be shown and checked in the 'Plugins' tab for the mod to work, likewise with any BSA that they use, these must be shown and checked in the 'Archives' tab. This is where the structure of these user-created texture mods comes into play. If all you are doing is generating LODGen or optimising textures there will be neither plugins or BSAs to show in those tabs,. However if you examine the 'Data' tab and expand the file structure to show the specific textures etc. you will see the mod(s) you have created as the providing mod for those assets, thus the game will use those. Choose any of the mods you have created and either double-click or right-click > 'Information' and look at the 'Filetree' tab. Notice the structure of that mod places textures (*.dds) into the folder tree according to the same file structure the game uses. Looking in the 'Data' tab at that same structure will show that file as coming from that mod.

Thanks, that peer-to-peer update "feature" is a real eye opener. How dare they use my bandwidth to fix their issues! Upgraded over the course of last night and looking at this P2P feature I actually will use the local PCs option. For those on limited internet the ability to upgrade/update ALL the PCs in the house with just one set of downloads makes a lot of sense.

The bashed patch created with Wrye Flash is handled in a completely different manner to that for Skyrim. For the patch to be created you must have either the blank patch in the Data folder, or in a mod of your creation, and that blank file is overwritten, not copied first then patched. Using WB in MO always places a new bashed patch in the 'overwrite' folder, with FO3 or FNV it doesn't. This means it is much more fiddly to have multiple patches for multiple profiles. When patching in the Fallout games, MO will log an error but still produce a working patch if the file is found in the Data folder. To get around this you should first copy a blank patch from the Wrye install and place it into a new user-created mod in MO.

Userlist is just the set of options you have set to order some specific plugins that aren't properly managed by LOOT. If you don't have one, don't worry. I'm not sure what your settings are and how that might affect WB. Can you try this, this is how I use WB for all the games I manage. Grab the latest Standalone version of WB. Create a folder away from any UAC folders or the games you want to manage. Simply open the archive and drag/drop the Mopy folder into that folder and WB will be installed there. In MO set the executable to point to the Wrye Bash.exe and in the 'Arguments' field add: -g Skyrim This way when you call WB from MO it will use the plugin list of the current profile and it will automatically be set to manage Skyrim.

FO3Edit and TES5Edit are exactly the same executable, the common name for all these tools is xEdit, so whatever you have set for your Skyrim via MO will work for FO3 via MO. Add the xEdit to the list of MO's executables and launch it through MO, the list of plugins that are currently active in MO will be used by xEdit. The state the window is saved in the Plugins.fo3viewsettings in the: [frmMain] WindowState=2 = maximised, 0 = minimised and 1 = the minimised to taskbar state you are seeing. That condition should be saved each time on exit based on the current window condition xEdit was last in. You might have permission issues on that file preventing it from being overwritten. You can manually change that with Notepad.

Did your running LOOT throw any errors? Also is this the external LOOT or just MO's internal 'Sort'? Looking at the error it is after some code called to examine the masterlist & userlist files used by LOOT, could you check that they are present and everything is working?

There's nothing in the instructions that would cause any files to be deleted, my best bet is that you have an overly zealous AV package that has considered those files as needing quarantining. Whatever the case using the Steam client to 'verify your files' should restore those missing files. After restoring them I would check your system to see what is removing them as it is not the doing of any mod or FNV4GB.

That's going to be a real shame if that option can't be disabled. Although I can sympathize with MS wanting to point all user queries to the one online search engine so they can improve it based on real life queries, I don't see why we ALL should be shackled to that sort of thing. My offline searches for things on my system shouldn't need to be sent half way round the globe to aid me. As it is now I use the tool 'Everything' to do most of my computer searches, very fast and can be streamlined with RegEx to finetune it.