keithinhanoi

Yes, I use that as well, and it's a lovely complement to Interesting NPCs in my mind. Seeing a number like 3700 for the number of scripts doesn't scare me off, because they are not the kind of scripts that are constantly running. 1.3GB? Here in Vietnam that may take 8-12 hours to download. I've become patient, not spoiled as I remember I was before I moved away from the US. Anyhow, the .bsa is just 48MB, with a 17.4MB .esp plugin. The rest is loose files, so the incremental updates are not as "painful" as that first download. Suggestion: consider Interesting NPCs for a special "character-focused" play through, if you're into themes...

On this one I'm afraid I'd have to yield to the master's knowledge - you should ask Neo on the SR:LE thread.

Good to know, thanks.

Well, thank you for the wishes. Alas, it would mean a full replacement of my rig, since I'm a Mac guy for everything else besides gaming. I will admit though that I've toyed with the idea of putting together a custom-build win box, because my iMac has a special feature where an outside source can drive the iMac's lovely 27" display through a DisplayPort connection (only at 1440p resolution). Main problem with my plan: in Vietnam all tech is phenomenally expensive (at US suggested retail or higher!) Oh, and also my wife would kill me. EDIT: Kuldebar - thanks for the tip on that alternative choice; I'll keep it in mind if I land up running into troubles with IA7 as you did.

Are you using the 2048 res set that Octopuss linked to? If so, how's that working out in terms of RAM / VRAM use? I'm just wondering since you've got a 1GB card like myself (as you know already!)

No, Extra Late is just a special designation "spot" in the BOSS Masterlist, and you should be able to find it in the masterlist by typing "Extra Late" in the text field next to the Find Next button, and then click that button to find it. Then you could click the <<Copy button, but really that's the same as typing it into text field to the left of that button. A screenshot is probably easier here: If you don't have Extra Late in your masterlist, then something is not right - You should have the latest masterlist, which was "frozen" by the BOSS team on 25 Feb 2014.) Besides that, all I can think of is that maybe you've added an extra space by accident somewhere?

My bad - you are right (I knew I should try to check while getting ready for work!) I looked again, and the new v2.2 DG+DB plugin has 4 ITMs. Maybe I clicked in the wrong spot... However, all 4 ITMs are placed objects in Solstheim World cells, so it just wasn't cleaned after adding those new DB edits. Also, earlier I didn't mention that there are still a good number of placed object records in NSUtR that reverts USKP position changes back to the vanilla values. And also I see some of the edited object with the added snow are missing the view when distant (VWD) record flag. All in all, nothing game-breaking, to my knowledge, but yes, it's probably best to wait until the dust (or falling snow) has cleared, no more frequent changes, and then talk about what records need to be cleaned up.

Took a quick look in TES5Edit. With the naked NPCs I'd guess it's related to the bashed patch because IA (7 at least) sets up a lot of outfit records to pull from leveled lists instead of specific items. Not sure why Ulfric was not losing his gag, but I notice IA changes his outfit record to use a leveled list as well, here: [16] Hothtrooper44_ArmorCompilation.esp Outfit 00045C33 <UlfricOutfit>The change to leveled list item ultimate leads to a default clothing list which is the same as the original static list in the outfit record. How other clothes / armor gets assigned to him is beyond my scope of understanding, though. Anyhow, the Outfit record I listed above could be patched back to vanilla if it's the source of the problem. @redirishlord: I agree that there are certainly much better quality textures to be found outside of IA, but what IA brings me that I enjoy is a large injection of variety in a single mod. If I had better than a 1GB video card, and could handle higher res textures, I guess I'd have to reconsider things. For now, though, the increased variety makes up for not being able to increase quality.

Yes, Octopuss, a timely post. Kris has continued, tirelessly, to update, improve, and expand Interesting NPCs on weekly basis. Since I've just finished making a all-encompassing compatibility patch in TES5Edit, I can tell you there are all kinds of things that 3DNPC.esp edits. First, there are loads of cell record edits, mostly slight changes in the positions of objects, sometimes ones that USKP makes positional changes to (presumably for same or similar reasons - so it's a coin toss of which edit you'd want to keep.) However, this of course means the sub-block CELL location records have to come along for the ride, and despite 3DNPC not making changes to them, the vanilla values they contain may overwrite edits in earlier loaded mods. Still, if you're using any lighting / weather mods (RLO, ELFX, CoT, RCRN, etc.) they are generally loaded later, so the their sub-block CELL location records would "win" the overwrite contest. Then, in NPC records, there's changes to Luaffyn which will revert the USKP-added dead body script (or BOYD, if you use it.) No big deal, just patch forward - I think 3DNPC's change was mainly to make her essential, if I'm not mistaken. Finally, there are dialog topics, obviously, with all that talking going on, but those can be left alone, as far as I understand it. Really where things get tricky with Interesting NPCs is with all of the placements of those new characters. If they're placed in a spot where another mod sticks a house/building or some other large object, then, well, they may get stuck there. Any mods changing navmeshes may also break expected NPC actions. Generally, I have not seen any major issues in my game, but having read the comments thread, I know that Kris takes user reports pretty seriously, and will do his best to remedy things if they were caused solely by the mod. Regarding the earlier produced lower quality voice recordings - If I don't like any particular Interesting NPC character, then I'll exit the conversation, and not talk to them again. There are just so many characters that are very nicely done to make up for it. On top of that, I have found for me that there are a few spectacular characters which, on their own, are good enough to be a complete follower mod. I will admit that many of them are far more talkative that vanilla characters can be, but it's often a pleasant break from the brief and abrupt exchanges you often get elsewhere. Besides some of the better potential follower characters, my other favorites are ones who have been completely integrated with existing vanilla characters. So, yes, it's an enormous mod, not without some shortcomings, but it is absolutely near the top of my must-be-on-my-mod-list list.

Those sound like things that a patch in TES5Edit would resolve. My head is still spinning from the week and a half of building my global compatibility patch plugin, but when that wears off, I'll go back in and look at what I had do with IA7, since I also use CCO. Haven't yet had a chance to try Alternate Start, if you can believe it, though it's sitting, waiting and installed in my MO list, so I'll take a look there too. When I have a chance.

In his last update, v2.2, the Change Log shows that he's cleaned the plugins in TES5Edit. He's also added a new DG & DB version (the DB edits are new,) so I downloaded it to take a quick look and compare them this morning before heading off to work. I didn't catch any ITM records, but there are still some oddities, such as a couple of location names still in Italian, and I saw one record with an EDID of 'v' - I have to assume that was a mistake.EDIT: I forgot to mention the out-of-orders list of masters in the header of the new DG+DG plugin, which has already been mentioned in the NSUtR comments thread - though Prometheus seems to be aware of that, having mentioned some troubles with it. I also see that he's using custom names for all the edited meshes, so with regards to my earlier comment about incorporating compatibility between the SMIM farmhouse with ropes mesh and NSUtR, it will ahve to be option 2. In other words, the fix needs to be a mesh file that adds the snow piles from NSUtR to the SMIM mesh, but named such that it would replace the one provided by NSUtR. It being a loose file means that it would "overwrite" the one in NSUtR's .BSA, and in MO you'd just want to make sure that mesh file came somewhere after NSUtR in the mod priority order. Judging from everything I've seen so far, though, and despite what I've said, it seems this patch will have to come from a third party who has gotten expicit permission from both Prometheus and Brumbek. <opinion> @DoYouEvenModBro - with all due respect, I disagree. Regardless of an author's attitude, I believe it simply goes against all common courtesy in the modding "world" or "scene" to simply emulate somebody else's original idea because they won't / can't fix a few relatively minor things. Making requests, particularly for best compatibility with a baseline of a vanilla game (plus the unofficial patches, probably), is fair enough, but it's the author's mod, and their perogative to implement those things or not. So then it's up to us whether we accept that and use the mod, or not, and also to fix it ourselves to bring compatibility with our particular mod lineup. But, if somebody wants to share those compatibility fixes with everyone else (on Nexus or elsewhere,) then by common courtesy, and respecting each author's terms of usage, he/she really needs to contact and get permission from the authors of all involved mods. </opinion>

I will see how I can contribute to the wiki, but fully knowing that there is a process to how it is updated that requires a number of people to agree on any edits. Nevertheless, I'm getting very close to being ready to share the document explaining all the ENBoost memory performance features, which I'd like to call The Elder Boris Scrolls - ENBoost Demystified (tip of the hat to redirishlord / EProctor on that name). But before that happens, I just have a few more questions to ask on the mountaintop, if I can get away with it...

Why not ask the author of SMIM, Brumbek, to help out? He's already collaborated with other mod authors to produce custom meshes - for example, the new full 3D windmill sails in SkyFalls & SkyMills. Also, many authors have incorporated his meshes into their mods. Then there are two ways to make SMIM-enhanced meshes available: 1. A simple mesh replacement, as an option in the No Snow Under the Roof installer - which should be installed after SMIM (unless you use MO.) 2. A second .esp plugin option, by doing the following: Any new custom mesh(es) that combine Brumbeck's improvements with Prometheus' added snow would be given (a) different name(s), which are referenced in a No Snow Under the Roof (SMIM compatible) .esp plugin. This would allow for the fullest compatibility because the modified mesh(es) would not get used in vanilla Skyrim (or at least for those people not using NSUtR), and they also would not overwrite the vanilla or the vanilla-replacing SMIM meshes. Now, who is friends with Brumbek that could help make an introduction to discuss creating a few modified meshes?

Yes, and apparently it's now improved with "error check when enabled" - see his entry for 4 March 2014 on the ENB news page. I can also report back that he replied to my question to clarify what he means when he says "memory manager." He is referring to the main ENBoost feature that is enabled with speedhack=true & ReduceSystemMemoryUsage=true in enblocal.ini. (source post here) So, I can now put his previous comment about the usefulness of the ExpandSystemMemoryX64 setting in better context: ExpandSystemMemoryX64 is useful, but in practical terms it is much less useful than if you enable the main ENBoost memory manager (via speedhack=true & ReduceSystemMemoryUsage=true in enblocal.ini) with ExpandSystemMemoryX64 disabled. That said, a few people on the ENBForum thread for ENB for Skyrim v0.251 reported that they have fewer crashes with ExpandSystemMemoryX64 enabled, even though they have ReduceSystemMemoryUsage enabled as well. Interestingly, Boris has also explained the way that the DisableDriverMemoryManager setting works in further detail in the same post I mentioned above, and also in this follow-up post responding to my asking for clarification. Taken all together from his responses, he seems to saying that: Your installed video card driver and DirectX9 normally manage video memory resources, including: Moving object geometry and textures from system RAM to video RAM (VRAM)Deleting object geometry and textures from VRAM when it gets filledMonitoring usage of geometry and textures to reduce level of data transfer (presumably by keeping the most frequently used data)If DisableDriverMemoryManager is set to true in enblocal.ini, then Boris' driver adds a third method of video memory resource management that improves on older obsolete memory management functions. The video memory management provided by your videocard's driver and DirectX9 are still used for the portion of your VRAM set aside with the ReservedMemorySizeMb setting in enblocal.ini, in oder to maintain stability with other applications and processes that still access your VRAM while Skyrim is running. That's the best I can understand of his explanation, but it's not totally clear to me that Boris' method of video memory resource management is the only one used for Skyrim (outside of the VRAM set aside with the ReservedMemorySizeMb setting.) Maybe I will try asking...

Thanks CJ2311, Kelmych, & Neovalen - I've removed the entry for XCLN. Uuuh, pretty sure these need to be forwarded or merged depending on the case, BYOD would be a good example of this since it uses the same body cleanup script than the USKP, but changes the reference to the NPC's grave. Well, I should have put a better explanation. What I read was that for different scripts attached to the same actor, there is no conflict because they are combined and attached to that actor at runtime. However if two mods make changes to the same script, like with USKP and Bring Out Your Dead, then you need to forward each full set of VMAD data with whatever changes you want into your patch plugin. I just can't for the life of me find the source for that. I saw it quite a while ago, and just took down notes without the URL. Anyhow, I've put a more descriptive entry for VMAD, with the "not 100% confirmed" warning still there.

@MonoAccipiter: Thanks a bunch for that source from Arthmoor - I've added it, and put more detailed list of non-conflicting sub-record types under the LCTN Record heading. The other post on the TIFC sub-record type seems to contradict what ripple has said - I've added this, and will wait for someone else to help clarify on TIFC sub-records. @Nearox: Thanks - It's not a great post... but I hope it will be one someday. I have my own reasons for doing this, though, because I am working on my own global compatibility patch in TES5Edit, and want to make sure I haven't copied / merged edits into that patch that I shouldn't or don't need to. I will wait for CJ2311 to post here - or maybe I should pray that he does?

Over time, and by reading comments of mod authors, I have learned that for certain record types displayed in TES5Edit, when using the conflict filter feature, some records are incorrectly identified as conflicting (ie., "conflicting" = overridden by a plugin which comes later in the load order.) For example, ripple, the author of Inconsequential NPCs has explained that location persistent references (LCPR sub-records in LCTN / Location records) supplied by different plugins are not actually overwritten by the last mod in the load order LCTN for certain locations (source). The implication here is that all those references are combined and used from all mods with that record type when Skyrim is started. So in other words, when making a compatibility patch in TES5Edit, you do not need to copy overrides for those particular records. I have asked in a number of places which records types do not need to be carried forward into compatibility patches, but have never received a reply, and still to this day have not found a definitive list in one place. Well, I'd like to change that, and I need your help, if this is something you are knowledgeable about. Below is a list of record types, grouped by category, that I have read comments saying they are incorrectly identified as conflicting, because they are actually combined at runtime: A List of Non-Conflicting Record Types seen in TES5Edit [WIP] Default Object Manager (DOBJ)Record sub-record types: DNAM - Objects (Confirmed here) Dialogue Topic (DIAL) Record sub-record types: TFIC - Info Count (Confirmed - sources: here & here) Dialogue Information (INFO) Record sub-record types: PNAM - Previous Info (Confirmed here) Idle Animation (IDLE) Record sub-record types: ANAM - Related Idle Animations (Confirmed here) Location (LCTN) Record sub-record types: (Confirmed here) ACPR - Actor Cell Persistent Reference LCPR - Location Cell Persistent Reference RCUN - Reference Cell UNique ACSR - Actor Cell Static References LCSR - Location Cell Static Reference RCSR - Reference Cell Static Reference ACEC - Actor Cell Encounter Cell LCEC - Location Cell Encounter Cell RCEC - Reference Cell Encounter Cell ACID - Actor Cell Marker Reference LCID - Location Cell Marker Reference ACEP - Actor Cell Enable Point LCEP - Location Cell Enable Point NOTE: Other LCTN sub-record types require conflict management. (Confirmed - sources: here, here, here & here) Story Manager Quest Node (SMQN) Record sub-record types: (Confirmed - source: here & here) SNAM - Child sub-records QNAM - Quest Count / Quests These do follow rule of one now: https://github.com/TES5Edit/TES5Edit/issues/1016 Story Manager B??? Node (SMBN) Record sub-record types: SNAM - Child sub-records (Confirmed here) For more details about how the above listed sub-record types merge at runtime, please see this excellent opening thread post by Arthmoor from 12 March 2014. Many thanks to him for confirming / explaining all of these, and a tip of the hat to MonoAccipitor for noticing Arthmoor's post. I will update this list with additional confirmed non-conflicting record types based on your replies. Thanks in advance for your help, and let's hope others can benefit from this list!

Fair enough, um, Dr. Torminator. :D But I've never seen any real world examples of someone being instantly paralyzed with the body so stiff that it bounces around like a plastic statue. So, I guess I'm a "loose" paralysis kind of guy... ;)

Discussion thread: Ragdoll Paralysis by silverfish Wiki Link Dropped in v3.0. Ragdoll Paralysis is a mod I found back in November when looking for a mod fixing two things: 1. The completelty unreleastic stiff statue body effect when NPCs are paralyzed. 2. The floating weapons "bug" that happens when an NPC is killed by a paralyzing hit, as seen here. Well, I sincerely apologize for not telling others about this little gem earlier, because in my experience it addresses both of these things perfectly. I've been playing an archer character, and to make sure that the floating bug weapons don't happen on Bullseye perk paralyzing killshots, I needed to download and install the optional version (under "Miscellaneous") instead of the main download. This optional version applies the ragdoll effect to all instances of paralysis except for anything that freezes the NPC. Note that to accomplish the fixes, all paralyze affects call a new custom script by the mod author. The source is included, but I know so little about scripting that I can only say that it does not appear to be "script heavy" as it's only called when a paralysis effect occurs. To be honest, I am completely surprised this mod fix isn't part of the step core, but I'll leave that to the admins and the community to judge. Me, I'm just happy to finally be able to "give something" back to STEP (I hope!) Get testing now - I'm really hoping you have the same great results I did! Mod Testing This mod runs a script and has no known conflicts. To test this mod simply play with it active for a while making sure it is working as intended.

Boris never claimed there would be no issue with the ExpandSystemMemoryX64 feature. He made it for himself, and shared it because he thought it would be useful to others. But having read his posts on the feature, he made it pretty clear that he was sure it wouldn't work for everybody. Then with binary v0.246 he changed the default in enblocal.ini to disable it, apparently due to too many complaints from people. We don't know if some number of people complained by PM. He made it sound like people were ganging up on him, he didn't like it, and finally *bam*, a knee-jerk reaction. So now suddenly we're getting vocal pleas from a few people for whom (to their suprise) the feature seems to have made their game much more stable. But I don't understand the quick blame on jonwd7 for causing the situation other than the inability to read around. Posts by Boris on the sheson's memory patch fix thread show that he had done some tests and decided the SKSE alpha introduced some incompatibility with the feature. I think there's more to this than that one high-profile spat. With the recent spate of posts asking for Boris to put it back and piling blame on "that guy", my ironic side wonders if they've got Footprints in their mod lineup and have no idea "that guy" is the author.

Finally got in a beta test run a few weekends ago. Can't get past the bazillions of strangers that won't interact with me with names like bling-bling92 and such. "Social" my butt. Also the clothing / arrmor that looks like it's plastic wrapped on the body really bothers me. I never felt engaged, and with everyone else running and jumping around at high speed, it felt like a trainwreck between TES RP with Quake III Arena. I've got a "bring a friend" beta key for this weekend as well - first PM gets it.

Using symbolic links to individual mod follders in the /mod organizer/mods/ directory will allow you to put your mods anywhere you like. I've even tried linking to mod folders I copied to my NAS. No problem. But the slower the source, the slower things will be in loading, and could impact performance - at least having files on the NAS would definitely lead to slowdowns in game, anyhow. Although windows itself is (almost) a joy to use when running on an SSD, by putting MO and the mods on your HDD, it kind of defeats the main purpose of SSDs. They are much better suited to data which doesn't change all the time, in other words a source for files that you read a lot. And most games fit that description. But to answer the original question - there's no real "problem" in keeping MO and your mods on an HDD when your Windows system drive is on an SSD. Power user hint though - on my setup, I've got my mod downloads folder on my NAS - so I can keep backups of my downloads without eating up space on my SSDs.

Nope - ENBoost will work fine with the RCRN_d3d9.dll "proxy chained" in the enblocal.ini. I've got RCRN + ENBoost, and everything works fine. You'll know both are working because you'll see the ENB text in the Skyrim menu when you've just started the game, and pressing the pause key will toggle the RCRN post-processing shaders.

Well, it depends on what Boris means when he says "memory manager," which is why I asked him. Still waiting for the answer. Anyhow he's talking about one of two possible things, either: 1. The main ENBoost additional dynamic memory allocation, launching 1 instance of enbhost.exe for every extra 4GB needed to cache textures and object geometry. This is enabled with two settings in enblocal.ini: [PERFORMANCE]SpeedHack=true[MEMORY]ReduceSystemMemoryUsage=trueor 2. Enabling his own video memory manager using the setting: [MEMORY]DisableDriverMemoryManager=trueThe reason why the setting is named Disable... is because it disables the video memory manager that your videocard driver provides. For example, if using an AMD card, the Catalyst driver's memory manager is disabled with the above setting, and Boris' version takes over. According the Boris, the advantages of using his video memory manager is that it will ignore errors that would normally lead to CTDs when using your video driver's memory manager. However, this comes at the potential cost of decreased performance (lag / stuttering) or even long pauses in-game. Whether disabling your native video card driver's memory manager will work well for you highly depends on your make of GPU and what driver you have installed for it. There ya go - a sneak peak to my ENBoost (enbhost.ini) settings explanations that I'm working on. :happy:

Okay folks, I have dropped the motherlode on this ExpandSystemMemoryX64 situation. I asked Boris what he means when he says "memory manager", and I've tried to clarify for the record once and for all what ExpandSystemMemoryX64 actually does (or did, as the case may be.) I sincerely hope I am correct in my understanding of it. Holding my breath to see what happens...