enkephalin07

This is the configuration the 'saveini' command spits out when there is no Skyrim.ini, a launcher-generated SkyrimPrefs.ini, a completely clean install directory, and nothing enabled except Skyrim.esm and Update.esm. Note a few empty settings; I can't be sure whether the game engine uses them at all, uses them only if they're configured externally, or just ***** itself in surprise when they're set.

Those don't have to be in the default ini, every value has a default already in the engine or other data files. If you don't see them, they're there. If you want to see them, enter 'saveini' into the console and read the ini that appears in your Data/ dir; it'll be named after the last esp in your load order. As I said above, I have never set them. and wouldn't have known about them without reading the settings dumped. Without any results of experimentation, any advice would have limited credence. Is anyone familiar with these settings at all? EDIT: Alright, I tried setting these to the supposed "best", a configuration I've seen copied on several forums: uWaterMemoryInterior=20971520uTextureMemoryInterior=20971520uGeometryMemoryInterior=20971520uWaterMemory=10485760uTextureMemory=20971520uGeometryMemory=10485760Subjectively I think performance improved, smoother frames and fewer freezes, but nothing in SPM's objective output stood out. Then I tried setting them all to 0 to see whether the memory would be dynamically allocated (as it should have been in the first place!) or no memory would be allocated at all. The game launched fine, and I saw absolutely no difference in performance, subjectively or objectively. Skyrim is still hitting the page files when plenty of RAM is available, and ENB still isn't getting all the VRAM it should.

uWaterMemory=5242880uTextureMemory=20971520uGeometryMemory=5242880uWaterMemoryInterior=10485760uTextureMemoryInterior=104857600uGeometryMemoryInterior=10485760These appear in the Configurator's settings and the saveini dump. I haven't set them, so those are the defaults.

I don't know if I understand correctly what these values do. The amounts for geometry and texture memory seem far too low to make use of even the minimum system specs required for the game. Will increasing these put more into VRAM and less in page files? If ENB has disabled Skyrim's rendering, does it manage these values anyway?

I'm afraid this really isn't working anymore. I'm back to getting irregular CTD's, under-utilized memory resources and persistent disk activity causing constant freezes in cells that should already be loaded. Now I'm seeing textures that loaded fine before rendered as solid blue. How do I make Skyrim use the full RAM/VRAM available and quit over-taxing my HD? How do I end these CTD's? Edit: My mistake; the CTD and missing textures were from .bsa's getting deselected after updates. I'll open a different thread for the performance issue.

Are there any presets that don't require SweetFX? I'm reluctant to try that because of the clean-up if I decide not to keep it. SweetFX also doesn't work without turning off my card's AA, and imo it already does an excellent job at that; I've tried Sweet with other games and don't find it to be better.

It would still be better to launch SPM from MO. I keep MO open before, after and the entire time I'm running Skyrim, so I shouldn't need to shut it down to find a program I have less use for. It's better to have it accessible in MO's executable list than to dedicate shortcuts to it outside the context I'll actually want it. And it does work, just launch from MO and set SPM's launcher to SKSE (or just Skyrim.exe, if that's the kind of thing you want to do...) A drawback is that you have to specify one .ini, so it won't switch with you to another profile. A minor drawback for now, since the ini tools don't appear to be very developed.

Ah, that was it. I don't use Steam, so I don't even let their service start. Frrk, if the devs had documented anything, I would've found this ages ago. Where it usually hangs, I get this: 255 185260 185255 185271 185275 185275 186275 187291 187 Some pauses, but it continues. Thanks, DoubleYou.

Um, any source I've seen has states that memory patch 3.0 is deprecated since its function has been integrated into SKSE. As of 1.7.1, it's not even disabled by default anymore, it's configured in the ini in the installation zip. I haven't changed the memory settings: [Display]iTintTextureResolution=2048 [General]ClearInvalidRegistrations=1 [Memory]DefaultHeapInitialAllocMB=768ScrapHeapSizeMB=256 [Debug]WriteMinidumps=1I know TintTextureResolution works and WriteMinidumps works, so what between them isn't working?

I'm not using 3.0 (is anyone still using that?) I'm talking about the mem patch integrated into SKSE 1.7.1, using the preset ini. Memory Logs Block looks like it works with it, though. Before trying this, I set ENB's VRAM down to 2GB, my actual VRAM, set your ini's MaxOnly to false, and recorded until the game and SPM's stat display froze. If there was a timestamp on these, I'd be able to match it up with what I'm looking at in in SPM. Approximately at the freeze time, RAM had been >2GB for a few seconds, and VRAM spiked up to ~1.1GB. GPU also spiked, but not to its maximum. EDIT: Wtf, I tried setting Scrap Heap to 512 and got an identical result. If the first block is supposed to be Initial Alloc, it's not even close to the 768 it's set for. Now I know this ini is getting read, because SKSE didn't start generating minidumps until I added the line for it. So what sorcery must be done to get SKSE to perform to promise?

Performance monitoring shows that my CTDs, ILS and freezes occur when RAM usage spikes over 2GB and VRAM over 1G. The problem is that both are well within available resources. With SKSE's memory patch, TESV should be able to manage up to 4GB of memory. The ENB guide here recommends setting VideoMemorySize to VRAM+RAM-2GB, but I've left it to autodetect and it settles on 4GB -- put together, this is still less than available resources and far less than anything TESV has demanded. But does the guide take into account SKSE's memory patch? Does ENB take over memory management completely, do SKSE and ENB divide memory management, or do they conflict with each other? My system specs don't explain why this memory usage would be a burden to TESV, so there has to be a problem with the way memory is handled. Minidumps indicate TESV is trying to access memory beyond the stack limit, so there's some memory allocation errors going on.

As far as I can tell, increasing fUpdateBudgetMS and fExtraTaskletBudgetMS may have diminishing gains, but never hurts. 1.6 may be a little better than 1.2, 2.0 is slightly better than 1.6, 200.0 isn't any better or worse than 2.0. I've never seen it reduce framerates, possibly because it has a hardcoded cap too low to make a significant difference. Since I just got Performance Monitor running, I put it to the test. My budgets were at 800 because I set them to test earlier and hadn't noticed they were still there. So just to be absurd I increased them to 8000, launched, verified in the console they were indeed 8000, and played through ~1.3k data samples, and compared to an earlier. I had higher maximum RAM/VRAM usage in this, lower maximum CPU/GPU, but they were close in averages. But I was also doing different things in each test, the first was sneaking and fighting through dwemer/falmer ruins, the second was strolling and chatting through highly populated cities. This didn't get a record of FPS, but subjectively I couldn't say there was a difference. fPostLoadUpdateTimeMS adds seconds to your load times, but would you notice the seconds of difference? If you often enter to script initialization clusterfks, seems like it would be worth a few seconds wait, but I couldn't tell whether it ever prevents ILS.

Yes. That only happens every time Skyrim runs, unless something else has gone terribly wrong.

Thanks, that worked.

ENB Host, maybe? It wasn't running either of the times I caught this, but it's not unusual for it to hang around doing clean-up before closing.

I doubt this is an SKSE issue, but since it provides the minidump, maybe you can help me interpret it? Generally it's telling me there was an invalid pointer read at TESV+64fd6e due to exceeding stack limit. I don't know if I can add any more meaningful information than that. Is there anyone who could either have a look at the .dmp, or just tell me what to look for, or preferably, both. Using skse 1.7.1 so the mempatch is already enabled in the ini.

I don't know how to reproduce it, but I've twice seen ModOrganizer.exe listed as a process after closing. No disk activity, it just occupies RAM and an unjustifiable amount of CPU%. Opening MO again creates a second process that consumes RAM and CPU appropriate for the tasks it's performing. Killing either process tree does not affect the other.

The SPM install instructions recommends launching MO from it, but I can't quite get the pathname it recommends. [C]:Program Files (x86)Steamsteamappscommonskyrim[install path]ModOrganiser.exeCouldn't MO launch it instead, and if so, what would the path be? How much will running multiple chained launchers impact performance and stability?

Convention has come to accept LOOT's results as gospel; Mod Organizer always advises on installation order in accordance with it, and has now added a Sort button that, for one-click ease, immediately arranges plugins with no further user input, and absolutely no transparency in what it's doing. After LOOT gave me a few glaring mistakes, I started to educate myself by checking my plugins against the master list, and found so few of them listed. So far, LOOT has only helped as often as it hurt, but the majority of the time it only fixes what isn't broken, and arbitrarily returning an organization illegible to the human eye. As note above, transparency and accessibility are an issue with LOOT's structure. There's a restricted pool of contributors, and a barrier to qualifying to become one -- who wants to open a new account and install new software for one and only one purpose? Under the conditions, who would volunteer one or two recommendations, even when it regards their own mods? Who especially would jump through hoops when they don't have any foreseeable reason to contribute in the future?

I no longer see log files in overwrite, but I still get .dmp files from the same folder, so I guess MO ignores .log files now. It should also ignore .tri files. Race Menu will garbage-collect and re-write them on initialization, so it doesn't matter what you do with them, or whether they persist across different profiles. They aren't anything that requires a user warning.

Revised troubleshooting section: It's really not a good idea to advise someone to turn off their anti-virus. If anyone decides for themselves to do that, they have themselves to blame, and not this guide. And no matter how bold you frame the warning to turn it back on, when someone exits a game, the only thing on their mind will be the reason they shut it down. Who will read that bold print under the circumstances?

If Wyre Bash can display the Masters a game was saved with, it can't apply that list to current load order Why not? Who needs a backup when your last known stable save already contains a stable load order? I always wonder that after Wyre Bash chews up the plugin list I gave it and craps itself. Is this something Mod Organizer can do, or is it not as simple as I make it sound?

If there's a more detailed explanation than "8GB RAM + 2GB VRAM - 2GB = 8GB" then it probably belongs in the guide. I rarely see it TESV mem usage rise above 2GB, so it probably hasn't been needed and I shouldn't worry about it. But if this can use more memory, I'd like to try; I haven't put this system to a real stress test yet.

According to the runtime Profiler, I have 3745 available video memory, no matter what I configure in enblocal. If I set autodetect to true and vmem size to 0, it'll display 4096 for total video memory, which is playable and stable most of the time, but going by the suggested formula, I should have twice that. If I set it to 8192 or lowball it to 7168, profiler will display those for total memory, but available memory remains at 3745, and the game runs a little less stable. From watching the performance in task manager, I can see TESV is never taking above that limit. I tried adjusting the reserved memory size, I tried disabling driver memory manager, but ENB still isn't allocating the memory to Skyrim. Am I reading this wrong, or am I just not getting anything out of setting higher memory sizes? Is something restricting resource usage, and is there a workaround within or outside of ENB? EDIT: Oh, specs. I'm running Win 8.1, 64-bit, with 8GB Ram and 2GB VRAM, AMD-Radeon dual graphics, with Crossfire set to default for this app.