z929669

Also include the following to generate minidumps in your SKSE logs directory if/when you crash (see OP): [Debug] WriteMinidumps=1

I have tested the limits of the INI settings extensively. Environment is Windows 7 with MO used to start Skyrim via SKSE (uGrids = 11 with STEP:Core 2.2.8 and full Requiem build ... see my prev posts on this). All of this was running under Stable uGrids mod and ENBoost. The latter confirmed to consume about 1.65 GB of memory from the TESV process (I assume). In the background, I am running Process Hacker and VMMap to view/kill TESV.exe as necessary. This is only testing to determine the limits of execution of the hacked skse_steam_loader.dll. My savegame loads just outside the path to Solitude (I am looking towards the main Gate from the carriage-for-hire). For starters, MemBlocks 1 & 2 correspond to the highest two Privet Bytes allocated to TESV.exe process (as seen using VMMap by Sysinternals) ... HINT: sort by decreasing "Committed"On my box (link to my specs in sig below), MemBlock1 cannot exceed 2046 KB or the TESV process dies after a few seconds (while MemBlock2=256).On my box, MemBlock1 > 512 and On my box, MemBlock2 cannot exceed 256, or I CTD before getting to the main menu.Reverting MemBlocks 1 & 2 to 512 & 256, respectively restores functionality (on my box)Using the DEFAULT skse_steam_loader.dll, I get a ILS (infinite loading screen) after selecting "Continue" via the main menu (default MemBlock sizes confirmed to be 256 KB for BOTH)Using the hacked skse_steam_loader.dll at MemBlock sizes of 256 KB (mimicking the default), results in identical ILSFor this particular savegame under these particular conditions and on my particular box, I need to allocate MemBlock1=360 and MemBlock2=180 in order to load a functional session. I have done no extensive testing under these minimal conditions.I have tested 512/256 for approx. 90 minutes without any issue. I see no reason not to continue using these upper limits (as they relate TO MY BOX). It would be great if others that do not have my system specs (e.g., more/less RAM/VRAM) could confirm or deny my findings as generally applicable. The following image is a map to the numbers that are in play.

NEO, could you zip that thing up and post as an attachment? (TIA) ...the link does not work for me Thanks for setting configurable values that are a bit more user friendly (no offense to sheson). It is probably a good idea to instruct users as to those settings. Correct me if I am wrong, but MemBlock1 should not need to be set excessively, and it probably does not ever need to exceed 512 (and should probably be lower, and can be set to any factor of 4, right? .... e.g., 4*X). Explanations of MemBlock1 and MemBlock2 would probably be beneficial (where is Monty when we need him?). Here is my assessment of TESV.exe when running at uGrids=11 outside of my house in the Haafingar. I believe that this indicates that MemBlock1 dictates the cap for the first block addressed at DFEE0000 and MemBlock2 corresponds to the cap at address F81F0000. Is this correct?Is it also correct to assume that these could be set to something like 420 and 160, respectively?What are the ramifications of crossing these thresholds?What about raising them too high? EDIT: link working now

uGrids 11 perfectly stable for 90 minutes of play under STEP:Requiem build.

It was always there I think, but direct links to forums seems disabled, which is pretty inconvenient. I updated the OP with your OP from that forum. Feel free to create a new thread on our forums, and I will paste that OP source into your OP so that you can keep it updated here if you want. Either way works.

I will move it, but we do need mod testers.... ANYONE CAN DO THIS!

Read the thread! I am not sure why the forum link is not working. It seems that we need to navigate into the top-level forum and drill down. Seems stupid, but it may be to prevent bots from entering into the forum from direct links. OP updated to allow users to find the content of interest.

I agree with this statement.

I will crush my enemies, see them driven before me, and hear the lamentation of their women. Ahh, yes.Conan! What is good in life? .... To clush yo enemies, see dem dliven before you, and to hear da lamentation of de women! My absolute favorite quote from one of my absolute favorite movies. Now the charts (using the cart ride intro sequence for consistent compare): Baseline: STEP:Core 2.2.8 STEP:Core 2.2.8 with Safety Load and Stable uGrids STEP:Core 2.2.8 with ENBoost first, then with ENBoost + sheson's patched dll second (this has two runs in one, so note the x-axis for direct compare among the three figs). The scale is the same in all counts: About 300 seconds of measurement with the max horizontal at 3 GB and 100% for top and bottom charts, respectively. These are showing the effects only of ENBoost and not the patch. (Note the flip of memory allocation between VRAM and RAM when invoking ENBoost and increased GPU clocking). I had not previously been using ENBoost, so my observations could be with regard to that patch alone, and I cannot attest to the effects of sheson's patch methods with regard to skse_steam_loader.dll. Regardless, I will be running henceforth with both ENBoost and sheson's dll. It may be that true testing of these three scenarios should be done under various, more intensive conditions (e.g., max texture packs, high uGrids). I am running this on a 64-bit OS with Radeon 7970, 3 GB VRAM, 8 GB system RAM. My guess is that these fixes are ideal for people with at least this much VRAM and RAM, and a true bench will examine the allocation of resources to Skyrim in conjunction with the 'enbhost' process under very demanding conditions and/or testing against a savegame containing a dependable and reproduceable CTD/ILS condition.

OK, I played 3 hours last night on my STEP:Core (2.2.8 proposed) + Requiem build with all of the hard-core mods/patches recommended by azirok: Immersive armors/creatures/weapons SkyTest Civil War Overhaul Dragon Combat Overhaul Falskaar Wyrmstooth The works. uGids = 7 Not a single CTD/ILS, which is highly unusual with this build (I get one at least each 45 min of gameplay normally) ... and I spent most of my time in Morthal-Solitude area, which is pretty intensive. SPM output shows significant reduction on host RAM allocation to around 1 GB stable. This normally meets or exceeds VRAM allocation. I'll post a screen of the like comparison run/save I am using for benchmarks in a few.

If ... UsePatchSpeedhackWithoutGraphics=true ... will the FPS limiter still work, or do I need to daisy-chain my limiter dll?

ENB binary = d3d9.dll ... ? nm, I see it (enbhost.exe)

Yes, I know how to install ENB, but I don't want its effects, just the memory patch. ENBoost requires ENB install, no? I simply want to know what INI settings to switch in order to knock out ENB (but keep the memory patcher functionality)

ENBoost is recommended as a prerequisite. Is there any recommended way to get the ENBoost memory patch working without actually invoking ENB? (I do not run with ENB, as it introduces unwanted baggage in my testing ... I will run it again eventually, but I want to avoid its overhead for now).

Just creating this thread to log my findings for updating the INI. Race Menu: Confirmed that a custom overlay texture should not be optimized (the result is a broken texture and a purple body): ; Race Menu actors\character\overlays\default.dds=SKP

Nope, all is well and good. Thanks for softening it up though ;) Just a reminder to all that we making these mod choices here at STEP do not choose the "best" from among the viable alternatives. That is impossible, since we are not qualified to speak for others. We can only speak for our opinions about what is "best for STEP", and that has nothing to do with the overall quality difference of anything. As I said previously, we are just trying to mix and match among many mods to make the game more pleasurable for anyone that happens to agree with our approach. We simply have no desire to mix Mozart with Brahms or Van Gogh with Rembrandt ... or Frank Frazetta.

"STEP" is not saying anything about CaBal's textures. Individuals are. (like you and DoYouEvenModBro). I personally can't wait to try these and the others SRB brought up. We need Dragonborn textures badly. Is this total DB landscape coverage? (I can look myself ... someday) EDIT: ... and screens are fine for texture compares, as long as they are comparable screens using comparable settings (preferably same source) ... evan CaBaL's ;)

Letting this one bake along with Safety Load. Should not be needed by STEP, but may be helpful. We can decide by consensus later.

Let's let this one bake some more. It should not be needed for STEP:Core, but possibly for Extended. Maybe not at all. Same goes for Stable uGrids. Simplification seems best with so much contention around these mods.

This was a type. '0.01' was intended. Updated

Still working on it and not sure when I will have this info. Need to resolve CTD when entering Whirerun.

Yep. We want max compatible for STEP without mucking with conversions ( unless they are simple and complete). I'd like to see a female body vanilla hi- poly-count mesh improvement with smaller breasts. There is none though. Sent from my SPH-L720 using Tapatalk

This should not conflict with any other mod, since STEP does not have any female body replacers, so it should go alphabetically ("Better Female Natural Body") into section H. Clean skin textures should go after if using.

OK, we digress :P Yes, the mod page is a bit silly in so many ways, but boys will always be boys, especially when you go around shouting words like 'tiolet', and 'poop', ... and 'penis'. We never really grow up you know ;) So, other than pointing our users to a mod with some potentially offensive material (we in the US are shamed by sex and nudity, you know ... all part of good'ole-boy politics and religion), I think this mod stays true to vanilla and shortens the mod list a bit, so I am for it.