keithinhanoi

Hey - I've already looked into doing this, and it turns out it's quite a bit more complicated than it seems. The problem is that the _sndlcquestscript has dependencies on other scripts from iNeeds and elsewhere. I opened up iNeed's .bsa archive using the BSA Browser utility, and extracted all of the mod's script source files. Even with those available, I still got errors when trying to compile a modified version of _sndlcquestscript in which I replaced "NerniesCityandVillageExpansion.esp" with "REGS - Resources.esm" in the the script's source text of its routine to add Nernie's food items for compatibility. So, I have decided to try something different. I've made a "fake" NerniesCityandVillageExpansion.esp plugin into which I copied all of the Nernie's food item records out of CJ's REGS - Resources.esm. So, iNeed's script will see the Nernie's plugin as being there, and find the food item records to add to it's list of things that can "stop" your hunger. Luckily, I'm not near the limit of plugins, but I suppose you could add those food item records to another patch and then rename it to "NerniesCityandVillageExpansion.esp" to employ the same trick. Perhaps a better way to retain compatibility here, CJ, is to break NerniesCityandVillageExpansion.esp plugin back out of the REGS - Resources master, or make an option for installing Nernie's merged or not. But I don't know how many people are actually using iNeeds. EDIT: Ninja'd by CJ - so now you have two suggestions on how to get iNeeds compatibility!

Unresolved reference errors very likely means that the relevant masters were not in the plugins' header. If they were there in the header, TES5Edit would automatically load them along with the patches that list those masters, and so you'd have the correct references to the FormIDs. Possibly related to this, I have noticed that there's a problem with bringing records with injected records into a patch plugin. The original source of those injected records won't be automatically added to the patch as a master, and this definitely will lead to problems if you are trying to merge that patch with other plugins. The correct source plugin for those injected records needs to be manually added to the patch plugin. I've seen this happen with patch plugins for WAF & other mods, and you can see the injected records references showing up in italicized text in TES5Edit. As soon as you add the correct plugin as a master in your patch plugin, then the text changes to normal (non-italic) text.

Region record data needs conflict management, and if you look at how sounds are added to regions by the DLC's you'll see that the entire vanilla list is repeated and then any new sounds are added. If a later plugin removes some sounds from the list, they won't be used in-game, so you'd need to re-combine them in a compatibility patch. I've also asked Arthmoor about WNAM records and Region Data, and he said they definitely follow the normal "last one loaded rules all" rule of load order. Interestingly, although I've had some arguments with the authors of one particular mod (who will remain unamed), Arthmoor also confirmed that scripts attached to NPCs or objects - including the "Prisoner" player character (ID 00000007) - using a VMAD record, also require conflict management. This is to say that if two mods attach scripts to your ("Prisoner") PC, even if the scripts are of different names, only the one from the later loading mod is used. And if the last-loading plugin which edits that NPC record has VMAD entries, then no scripts get attached. This is a bit annoying because I've found a number of mods that use scripts to assign FormIDs at run-time, and their VMAD data for some NPCs includes FormIDs with unresolved references, which means TES5Edit will refuse to copy override the data. By the way, the only way to be aware of unresolved references in a plugin is to either use the Check for Errors contextual menu feature, or to happen to notice them while looking at the record in question.

Since in the description of REGS you mention Solitude as being small for a capital, I'd like to suggest checking out Solitude - Capital Edition, by GrandDukeAdense (the author of Riften - Theif Edition.) Main downsides are it's still WIP, and will probably in the least conflict with Skyrim Sewers, as it also adds an explorable sewer system. I have to assume there's probably cross-over with some other mods now in REGS, but it's still very interesting nonetheless, and from the video and screenshots gives a much more crowded and densely packed city feel to Solitude.

As an English teacher I find marking the only answer to somebody's question as the "best" answer illogical as superlatives are to be used to identify one out of a group of 3 or more choices. "Resolved" or just "Solved" would be better. Anyhow, semantics aside, it seems a logical workaround would be to make sure the answer / solution is not given in the OP. For Wolverine's examples, simply copy paste the question from the Nexus comments thread into the OP and then give the solution in a reply.

Sometimes I feel like a vulture that has been circling in closer and closer for a while around a dying horse - but I can't beat a dead horse in this situation because it's not dead yet! Regarding the whole DXDiag report values on video memory - I turns out that my theory about how ENBoost determines VideoMemorySizeMb when AutodetectVideoMemorySize=true was wrong. What I should have been doing is enabling ENB graphics so I could take a look at the reported value for VideoMemorySizeMb in the ENB GUI. On my particular system, if I set AutodetectVideoMemorySize=true then the video memory size as shown in the ENB GUI is over 16GB! So it's clearly not based on the Windows video driver's definition of total video memory. Based on your experience though, I'd have to guess that when you set VideoMemorySizeMb to 1024, the major drops of FPS in cities was indicative of constant textures / geometry having being unloaded from VRAM, and new data being loaded and cached from your SSD to VRAM. In other words, there wasn't enough "video memory" (VRAM + RAM) available to handle the load - and this is probably related to the resolutions of your textures and fact that you've got a 1GB card. Then I have to wonder why it wouldn't help to increase your VideoMemorySizeMb above 4GB, since setting it above 1GB helped a lot, unless it's not actually getting used beyond a certain point. What happens when you set it above 4GB - any change in performance / stability?

A preview from my Elder Boris Scrolls document: ExpandSystemMemoryX64 true = this changes some memory allocation code in Skyrim (TESV.exe) to put some allocated data at the top of the Skyrim’s memory space, which, according to Boris, greatly reduces memory fragmentation and makes better use of all of the memory available. Although it was originally intended for 64-bit Windows users, it also seems to work for many people running 32-bit (x86) Windows, and for some people seems to reduce the frequency of CTDs. false = the memory allocation program code changes are not active NOTES: 1) This setting does not increase the amount of memory that Skyrim (TESV.exe) can use. On 32-bit systems, Skyrim can use 2GB of memory, and on 64-bit systems it can use 3.1GB of memory. ENBoost, however, can increase the memory that can be used for 3D object geometry and textures by enabling ReduceSystemMemoryUsage. 2) As of ENB Skyrim v0.246, the included enblocal.ini file had ExpandSystemMemoryX64 set to false. Boris changed it to false because of too many complaints from users who experienced crashes with it set to true. The reasons for crashes with ExpandSystemMemoryX64=true are still unclear, but Boris suspects there are issues with some anti-virus programs or other programs that inject processes into TESV.exe. Here's just some of the things Boris has said about it that led me to this explanation for ExpandSystemMemoryX64: Using the utility VMMap, I have with 100% certainty confirmed that setting ExpandSystemMemoryX64=true results in memory allocations at the top of Skyrim's addressable memory space - and of special note this includes the memory blocks affected by Sheson's memory patch fix. I don't have a complete explanation for ReservedMemorySizeMB yet, but basically my understanding is that this is used to set aside an amount of VRAM that will not be touched by Boris' memory static allocation routines, and instead be used for dynamic allocation, which means the moving of resources between RAM & VRAM (and also possibly between VRAM and the RAM used by enbhost.exe). However, the purpose of the setting has been brought up in the ENB Forum thread on the new 0.252 binary release, so I'm asking more about it. What is certain is that ReservedMemorySizeMB cannot be set higher than 1024 (1GB), and that Boris has recommended it be set to 512 if your video card only has 512MB of VRAM. He has also just this week stated that setting it to 512 is a good idea for 64-bit Windows users who have a relatively low amount of VRAM compared to the resolution of the textures you have installed, but if your running 32-bit Windows, then ReservedMemorySizeMB should be set smaller to avoid CTDs. As for VideoMemorySizeMb, it sets the amount of VRAM + RAM that is available for the ENBoost memory allocation. So, if it's set to be the same as your VRAM or lower, then presumably enbhost.exe won't be used, or not used much. If VideoMemorySizeMb is set higher than VRAM, then RAM will also be used (through instances of enbhost.exe) to cache textures and object geometry that's not currently being rendered. Although pulling cached data from RAM is obviously faster than getting it from your HDD or SSD, it's still slower than VRAM, and has to moved into VRAM to be used, so that's when you would get stuttering / lag. I think this is why Boris normally recommends setting VideoMemorySizeMb to be equal or a little under your actual amount of VRAM. Still, it's worth doing some testing to see what the net effect is of setting it at the same as or lower / higher than your VRAM.

Yes, all of your shadow settings are the same except iBlurDeferredShadowMask and fShadowDistance / fInteriorShadowDistance. Of all the settings, shadow map resolution and shadow distance definitely have the most impact on performance / FPS, but another factor here might be related to what ENB preset you're using and which specific effects that you have enabled. I settled on my shadow settings out of testing without any ENB graphics, and have only tried lowering the shadow map resolution values since I've started doing testing with different performance ENB sets. After reading what you've described, I'm going to have to try some test with the (exterior) shadow distance reduced to see how much of a difference it makes. Also, I thought I might mention some slightly OT notes about my really high fInteriorShadowDistance setting: Anyhow, I will do some more testing with the shadow distance setting when I have the chance, and report back here on my findings.

CJ / Nearox - since you've settled on BFT as part of the REGS pack, I'm wondering if that means it's not possible to use Touring Carriages if not using BFT. I know that wasite states FAtT IV causes problems for TC at the South Dragonbridge, but is there anything else that will screw things up. Since TC can supposedly be "safely" uninstalled, my plan is to disable Populated Lands Roads Paths while I experience all of the different dialog / monologue that TC brings, and then I may likely uninstall TC, and activate PLRP and BFT. Your updates seem to be getting more frequent now - I almost can't keep up with it!

I downloaded this about a week or a week and a half ago when it first showed up on Steam Workshop. Compared to CoT, this mod is much "lighter" - if that can be said about weather mods. This is because it only makes changes to some vanilla Image Spaces, Weather Region definitions, and Weathers, and no new weathers have been added. So compared to CoT, it should in theory be more compatible with other mods, but you'll still need patches for mods that affect any of the above record types, and it won't be compatible with any mods that change weathers (so CoT itself, RCRN, and the exterior / weather plugins of ELFX & RLO.) I'm sorry to say that because I'm doing other types of testing right now that I've not had a chance to run Pure Weathers through it's paces, but it's clear from looking at it in TES5Edit that there will be some noticeable differences in the colors, light, saturation, contrast, HDR / eye adaptation effects, some changes in bloom, and different varieties of weathers in regions, as compared to vanilla - but definitely not as much variety in weathers as CoT provides. I can't comment as to whether the weathers will look good with any ENBs - but I expect the ones design to work with CoT won't work so well with Pure Weathers. Also, I noticed there are 44 ITM records, the entire Worldspace record section of the mod - I don't see any reason why that would be intentional, but it's probably best to ask Laast.

Hmm, well I'll have to check into it then, because Interesting NPCs (and some other mods I use) add the PersistentReference QuestItem DisplaysInMainMenu record tag to quite a few existing vanilla objects / NPCs, so this could be for the purpose of scripted behavior of the added NPCs, I'm guessing. Best person to ask would be the author, Kris Takahashi. So I'll do that, because I'm worried that not forwarding that flag into my patches may "break" things a bit. As for rotated or relocated items, I notice that they're often things that are also moved in the Unofficial Patches, so in other words, intentional repositioning of objects, perhaps to make sure an NPC doesn't trip on / bump into it during scripted actions. But yeah, there's no real way to know why, and even more frustrating is knowing whether the mod or the unofficial patch's re-positioning should be brought forward into a compatibility patch plug in. I do see quite a lot of this with ELFX, for example, but in that case, the repositioning of lights is most definitely intentional (to get better shadowing / lighting effects, etc.), and as long as it isn't getting in the way of another mod's placed objects (or relocated buildings), I don't bring foward UxxP reposition to override ELFX's.

CJ, I'm really curious - when you mention wild edits in Interesting NPCs, are you referring to some object / NPC records in 3DPC.eps which set the Record Flag of PersistentReference QuestItem DisplaysInMainMenu? What is that flag used for? I'm wondering because I have up to now believed that I should be forwarding records to set that flag if a later mod gets rid of it in any particular records.

I asked about EDID records, and Arthmoor confirmed this, though he cautions against using coc or any console commands as a way to "play" the game. Interestingly, Arthmoor explained that the addition of or change to an EDID can be used as a way to avoid TES5Edit flagging any intentional ITM records for cleaning. Clearly a good technique to be aware of by any mod authors. Also, he said that EDID sub-records are useful for Papyrus auto-fill - another modding technique. However, coming back to the topic of my original post - from the standpoint of an end-user (player) trying to do conflict resolution by making a conflict patch plugin in TES5Edit, there's no real need to forward EDID sub-records into the patch plugin. So, I think EDID sub-records could be added to the list, but along with the caveats that Arthmoor has mentioned.

Another impressive update to the now formidable list of mods for this pack. My impression that things were slowing down was clearly mistaken. However, I'm with Kuldebar in that although Moon and Star looks pretty fantastic, I'm hesitant to install until I've seen a "period of stability" where no issues are reported for a week or two, and it seems the dust has cleared on the initial release. I'm nowhere ready to start my new play through - still trying to eek out enough performance so I can use some ENB features - so I'll see where things are when I'm ready to go. I do have a question for CJ & Nearox though - How many of these quest mods add new / notable dungeons? I ask because I am trying not to read too much in advance about these mods in order to avoid spoilers, but as an adventuring-type, I do love me a good bit of dungeon-diving. TIA

With UsePatchSpeedhackWithoutGraphics=true in enblocal.ini you should also see Boris' shadow fix, even if UseEffect=true and all individual effects are disabled in enbseries.ini. Not the Detailed Shadows effect, but the general improvement to Skyrim's "blocky" shadows. If performance is the goal, in my testing I've found that by making sure all shadow resolution settings are at 512 in skyrim.ini / skyrimpref.ini, I still see the enormous FPS / performance gain outdoors (exterior cells) that I would get with no ENB active, on my fairly underpowered GPU. However, ENB takes away (or hides?) enough of the blocky edges at 512 resolution that I can accept the tradeoff between shadow quality and performance. Here are my exact "performance friendly" shadow settings, for reference: In addition, I have not yet tried this test, but in my research on the enblocal.ini settings, I've found posts claiming that setting UseDefferedRendering=false can bring slight performance gains even if all individual effects are disabled in enbseries.ini. UseDefferedRendering toggles ENB's deferred shading rendering, which is required for a good number of ENB lighting effects, including ambient occlusion (SSAO), image based lighting, reflections, particle lighting and skylighting. If you're not using any of those, then it's perfectly safe to disable UseDefferedRendering - just be aware that you will see a red warning message in the main menu when you start Skyrim telling you that Deffered Rendering is disabled (similar to the ENBoost only message.) So, this is something else to try in any effort for a performance gain. Personally I would much prefer to use binary 0.251 due to all the ENBoost-related optimizations and fixes that Boris has incorporated since that feature was introduced. I am in progress with testing, so if anyone here is interested, I can report my performance-related findings when using binary 0.251 back here.

FLST - Form ID List has been removed, and I've asked for clarification on EDID sub-records, as I thought they're mainly useful for identifying things in CK, and not actually used by the game.

REGS - Cities in up in the Foundation section of the guide - so there's now three downloads that are only linked from the guide (as opposed to Nexus or the Steam Workshop.)

Awesomeness exemplified yet again. Just one thing I noticed - it seems that the userlist.txt text on dropbox still needs to be updated. I see the 3DNPC.eps override and the RWT rules are still listed there. I'm currently working on improving FPS (farewell SFO and Unique Grasses, sniff-sniff), so I can then settle on a "performance" ENB, and after a final conflict check in TES5Edit, I think I'll actually be ready to start my play through. Then I should be able to provide more detailed reports of any idiosyncrasies I may find.

What an awesome reply. Reading through Touring Carriages comments thread in more depth, it becomes clear that the collision area around the wagon is needed to "knock" NPC's out of the way, as the wheels of the carriage could otherwise kill them. The side effect is that if you have anything in the way of the normal vanilla navmesh road paths, you'll most certainly get a collision - as the author has mentioned in his comment thread sticky post. Nonetheless, I'm still going to try this supposed mesh fix just to see what happens. Wild guess here, but I'd imagine the IA7 issue has to do with some mesh provided with the mod having collision flags set.

I just finally had a chance to try touring carriages just last week and all the swinging back and forth and knocking NPCs down left me laughing so hard I couldn't breathe. My second ride did not go so well the second time when we smacked into a signpost, and the mod had to go into "recovery" mode. I've also had some very jumpy opening cart rides, so I'll be giving this a try soon & will report back here.

Ah, and you've just taught me a valuable lesson - thanks! Well, the mod's pretty simple, so I was able to identify two things there for the mods Cyrodiil Border Gate - the map marker and XMarkerHeading sub-records. I've added those to the list in my post above, but I download the separate border gate modules and compare to what I've got after deleting those records, when I have the chance. I don't use Close and Guarded Border Gates, so I'm not sure about that. Definitely Unique Border Gate's Cyrodiil border gate is placed right in the same block / sub-block (0, -1 and 0, -4) as Fight Against the Thalmor II - Cyrodiil Frontier's border gate. I only checked in TES5Edit, and didn't go check in game, though.

Actually, I just opened up the DnnUniqueBorderGates.esp plugin from the main download, and deleted the records for the Cyrodiil border part of the mod. So, that's the entire Worldspace record group for Block 0, -1 here: DnnUniqueBorderGates.esp Worldspace 0000003C <Tamriel> Block 0, -1 and in the Tamriel Worldspace, there the Cyrodiil Border Gate map marker and XMarkerHeading for that gate: DnnUniqueBorderGates.esp Worldspace 0000003C <Tamriel> 00000D74 Persistent 02002DFB DnnUniqueBorderGates.esp Worldspace 0000003C <Tamriel> 00000D74 Persistent 02002DFC and then there will be an unused NPC entry for LvlGuardImperialCyrodiilBorder, so you can delete that entire record group if you want: DnnUniqueBorderGates.esp Non-Player Character (Actor) After deleting those things, there should be zero conflicts with TheFrontier.esp from Fight Against the Thalmor II (and no conflicts with other the mods of the series for that matter.)

Well, in that case I'm going to merge the other 3 border checkpoint locations so I can drop it in along with REGS!

Interesting and seems nicely done from the pics - though I notice a comment about the need to use the optional separate modules if you're playing with Fight Against the Thalmor installed. Excuse my ignorance because I haven't read all of the FAtT descriptions (fear of spoilers) - does FAtT place a new Cyrodill border area?

I see. Well, just so you know, in some PM exchanges with the author of the similar mod I mentioned, IC-EDFL, he's re-working it to make some major improvements, and seems very open to the idea of optional versions that are compatible with other mods or different configurations of the added lights that switch on and off. Thanks for the explanation.