GalenZ

Please don't remove RoE just because you added OBIS. RoE alters lots of NPCs that OBIS doesn't, and has no scripts, so it's valuable even with OBIS installed.

Absolutely! Some other mods will also cause that problem occasionally, but GRA-TRBA is the biggest offender by far. The only way to solve the problem is to NOT include it in a Bashed patch. If you load it after the Bashed Patch, it's level lists will rule, which means that you won't get the duplicate stuff - and you also won't get stuff added to those lists by any other mod. Having looked at the mod internals in great depth, and played with it some, I strongly recommend that it be removed from the FLNV mod list. It simple does NOT play well with other mods.

@Jax765: The problem with Right to Bear Arms is that it totally messes up level lists, in ways that do not play well with other mods (basically, changing 'select one' lists into 'use all' ones, which messes up merging). I noted the problems on this forum some time ago, noted that it would need a lot of hand-editing to get to play well with others, and finally did that editing this past week. I actually had to edit the mod's esp, as a patch esp wouldn't prevent it's problems from going into a Bashed patch. Having now played with it a few days, I'm on the verge of taking it out again. While theoretically nice, in that I can find unique GRA weapons out in the world rather than having to buy them, in practice it's made my game less enjoyable. I keep getting all these little (admittedly cute) notes that point me directly to the locations that contain the unique weapons, and so far, they have been ridiculously easy to obtain - like, the ultimate Two-Step Goodbye ballistic fist in a very easy safe in a well-known and easily accessible place with only a single scorpion guarding it. To me, it feels like total cheating to have gotten it that easily - I might have just as well given it to myself via the console. @BurritoJustice: Re: AWOP. I have it in my game along with all the other FLNV mods, and like it a *lot*. The low-loot patches prevent it from being as much of a monty haul dungeon as it's been in previous playthroughs, the internals play well with other mods, and I have not noticed any bugs or instabilities related to it. Total win in my book, and definitely a 'must have' part of my load order.

The problem is definitely with the new Steam client, is affecting Skyrim too, and a workaround has been found. To quote from https://forum.step-project.com/topic/7224-something-is-preventing-skyrim-from-running/ : At this point I believe it's Steam. Why? Because Steam is the only thing that has had an update in last few days - very close to when my problem started. I've been using MO 1.2.18 since it came out (a month or so ago maybe???) and it's been working fine. On top of that, I found this MO's Nexus page, user "Dwailing" has a workaround that worked for me - full normal load order. It's all about timing though. The workaround: Shutdown Steam. Start Skyrim from MO. It will complain about Steam not running. Tell MO to start Steam. As soon as that happens, MO will give you another window that asks you to click "OK" when Steam is started. DON'T WAIT from for Steam to start, IMMEDIATELY click OK. Doing that has my normal full load working again. It's tricky because of the timing, but it does prove there's nothing wrong Skyrim, MO, the number of mods or the mods themselves. It's something in Steam. I just hope Steam gets this fixed soon!!!I can verify that this works for me, so long as I am *very* quick about hitting 'return' to activate the OK button. I have created a trouble ticket for this at Steam support, and I highly encourage anyone else who has the same problem to do so also. The more problem reports they see, the more likely they are to address the issue.

Never mind - found it myself! Steam/SteamApps/common/Fallout New Vegas Mods (right next to the main FNV game folder) for reference. I'd casually deleted it in a frenzy of disk cleaning, but fortunately it was still in my Recycle bin. Yay for small victories!

Somehow, WB lost my hand-added tags, so I have to re-create them. Where does WB store the set of tags I've added, so I can back them up and restore them to avoid this problem in the future?

I am having the exact same problem with Fallout New Vegas - it worked on Thursday morning, but on Thursday afternoon, the exact same setup failed to start. I have determined it has something to do with the number of mods/amount of data being loaded, as my vanilla profile works fine, as did a test profile with only 47 mods - but when I added even one mod more (didn't seem to matter which one), it hung before the splash screen. After a malware scan and a couple of reboots, my limit went up to 80, but I'm still far from the 128 mods I was running fine the other day. I have a post over on https://forum.step-project.com/topic/7169-mod-organizer-not-launching-properly/ outlining all my hair pulling and failed solutions. Suffice it to say, the problem does not seem to be mod/install related - it's something systemic and more fundamental. My suspicion is that it has something to do with the latest Steam Client update, which occurred on 2/18. Staying in Task Manager as I try to start the game, I see steamerrorreporter.exe triggering - but don't see any error message myself, so I don't know what the problem is.

The only BSA I have are the vanilla ones for all DLCs, and when I have MO manage them, they're checked, and when MO doesn't manage them, I can't check them. In any case, the problem has *nothing* to do with my FNV install - it's something systemic. Some virus scans and a couple of reboots later, the problem seems to have magically vanished - I'm adding in all my mods again, and starting the game just fine (so far, knock wood). And my computer somehow seems faster, too. There must have been some nasty process running in the background that I wasn't aware of or something, though my it would make FNV hang with 49 mods, but not with 48, is beyond me. I'm chalking this one up to gremlins, because I have no idea what the problem was, or why it seems to have suddenly gone away... EDIT 1218pm PST - I may have spoken too soon. Still hanging, just with way more mods activated. Still nowhere near the 128 or so that I used to hit easily, though.

I've been doing a lot of merging and tagging the past few weeks. My root documents are https://tesfans.org/guides/wrye%20bash/docs/Wrye%20Bash%20Advanced%20Readme.html and https://wryemusings.com/Wrye%20Bash.html. However, I've learned quite a few little subtlties that have never appeared in the documents, especially regarding level lists and inventories. 1. Do NOT use Delev/Relev tags often - and when you do, only use them on up-front overhaul mods like YUP, PN, FOOK, Jsawyer, etc, or mods that *only* patch lists defined in an esp, rather than in one of the game esms. These tags only affect level lists - but they affect both leveled items (LVLI loot lists) and leveled creature (LVLC) lists. Delev means that the tagged mod can *remove* things from a master's list - and even if other mods later put a removed entry back on the list, the removal will stand. Relev means that things like what level the object can be found out can be changed by the tagged mod; relatively few mods do this. Back when was younger and more ignorant, I tended to added delev/relev tags to any mod that I knew edited level lists. I have since determined that this is a VERY bad idea. If you absolutely need to alter a couple of master lists to remove some item, it's best to be very targeted about it. That is, create a tiny little esp that ONLY edits the very few lists you want to remove stuff from, and tag only that mod. If you only redefine level lists, then the mod can be merged into the bashed patch and not take up a precious mod slot, and you will ONLY delev/relev the very few lists you want to change. 2. Deflst tags drove me crazy for a while, as the documentation on them is very hard to find. It ONLY affects FormID lists, such as repair lists. And somewhat like Delev does, it basically allows you to remove entries from a master list - but by actually *redefining* the whole list, from scratch. This makes it nastier than Delev, as it also removes items added to the list by ANY mod before it in the load order, not just the mod's masters. This power means that it should be used VERY sparingly, again only in either upfront overhauls (YUP, PN, FOOK) or very targeted bashable patches that you place *very* early in the load order. 3. The Invent tag, which specify mods that update inventories, has some wierd little quirks when you have multiple mods all trying to change the same inventory. Specifically, you'd think the last mod tagged 'Invent' that changes an inventory would win - so that you could, say, create a final patch of 'My NPCs' and tag it so it it's inventories would rule. However, it doesn't work that way, because 'Invent' acts like a Delev tag on a mod's masters. For example, say PN adds a some great armor to a guy. Then some mod that has PN as a master (say, a merged patch), and an 'Invent' tag, does NOT list the PN armro is that inventory. The upshot is that no matter how may other mods with Invent tags try to add that armor back in, Bash will regard that armor as 'deleveled' from the invetory, and will NEVER add it back in in the final Bash patch. This drove me *crazy* for a while - why wasn't the last Invent-tagged mod winning? To avoid this problem, you need to be *very* careful when adding 'Invent' tags to any mod that has a non-vanilla master. The upshot is, you need to be very careful about grouping mods together in merges. I strongly suggest you try to make merges have as few masters as possible, preferably only the vanilla set. If you absolutely need to merge mods that have a non-vanilla masters, group them together if possible. And if you have a mod that has two esps - a base esp, and then a patch for (say) PN - do NOT just toss both those mods into some larger merge willy nilly! Doing so will mean that Invent tags will cause all sorts of messups in the final bash patch. If you absolutely need to merge a mod that depends on a non-vanilla master, try to put it in a 'final patch' mod that nothing else will ever overwrite. For example, I like taking all the (non-bashable) PN/FOOK patches for things like Tales from the Burning sands, and create one final PN-FOOK patch merge that will go pretty much at the end of the load order. 4. As a final hint, avoid merging any mod that BASH can merge itself (i.e. is 'bashable'). Bash can only merge 'patch' mods that don't define any new records, but that's a huge set. it also gives you an opportunity to create highly targeted 'patches' that don't define anything new themselves, but that provide the final definitions for things like weapons, armosr, ingestibles, etc - things where you may be integrating parts from different mods. I have a large set of patches like this, called things like 'My Weapons.esp', 'My Ingestibles.esp', etc, that provide the final definitions for those classes of items. And I try to keep all those patches limited to vanilla masters, or at least masters that you know you'll always have, like PN. If I need to patch an item defined in a non-vanilla master, I'll create a separate bashable patch for everything using that master - e.g. 'My PPA Patch', which contains all records affected by Powered Power Armor - so that if I decide to create a build without that master, I'll have no problem figuring out which records are affected, and can just disable one mod, rather than editing a half-dozen. Best wishes going merge-crazy - 1.8 looks *really* powerful. I hope this helps.

I am having this identical problem - and to make it worse, it *just* happened. On Thursday morning (19 feb), my game was working fine with tons of mods. When I came back that afternoon, it refused to even get to the opening splash screen. I have been ripping my hair out trying to see if somehow I screwed up something between the times, and have had a great time (hah!) cleaning up my various ini files, etc. But nothing has worked. Specifically, at this point, I can start the game using MO, using either NVSE or FNV4GB as my launch app, with up to about 48 mods installed, and all appears to work fine. But as soon as I install mod 49 - or sometimes 5O - it hangs before the splash screen, and I sometimes see a steam error reporting process pop up for a bit in task manager, when I go to kill the app. I take out the mod I just added - which one it is doesn't seem to matter much - and then the game starts again. Problems I have ruled out: I have no bsas loaded except the vanilla game ones. Launching with NVSE and FNV4GB produce the same behavior. Launching with or without d3d9 enabled produces the same behavior. Launching with out without New Vegas Ant-Crash is identical. Launching with or without NV Stutter Removed produces the same behavior. Which mod causes the freeze changes - it can be something as complex as ElectroCity or New Vegas Bountues 2, or a simple little esp that changes some records for Roberts textures. I have rebooted my machine. I have run memory diagnostics. I have re-installed Steam. I have re-installed MO. I have re-installed ENB. I have removed my FalloutNV exe and let Steam refresh download it again for me. It *seems* to be related to number of mods installed - around 48-50, but the count varies. If I have a lot of other apps running (like Chrome windows), then mod 48 can push me over the limit; close all those chrome windows, and I can get 49 or 50. And it *just* started for me yesterday. Before that, I was running 128 mods, no problem. I have deep suspicions that some automatic Windows or Steam upgrade is screwing me, because when FNV started not running, I couldn't get Chrome to start up, either - until I re-installed it. I have a fear that some hack invaded my system, and am about to do a major sweep and clean for trojans and such. So, this is an ongoing and very recent problem for me. I would appreciate hearing from anyone else who is experiencing similar problems, and would *love* to hear from anyone who's had the problem and fixed it. Thanks! -- Galen

Re: ENB/ENBoost - I'd like to echo Kittyvonvita1 in noting that following the FLNV guide did not result in me having ENBoost active in my game - I had to re-install it and leave the d3d9.dll in the main FNV folder to get the ENB overlay on game start. I'm pretty sure this is not idiosyncratic to me - when I run FNV4Gb.exe outside of MO (such that it puts the laa executable in the exes/ folder) then it only gets ENB if the d3d9.dll is also in the exes folder. But I believe the change to the FNV4GB command line, making the laaexe be ./FalloutMO, means that it doesn't even *look* in the exes/ folder for d3d9.dll anymore. This, to get ENBoost with the new setup, d3d9 must be left in the main FNV folder for it to be loaded at startup. Can someone else verify this? I would also like to suggest that a note be added to the FNV4GB setup instructions for NVidia Inspector users - specifically, the need to add 'FalloutMO.exe' to the list of valid executables on the Fallout New Vegas profile of Nvidia Inspector.

I do a LOT more merging than suggested in the FLNV Guide, and have discovered that I need a lot more reminders and discipline that just editing the Info tab of the merge. I also find that when I merge mods, they sometimes need cleaning before I can merge them, and I'm loathe to alter the distributed originals. Also, as my build evolves, I sometimes find myself changing my merge sets between playthroughs. So, for what it's worth, here's the merging discipline I've evolved over time, including use of the new Merge Plugins 1.8 script: 1. For each merged mod, I create a new 'xxx ESPs' mod that contains all the esps that I'm going to merge, where 'xxx' is a three or four letter acronym unlikel to appear in any mod name. For example, my merge of the New Vegas Uncut mods is 'NVUM', so my new mod folder is called 'NVUM ESPs'. I generally create this folder using a file manager, outside of MO. 2. For each mod that I'm going to add to the merge, I rename the mod in MO to start with my new acronym and a dash. i.e 'xxx - old mod name'. For example, 'New Vegas Uncut 1 - Rotface to Riches' becomes 'NVUM - New Vegas Uncut 1 - Rotface to Riches'. This is best done in MO. The upshot of this is that I can use MO's name filtering to easily find all mods in a merge. Also, all those mods are grouped together in a file manager. 3. For each source mod in the merge, *copy* the esps to be merged into the new 'xxx ESPs' mod, then move them into the 'optional' folder in the source mod. So, at the end of this step, my 'NVUM ESPs' mod would contain rotfacetoriches.esp, kochandbohr.esp, etc. By the end, you now have a situation where the original mod folders no longer contain the active esps to be merged, but the <xxx ESPs> mod does. This step needs to be done in a file manager, outside of MO. 4. If the mod to be merged contains a sound/voice folder, also copy the sound/ folder into the <xxx ESPs> folder. The new 1.8 merge script will correctly copy and rename the voice files during the merge. If you are still using the 1.75 merge script, see the addendum at the end of this post, for the other steps you will need to do to get voice files working. 5. Create a new profile in MO named 'Merge xxx', e.g. 'Merge NVUM'. You will be using this profile to do the actual merge. 5a. Switch to your new profile. 5b. In the left hand window, select all active mods, and use the context menu to 'Disable all visible mods'. 5c. Activate your new <xxx ESPs> mod. In the right hand Plugins pane, the only active mods should be the ones to be merged. 5d. It is very likely that the plugins pane will have little red icons saying that your esps to be merged are missing masters. Go back into the left pane, and re-enable the master mods they need. 5e. You should now have a very minimal set of active plugins in the right pane - the mods to be merged and thier masters. Rearrange their load order to your liking; generally, I do it by hand to keep them alphabetical, rather than invoking LOOT. In any case, keep all the mods to me merged together in the load order. 6. Bring up FNVEdit. 6a. Select all the mods to be merged and 'Check for Errors'. 6b. If there are any errors, fix them - and if you don't know how to fix them, then you shouldn't merge that mod. 6c. Filter for cleaning. 6d. Clean the mods to be merged - remove ITMs and fix UDRs. 6e. If you changed any mods, then exit FNVEdit and save them, the start over at step 6 again. Note that your changes will affect the ESPs in your <xxx ESPs> folder, and not the originals. Note that when you start over, you MUST 'check for errors' again; re-cleaning is not needed, but is safe, as it shouldn't change anything.6f. You should now have a set of cleaned mods with no errors.6g. Select the mods to be merged, and run the Merge Plugins script. Having used the 1.8 version for a few days now, I <highly> recommend it as a major improvement over 1.75, if only for the fact that it copies voice files correctly to the output, and plays well with MO. However, it also has other fixes that should reduce the likelihood of errors. Look at the mod documentation and comments for setup advice - it has a fairly major interface change from 1.75. I'm using 'renumber form IDs only when neccessary', 'do a second pass always', and 'use batch file to copy assets' options.6h. When it asks for the name of the new esp file, I like using the full version of my acronym (e.g. 'New Vegas Uncut - Merged') rather that the acronym itself. However, it totally doesn't matter what you name to output esp.6h. Once the merge script completes - including copying assets - close FNVedit.6i. When it asks to save changed files, do a 'Deselect all', then select *ONLY* the newly created merged output esp. 7. Your newly merged esp - and assets like sound and text files - should now be in your Overwrite folder. (and since the 1.8 merge script checks to make sure your overwrite folder is empty before it does the merge, the Overwrite folder should contain ONLY the files constituting your merge).7a. Create a new mod from your Overwrites folder, and name it 'xxx Merged yyyy-mm-dd', where xxx is your acronym, and yyy-mmm-dd is of course the date of the merge. E.g. 'NVUM Merged 2015-02-19'. 8. You now have three types of mods involved in your merge: assets to your merged mod, in mods with the prefix 'xxx -'. esps of your merged mod, in a mod with the prefix 'xxx ESPs' the actual merge itself, with renamed sound files, in a mod with the prefix 'xxx Merged'. 9. You are now done using the 'Merge XXX' profile in MO. Leave it intact, in case you want to change files and re-merge later. But switch back to your main MO profile. 10. In your main MO profile, activate the newly-created 'xxx Merged' mod, and move it to where you want it in your install order. You should now have all the 'xxx -' mods, and your new 'xxx Merged' mod activated. The 'xxx ESPs' mod should NOT be activated in your main MO profile; it is only activated in the build profile. 11. Run LOOT. 12. If you're using Wyre Flash to create a bashed patch (which I highly recommend), the bring up Wyre Flash, add any bash tags neccessary to your new merged mod, create the bashed patch, check in in FNVEdit, then rise and repeat until all looks good. 13. Ta-da! Your new merge is now done! You should never, ever touch its contents. Now, the whole reason I've gone through all these shenanigans is for when you want to REBUILD that merge, perhaps after adding or removing esps. The discipline for altering the contents of the merge is much like the above, bu with the following caveats: a. When you alter the contents of your 'xxx ESPs' folder, make sure you update your readme file to document the changes, and WHY. Remember, this file will be copied into the merged output mod. b. Always switch to the 'Build xxx' profile to do a build. All the esps for that merge will still be together and enabled in that profile, and it will be easily to slot things into the load order, without having to re-do it from scratch. c. Because each merge is in it's own timestamped mod, you can keep old merges around for older build profiles. For example, I may have a 'Working Build 02-01' profile that has has older merges activated, while my 'Working Build 02-18' profile has later ones. d. if you *really* want to get anal about the contents of older merges, then you can also copy the 'xxx ESPs' mods to their own timestamped versions before you change them. I don't bother, but YMMV. d. If, at some later point, you decide that mod xyz should be in a different merge, you can just add the new merge acronym to the front of its mod name, and repeat the process with a new merge, while still keeping compaibility with older merges. For example, I originally followed the FLNV merge order to the letter, and created merged like 'NVUM' to hold the half-dozen New Vegas Uncut mods. However, as my build grew and grew, I started hitting my mod limit - and wanted to combine those mods into a larger merge, that also contained things from Machienzo and Yuki, named 'GMM' (for Gameplay Mods Merged'). So, my New Vegas Uncut mods now have names of the form 'GMM - NVUM - New Vegas Uncut ....', which tells me they are in BOTH the NVUM and GMM merges. And I can still filter mods for 'GMM' or 'NVUM' names to find only those mods constituting that merge. Addendum: Note on merging voice files using the 1.75 script - The Merge Plugins Script V1.75 does NOT merge voice file correctly, even though it (sometimes) appears to create the correct folders. When using 1.75 to merge mods with voice files, add the following steps to the merge process: 4a. Once you have all your esps and Sound/ folders together in your <xxx ESPs> mod, create a new mod named 'XXX Voices'.4b. Copy the sound folder from 'XXX ESPs' to 'XXX Voices'. (Copy, not move - you still want to keep the originals together for when you move to the 1.8 script).4c. In the 'XXX Voices' mod, go into the 'Sound/voices' folder. You should see a bunch of folder with names of esps, such as 'awilderwasteland.esp' or 'SaveCass.esp'.4d. Create a new folder with the name that you're going to use for your final merged esp, such as 'New Vegas Uncut - Merged.esp'. It *must* have the '.esp' as part of its name, even though it's a folder.4e. Move the contents of all the other 'xyx.esp' folders into your new 'my merged name.esp' folder. This needs to be done outside of MO, using a file nameger. I personally use Q-Dir, which has four panes to make copying and such easy; it can be obtained from https://www.softwareok.com/?Freeware/Q-Dir, or Softpedia or MajorGeeks.4f. In your main profile, activate your new 'XXX Voices' mod, e.g. 'NVUM Voices'. It will now attach the voices from the source esps to the new merged esp. ---- I hope all this helps some other people avoid many of the numerous learning experiences that I've had over the past month or so, as I've tried to go way beyond FLNV, and shoehorn over 300 mods into the 130-odd mods that I'm allowed in my load order. The trick is incremental development - create a working build with a limited set of merges, and then try adding new mods to those merges for the *next* build. Thus, my need for all the persnickety discipline that I've outlined above. Good luck! Galen

I'm having problems getting iron sights to work with Enhanced Camera. Basically, the sights never line up in first person, always being low and to the right, though when I zoom out to 3rd, it *looks* like everything is lined up properly. I've reinstalled EC and WAR and the EC-specific WAR animations a couple of times. but no joy. This doesn't happen on *every* weapon; a few seem to work fine. Also, in one new game, I got a double pair of hands - a perfectly alighned iron sight (the standard 1st person animation), and a second set that held the weapon low and to the right. But after holstering the weapon and re-drawing it, I got the same mis-aligned sights that I was used to. Looking back in this forum, I see that that other people have apparently also had WAR/EC issues as well, but can't find detailed explanations of the problem or the solutions. Presuming that other people are getting iron sights to work with the standard FLNV setup, can anyone suggest what I'm doing wrong, and how to fix it? Thanks!

Re: conflicts between Trooper Overhaul and GRA - The Right to Bear Arms. No question, these two mods totally conflict, and there's no way of easily reconciling them - it would need a hand-crafted patch. The suggestion I made obviously totally overwrites the Trooper Overhaul, but it's still better than having a trooper carry *everything* from an Overhaul leveled list, which is what a default Bash patch will produce. I hadn't realized that TRTBA allowed me to get good stuff too easily; since that's the case, I think I'm just going to remove it from this playthrough. Regarding Christine, if someone really wants the WRP version without anything from WMX, then christinecos.esp either needs some extra Bash tags, or else be loaded after the Bash patch. And thanks for the quick reply!

Looking through a new FLNV build in FNVEdit, and I noticed a few small problems that you might want to address in the build page: 1. Interior Lighting Overhaul - numerous image and acoustic spaces are being overridden by mods like Lauren's Bathroom Poetry and Vault 22 Flora. Most easily fixed in WyreFlash by adding Cell.ImageSpace and Cell.Acoustic tags to Interior Lighting Overhaul - Core.esm. 2. In my LOOT order, mapmarkers.esp was loading last, and overriding climate data from Nevada Skies. I fixed this by telling LOOT to load Nevada Skies Ultimate DLC Edition.esp AFTER mapmarkers.esp. You could probably also just add a Cell.Climate tag to Nevada Skies in BASH. 3. Using the Weapon Retexture Project version of the unique Christine sniper rifle totally overrides the WMX modded version, but the bash patch tries to merge the two, not entirely successfully. Looking at the records, I think I prefer the WMX moddability to the WRP eye candy, so I removed the WRP Christine patch (christinecos.esp). If you want to keep the WRP version, you may want to look at the BASH merge of record 032110ba to see if it's okay. 4. There are numerous level list conflicts between GRA - The Right to Bear arms and everyone else, because GRA-TRTBA sometimes replaces whole lists with its own sublists and the set the 'UseAll' flag, while BASH goes back in, adds everything back that BRA removed, and includes the 'UseAll' flag (e.g. 0002e2a6 WastelanderApparel, 000609dc CondPrewarBusinesswearDirty, 00ccf86 LootAmmoNVBullets10, etc). This will totally screw all users of the list, who will suddenly get everything on the old list, plus entries from TRTBA. This can be mostly fixed by adding Bash tags Deflst, Delev, and Relev to GRA - The Right to Bear Arms, and telling LOOT to load TRTBA after everything else - in my run, after ADAM Complete.esp. There is still one bad bashed list - 00f1b11 CondNVTrooperHelmet , which adds stuff from TrooperOverhaul-Dragbody.esp - but it's a whole lot better than it was. However, I think the better solution is to tell LOOT to load GRA - The Right To Bear Arms.esp AFTER Bashed Patch,0.esp, so that it's level lists override everything. Note, however, that LOOT will only do this if the Bashed Patch does not refer to TRTBA; if the bashed patch already does so, the solution is to use MO to manually change the order, then rebuild the bashed patch, THEN edit LOOT metadata. That's all I have for the moment, though I'm sure I will find more issues soon enough. Many thanks for everyone contributing to FLNV; it's made my task of getting back into FNV a *lot* easier! -- Galen

Has any one played with Orvar's Tomb Remastered (https://www.nexusmods.com/skyrim/mods/57221), or considered adding it to REGS? It looks really good from its review by Brodual (https://www.youtube.com/watch?v=ZUvZFAuymsc&index=13&list=UUMQkYC9HUcPTertReHILVOA). And looking at it in TES5EDIT, against the rest of REGS, the only conflict I see is with a navmesh in falltreebranches.esp, which is of no significance whatsoever. I'm going to try to merge it into my new build, and I think it would make a good addition to REGS.

A note on using the Merge Plugins Script (v1.6, from https://www.nexusmods.com/skyrim/mods/37981) in FNVEdit: it seems to generate esps that Wrye Flash cannot merge. I used this script to merge a number of armor plugins, and all seemed well - no errors listed by FNVEdit, and looking at it, everything seemed OK. However, when I tried to use Wryre Flash to merge it's data into a Bashed Patch, it said there were errors in the merged patch, so it's changes were not incorporated. (This drove me batty, until I actually looked at the entire bash output - the error message wasn't visible until I scrolled down). However, when I loaded the merged patch into GECK, and then saved it immediately without making any changes, Wyre Flash was able to handle the Geck-updated version without error. So, the upshot is: 1. Always check the output of Wrye Flash to see if there were any errors. 2. If Wrye Flash has a problem with a patch you created using the Merge Plugins script, try running the esp through GECK to see if that clears up the problem. BTW, I want to thank EssArrBee and everyone else contributing to this forum, as it's really helped me get my old FNV game up and running again! Kudos to all! Galen

As a long-time modder who deeply appreciates all the work that you guys are doing with REGS (and STEP and SR:LE), I would like to weigh in with an opinion on the SkyHavenTempleEnhanced issues. While the concept of SHTE looks great, and I appreciate you guys including it in the latest build, I am deeply concerned about it's incompatibilities with STEP and EFF. While I'm sure that the STEP incompatibilities can be easily addressed with a patch, I'm not so sure about the EFF problem - and I would hate to see REGS mandate which follower mod I can or cannot use (especially when it conflicts with SR:LE). If this becomes a non-issue with the latest EFF build, than all is well and good, and I have no problems. But if the conflict remains, may I suggest that you consider 'splitting' the REGS loadout with an either/or option? That is, if one is willing to forgo EFF, then install SHTE and any required patches; else, direct the player to install the previous build's SkyHavenTempleMerchantsAndMore? This would allow people who want to use EFF to still have an improved temple listed in REGS, while making clear the cost if the player wants to install the full SHTE. May I also suggest that you also list other known incompatibilities in other REGS mods? Yes, I know a user should be able to look at the original mod listings to suss these out, but that's hard work that everyone needs to duplicate, so most people won't, and people will complain when problems arise. For example, it is not obvious that installing Aurora Village conflicts with both Oakwood (a place mod) and Anduniel (a very nice companion mod), but adding that message would be a big help to anyone installing REGS, especially if they're doing so after (say) already having Anduniel installed. I personally have no idea what other mods might conflict with what, but it would be really nice if the REGS install pages could act a one-source-stop for that kind of info, rather than making everyone have to look at the pages for every REGS mod they install. Just my two cents worth. Galen

Regarding REGS 3.0 and SR:LE compatibility: 'SkyHavenTempleEnhanced - Recruit More Blades' has conflicts with SR:LE. Specifically, its main page states that it totally doesn't work with EFF, while SR:LE installs EFF. However, it says it works fine with AFT and UFO, though looking at the mod notes, working with AFT requires some in-game tweaking once you start hiring new Blades. Also, SHTE conflicts with 'The Paarthurnax Dilemma' (which is installed by SR:LE), though this is apparently easily fixed by simply not installing The Paarthurnax Dilemma. May I suggest that these conflicts be noted in the REGS entry for SHTE? Also, I would like to install REGS with RRRE, but I also want to install Moonpath to Elsweyr, which edits the same inn. I was told a few weeks ago that there is just one object in RRRE that prevents Moonpath from working, and that it could be easily moved or disabled to allow compatibility. Could someone please tell me which object that is? And is there any chance that Moonpath could be added to REGS, and a 'official' REGS-RRRE-Moonpath patch be created?

Heh - I know all to well how nasty a TES5Edit wound can be... Hope you heal up soon and can go back out and kick some dragons again... Thanks for the suggestion re: RRRE + MPTE. However, not knowing exactly what the issue was, I decided the simplest solution was just to toss RRRE, as I really didn't need it's core functionality. Besides, I'm getting way close to the 255 mod limit, so any excuse to toss an untried mod is welcome. This is why I really appreciate the work that the STEP team is doing, as STEP gives me an excellent guide to what mods are worth playing, and which ones play well together, without me having to experiment too much. Kudos to you all! Now, it seems that all my mods are in order, so I think it's finally time to go walk into an Imperial ambush on the border of Skyrim...

Thanks! That's what I thought - and looking in TESVEdit suggested - but I figured it never hurts to check. May I suggest that you put that note in the install guide? Another minor note: The link from the REGS wiki page (https://wiki.step-project.com/Pack:Explorers_Guide) to the forums does not work (it points to https://forum.step-project.com/showthread.php?tid=4922, which 404's for me). Any chace this can be corrected, so people can more easily find this forum? Now, as soon as I get Realistic Room Rental Enhanced to play well with Moonpath to Elseweyr, I'll actually try to start *playing* the game, rather than modding it, as I've been doing for the past week... Galen

Glad to help! Another conflict note: Aurora Village is totally incompatible with the Anduniel companion mod, as Anduniel puts a meadery on the same site. As I would rather have Anduniel than Aurora (good companion mods are way rarer than new villages), my question is: how much of the REGS pack depends on Aurora? Any expected problems if I just take it out and put Anduniel in it's place? Galen

A note on load order and setting it with BUM: If you're playing with Interesting NPCs (3DNPC.esp), set the load order of the REGS patches to the bottom of 'Companions Load Early', rather than the bottom on 'City Overhauls' as specified in the REGS installation guide. In fact, I suggest that you might go so far as to put them at the bottom of 'Compatibility Patches', to make sure they load after other 3DNPC patches (RRRE and ETaC in my build), for safety. The reason for this is that the REGS navmeshes must load *after* those in 3DNPC.esp, but the 'City Overhauls' section loads way before it. If you look at the BOSS rules, you'll see that *lots* of mods are set up to load after 3DNPC.esp if it's loaded. To the makers of this mod, well done! I'm still in the process of creating a new Skyrim build (SR:LE + REGS + lots of other stuff), so I haven't played with it yet, but it looks excellent, and I deeply appreciate all the work that you did creating patches and navmeshes to get it all to work together. Galen

Admin: Â Please delete this thread - I can't seem to do it myself. Â I had a stupid bug that I fixed myself. Word to the wise: Â if you can't get GenerateFNISForUsers.exe to run, make sure you actually have the mod *activated* in MO... Â Duh! With head hung in shame, Galen