GrantSP

xEdit is the generic term used to cover that programme for all the games. It is exactlty the same tool, just used for different games. When you mod the game you ar ein fact deliberately introducing a "conflict", ie. a record that overrides one in the official plugin for the purpose of changing the game. So, yes, conflicts are normal. However without seeing your specific conflict I can't definitively say if that conflict is intentional, only you can determine if it is something you want.

Not sure about the bash tags. Makes it more manageable I suppose to do so after each new mod is installed, but it may also be just as easy to do it when they are all installed, trial and error I guess. As to what you describe as "memory leaks". Perhaps you are referring to the LAA flag being enabled on the GoG version. This means you don't need to patch it to make it use the available memory that more modern software does in Windows. I've not heard about any such memory leaks on Steam games due to their DRM.

I have no idea what you're talking about when you say: Any plugin, whether an official DLC or a mod from a 3rd party, needs to checked in MO's right-hand pane. There is no such thing as "already installed" with regards to how these plugins are provided to the game by MO. Ensure every plugin you need are checked, all BSAs shown in the 'Archive' tab are checked, if you are using MO to manage your archives, and then check with xEdit to see what is causing any conflicts.

I don't know who you're talking to but not checking DLCs is NOT normal. Check all the plugins you need.

Welcome to STEP @Takijira Are you sure you edited the correct INI? MO uses profile specific INIs so if you only changed the default FNV ones that won't work.

I'd be very surprised if you have ~200 plugins active in a Fallout 3 game. The engine is nowhere as robust as Skyrim's and usually it will start to fall over around ~130. So, yes, If you want to use that many mods you will need to combine a number of those plugins to get the total number down.

It makes no difference whatsoever to MO whether you have merged/bashed/conflict/whatever patch. MO is just a tool to mod/launch the game. Don't be confused by the option MO presents when installing a mod to 'merge' it. This has nothing to do with the contents of the plugin, just the assets in the archive.

JSawyer's mod will definitely make a difference. I'm not sure that any carry weight mod will work properly with it.

Yeah I agree, but we are all held captive to it if we want to use the correct drivers etc. in the future. Remember Microsoft has said that ALL new CPUs will ONLY be supported by Win10. That means any new system you make will have to have it installed. Anyway the removal of said bloat is fairly straightforward.

I've been running Win10 since its initial release, albeit with some of my tweaks to remove bloat, and find it as stable as ever. I run myriad games on my system, some of them much more intensive than Skyrim and never do I suffer from CTDs.

You're going to have to clarify something here. On the one hand you state: and then again you state: So which is it? I see nothing about your system that is inherently unstable which means Skyrim should play the way it does for 99% of the userbase of vanilla Skyrim. As previously mentioned the test you employ is bogus and what is worse if you continue the game from that point you may have introduced anomalies due to scripts firing prematurely, or conversely not firing when they should. Your playthrough should be on a save that was not 'stressed' that way.

Hmm... I just installed HGEC to see what it provides and it's just textures and meshes so if everything is in the correct place, as it appears to be in my install, it should just work. Only thing I can't check is the Morroblivion part of your question. If, and that's a big if, the paths is somehow changed to use assets differently, then straight out Oblivion mods may not work. I find that very odd though that such a big change would be used since Oblivion is basically built on Morrowind's format.

Check the 'Data' tab and see if the installed mods are being used to replace the assets, if not you may have incorrectly installed them and they are in the wrong folder. I know Roberts' Body Replacer uses a BAIN wizard to copy the correct files but if you somehow chose to do so manually and didn't set the top level folder they will be installed wrong.

Check ALL the paths you've set are at the same user level. If the merge is trying to access a path with elevated privileges you will get notified. Also in the future try and name your thread posts with a more descriptive title. This one will be very obscure for anyone reading through the forum in the future, you've not explicitly stated which of Mator's tools you're using (clearly it's Merge Plugins) nor have you mentioned that in the title.

Hmm... maybe the last Bethesda update broke something. I have just noticed that if I try to load a game from a shortcut on the desktop my mouse is disabled, loading from MO2 works fine. This is the first time I've loaded up SSE since the infamous Creation Club went active, perhaps that is the issue. At any rate if it works from the MO2 GUI, just go with that. Also regardless of whether errors happen MO/MO2 logs all activity it generates. Look in %AppData%\Local\ModOrganizer\Logs\

The format of the shortcut is this: <path_to_MO2>\ModOrganizer.exe "<path_to_SSE>SkyrimSE.exe" Post your logs if you're having issues with MO2's functionality. Use <spoiler> tags or an online service like PasteBin.

If you're using MO2 then I assume this also for Skyrim Special Edition which in turn means this SKSE64 which is still in alpha. No bugfixing will be done until SKSE is released to the public properly.

The last time I saw that error was due to the mod in question being for SSE not old Skyrim and therefore the BSA was in another format. Is this mod for Skyrim or Skyrim Special Edition? On another note it appears you are not installing those mods via MO but directly into the Data folder. Why?

Rule of thumb with MO's overwrite folder is: if the file exists it will be replaced, if it is new then it is created and found in the overwrite. Keep in mind MO can not do anything to any file contained within a BSA. Any new stuff you create cannot possibly overwrite any existing data from USLEEP. The path to any *.nifs you make should be pointing to your plugin, ie. \meshes\actors\characters\facegendata\facegeom\<yourplugin.esp> thus it won't conflict with anything.

To directly answer the question in your post's title: It doesn't matter! The 'mods' listed in MO's left pane are purely a MO thing, all that is being presented is the name of the supplying folder in MO's installation. Since there are no plugins, *.ESP or *.ESM files, that may conflict with Update.esm it makes no difference. Of course with other mods it may make such a difference but the provided example, no, it doesn't.

If it's any consolation I too had those sort of issues with Qt dependencies last time I tried. Could be we're both "old farts"?

That sort of "issue" really only comes around when we're dealing with large lists of mods, anyone with just a single modded game in one profile and perhaps a testing profile with the same list, plus additions for testing, and maybe a bare-bones minimum profile to fall back on should be able to do just as you describe and correct the ID after adding in the new mod. It's only when you add a batch of mods together that it may become cumbersome. In that instance I often open the 'modlist.txt' from one profile in an editor and make the needed changes by changing the "-" & "+" as needed to indicate whether the mods are active as well as moving them around to correct the order. Even this is rarely done as once you have a stable set of mods that should be kept as a set profile and then you should work on a copy of it when adding in new ones. I think what you may need to look into is your work flow with profiles. Not a criticism, just a suggestion. Everyone works however comfortably it feels for them.

The only thing(s) that could cause that are to do with the file: archives.txt in whichever profile you have active. That file lists all the BSAs and their status. If another process is operating on that file any changes you make inside MO's UI may not take or the permissions on that file are set so the specific MO instance can't write to it. This last one is why I always advise against users running MO as admin at any time, as if that file was created during that process it may still need admin rights to edit it later on and MO may not always be started as such. Try copying that profie using MO's 'Profile manager' and make any changes to BSAs as needed and see if that profile too gets reset after a system restart.

You need the original English mod to supply all the assets, textures, meshes, etc. but the plugin isn't used. You get the German version plugin for the game you have, either vanilla or with BS Bruma installed. I don't know about the T'Skyrim plugin but if what you describe is true then yes, you'll need to do some xEdit trickery to make your own patch. It won't be as simple as renaming and adding it as a master, you'll need to make sure other records are referenced correctly to avoid conflicts.

Okay let's examine this a bit. That texture is used by STAT: 00087837, for example, which in turn calls the *.nif: Architecture\WhiteRun\WRInteriors\WRCastle\WRIntCastleFreePillar01.nif That in turn uses the texture in question but if SMIM is active the path is: textures\smim\architecture\whiterun\WRCastleCarvings.dds not the one referenced in aMidianborn, ie. the vanilla. So, yes, if SMIM is active the aMidianborn textures are not used because SMIM's path are, as you correctly surmised, different to those in the vanilla game. Clearly a patch is needed to correct all the SMIM pathing changes so that all the other texture overhaul mods are using the correct textures. Or some file switching to move textures around to replace the 'fugly' ones used by SMIM.