Jump to content

Recommended Posts

Posted

Wait, are the default values of this set to an actual allocation of 512 or a VMMap 512? Also, what values would be changed for a VMMap 768/512 split? I'm assuming that you would just add these lines to the SKSE.ini:

 

[Memory]

defaultHeapInitialAllocMB=768

scrapHeapSizeMB=512

 

I just don't want to spread misinformation.

i guess you have to put this lines: 

[memory]

DefaultHeapInitialAllocMB=768

 

in skse.ini in order to have 512/256 in VMMAP, but i need to do some tests to be sure. In the code, skse authors have written:

SafeWrite32(0x00687E87 + 2, defaultHeapInitialAllocMB);

instead of:

SafeWrite32(0x00687E87 + 2, kVanilla_defaultHeapInitialAllocMB + defaultHeapInitialAllocMB);

, and the defaultHeapInitialAllocMB var is firstly initialized to kVanilla_defaultHeapInitialAllocMB var.

 

So before doing some more testing, i can not be sure of the best defaultHeapInitialAllocMB settings.

I think it's been empirically shown that sheson's default values work well for the average user and 768/512 (VMMap) works well for those with ugrids 9+. I'm just trying to figure out how to set these equivalents  with the SKSE implementation.
Posted

 

Wait, are the default values of this set to an actual allocation of 512 or a VMMap 512? Also, what values would be changed for a VMMap 768/512 split? I'm assuming that you would just add these lines to the SKSE.ini:

 

[Memory]

defaultHeapInitialAllocMB=768

scrapHeapSizeMB=512

 

I just don't want to spread misinformation.

i guess you have to put this lines: 

[Memory]

DefaultHeapInitialAllocMB=768

 

in skse.ini in order to have 512/256 in VMMAP, but i need to do some tests to be sure. In the code, skse authors have written:

SafeWrite32(0x00687E87 + 2, defaultHeapInitialAllocMB);

 

 

instead of:

SafeWrite32(0x00687E87 + 2, kVanilla_defaultHeapInitialAllocMB + defaultHeapInitialAllocMB);

 

 

, and the defaultHeapInitialAllocMB var is firstly initialized to kVanilla_defaultHeapInitialAllocMB var.

 

So before doing some more testing, i can not be sure of the best defaultHeapInitialAllocMB settings.

I think it's been empirically shown that sheson's default values work well for the average user and 768/512 (VMMap) works well for those with ugrids 9+. I'm just trying to figure out how to set these equivalents  with the SKSE implementation.
Ok, i see what you mean, so let's try this:

[Memory]

DefaultHeapInitialAllocMB=1024

scrapHeapSizeMB=512

 

What seems strange to me is this comment:

// in megabytes, -256 depending on bInitiallyLoadAllClips:Animation
Posted

I've tried out the new SKSE 1.7.0 alpha build.

 

Without any changes to skse.ini, both memory block 1 & 2 show as 256MB in VMMap and also using sheson's Memory Blocks Log plugin.

 

Then I added these lines to the skse.ini:

 

[Memory]

DefaultHeapInitialAllocMB=256

ScrapHeapSizeMB=256

 

Skyrim does NOT start, at all - a bit of a problem!

 

Looking at the source code, I can see right away that there is no trap to prevent users from setting both memory blocks too low.

 

By setting DefaultHeapInitialAllocMB to 256, that means I have set memory block 1 to zero as we would see it in VMMap.

 

As thalixte has pointed out, there are some clues in the source code as to why the default value set for block 1 in TESV.exe is 512MB, while we only see 256MB being used in VMMap:

 

// in megabytes, -256 depending on bInitiallyLoadAllClips:Animation

<snip>

_MESSAGE("default heap = %dMB (effective %dMB if not preloading animations)", defaultHeapInitialAllocMB, defaultHeapInitialAllocMB - 0x100);

This must mean all 512MB is allocated if animations are preloaded, but that must not normally happen. I've never seen this bInitiallyLoadAllClips setting - is that something that would be in skyrim.ini or skyrimprefs.ini?

 

 

Anyhow, continuing with my tests -

 

Since clearly the skse.ini setting needs to be 256MB higher than what you want to see in VMMap, the next .ini settings I tried were:

 

[Memory]

DefaultHeapInitialAllocMB=768

ScrapHeapSizeMB=256

 

In VMMap and in the Memory Blocks Log, I confirmed that the allocations appear as 512MB & 256MB.

 

To answer tony971's question, in my last test, I changed the .ini settings to:

 

[Memory]

defaultHeapInitialAllocMB=1024

scrapHeapSizeMB=512

 

In VMMap and the Memory Blocks Log, the block 1 & 2 allocations were 768MB & 512MB.

 

I hope that clears things up.

 

 

Some final thoughts -

 

1. I need to let the SKSE authors know as soon as possible about needing to prevent users from setting the two allocations under the vanilla defaults.

 

2. I don't see the third part of sheson's patch in the source code file I looked at, named Hooks_Memory.cpp. Maybe it's elsewhere - but I'm curious to know if they implemented that as well. Sheson has explained it as an important part of his original idea for the memory allocation fix, and it should probably still be left as part of the patch.

 

3. I really want to know what this bInitiallyLoadAllClips setting is, and the animation preloading that supposedly would take up the other 256MB of block 1 that we never see represented in VMMap. Is that something we want to be doing?

 

4. Before dropping in the new SKSE alpha build I had been doing tests with SSME in trying to figure out a problem with reproducible CTDs when loading some earlier savegames. When I removed SSME's .dll, and used the new SKSE build's memory patch - I was not able to reproduce any CTDs when loading any savegames whatsoever. This is an interesting development because absolutely nothing else was changed between the last CTD I got 20 minutes prior to my tests with the new SKSE build.

Posted

I've tried out the new SKSE 1.7.0 alpha build.

 

Without any changes to skse.ini, both memory block 1 & 2 show as 256MB in VMMap and also using sheson's Memory Blocks Log plugin...

 

... prior to my tests with the new SKSE build.

Many thks for this exhaustive report keithinhanoi (off-topic: very beautiful city, i've been there two years ago for a month).

I made some researches, and it seems that the bInitiallyLoadAllClips setting is part of the animation section in skyrim.ini, but don't know what it really means.

Posted

It's really fantastic that the SKSE team incorporates this fix. But I am a bit concerned that having to set DefaultHeapInitialAllocMB to 768 in order to get 512 in vmmap is going to confuse a lot of end-users. 

Posted

It would seem that the SKSE team has some more coding to do (and more explanatory comments within the code might be helpful :\ ), given the alpha release state, and I will test a beta when available (thanks to tony971, thalixte, and keithinhanoi for providing feedback on the alpha).

I think it's been empirically shown that sheson's default values work well for the average user and 768/512 (VMMap) works well for those with ugrids 9+. I'm just trying to figure out how to set these equivalents  with the SKSE implementation.

I think that it is pretty clear from my own exhaustive testing at uGrids 11 under [ STEP:Core + Requiem + kitchen sink ] that 768/512 (VMMap) is unnecessarily large an allocation. Nobody here (and to my knowledge, anywhere) has empirically shown that 768/512 is needed in any scenario. This is pure speculation and evidence would suggest otherwise.

 

I have been running now for 30+ hours using Neo's version of sheson's patch at 512/256 ... It may *feel good* to allocate more, but why unless empirical evidence lends to doing that?

 

Perhaps the SKSE teams version uses a different base value for DefaultHeapInitialAllocMB (MemBlock1) and has made other alterations/omissions (why without explanation and in a silo is completely beyond me ... an aloofness I have found in many developers), and 768/256 might be the new norm in terms of this version, but this is still 512/256 as mapped to sheson's version.

 

As I said previously, 420/200 is just enough for uGrids 11 on my box (450/200 would be maybe a little 'safer'). Even at uGrids 17, 470/210 was enough for a long trial run. These values might correspond to SKSE block sizes of around 730/210 max.

Posted
For those who do not use a steam version' date=' i found in the source code that you need to launch skse with the forcesteamloader parameter in order for the fix to work.[/quote']

What exactly is the parameter? Can't find it on google.

Posted
For those who do not use a steam version' date=' i found in the source code that you need to launch skse with the forcesteamloader parameter in order for the fix to work.[/quote']

What exactly is the parameter? Can't find it on google.

+1 for nearox's request. I don't want to use steam, it takes many recources.

Posted

Those having trouble with ENBoost should be certain to use the correct INI version for your GPU and VRAM capacity. As a test, abandon your standard ENB, and use only the barebones ENBoost with UsePatchSpeedhackWithoutGraphics=true.

 

Also, playing without Steam could be introducing unknown behavior, so try with Steam configured properly as another trial run.

 

Lastly, CTDs and ILSs will still be a problem if there are any mod issues or incompatibilities, so this is a likely possibility. Try using MO and set up a different modding profile with, say, STEP:Core as a base just to rule out this possibility (or even a vanilla setup would rule out mod problems).

 

 

Your issue lies elsewhere, no doubt. Again, set up a vanilla profile under MO and be certain to use a clean Skyrim install (see the STEP Guides on the wiki). Then follow SRB's link above.

 

A fellow user named Solmyr have pointed out OneTweak was the culprit. One needs to edit OneTweak.ini changing BWMode = 1 to BWMode = 2.

Posted

@Hellanios: Add -forcesteamloader to the shortcut to skse_loader.exe. If using MO, you have to put -forcesteamloader in the "arguments".

Posted
@Hellanios: Add -forcesteamloader to the shortcut to skse_loader.exe. If using MO' date=' you have to put -forcesteamloader in the "arguments".[/quote']

Yeah but how? Could you provide instructions?

Posted

Haha sorry, I thought it was pretty clear like that :P

 

In MO, open the menu to modify executables. Go to SKSE. In the empty field next to arguments, put -forcesteamloader. Click modify. Ola kala :)

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.