keithinhanoi

I'm sorry to say that I'm unable to report with details of numbers, but on my system (Win 7 x64, 32GB RAM, 1GB Radeon 5750 Mobile,) using an patched .dll (already compiled from XXX's original code, shared on a Reddit thread) set with the default 512/256MB blocks, I am able to waltz through every trouble area I have seen even in a fresh new game with my current mod line-up (200+ mods, 140 plugins). These trouble areas were previously 95% consistent in producing CTDs / freezes, and they're all gone now. Note that I am using the ENB wrapper with graphics post-processing off, and after one CTD on exiting an interior cell, found that turning on the Stable UGrids Loading SKSE plugin from Altimor made things work properly for me (not sure why that's true, though.) However, I have never touched my UGrids setting, so it's still at the default of 5. I reverted back to the original .dll and followed Sheson's instructions to investigate causes of CTDs, etc. in your game (I love the console toggleborders - type "tb" hint, btw). I confirmed my crashes were due to attempts to a new block allocation when block 1 is filled.. It seems so simple now in retrospect, but I am left shaking my head at just how much time I've wasted trying to chase down CTD's / freezes thinking they were due to specific mods. It turns out the combination of mods seems to have been simply shifting the same problem around to other places in the game where the 1st allocated block becomes filled. Although I've not had much time to do in-game testing, I've been able to do quite a bit of reading, which leads me to some questions for everyone reading here: 1. With all the reports of different file sizes and results from the same patch code added and compiled on different people's machines and with different versions of Visual C++ Express (particularly the suggested 2010 version vs 2013,) I wonder why this is true - and which version of VC++E is the "correct" or best one to use for compiling the patched .dll? 2. Having used VMMap to look at my TESV.exe's VM allocations, I don't see a direct menu option for presenting the usage for any particular allocated block (or child) in graph form (over time.) I expect since the program is fully scriptable, it should be possible to save a log of the trace for an particular block(s)/child(s), but I've got a knowledge/experience gap here - can anyone confirm that this is possible? 3. If the answer to #2 is "yes", then I expect the best way to discover the optimal block sizes is to start with the patches default 512/256MB allocations, and save a log of private memory usage for block 1 & 2 over some period of gameplay in memory "intensive" areas, and then search for the peak usage values and add to those (as Sheson & z929669 have explained) for your final block size settings. Can anyone confirm that this would be a good method for this? Also, what could we do in game that would guarantee to produce situations with peak memory block usage values? #4. I've read posts by Sheson (& elsewhere) that if the block allocation sizes are set too large and/or you have limited system ram (4-6GB) then it is possible that this will "squeeze" the memory available to allocate to other non-renderer processes in the game, including NPC's not completing actions, and probably more importantly, the papyrus VM bugging out and not working properly, so scripts will fail, etc. Can anyone confirm this to be true, and even better, explain why/how this happens? On #2 / #3, it would be of course lovely if the patch code could be extended to read the private bytes usage of the two blocks and present them on screen in game, as a direct way to help in determining the optimal values. I don't expect anything that advanced any time soon, so I'm hoping my ideas /questions above may help to make a good methods to determine those settings. Thanks so very much to Sheson, as well as z929669, Neo and everyone else that has done testing and reporting on it. I do hope I can find some time myself and report back as well (especially as I've got a uniquely large amount of system RAM!) Exciting year this is going to be.

@WilliamImm - that's great that those tags are in there now - it will save some potential hair-pulling for some users of WAF-R. @Neovalen - I noticed this STEP Forums post from Nearox asking about the STATS tag in WB. I don't know what version of WB he was using (I'm on 304.3), but he did get some info on the modified stats in his WB report after making a bashed patch. I don't get a list of modified stats for each mod like that in my bashed patch reports, it's just blank under the heading as I mentioned. I find it strange, as I've also got all the unofficial patches, WAF-R, and C&CF active in MO, and they're in the list of mods with STATS tags the bashed patch report. Even reducing the active set of mods to just those doesn't help any. When I look at the bashed patch in TES5Edit, I don't see any evidence of records with stats being pulled in. Do you have any ideas of examples of what I could look for? Honestly, I'm not sure why WB is messing up the stats thing, when everything else works fine. EDIT: Well, overnight, the BOSS Masterlist has been updated and now none of the Unofficial Skyrim patches have the STATS tag suggestion anymore. What's going on with that?

Hi all, I have updated my Guide to Installing RCRN AE with Mod Organizer. It now has some clearer explanations to some steps, and especially the reasons why a new MO profile should created. Also, I've added guides for how to use the RCRN Customizer in MO and finally, how to completely uninstall RCRN from MO and your system. Because the formatting is not as easy to create here in the STEP Forums, I would like to kindly refer everyone interested to read the guide in my original thread on the RCRN Community Support Forums where I will continue to maintain the most up-to-date version of the guide. Finally, I'll take this chance to reply to a few questions people have asked in this thread: @Bundy714: I'm sorry to say that in the end I found ENB Manager and Changer a less than intuitive solution to explain in a guide, and think it's better to refer to the RCRN website's support pages and forums to get information about using RCRN's injector along with and ENB, or just using an ENB alone. Anyhow, that portion of RCRN is installed outside Mod Organizer, so it's not within the scope of my guide, I think. I hope my earlier reply post to you has been helpful. As for the comparison between CoT+RLO and RCRN, it has now changed into comparing CoT+RLO and RCRN+ELFX for me, but I'm still working through some strange overly brightly-lit areas and conditions that I've seen while running CoT. I've also been doing a lot of troubleshooting of CTDs from the mod lineup I want to use for my next play-through, which has sucked up most of my time. Generally though, I really really like what I'm seeing with RCRN, but keep in mind that I am unable to enjoy CoT with ENB, and this means I don't get the full benefits of prod80's CoT Weathers Patch mod, for example. However, the RCRN team has said they will include compatibility with MannyGT's Supreme Storms and Supreme & Volumetric Fog (and of course RCRN already has that feature anyhow.) So that will help a lot, because they really add a lot to the non-sunny weathers of Skyrim. Long story short, I'm still not 100% sure I'm going to stick with RCRN for my play-through, but it's still well over a 50% chance I will right now. @GITech: As mentioned above, I have updated my guide with better explanations of what kinds of things can happen if you install RCRN with your current game's MO profile active. The implications of what the RCRN Customizer application can do are even scarier though. There's a potential for deletion of files in some of your other mods if they are active when you run the customizer. I don't see any dangers or problems with making a new clean profile in MO through. It takes up almost no space on your drive (just a few text files, really, and doesn't hurt anything about your current game. More of a pain to me would be having to move files out of the Overwrite directory if I had the habit of leaving things in there. But I don't - I move things into their own mods or back to their source mods (an especially good idea if you actually try to manage different games in different profiles.) I' suggest you hop over to the RCRN forum thread and take a look at the edited explanation in Step 13 of the guide (look in the spoiler text).

I think Safety Load needs to be used with great caution, in that the graphical menu (inventory, spells, etc.) glitches it seems to cause appear to lead to corrupted data in your save game. I've used it since version 1.0 extensively, and while using it saw graphical glitches in menus for the first time ever. I and a bunch of other people reported this in the comments thread, and then kapaer released a 1.1a test version to try to fix it. This seemed to help greatly, and so kapaer then released the 1.2 version which included that fix. However, I have continued to see menu glitches (very occasionally) and there are still reports from people in the comments thread of the same. What was scary to me was that in my testing, if I got graphical menu glitches while using SL, and then saved my game after closing whatever menu was open, that save game was prone to CTDs soon after loading it. I even tried quitting Skyrim and disabling SL completely before loading that save game. From that, I have to assume it had been corrupted in some way. Based on this, I'd highly recommend putting very clear warning/disclaimer text if SL will be listed in 2.2.8. In the meanwhile, I've stopped using it and will only consider it a "last resort" tool for ILS troubles (if I ever get any) until somebody manages to adjust the source code so the graphical menu glitches are no longer seen.

Ratsroot and Neo, I really appreciate the replies. Neo, thanks for sharing your knowledge on those last few questions. You know, I've looked through the "official" TES5Edit documentation, and it just doesn't explain it clearly. I also searched the Unofficial Patches comments thread, but didn't glean anything. Posted once to ask about it but was ignored. However, your four sentences make it crystal clear. It's strange though, because in TES5Edit with my entire plugin list loaded I remember seeing instances of some changed stats loaded later than WAF-R and CCF not being "reverted" in my Bashed Patch. I will have to go through the records again to double check. My asking that last question embarrassingly reveals that I have not (recently) read through SR:LE fully. Since I retired my last (somewhat borked) savegame, I've made my baseline STEP setup, took away things I (or my older videocard) didn't like, and have been trying to be a little more independent and accountable for my own choices of mods. That said, things like confirming whether WAF-R should have DELEV/RELEV tags added has proven to be very difficult. Kryptopyr doesn't mention it anywhere in the mod's description, and although in the Nexus comments thread one person suggested the tags should be added, there was no replies to confirm that. Also, unless I'm crazy or blind (which is possible, as I've started having to use reading glasses) I don't see a recommendation in the STEP 2.2.7 Guide to add the tags for WAF-R in WB. In your guide, though, there it is in bright bold orange letters, under the entry for in WAF-R. I really should have read through all of SR:LE to the end! :facepalm: ---- EDIT: I've just rebuilt my Bashed Patch after adding the DELEV/RELEV tags to WAF-R, and when I saw the (html) generated report at the end, saw in the Import Stats section that there's nothing listed under the Modified Stats subheading. This is the same as I've seen since the Unofficial Patches as of v2.0 started being tagged with STATS, but it just reminded me of this lack of information in the report (which is the reason I went looking for an explanation on the tag in the first place.) Neo - do you know if it's normal for WB not to include a detailed list of modified stats in bashed patch report? TIA again!

Hi, another SR Guide "graduate" here - I have Neo to thank for introducing me to MO and how to use TES5Edit, not to mention all the other must-have tools for properly modding the game. I'm currently doing testing to select a mod lineup for a new playthrough, and currently have a working set that's about 85% the same as SR:LE, and since in it's current state, it's got both WAF-R and CCF, I'd like to ask for a little help with understanding the multitude of overriden keyword subrecords I'm seeing in TES5Edit that those two mods make changes to. To make it easier to follow my questions are in boldface. I see that the all the new WAF_... and SPIKE... armor/weapon keywords are "injected" into the games' keyword list. However, the actual keyword lists for items seems to be handled differently, based on the fact that there are Keyword Count (KSIZ) subrecords for each armor/weapon. So my first question is: Q1. Is it true that the keywords used for each armor/weapon record are determined by the normal plugin load-order override mechanism? Then, I see that Kryptopyr, the author of WAF-R and CCF, states that she has made intentional changes some fixes to armor records make by the Unofficial Patches, and that WAF-R and CCF are designed to work with each other. So my next question is: Q2. If the answer to question 1 above is "yes," then (as long as I'm using the BOSS recommended load order) is it safe to assume all armor/weapon keyword list subrecord conflicts between WAF-R/CCF and USKP/UDBP/UDGP can be ignored? Finally, I notice that some keyword record/subrecord data is displayed in italics in TES5Edit. Q3. What does italicized text mean in TES5Edit? I also have two more questions, not about keywords, but related to WAF-R and CCF and compatibility through making a Bashed Patch. Q4. What does the STATS tag found in WAF-R and CCF (and the Unofficial Patches) tell WB to do when it makes the Bashed Patch? I have searched all over for an answer to this, but no luck so far. Then when looking at my Bashed Patch in TES5Edit, I notice that for the vast majority of WAF-R's Leveled Item records (with names starting LItem.../Sublist...) if there are records with the same reference name, but a different value for the level, the level value is pulled forward from Skyrim .esm, and not from WAF-R. This is because both the BOSS Masterlist and WB only recommend the STATS Bash tag for WAF-R (and I'm using the automatic tags feature of WB) Here's a screenshot example of what happens for LItemEnchWeaponSword (record XX04B586): This doesn't make sense to me, because it seems that the levels should be pulled from WAF-R. I want WAF-R's leveled list changes because that's one of it's features. So the question here is: Q5. Should I add DELEV/RELEV tags to WAF-R, and if not, why not? I apologize if this is not the right thread to ask those last two questions, but I figure that someone reading here may know about this or Neo himself has looked at these things before when evaluating whether to add WAF-R & CCF to the SR:LE guide. Again, I'd like to express many thanks to Neo for helping me to "enter the matrix" through the original SR guide.

Are you by chance using Safety Load? I ask because this is this SKSE .dll plugin is the only mod that I've seen with reports of graphical glitches in the menus - in fact I've seen them myself in my game when using an earlier version of the mod. If so, then you may want to do your stability tests without Safety Load, because it's best used as something of a last resort (or when you don't want to give up anything in your mods lineup, or can't, due to attachment to your current play through character.) SIC 6.5 was released a few days ago, and although I can't compare the MCM Menus to the previous 6.1.3 version (I've already upgraded), I see that in 6.5 there seems to be three menus with settings for non-Vanilla spawns: Additional Spawns, Night Spawns & Random Events. In all three of these menus, you can turn everything off. Presumably, in tandem with a bash patch, this would allow you to experience SIC's creatures without any additional placed, random or special spawns, and hopefully avoid having to make any changes to SIC's .esp plugins. I'm going to check if this is correct by asking lifestorock in the SIC comments page, and will report back here after he replies. However, as a final note, I want to say that I would not stop using the Random Cell Respawner feature. This feature actually does not add any additional spawns. It just adds an element of randomness to the length of time that needs to pass before the Skyrim engine does it's normal interior / exterior cell resets (which respawns any spawn points.) Normally the time is 10 in-game days to reset an unvisited exterior cell, and 30 days to reset an cleared interior cell. The Random Cell Respawner adds/subtracts a random amount of time for every reset, which makes things a little more unpredictable and interesting. I'm not sure if Nearox was referring to the Random Events feature or the Random Cell Respawner feature when he said "3) Disabling all additional spawns in MCM", but I have to assume he meant the Random Events feature.

@Bundy714: Just to avoid confusion here - the RCRN AE mod is a combination weathers / lighting changes in Skyrim (like CoT + some parts of RLO) and postprocessed video graphics effects using a d3d9.dll wapper (very similar to SweetFX.) The postprocessed graphics provided by RCRN are nothing like those offered by ENB. Since the postprocessed effects of RCRN is very similar to what SweetFX does, as a user of RealVisionENB you're probably not going to RCRN's postprocessed effects on their own. What you'll probably want to do is proxy "chain" RCRN's wrapper to be loaded along with ENB. As to what to do depends on which RealVisionENB option you're using. For example, Option A FULL is already set up to proxy load SweetFX's wrapper. So in this case you could try changing the proxy setting in enblocal.ini to load RCRN AE's wrapper instead of SweetFX (ie., by setting ProxyLibrary=RCRN_d3d9.dll). The problem is that the people who made RCRN AE "tuned" the postprocessor wrapper settings to work with the colorspace changes they make through the weather / lighting .esp plugins portion of the mod. So combining the RealVisionENB with the RCRN AE postprocessing may not look right color/contrast-wise without some tweaking. Anyhow the truth is that you don't really need to use ENB Manager and Changer to test RCRN versus RealVision. You can manually manage them by keeping backups of the two (or three) d3d9.dll files (ie., for ENB, SweetFX and RCRN AE) along with a copy of an enblocal.ini with the correct proxy load setting. Those are the only things that determine what gets loaded - all the other .fx, etc. files don't get used without them. So, if there's not d3d9.dll in your Skyrim folder, no ENB/SweetFX/RCRN gets loaded. Anyhow, if you do install RCRN AE, when it sees that you've got ENB, make sure to choose the "I'll set it up manually" option so that you've got their postprocessing wrapper named as RCRN_d3d9.dll, or otherwise it will change out the SweetFX proxy load (assuming you're using a RV-ENB FULL option) to load RCRN AE's postprocessing instead. I'm sorry to say, however, that since the best ENB I can use on my particular system is ENBoost (without postprocessing), I can't really do any in-game testing with any option of RealVisionENB and RCRN AE. In my case, I'm comparing RCRN AE to CoT+RLO with my own custom SweetFX settings.

@Aiyen: Although I agree with you that my guide does show just how much RCRN's installer wasn't meant to work with MO, having looked at how the install and subsequent customization settings are handled, I can understand why they have taken the route of an automated installer and customizer. I think aLaaa mentioned 60+ .esp plugins to cover all of the potential variations given the users settings preferences and installed DLCs. The only other way I can think of at the moment to handle this would possibly be through MCM menu settings, and scripts that check for the presence of either/both official DLCs. I imagine that could be far more complex than the installer/customizer combo they've come up with, and may not even be technically feasible to do in the first place. Add to this the requirements of SKSE and SkyUI. I suppose a FOMOD (or BAIN?) installer would also be possible, but you then lose the "ease of use" aspect of the customizer, or at least it would not be as slickly presented all in one executable. With RCRN as a FOMOD, you'd have to reinstall it again and again in most cases where you want to change the custom settings. Whether or not you agree with the method of installation, I honestly feel the RCRN team deserve respect for producing something so well organized that can offer all of the customization options it does, and still be as accessible to the largest number of people modding their Skyrim game as possible. Personally, I'm a user of Mod Organizer, with a set of mods derived from (but not strictly following) S.T.E.P., and yes, I'm a control freak about my Skyrim / Windows setup - and have to realize that I'm not part of the group that RCRN AE was "targeted" at. That's fine, I can deal with it, and know that MO is still powerful enough a tool to allow me to get RCRN working for me. It involves a lot of steps, but actually is a lot easier to deal with than working with some other external executable tools within MO. That said, certainly my variation of DoubleYou's guide is not meant for first time MO users! 'Doh! Why didn't I think of that for managing RCRN's shader, etc. files installed in the /skyrim directory?! What brilliant idea - a bit of a hack, but very useful to be able to "switch" off RCRN's shaders (which would still remain even if you "turned off" the /data assets part of the mod in Mod Organizer.) Thanks for mentioning that, and I'll do some more investigation into whether I can add that to my guide in an "Advanced Users" section at the bottom.

After some careful testing of the RCRN AE install process, I've expanded on DoubleYou's series of steps to install RCRN AE 2.1.4 and get it working with Mod Organizer. EDIT (16 Jan 2014): Because I have updated my RCRN in Mod Organizer Installation Guide, and the formatting is not as easy to create here in the STEP Forums, I would like to kindly refer everyone to my original thread in the RCRN Community Support Forums where I will maintain the most up-to-date version of the guide.

It's clear that the false esm concern is a non-issue for anyone using MO 1.0.0 rc1 or later, so that just leaves the question of MO's methods of managing BSA's and how it affects the bugs introduced by BSA asset files that may overwrite those from the the Unofficial Patches esp cum ESMs. Regardless of personalities, quickly drawn conclusions, finger-pointing and the like, the fact remains that the purpose of the UPs is to fix the base vanilla game and DLCs, and as such any mods which make changes to the same assets / records that the UPs fix would need to incorporate or "bring forward" those fixes in order for the user of the mod to gain their benefits - except in the cases where the mod changes those assets intentionally for different game behavior. So if you look at mods as bricks on a foundation - as Neovalen has described in his SR guide, the bottom layer are the vanilla files, and then immediately on top of that would be the UPs, and then all of a users mods, usually in the order suggested by BOSS. Since normally the UPs are loaded before any other mods, you're going to see the same problem with the dragon soul absorption script problem regardless of whether you're using MO or NMM or WB. However some mods which write these scripts as loose files already have the UP fixes incorporated and so the scripts don't need to be deleted. Like anything, it boils down to user awareness. MO doesn't create the dragon soul absorption script problem any more than NMM or WB does. The user creates it, and the information on how to fix it is available. Some mods which include these scripts even have the UP fixes incorporated (Dragon Soul Absorb More Glorious is one I've used without any bugs, for example). As far as MO's method of BSA management goes, I see it as much more flexible, because it gives you complete control over assets, whether they are in BSA or loose file form. It also shows you where there are conflicts (more than one mod with assets of then same name in the same directory location), and lets you sort out those conflicts how you like. If anyone has big problems with the idea of their BSAs being loaded in a different order than their accompanying ESPs, then they can just de-select all BSAs in the Archives tab of the right-hand pane, and they will get the default behavior (BSAs loaded in order of accompanying ESPs, then overwritten by loose files.) Personally, whenever changing the order of mods in the left pane and therefore the order any "managed" BSAs are loaded, I keep in mind that the BOSS sorting order recommendation may take BSA load order into account - or at least that BOSS ordering doesn't take any changes in BSA load order into account. So I change mod order with caution, and the main driving reason to change the order is to set which one will overwrite other mods' assets. This is particularly useful with mods that have replacements for vanilla textures, meshes or sounds (or even replacements for other mods!) And this is exactly where MO shines the most IMO, because it lets you do this without constantly uninstalling and reinstalling mods or managing loads of loose file backups in different directories.