GrantSP

As @Nozzer66 already answered you about that message I will remind you to look back at his answer. To elaborate on that though, the same code that provides an ENB preset with its graphical changes is used to enable ENBboost. Depending on the settings in your ini. That message is reminding you you have ENBboost, not a graphical change preset. Sometimes mods take some time to show up in the MCM, give it a little time and allow the scripts to run through and then try again. If you want to try something else, move your SkyUI.esp further up the order. I'm pretty sure it doesn't make too much difference, but it won't hurt. I have a question about your modlist. You have 2 mods called SKSE, one at the top that looks like it is fine, most likely you followed the install instructions and this contains the scripts from that version, what though is the one at the very bottom of that list after FNIS & DSR?

Wow! where do you live? That's a fairly long list of acceptable places. Anyway, on the Clear & Present Danger page, if you look in the 20th Century section there is a link to the FNV equivalent. Following that takes you to it's host site where I believe they also have a copy of this mod. Haven't checked it, can't be 100% sure it is the same file, but it looks like it.

Since Skyrim.esm and Update.esm are essential, they cannot be toggled on/off in MO and will always be available to ANY tool run via MO. This is only true if the tool, in this case DSR, is set up correctly. Watch the GamerPoets video and see if your settings match or come close to, his.

Couple of things. Every item in the left-hand pane can be considered a 'mod' so: Unmanaged: Dawnguard is a mod cleaned Dawnguard.ESM is a mod (even though this is essentially the same file as from Unmanaged: Dawnguard , just cleaned) Dawnguard Textures opt is a mod Unofficial Dawnguard Patch is a mod Things that pass the 'conflict' examination ModA has some files: Texture1, Texture2, Texture3, Texture4, Texture5, Texture6, PluginA ModB has just one plugin: PluginC ModC has some other files: Texture4, Texture5, Texture7, ModD, more files again: Texture1, Texture2, Texture3, PluginA, PluginB Assuming those mods are in that order in the left-hand pane the files that get through to be used in the game are the ones highlighted. ModB's file PluginC gets through the conflict because, although there are two other mods lower than it, they contain no conflicting files, it is the only one that contains PluginC.

After some discussion in the LOOT forum @ BethSoft, I found out that you do really need to clear out both the installed folder that LOOT 0.6 was in AND the %AppData%\Local\LOOT\ folders of their .Git folder and masterlist.yaml, (there are separate folders for each game that contain these things) if you switch to using 0.7. ALL of my errors were immediately fixed by doing this simple clearance first.

All games have a limit of how many plugins you can load, hexadecimal limitations impose that as 255. Removing those four mean when you get close to the limit you are four less. For a basic game that has few mods, no, it makes no difference. Well it might add milli-seconds to the game engine loading records into memory, but to the user, no discernible difference. The biggest user noticeable change is the avoiding the 'loose files always wins' scenario.

MO wiki on archive management. The choice is yours, you can eliminate plugins whose sole purpose is to load a bsa. You also can gain priority of the bsa contents over loose files that you couldn't beforehand.

What issue? SkyUI works just fine when started from MO. So too doesOpen Cities Skyrim, what possible reason could there be for it not to work? MO is just a manager of mods as is NMM or Wrye Bash. There are no compatibility issues with using these mods. If you are referring to some installation workarounds, both these mods install just fine.

The point here is that renaming the bsas isn't the solution, it is the first step towards finding the reason for the error.

Makes no difference where it goes really as mods that use those scripts shouldn't be providing copies of them and the scripts they overwrite are from the vanilla assets. Best to have it load early though, where you have it is fine but you could place it earlier if you want. Additionally you have a lot of issues mentioned in this thread, can you post which ones, if any, are no longer of concern.

Thank you. I just tried giving myself some of the other items like a belt version and, yep, all works fine.Even the battery icon displays. I can't figure out though how to get iHUD to show it along with the other stuff so I can move it into place, is it only moveable from within its own menu?

I've got a slight issue with the Flashlight that I can't get my head around. Since I never had a flashlight in my inventory, I've not been able to verify the installation properly until now. Firstly I had a strange situation where, going against all logic that I can see, FlashlightNVSE needs to loaded AFTER oHUD to get it to register. When it is before you get an ingame error message about the *.xml files conflicting. Okay, so running it after seems to have everything work fine, perhaps because the flashlight uses NVSE to do its stuff it can be loaded after, at any rate, that side of the issue seems to be okay. But, after giving myself a handheld flashlight via console commands, I am unable to toggle its use via a hotkey. When I activate it in my PipBoy, the ingame configuration tells me the default key is 'J' and I can change it with MCM. Opening MCM I can do that and change it to 'L' but nothing happens. The only way to get the handheld flashlight to function is to activate as a weapon and draw it as I would any other weapon. Is the flashlight hotkey only for a specific flashlight? Is my ordering of the mods incorrect and it must go BEFORE oHUD, despite the protestations of the game?

You've done well @EssArrBee, as I posted on the other thread, it is definitely linked to bsas that share the same name as the plugin. You deserve a cold drink, have one on me.

You've cracked it! That is exactly what happens. I added back a bunch of bsas and I couldn't start. Renamed Advanced Recon Tech.bsa and tried again and... success. It also doesn't matter if the renamed bsa is checked in the archive tab or not, so long as the name doesn't match a plugin the game loads just fine.

Brilliant. That is exactly the sort of knowledge that makes these things necessary. Well done @Kelmych.

No problems. Glad you got it sorted.

@Tannin is at the moment conducting further tests, so I would advise a 'watch and see' stance to this matter. It has no impact on the actual managing of your mods and the game(s) it manages still run fine. You can always use the 'INI Editor' tool to make adjustments to you inis, or use Notepad.

That means on the Nexus page choose only the file listed in 'Miscellaneous' not the 'Main' file.

As asked before: you are running the game via the SKSE loader aren't you? Or even more pertinent, it is installed correctly?

I don't know the mod you are describing, I'll look for it later, but I would suggest NOT installing it via MO. My first inclination is no matter which way you choose to install it, with or without MO, it will want to install directlt into the Data folder and this will mangle MO's handling of the content. If it is just a zip packaged as an exe you could probably re-package it as a zip file and install it that way in MO. If it is an InstallShield installer or similar then there may be no way around using it to install as it wants. Afterward you may be able to re-package the files from you Data folder into a zip and install again from MO. I'll check and get back to you. EDIT: Fallout New Vegas Enhanced Content Seems to be an impressive/extensive compilation. From what I gather you could install this by choosing all the optional files instead of the main installer.

In my understanding that issue is has a lot to do with the fact that whole scene is a scripted intro and mods are trying to initialize their Papyrus scripts and are fighting for control of the processor time. This manifests itself in the physics engine going bonkers. Like @hishutup says the way around it is either use Alternate Start to get get by that, or disable all your heavy scripted mods and only enable them after you have escaped from Helgen.

From top to botton of the left-hand pane it goes from first loaded to last loaded. In other words if a mod is lower in this pane it will have priority and be used in game. So if we take that list and look at it logically, ANY mod that has the same named files in it as an early mod, appears LOWER, those files will be used. Looking at the screenshot provided, Unmanaged: Dawnguard has the same files as Dawnguard Textures opt BUT, the files are only the textures, if you have cleaned your Dawnguard.ESM it isn't part of the Dawnguard Textures opt so it too can be placed below the vanilla Unmanaged: Dawnguard. Likewise the Unofficial Dawnguard Patch, it contains changes to files NOT in the Dawnguard Textures opt and can safely go above OR below the optimized mod, but it must go below, ie have a higher priority than, your cleaned ESM. Now to the Hi-Res Textures. All your optimized versions must be below the vanilla Hi-Res Textures, which are in turn below the vanilla standard textures. The MO 'Information' window has a tab called 'Confilcts' which shows which files are going to win or lose the conflict in game. In this case Unmanaged: Dawnguard, Dawnguard Textures opt, Unmanaged: HighResTexturePackXX and HRDLCXX opt all contain textures but only the HRDLCXX will win, because they are LOWER or have a larger PRIORITY number. All of these mods though only affect the textures. Unmanaged: Dawnguard and your cleaned Dawnguard.ESM will have no bearing on the placement of textures since it is only the placement of the master plugin, Dawnguard,esm, that is important. In this case your cleaned ESM can go ANYWHERE LOWER that the Unmanaged: Dawnguard. In this specific scenario, where you have optimised versions of both the vanilla and the Hi-Res textures, I do find it strange to have them both. As I don't have any optimised versions of textures in my game, yet, unless there are certain files that exist ONLY in one or the other, I see no reason why you would optimise the vanilla textures IF you are later going to have Hi-Res textures replace them, let alone if those are optimised or not. If a texture, let's call it TextureA exists in the standard resolution vanilla mod and in the Hi-Res Texture mod, you clearly need only ensure the Hi-Res has the greater priority. There should be no need to optimise the vanilla or standard res file if the Hi-Res version will replace it. I will bow to greater authority here as I said, I currently have no optimised versions in my game but I find it hard to conceive there are files (textures) in the vanilla that aren't in the Hi-Res.

Something is not right there. I barely get over 12% CPU usage. The only difference of note is my CPU is an i7, but that surely can't account for that difference. Like you I use OneTweak because of the combined tools it provides, I know others here don't think much of it. If you really believe OneTweak is the culprit and can't live without borderless windows, there are other ways that you can get.

There are already numerous requests for colouring the panels in MO to aid in some manner. Some of those may be part of @Tannin's version 2.0 planning, which is about UI change.

I can't see how what you are describing can happen for the reasons mentioned previously. In your basic profile, I'm assuming this contains perhaps only the vanilla plugins and maybe one or two others. When you activate that profile and run GECK or xEdit, are ONLY those plugins loaded, no others? I have a 'Vanilla' profile that only contains the main game files. If I load that into ANY tool, ONLY those plugins will be available. No matter what I do in this profile, the order of plugins for another profile simply cannot be changed because the lists of mods, plugins, etc, exist in an entirely separate folder. The only way I can think of what you describe happening is when mods exist in a shared environment, this WILL happen if mods are installed directly into the Data folder and not installed via MO. Since you mention TTW, have you installed all the needed files via MO, or are some 'non-vanilla' files existing in the real 'Data' folder?