GrantSP

No. By "install via MO" I mean you need to have them added as executables in the MO program and run them from there. You can install them by any method you like but for them to "see" those MO installed mods they need to be RUN from MO. If you have done as the instructions on the description page and the variuous YouTube videos describe, and I am assuming you have, the only other thing I can think of at the moment is Windows UAC is interfering in some manner. If you have installed MO into the Program Files directory I would suggest you uninstall it and place it elsewhere.

In addition to my answer to your question in the Nexus forum, you must recognise that ANY tool that you want to use on your MO installed mods MUST ALSO be installed as an executable via MO. MO uses a virtual file system and therefore the mods installed need to 'worked on' by tools that are aware of that VFS. LOOT, Wrye Bash, TES5Edit or any other tool you want to use will only 'see' mods if they are run via the MO ui.

"Extensive testing". Ah, no. What I have tested though leads me to conclude this is a very solid and well designed tool. The xEdit scripts provide you with just the right amount of feedback to give you an idea of what is being manipulated. The whole process is very user friendly, indeed going by the amount of comments from newbies that are using this tool, it is extremely user friendly. It is completely compatible with everything as it reads in weathers from your installed mods and creates the RealShelter patch using those values. From what I can see this new mod is an entirely new beast to the old one.

Yeah that is a bit of a pain but apparently that can't be changed.

I have recently started my research for my 'pure-mage' play-through and appreciate any and all discussions on these sort of things, thank you. It is probably worth mentioning that Simple Skyrim Spell Scaling Solution is considered old and buggy and there is a replacement mod, Simple Magic Rebalance by Gruftlord that does the same thing and is not buggy.

Thanks Tannin. I purposely didn't post this in the MO bug reports since I don't view it as a bug, more of a curiosity that may be seen by others. I'll check the log tomorrow and see.

I just experienced the strangest bug with regard to MO's handling of bsa files. I have Immersive Armors installed and it outfits Kjar (the ship captain that takes you to Solstheim) in a Sea-Dog pirate-like outfit. Included in this mod is the Hothtrooper44_Armor_Ecksstra.bsa which also has an esp. Now since MO handles bsa files without the need for dummy esps like this one it prompts you to uncheck it, which is how my setup has had it for months now. So with no other armour/clothing mods installed after this one, and the left-hand pane having Immersive Armors with a high enough priority to beat any other potential conflict I started the game and headed out to get my boat ride. Well imagine my surprise to see Kjar sitting on his boat with no textures displayed on his fancy new Sea-dog outfit. He was all blue. So, quit out and check for load-order problems. None. On a hunch I checked the esp that would ordinarily load this bsa and started the game. Success, he is now clothed in what are quite snazzy duds. Quit out again and check what is going on. This time I unchecked the esp and started the game, just to make sure that was the problem. This time the textures are still loading. To make things clear. After installing all the armor/clothing type mods for this profile many months ago I have not seen any issues with missing textures. In fact I haven't had missing textures on anything, clothing or environment. The only thing that I have done in the last week was check to see how MO handles the file conflict process with bsas as archives and without them as archives. That involved unchecking the option on the data tab and refreshing before examining the Conflict tab. This makes me think we might need to actually have these esps checked just once and then disable them, though for the life of me I can't see why or how that would work. Anyone else seen any oddities with MO's bsa handling?

If you want to look out for the welfare of your SSD, there's nothing stopping you from installing MO, or just the MO Downloads folder on a HDD and keep the SSD for Skyrim. Like @hishutup said, all the work is done 'in memory' with the VFS, except for any memory swapping to hard-disk. (but if your system is doing that too much, it might be time to invest in more RAM anyway.)

@fireundubh for someone that is "really not that great with C#", you seem to moving along quite nicely. Well done.

Yeah the example I chose wasn't probably the best since both those scripts are identical. But... The biggest thing to remember here is IF MO is used to handle bsa files then for all intents and purposes they are to be viewed as simply another folder of loose files. If the mod simply has an esp to load the bsa then yes, it will be greyed out and can be unchecked in the load order. Most mods though don't simply supply an esp to load a bsa and therefore need to have both the esp and the bsa loaded. In other managers that don't treat bsa files as folders the load order of that bsa doesn't really matter since it will be loaded by the esp with the matching name. This is where MO is both better and trickier. You can have SOME files inside a bsa overwritten if it isn't the highest priority even if the esp that goes with it does have the highest priority. No longer is it a case of a mod with a bsa ALWAYS wins if the matching esp is higher. So since the question revolves around bsa files that AREN'T extracted the answer is YES, there can still be potential conflicts if the bsa isn't in the correct order. I guess this is another reason why @fireundubh made such a thing about the conflict resolution in that other post. In situations such as this, my Wet and Cold example, MO flags it as a potential conflict but in reality there is no problem. We need to think in terms of individual files when we decide left-hand order. It makes no difference if the bsa is extracted or handled by MO, those files will stand or fall for themselves regardless of esp position.

hmm... I'm not sure that is exactly correct. Unless of course I am completely misunderstanding what you are saying. Let's take a real life example: 'Wet and Cold' & 'Wet and Cold - Ashes'. These mods are an esp and a bsa each. In the bsa for both is a script, '_wetcoldbreathfastarg.pex' Ordinarily the order of both the bsa and the esp is 'Wet and Cold - Ashes' comes AFTER 'Wet and Cold' meaning that script will show as conflicting and the 'Ashes' version gets used. In my setup it is: Wet and Cold 31 Wet and Cold - Ashes 32 in the left-hand pane. Wet and Cold 56 Wet and Cold - Ashes 107 in the right-hand pane. Now if we leave the esp files alone and reorder the bsas, the 'Ashes' version of that script gets overwritten in the conflict, despite the 'Ashes' esp still having the greater priority. This would be true if the bsas were extracted or not. If the left-hand pane mod, which contains either a bsa or loose files, has the higher priority then those assets will be used.

@Crimson13 Yeah pick one, NMM or MO, and nuke the other. (Preferably NMM) Or if you need to use it, NMM, for games other than TES4 & 5 or Fallout[3/NV] then make sure there are no conflicting config files or folders that are used by more than one tool.

When you uninstall FOMM you may have to do a bit of 'house-cleaning' to get past this error. Apart from the installation folder that the FOMM exe resides in, there is also the two folders that store you mod installations but, more importantly, there is a config file stored inside your C:\Users\<your user name>\AppData\Local\FOMM\ path. On my system there is a folder called "fomm.exe_Url_tuoda5d5ilitfciodx1ffkav12tg1j0f\0.14.11.9\" which has the user.xml config file. Obviously for you that fomm.* folder will named slightly different. After uninstalling the program with Control Panel you should be able to safely remove any/all of these folders if they still exist. Try that and if it still persists then you may need to remove any orphaned registry settings as well.

After you un-install, or even before if it still throws a wobbly, you could delete the 'Install Info' folder under the the FalloutNV folder. That ORIGINAL_VALUE fomod message is from your InstallLog.xml that FOMM, and also NMM I believe, generates whenever you install mods. Apparently it refers to a dummy mod and is just part of it's initialization process. That way when you install it freshly in the new location the 'Install Info' folder can be created with fresh values.

@fireundubh I get where you're coming from, but I really think you're making a mountain out of a molehill. Whenever a mod user installs a mod the onus to install it correctly is on him. The user should know what it is about that particular mod that may/may not result in a 'conflict'. To help him/her do that the mod authors usually provide some sort of information about what the mod contains and any possible problems from mods that also have those files. If I install ModA because it has textures that I want to overwrite vanilla files, that is my choice and I have the responsibility to know which files. If I also see that ModA also shows some 'conflicting' meshes then likewise, it is I that needs to know which ones, not a tool designed to assist me in installing them. Let me ask you, before MO did you have the same or similar set of mods installed? Presumably these 'conflicts' were also there in your previous installs. Did you not notice them? Or perhaps those 'conflicts' were not really conflicts at all. If you had 200 mods installed I assume you did as much testing as needed as you installed them. What's the difference? MO shows 'conflicts' that aren't because the game runs fine and looks ok. When you install mods with any other tool those possible 'conflicts' are still there but you aren't seeing any flags so you don't notice. Sure, if there was a plugin that provided the sort of detail you describe, I would no doubt enjoy seeing it. But as a tool to aid in installation MO does just fine.

In the executable dialog do you have anything in the 'Start in' field? That is, does the program look to the default folder because it is told to? Also could provide us with the command that have to start FNVEdit? Any additional command switches? Honestly it is very strange. All you have shown so far seems to indicate everything should be fine.

If I am understanding it correctly you don't actually have a problem. FNVEdit is 'fooled' into looking at MO's VFS to find the plugins.txt and the messages displayed inside FNVEdit (or any of the xEdit programs) say it has found it in the FalloutNV directory. That message is saying that 'inside the VFS' the plugins.txt is in that path. Even if your real system has no such file at that location the message will still show. This is what we want. Your second posting shows the logged output saying: That's good, that's an indication all is well. FNVEdit should show you all the active mods available as defined inside MO. Can you actually load up your mods and edit them?

Thank you z. As I don't have the 'problem', I don't need the 'fix'. Still it is an interesting addition to the tools available. I really hope the virus-checking algorithms used by most sites around get much better at deciding what is or isn't a threat. All we need now is for MO's 'hook.dll' to be deemed a threat and we're screwed.

I took it from your OP that you were asking about the values assigned to those variables, not the variables themselves. Apologies for the confusion. Apparently not.

No, I would counsel the opposite. These settings aren't in the default ini files and are probably the result of someone's tweaking and then posting his results online. My guess is you came across them somewhere and added them in. It is also possible one of the extras you have installed might have added those and if that is the case then you should probably track down which one and read their documentation. A cursory 'Googling' of that term shows next to nothing about it so I would take that as being an 'undocumented feature' someone found. Removing them, or at best commenting them out, and testing should be fine. What's the worst that can happen? I doubt very much your computer will explode. ;)

You are not alone in having software flagged as 'threats' even though they are false-positives. I have for a number of years used software from a coder called Nir Sofer. Recently his tools too became the targets of over-zealous virus checkers and that has prompted him to revise his web site to reflect this 'problem'. It is just the climate we all live in now in this internet era. I would though add my concerns to the way your utility was marketed. IMO using 'Skyrim.exe' in the name was just asking for trouble. Nexus moderators are a notoriously panicky bunch and that would have been the 'red rag to the bull' for them. Additionally, is this truly a necessary tool? I never lose my cursor when alt-tabbing from Skyrim. Am I just one of the lucky few.

I've seen a few postings around that are supposed to show "the best ini settings!" and they do include settings similar to those. However I have also seen a few comments advising to never touch anything to do with [budgetCaps]. It wouldn't hurt to just comment those out and see if it gets better.

Ordinarily I would say no, it doesn't matter, but it makes eliminating problems easier if we go the extra step. It should be a case of MO merging the ini settings it has, into the skyrim_default and the result is found in your profile folder. You know, when all logical steps prove useless, the only remaining steps no matter how obscure might be the thing that helps. I wouldn't bet on it though, more than likely something else is going on. Question. Where are the settings assigned by that nVidia Inspector stored? Are they in your skyrim.ini? I haven't used that tool. What happens if you skip that step?

You are actually starting the game with the newly created profile? Creating the profile doesn't automatically select it for use, you need to pick it from the wide drop-down box at the top of the left pane. Sometimes the simple steps are the ones we assume have been done.

That sort of thing could be done with the 'Notes' feature. I write notes on all sorts of mods that don't have a specific tag or are the result of my editing. I can see the benefit of adding more columns into the panes. I'm not sure if that could be done by the user though, maybe Tannin would need to hard-code those into the UI. Have you posted these suggestions in the 'Feature Request' at "The Bug Genie"?