Kelmych

The mod you reference sounds like it might provide (or intend to provide) gameplay similiar to what Oscuros Oblivion Overhaul did for TES4. I felt the vanilla TES4 NPC leveling made little sense.; there were even forum threads about how to complete Oblivion while remaining at level 1. OOO didn't completely remove NPC leveling, but for each NPC type it was changed to a fairly narrow range (e.g., 20-30 or 40-50) and NPCs would randomly have a level in this range.

There is a short section of the FO3 guide that has a general discussion on bash tags that you might find useful (for Skyrim you would use Wrye Bash and TES5Edit vs. the FO3 equivalents) including the use of the Generate Tags for Wrye Bash script you can use with your patch plugin to add automatically bash tags. You will need to use TES5Edit on the bashed patch to see whether all the identified tags are the ones you want. You can use LOOT to automatically sort the plugins including the new patch, or manually put the patch plugin wehre you feel it should be. Look at the OP in the main Wrye Bash patcher update thread to get the link for the most recent development version of WB 307.x, and install this version. It should handle some additional bash tags. After this is done run Wrye Bash. If you right click in the bash tag window on the bottom right it will show the bash tags that are available in this version of Wrye Bash. I don't think the WB patcher uses all of these yet; you would have to read the WB forums to see which ones are actually supported. Names, Stats, and Invent certainly are, but I'm not sure the AI tags work. If you used the script mentioned above and highlight your patch mod the tags that the script felt might be relevant will be checked. Run TES5Edit and look at your patch to see whether the bashed patch has the changes you wanted. If not you might need to load your patch after the bashed patch or create an additional compatibility patch that loads after the bashed patch.

UIO works with two sets of menu folders: It works with mods that have xml files in menus\prefabs\ . The files in this folder need to have pointers added in menus\main\hud_main_menu.xml so they show up in the pipboy. UIO adds these.It uses menus\main\hud_main_menu.xml. It takes the winning version of this file (the only one it sees since the other versions are overwritten) and adds the pointers mentioned above. UIO ignores all other menu files such as map_menu.xml As GrantSP mentions, the guide needs to be changed a little since MO no longer has the installation problems it used to have.

When I was editing my response the word texture got lost. I meant to say that the interface texture files were installed for all three pipboy possibilities, as shown in the screenshot from Gazda. Only one map_menu.xml gets installed, and it is edited by the fomod.

UIO only affects a few of the UI mods, and map mods like Better Map Detail Map and Icons are not among them (UIO doesn't affect map_menu.xml). The UI mods that don't depend upon UIO are installed after UIO so that any problems with UIO and menus can be resolved before the other UI mods are installed. The installation (left pane) order of UIO matters because of the menus in the mod; the order of these do matter. As GrantSP mentions it doesn't have a plugin. The load (plugin) order of the UI mods affected by UIO also matters. Mipmaps matter for most textures but not a lot for textures used for interface screens. Mipmaps in a texture file (*.dds) used for interface screens like the Pipboy should not have any noticeable effect on the interface menus. The fomod installer in Better Map Detail Map and Icons changes the map_menu.xml file based on the pipboy version it detects. It doesn't look like it uses this information to selectively install install the interface files (it installs all of them, but they don't get used unless the associated pipboy mod is active). If useful I'll provide more detail on what UIO does. Most users don't care a lot about how it works, they care only that it does work.

MO preserves a lot but not everything. It saves the list of mods, the mod priority order, and the plugin order for each profile. It doesn't save the mod files themself for each profile; this would take a huge amount of space. I have several profiles that use different installation options for a few of the mods (e.g., a STEP Extended profile that uses Skyrim Flora Overhaul basic (1.87) and another profile that uses the most recent version of Skyrim Flora Overhaul (2.5b)). When this happens I save different versions of the installed mod, each with different installed options to use with the associated profile. Each different version has with a different name (e.g., SFO Basic and SFO 2.5b, and two different versions of the DynDOLOD files).

I've been using both settings. I haven't compared then by running DynDOLOD twice and then switching the files/plugin. I'll see if I can find a view that includes the effect of fxglow.

If you run DynDOLOD and then change the name of one the plugins used by DynDOLOD, you will need to rerun DynDOLOD or make changes as discussed in the DynDOLOD thread.

Should just be a new profile.

The installation instructions were updated to version 2.6

If you are starting a new game it's a good idea to start with all the mods you are going to use, at least the mods with plugins. Some plugins can be added after the game starts but this is always a potential source of problems. One possibility is to start the game with STEP Core or STEP Extended and play for a short time, then decide whether this set of mods is sufficient and whether there are problems with VRAM use, script use, etc.

There weren't a lot of changes in the recent UUFO3 patch update, but as Nozzer66 mentions whenever a large mod like this is updated redoing the bashed patch is a usually a good idea.

The modular versions of ETaC are used only when you don't want to use all of the locations that ETaC supports. For example, if you use the Immersive Citizens - AI Overhaul mod (included in STEP and SR:LE) then you should use the modular version and eliminate several of the locations that are known to cause problems with ICAIO. This needs to be done for the main part of the mod as well as the patches. If you want to merge the ETaC modular files there is a detailed set of instructions on the Forum section of the ETaC Nexus page. If you choose to use ETaC and merge these files, it is a little challenging but the instructions are quite detailed.

I've never seen the Visual C++ error in FO3. I've always tried to keep up on adding the most recent versions; I'm still running Windows 8.1. for a little while before I move to WIn 10. I'm not sure if any of the runtime extenders or perhaps utilities need the Visual C++ runtime tools. My approach to the FO3 museum area, as it was for several of the more challenging areas, is to sneak until I could target a SuperMutant with a long range sniper weapon and take a shot or perhaps two and then run away for a short time. Then repeat. After the first shot if I remain for any period of time they run toward me and ... I aimed using the cursor in first person and these weapons almost always have scopes; I generally find VATS to be fairly ineffective for long range shots. VATS shows fairly low probabilities on shots that I can often hit using the scope without VATS. I think FNV is a bit more stable. I don't remember as many challenging outdoor battles as FO3 has.

The easiest way to see whether a mod is or was in STEP is to use the advanced search button at the top right of the page, put the mod name in quotes in the search window, and search in titles only. Wearable Lanterns is not currently in STEP Extended; the mod thread for it is here. It was in the STEP list previously and removed at least in part because of problems with the mod. At the time it was removed the author Chesko had posted on Nexus that it would eventually be fixed but not until other projects were finished. It was updated fairly recently and presumably the old problems were fixed.

One area that will likely cause problems for you is the patches. Depending on the mod choices you use it might need be necessary to remove some of the records and associated masters from the STEP Extended patch and the SR Conflict Resolution patch using TES5Edit. I have a different set of mods that include STEP Extended and most of the SR:LE mods, and I needed to create a custom version of the SR Conflict Resolution patch. You might also need to be careful with your choices among script intensive mods; Skyrim has an internal limit on string count (as mentioned in the April 2016 State of STEP )

We have seen similar problems a while ago with some spells, so it might be a spell effect that isn't going away as GrantSP suggests. USLEEP has fixes for several of these. You might want to try a google search on spell effects not going away.

Which part of the DDSopt guide were you reading and using? There is discussion and guidance on the constraints menu, and other menus, including when to use different settings in the guide. The main portions of the DDSopt guide are a reference guide. Those sections provide detailed information on the possible values for the configuration options and what these affect. The Interface section provides screenshots on the menu settings including three different sets of recommended values for the constraints settings; the choice among these 3 depends on the types of textures being optimized. The Setup DDSopt section of the Quick Start guide (part of the DDSopt guide) does mention when each of the three constraints choices is appropriate. The default settings are in the "Constraints" screenshot. The only use I have seen for the DXTx constraint settings example are for some terrain textures in the vanilla Skyrim textures, as can be seen in line 21 of "Optimize the Vanilla Textures". The alternate constraints reduce the size of uncompressed normal maps by 50% with very little quality loss and decrease VRAM use. In rare cases this doesn't work well, and it isn't compatible with texture editing within the Creation Kit. STEP and SR:LE do have some mods with uncompressed normal maps, and these have become more common as mod authors provide versions with higher quality textures (which of course raises VRAM use). If there are specific questions let us know.

That small guide was written before the Merge Plugins utility was available. For many merges the new tool is sufficient since it can handle merging mods that add new FormID content. If several of the mods being merged add or modify navmeshes then an additional process may be needed. An excellent tutorial for this task is available in the forum section (specifically forum 5) on the Nexus page for the Expanded Towns and Cities mod.

That mod mentions using DDSopt and the Nexus page, but it doesn't mention how DDSopt is configured. The recommended DDSopt parameters in in the DDSopt guide are quite different than the original ones that came with the mod on Nexus. I'd be a lot more comfortable with the Nexus version of optimized textures if I knew it used the information and parameters from the STEP DDSopt guide.

I wonder why there aren't similar reports in FNV since the FNV guide uses similar body mods.

I'll look into it to see if it fits better.

You might want to look at the extensive Skyrim INI guide where these are discussed. Some of them don't seem to have any effect on the game (e.g., the iHWThreadx where x is a number between 1 and 6). If you have found that these do affect the game it would be very useful to know how and when they affect it.

The Point Lookout one adds a few items, much less than the one with the EVE bridge. A note can be added about removing it.

I don't see this container in the RH_Ironsights.esm from Paradox Ignition. Are you using the 'RH_Ironsights - EVE Bridge.esp" plugin? It does include a test container and the guide previously had instructions to remove it, but if one of the recommended Blackened patches that include RH_Ironsights and EVE is used this container isn't present.