2019 Skyrim LE Stability Guide

[Zaflis]

13 hours ago, stingray1995 said:

Set your MipMap Skip to 1

I did some testing with this setting before, you really want to set mipmap skip to 0. There are a few mods that cause very bad texture artifacts with it, latest DD included.

 

In "mysterious breeding rooms", or new DD restraints:

 

Spoiler

 

[GenioMaestro]

5 hours ago, mrsrt said:

I had the thought, and this is why "ExpandSystemMemoryX64" I describe as an experimental option you should try first. But, logically, it shouldn't confilct, the mem patch works for the main process of the game, ExpandSystemMemoryX64 works with only enbhost process.

Again, that is totally false.

 

Please, read the documentation and learn what make each parameter before your imagination start working.

The SKSE Memory Patch works over TESV.exe and ExpandSystemMemoryX64 works over TESV.exe

 

ExpandSystemMemoryX64

https://wiki.step-project.com/Guide:ENBlocal_INI/Memory#ExpandSystemMemoryX64

When set to true, this parameter changes some of Skyrim's memory allocation code to cache data at the 'top' of Skyrim's memory space

 

ReduceSystemMemoryUsage

https://wiki.step-project.com/Guide:ENBlocal_INI/Memory#ReduceSystemMemoryUsage

This parameter will enable the ENBoost features to dramatically reduce CTDs and other issues caused from reaching Skyrim's memory limit.

 

You are mixing in your head what make ExpandSystemMemoryX64 and what make ReduceSystemMemoryUsage while each parameter make totally diferent separated things. The two parameters are totally independent and each one of them can be enabled or disabled because not have any relation.

https://forum.step-project.com/topic/710-enb-guide/page-24#entry109854

http://enbseries.enbdev.com/forum/viewtopic.php?f=2&t=4476&sid=f82358ebf34ce82e037a2d0180ce5b28&start=10#p63935

https://forum.step-project.com/topic/634-enbseries-by-boris-vorontsov/page-9#entry135635

https://forum.step-project.com/topic/634-enbseries-by-boris-vorontsov/page-9#entry135670

 

By pure logic, if "the mem patch works for the main process of the game==TESV.exe (AND) ExpandSystemMemoryX64 works with only enbhost.exe process" then is imposible the two parámeters collide, because diferent operations made over diferent executables NEVER can collide.  If STEP say that the two parameter are incompatible is because the two parámeters works over the main TESV.exe and you must not use the two at the same time. Probably, some of yours strange and unexplainable CTD are caused by the use of ExpandSystemMemoryX64 = true

[mrsrt]

7 hours ago, GenioMaestro said:

Please, read the documentation and learn what make each parameter before your imagination start working.

Okay, let's read together

7 hours ago, GenioMaestro said:

You are mixing in your head what make ExpandSystemMemoryX64 and what make ReduceSystemMemoryUsage while each parameter make totally diferent separated things. The two parameters are totally independent and each one of them can be enabled or disabled because not have any relation.

https://wiki.step-project.com/Guide:ENBlocal_INI/Memory

"Note:' for this parameter to work, ReduceSystemMemoryUsage must be set to true and EnableUnsafeMemoryHacks must be set to false (see below)."

 

7 hours ago, GenioMaestro said:

https://forum.step-project.com/topic/710-enb-guide/page-24#entry109854

http://enbseries.enbdev.com/forum/viewtopic.php?f=2&t=4476&sid=f82358ebf34ce82e037a2d0180ce5b28&start=10#p63935

https://forum.step-project.com/topic/634-enbseries-by-boris-vorontsov/page-9#entry135635

https://forum.step-project.com/topic/634-enbseries-by-boris-vorontsov/page-9#entry135670

None of your links contain that you want to say

 

You have better to change the tone. I'm not your friend, nor mate, I don't even know you. I update this thread to help others and do it well-intentioned. I can remove or abandon this thread, so more ctd related threads will appear where you'll boost your message counter. This is what you want?

[mrsrt]

51 minutes ago, stingray1995 said:

Enjoy your >60 frames forecast:  Cloudy, with a chance of flying mammoths, infinity tits and poltergeist clutter.  Oh yeah, probably fucked up NPC schedules and random crashes too.

I actually enjoy it, especially with g-sync. Yes, it's possible rarely to see juggling breasts if huge fps change happens within a second, but it completely depends on hardware and render complexity. For example, if you have absolutetly stable 120 fps you'll never see any problems. And no, it doesn't damage schedules and isn't causing ctds. I also never ever saw flying mammonths, lol. 

Also, I think the fps patch can be fixed to set the havoc variable every frame, not every second. Need some tests, maybe this problem can be solved completely. 

[GenioMaestro]

2 hours ago, mrsrt said:

https://wiki.step-project.com/Guide:ENBlocal_INI/Memory

"Note:' for this parameter to work, ReduceSystemMemoryUsage must be set to true and EnableUnsafeMemoryHacks must be set to false (see below)."

Try locate another web page or user that say the same because i think that is one of the errors of the step guide.

 

What do you think that make ExpandSystemMemoryX64?

Maybe you think that really allow skyrim use memory outside the 3.1 gb space?

Or maybe is the enbhost.exe the process that can use more than 4 gb?

 

Simply, because the parameter have "X64" not mean allow access memory in the "X64" memory space.

Skyrim is a 32 bits executable, enbhost is a 32 bits executable and the d3d9.dll is a 32 bits dll.

None of them can alocate memory outside their 4 gb of memory space.

 

Read the links that i post, please:

http://enbseries.enbdev.com/forum/viewtopic.php?f=2&t=4476&sid=f82358ebf34ce82e037a2d0180ce5b28&start=10#p63935

Second level is 4gb native limit of 32 bit applications and it's the case of ExpandSystemMemoryX64 or 4gb LAA patches.

The creator of ENB relate very clear the use of ExpandSystemMemoryX64 to 4gb LAA, then inside the 32 bits.

 

ExpandSystemMemoryX64 primary goal is to fix memory fragmentation issues which is very problematic thing in almost all games, fragmented memory reduce amount of really available free memory.

The objective of ExpandSystemMemoryX64 not is "alocate memory in the x64 zone".

 

Another very interesting post from Voris: 

https://enbdev.com/enbseries/forum/viewtopic.php?p=48345&sid=193fdf52a7f67531567e5add0ef7016e#p48345

Well, ExpandSystemMemoryX64 is good only for certain things and when memory manager enabled, it almost useless. For me it's very important feature for stability, even with 2gb x86 winxp.

Voris, the creator of ENB, say very clear that when  SKSE memory manager  is enabled, it almost useless

Because the SKSE Memory Patch make exactly the same for reduce the memory fragmentation.

 

Read a bit more, please: https://forum.step-project.com/topic/710-enb-guide/page-24#entry109854

In retrospect, this make complete sense, because based on the source code of the ExpandSystemMemoryX64 feature that Boris posted on the ENB forums, it uses a system memory allocation function call (MEM_TOP_DOWN) to change the allocation of memory from the "bottom" of the memory space of a program to the "top" of its memory space. The MEM_TOP_DOWN call is intended to be used for testing when converting a 32-bit application to 64-bit.

 

I did quite a bit of research about MEM_TOP_DOWN, and although my findings were inconclusive, I never found any evidence to fully support the idea that it would allow memory to be used more efficiently. For an enlightening and interesting article on MEM_TOP_DOWN, you can check out this blog post by Bruce Dawnson, a programmer at Google (who used to work for Valve). Scroll down to the bottom of the page, and you will see my questions to him that I asked back in March last year.

 

 

The only thing that make ENB when enable ExpandSystemMemoryX64 is replace a normal Malloc by a VitualAlloc with flag MEM_TOP_DOWN for make the allocation of the Memory Blocks in the upper zone of the 3.1 gb of the available memory inside TESV.exe, for make that not need ReduceSystemMemoryUssage=true, but maybe require it for have more free memory and be sure the memory can be allocated whitout error. Probably, Voris not implement a fail safe function.

 

Put the parameter ExpandSystemMemoryX64=true is stricly obligatory if you not use SSME or SKSE memory patch because reduce the fragentation of the memory inside the game and increase the stablity.

But, as Voris said, is totally unnecesary when you use SSME or SKSE memory patch because SSME and SKSE memory patch make exactly the same, allocate the memory blocks in the upper side.

 

If your game make CTD when you put ExpandSystemMemoryX64=FALSE, as Voris and all the guides recomend, seach the cause in other side, because that parameter make NOTHING.

If you want verify my words, make specific test with your game ussing VMap, as i made.

 

I recomend you install Memory Block Log and look the data. If you are near the 512 mb limit of the Memory Blocks, maybe, in some moments, you game can exced the limit and make CTD.

[Grey Cloud]

@stingray1995 you really are an immature pillock aren't you. You cannot refute anything GM has written or even come up with any quotes from a respected source, all you can do is post some naff video as if this confirms your position of superiority.

GM is Spanish yet he put in the time and effort to write that in English which is more than you managed.

[Grey Cloud]

18 minutes ago, stingray1995 said:

Que?

I rest my case.

[Zathuul]

4 hours ago, mrsrt said:

I actually enjoy it, especially with g-sync. Yes, it's possible rarely to see juggling breasts if huge fps change happens within a second, but it completely depends on hardware and render complexity. For example, if you have absolutetly stable 120 fps you'll never see any problems. And no, it doesn't damage schedules and isn't causing ctds. I also never ever saw flying mammonths, lol. 

Also, I think the fps patch can be fixed to set the havoc variable every frame, not every second. Need some tests, maybe this problem can be solved completely. 

Yeah, I wish I had g-sync but I gotta stick with 60 fps since I don't have the best pc at the moment. Thank you for posting this info though, your post helped me a lot when I was stuck. I even used the other website for info about ini settings along side this. Truly, thank you so much.

[mrsrt]

51 minutes ago, GenioMaestro said:

Try locate another web page or user that say the same because i think that is one of the errors of the step guide.

There's lack of info about the variable (literally, only these links you provided here), however the page I left is the first row from google and it was like this for years, based on it I made the conclusion. 

I tried to watch into the enb's dll, but, unfortunatelly, it's obfuscated, only the dll main unprotected. And as Boris didn't provide any docs for his product, we can only test and guess.

34 minutes ago, GenioMaestro said:

What do you think that make ExpandSystemMemoryX64?

Maybe you think that really allow skyrim use memory outside the 3.1 gb space?

Or maybe is the enbhost.exe the process that can use more than 4 gb?

 

Simply, because the parameter have "X64" not mean allow access memory in the "X64" memory space.

Skyrim is a 32 bits executable, enbhost is a 32 bits executable and the d3d9.dll is a 32 bits dll.

None of them can alocate memory outside their 4 gb of memory space.

Ofcourse, it is not magically casting the skyrim process to x64 base. However, the ReduceSystemMemory option creates another processes to allocate graphic stuff inside and in result Skyrim's process tree can go over the limit, this is what I mean under "expanding". The main process ofc never can go over 4G, but in result of this enb's work it can allocate much more, then why shouldn't it be called as "expanding"?

 

1 hour ago, GenioMaestro said:

Read the links that i post, please:

http://enbseries.enbdev.com/forum/viewtopic.php?f=2&t=4476&sid=f82358ebf34ce82e037a2d0180ce5b28&start=10#p63935

Second level is 4gb native limit of 32 bit applications and it's the case of ExpandSystemMemoryX64 or 4gb LAA patches.

The creator of ENB relate very clear the use of ExpandSystemMemoryX64 to 4gb LAA, then inside the 32 bits.

Yes, he speaks here about address mismatching if the "defragmentation" works. A mod can ask for a value in some cell, but the variable can be allocated in another cell because of the memory usage optimization. Excatly this behaviour leads to CTDs when access to a wrong memory cell was denied and exception thrown for example.

In that case the option would break mods with direct memory calls like hdt physics and many others, but I didn't see any problems with them, while playing with these options on for years. 

I also have doubts because ExpandSystemMemoryX64 very well helps with curing stutterings in openworld loadings (this is why I use it), and, due to graphics data holded in the enbhost, I think you understand where I'm leading.

 

11 hours ago, GenioMaestro said:

Another very interesting post from Voris: 

https://enbdev.com/enbseries/forum/viewtopic.php?p=48345&sid=193fdf52a7f67531567e5add0ef7016e#p48345

Well, ExpandSystemMemoryX64 is good only for certain things and when memory manager enabled, it almost useless. For me it's very important feature for stability, even with 2gb x86 winxp.

Voris, the creator of ENB, say very clear that when  SKSE memory manager  is enabled, it almost useless

Because the SKSE Memory Patch make exactly the same for reduce the memory fragmentation.

 

Read bit more, please: https://forum.step-project.com/topic/710-enb-guide/page-24#entry109854

In retrospect, this make complete sense, because based on the source code of the ExpandSystemMemoryX64 feature that Boris posted on the ENB forums, it uses a system memory allocation function call (MEM_TOP_DOWN) to change the allocation of memory from the "bottom" of the memory space of a program to the "top" of its memory space. The MEM_TOP_DOWN call is intended to be used for testing when converting a 32-bit application to 64-bit.

 

I did quite a bit of research about MEM_TOP_DOWN, and although my findings were inconclusive, I never found any evidence to fully support the idea that it would allow memory to be used more efficiently. For an enlightening and interesting article on MEM_TOP_DOWN, you can check out this blog post by Bruce Dawnson, a programmer at Google (who used to work for Valve). Scroll down to the bottom of the page, and you will see my questions to him that I asked back in March last year.

Well, after this maybe I start to understand how it works. When the game starts the first patch that applies to the game is ofc SKSE together with Sheson's patch. It handles block 1 and block 2, where main game data will be stored. But the enb patches will be applied only when the process start to init render what is far after Sheson's patch. The Boris's words about "almost useless" probably means exactly that it doesn't affect 2 main blocks of Skyrim's process memory. However, it will take care of next allocations what mainly will be textures/meshes for example which go to the enbhost processes.

In other words, probably, the ExpandSystemMemoryX64 works for both the enbhost and the game process, but the main part of the game process cannot be mixed up due to Sheson's patch and this is why it helps to cure stutterings, but doesn't affect on dlls. 

 

12 hours ago, GenioMaestro said:

If your game make CTD when you put ExpandSystemMemoryX64=FALSE, as Voris and all the guides recomend, seach the cause in other side, because that parameter make NOTHING.

If you want verify my words, make specific test with your game ussing VMap, as i make.

 

I recomend you install Memory Block Log and look the data. If you are near the 512 mb limit of the Memory Blocks, maybe, in some moments, you game can exced the limit and make CTD.

I'll try to do it next week. 

[GenioMaestro]

10 hours ago, mrsrt said:

There's lack of info about the variable (literally, only these links you provided here), however the page I left is the first row from google and it was like this for years, based on it I made the conclusion. 

I tried to watch into the enb's dll, but, unfortunatelly, it's obfuscated, only the dll main unprotected. And as Boris didn't provide any docs for his product, we can only test and guess.

The web is plenty full of documentation but a lot of times is incorrect. When is correct is a simply copy/paste of Boris words because nobody can know exactly what make that parameter, except Boris, because as you say, Boris not expose their source code.

http://enbseries.enbdev.com/forum/viewtopic.php?f=17&t=5292

 

10 hours ago, mrsrt said:

Of course, it is not magically casting the skyrim process to x64 base. However, the ReduceSystemMemory option creates another processes to allocate graphic stuff inside and in result Skyrim's process tree can go over the limit, this is what I mean under "expanding". The main process ofc never can go over 4G, but in result of this enb's work it can allocate much more, then why shouldn't it be called as "expanding"?

I not call it as "expanding" because, really, not expand anything.

Skyrim is a 32 bits executable and only can access 4 gb of memory. Is imposible break that barrier.

The only thing that make ReduceSystemMemory is put the mesh and textures in another process and that FREE memory inside the Skyrim executable. Is a trick for have more free memory. Not more.
The option ReduceSystemMemory in ENB not expand anything, simply FREE memory.

 

ReduceSystemMemoryUssage is strictly obligatory only and exclusively when the video card have 2gb of Vram or less and, normally, is not necesary when the video card have 4 gb of Vram or more.

https://wiki.step-project.com/ENBoost

ENBoost is highly recommended to be used by anyone who has 2GB VRAM or less. Users with newer videos which have at least 4GB VRAM may not require its use.

Is recomended and solve some specific problems and can increase the stability of the game.

But the Beth developers are not stupid. When the video card have enougth Vram for store all the mesh and textures, that mean your Vram is not totally filled, the game not waste memory in mesh and textures that already are in the Vram and the memory used by that mesh and textures inside the game memory is released.

 

For that, ReduceSystemMemoryUssage is not strictly obligatory when the Vram are not totally filled.

When the video card have 2gb of Vram or less the video card are constanly releasing textures because not have enougth Vram for have all the textures in the Vram and the game must waste a gigantic amount of memory in the textures for transfer it to the Vram when the camera rotate.

In that situation ReduceSystemMemoryUssage make a fantastic work because all that mesh and textures are inside enbhost and the game have a lot of free memory because the work of transfer the textures is made by enbhost.

 

Only when the video card have 4gb of Vram or more the sum of the memory used by Skyrim + enbhost execed the 4gb. But that is because enbhost store all the mesh and textures for transfer it to the videocard when need. But if the Vram is never filled the video card never request the textures again and the memory used by enbhost is wasted.

[GenioMaestro]

5 hours ago, mrsrt said:

Yes, he speaks here about address mismatching if the "defragmentation" works. A mod can ask for a value in some cell(address), but the variable can be allocated in another cell(address) because of the memory usage optimization. Exactly this behaviour leads to CTDs when access to a wrong memory cell(address) was denied and exception thrown for example.

In that case the option would break mods with direct memory calls like hdt physics and many others, but I didn't see any problems with them, while playing with these options on for years. 

I also have doubts because ExpandSystemMemoryX64 very well helps with curing stutterings in openworld loadings (this is why I use it), and, due to graphics data holded in the enbhost, I think you understand where I'm leading.

Is addres, not cell, but not worry, i'm from Spain and you from Rusian, our english can not be perfect.

Is a miracle that we can comunicate and sometimes we must make an effort for understand the words.

 

Search yours stutering problems in others side. ExpandSystemMemoryX64 is not the cause or the solution:

https://enbdev.com/enbseries/forum/viewtopic.php?p=48490&sid=6124e3a0e8880b27f9672fbb21c82262#p48490

Btw, ExpandSystemMemoryX64 do not affect stuttering and performance (at least to be noticable in game), if it do, something is very wrong.

 

 

5 hours ago, mrsrt said:

Well, after this maybe I start to understand how it works. When the game starts the first patch that applies to the game is ofc SKSE together with Sheson's patch. It handles block 1 and block 2, where main game data will be stored. But the enb patches will be applied only when the process start to init render what is far after Sheson's patch. The Boris's words about "almost useless" probably means exactly that it doesn't affect 2 main blocks of Skyrim's process memory. However, it will take care of next allocations what mainly will be textures/meshes for example which go to the enbhost processes.

In other words, probably, the ExpandSystemMemoryX64 works for both the enbhost and the game process, but the main part of the game process cannot be mixed up due to Sheson's patch and this is why it helps to cure stutterings, but doesn't affect on dlls. 

 

Your imagination continue working and that is bad, very bad. You must read my words again and not doubth of it because, as i normally said, i can DEMOSTRATE each one of my words.

Quote

The only thing that make ENB when enable ExpandSystemMemoryX64 is replace a normal Malloc by a VitualAlloc with flag MEM_TOP_DOWN for make the allocation of the Memory Blocks in the upper zone of the 3.1 gb of the available memory inside TESV.exe, for make that not need ReduceSystemMemoryUssage=true, but maybe require it for have more free memory and be sure the memory can be allocated whitout error. Probably, Voris not implement a fail safe function.

 

I recover my VMMAP and make some test. This is the memory map of Tesv.exe whit:

ExpandSystemMemoryX64=TRUE
ReduceSystemMemoryUsage=FALSE

Spoiler

 

As you can see ExpandSystemMemoryX64 works when ReduceSystemMemoryUsage=FALSE in the same way i see years ago, but i make the test again for be sure the new versions of ENB not change it.

Then, as i said, the paragrah in the STEP guide is incorrect.

And your idea about "the ExpandSystemMemoryX64 works for both the enbhost and the game process" not have any fundament because ExpandSystemMemoryX64 works when the enbhost process not exist.

 

ExpandSystemMemoryX64 can make any inside enbhost? NO

Make the same that i made, use VMMAP for see the memory distribution of enbhost when you enable and disable ExpandSystemMemoryX64 and you can see with yours onw eyes that not have any diference.

 

 

 

You are defending your "special guide" that "works for you and only for you" based in yours owns experiences and yours "incorrect ideas" whitout knowing how works the game or the tools or what make each parameter. You not know what make ENB or what is the real functionality of each parameter. You not know when and why must use each tool and each parameter or what effect can have each one of them in the game.

If you have a problem in your game, like prolems in HDT when activate OsAlocators, ask WHY you have it.

Not asume that OsAlocators not works or give problems. Not extract yours owns conclusions WHITOUT ask to the experts.  Is evident that you not are an expert.

You imagine why you have the problems and give yours own explanations wihout any fundament, simply because you imagine that works in that way and, of course, you end totally convinced of yours strange explanations whitout knowing how bad are yours conclusions.

 

But not worry, you are not alone, a lot of users make exactly the same as you made. Give their own explanations to their own prolems and, as you, try solve theirs own prolems in their own way. That lead to a lot of false knowneledge. A lot of users that not know what are saying or what they are making.

 

But I can not answer every erroneous message of every user that is wrong. I only answer messages when i see a user teaching a erroneous concept to another user. In that moment, and only in that moment, i answer and explaing the things.

 

I said a lot of times the same that is writen is any good guide:

The only way for have a perfect and stable game is use OsAlocators. Any other option is a stupid waste of time.

If you have problems with HDT when you activate OsAlocators try solve it with HdtMemPatch.

[mrsrt]

5 hours ago, GenioMaestro said:

I not call it as "expanding" because, really, not expand anything.

Well, maybe it's a real language misunderstanding.

 

5 hours ago, GenioMaestro said:

But the Beth developers are not stupid. When the video card have enougth Vram for store all the mesh and textures, that mean your Vram is not totally filled, the game not waste memory in mesh and textures that already are in the Vram and the memory used by that mesh and textures inside the game memory is released.

Then explain me something please. My vcard has 8GB VRAM. If I turn off the "reduce" option (expand disabled too) and enter some compilcated place the main process tries to fill whole 4GB and if location complicated enough it ends up with CTD. Meanwhile, if "reduce" enabled I can freely enter the location with no problem. Do you rly think Skyrim fills 8GB VRAM? Or again you'll say that I have something broken?

 

4 hours ago, GenioMaestro said:

Is addres, not cell, but not worry, i'm from Spain and you from Rusian, our english can not be perfect.

Each cell has its address

https://en.wikipedia.org/wiki/Memory_cell_(computing) 

http://www.cs.ucc.ie/~osullb/cs1101/notes/notes15.pdf ctrl+f: "Each cell has a number, called its address, by which programs can refer to it."

 

4 hours ago, GenioMaestro said:

Search yours stutering problems in others side. ExpandSystemMemoryX64 is not the cause or the solution:

https://enbdev.com/enbseries/forum/viewtopic.php?p=48490&sid=6124e3a0e8880b27f9672fbb21c82262#p48490

Btw, ExpandSystemMemoryX64 do not affect stuttering and performance (at least to be noticable in game), if it do, something is very wrong.

I guess, Boris didn't install highweighted textures to see the difference. And explanation here is very easy: when ExpandSystemMemoryX64=false and a new object needs to be placed in memory it will try to allocate instead of reuse:

 

As you already know, memory allocation is a complex operation and the more need to be allocated the more complex it will be. Exactly this complexity will determine how long freeze you'll get (or will not if freeze less than frame time) when dynamically load some texture. There's also take a part the drive where the game hold and OS, but it's not that case.

 

4 hours ago, GenioMaestro said:

You must read my words again and not doubth of it because, as i normally said, i can DEMOSTRATE each one of my words.

You speak like you cannot be wrong, everybody make mistakes, didn't the thread teach it you yet? Even if you can demonstate it isn't guaranteed that you will make right conclusions. 

 

4 hours ago, GenioMaestro said:

I recover my VMMAP and make some test. This is the memory map of Tesv.exe whit:

ExpandSystemMemoryX64=TRUE
ReduceSystemMemoryUsage=FALSE

  Reveal hidden contents

 

As you can see ExpandSystemMemoryX64 works when ReduceSystemMemoryUsage=FALSE in the same way i see years ago, but i make the test again for be sure the new versions of ENB not change it.

Then, as i said, the paragrah in the STEP guide is incorrect.

And your idea about "the ExpandSystemMemoryX64 works for both the enbhost and the game process" not have any fundament because ExpandSystemMemoryX64 works when the enbhost process not exist.

Tell me please, what do you see on this screenshot? I can tell you what I see. 

The top part is where the main game data holds. Exactly to this area access mod dlls. And as you can see it's fragmentated (wasn't touched by ExpandSystemMemoryX64), so memory addresses wasn't mixed up. 

Then goes big area of empty space and then defragmentated memory part made by ExpandSystemMemoryX64. But let's focus on the empty part, why do you think it exists here? Because it was allocated by Sheson's patch, it's block 1 and block 2. Exactly after them ESMx64 do its work. It's even possible that Boris hardcoded the place to avoid touching the main game data and make it compatible with Sheson's patch. Btw, here my guess is right.

 

I used vnmap to check enbhost, indeed ESMx64 doesn't affect on it at all, though it's not much fragmentated, however you were right here. I continued this research and found a big allocation for 512mb at the very end.

It looks and behaves like buffer, if so, it would explain many things. Let's check if enbhost access disk data to load resources. It can be easily checked with perfmon (default windows resource viewer). 

And no activity at all while loading. It means all resources is loading from disk only by the main game process, and from there pushing to the enbhost (proxying). Probably the buffer I found does exactly the job. Due to buffer logic it doesn't spend cpu time for allocations, and this way large texture loadings works much faster and doesn't cause freezes. And it's not guesses anymore. 

 

4 hours ago, GenioMaestro said:

You are defending your "special guide" that "works for you and only for you" based in yours owns experiences and yours "incorrect ideas" whitout knowing how works the game or the tools or what make each parameter. You not know what make ENB or what is the real functionality of each parameter. You not know when and why must use each tool and each parameter or what effect can have each one of them in the game.

 

Did you know about the texture buffering? Do you know whole backend for each enb option? None of us knows that you're listing here. To know what and how exactly works each option in game or enb you need to have source code or spend enough time to reverse the obfuscated enb dll and the 32mb game exe. 

 

4 hours ago, GenioMaestro said:

WHITOUT ask to the experts.  Is evident that you not are an expert.

oow, show me the expert please, lol

 

4 hours ago, GenioMaestro said:

If you have a problem in your game, like prolems in HDT when activate OsAlocators, ask WHY you have it.

Not asume that OsAlocators not works or give problems. Not extract yours owns conclusions WHITOUT ask to the experts.  Is evident that you not are an expert.

You imagine why you have the problems and give yours own explanations wihout any fundament, simply because you imagine that works in that way and, of course, you end totally convinced of yours strange explanations whitout knowing how bad are yours conclusions.

How many loud words. And, actually, you're partially right, because you repeared my words. As I already said, I do tests and use my experience (not gaming) to fill empty spaces of information with my guesses, because there's no such info throughout the internet, because these "experts" did not create a thread like this and did not provide the info. If I'm wrong I correct, but the vast majority is true and you know it. You're creating disputes for several pages because of 1-2 params, meanwhile all the rest guide is true and people already fixing their games using the guide. 

Also, tell me please, you had never made wrong statements and always had tested everything you say, aren't you?

 

4 hours ago, GenioMaestro said:

I said a lot of times the same that is writen is any good guide:

The only way for have a perfect and stable game is use OsAlocators. Any other option is a stupid waste of time.

If you have problems with HDT when you activate OsAlocators try solve it with HdtMemPatch.

And as I already said, you're free to make your own guide which I'll carefully repeat on my game and give you my feedback, after which I'll write everything I think. 

 

[GenioMaestro]

2 hours ago, mrsrt said:

Then explain me something please. My vcard has 8GB VRAM. If I turn off the "reduce" option (expand disabled too) and enter some compilcated place the main process tries to fill whole 4GB and if location complicated enough it ends up with CTD. Meanwhile, if "reduce" enabled I can freely enter the location with no problem. Do you rly think Skyrim fills 8GB VRAM? Or again you'll say that I have something broken?

If the main executable Tesv.exe consume all the available memory we have a sure CTD.

If that happend when you use yours special HD textures can be caused because the textures are bad, in bad format, whithout mipmaps, with bad resolutions... The textures are not simple files and have a lot conditions that must be acomplished. If one of the condition is bad the game must recompute it in ram resizing the textures or computing the mipmpaps and of course that waste a gigantic amount of ram.

Of course, i not discard you can have something bad configured in your game.

 

2 hours ago, mrsrt said:

Each cell has its address

https://en.wikipedia.org/wiki/Memory_cell_(computing) 

http://www.cs.ucc.ie/~osullb/cs1101/notes/notes15.pdf ctrl+f: "Each cell has a number, called its address, by which programs can refer to it."

Then, please call it address.

 

2 hours ago, mrsrt said:

Tell me please, what do you see on this screenshot? I can tell you what I see.

<sniped because all the words are wrong>

 

Probably the buffer I found does exactly the job. Due to buffer logic it doesn't spend cpu time for allocations, and this way large texture loadings works much faster and doesn't cause freezes. And it's not guesses anymore. 

I let the last part only for DEMOSTRATE that yours words not have any sense. When you want discuse about a matter, please, make extensive test for collect the necesary data and speak with consistence.

Stop imagine things and stop triying justify your words using your imagination.

 

That is my colection of screenshot of the memory ussage of Tesv.exe with all the posible diferent options.

Look it, examine it, look the diferences and repeat my test if you want.

The names are very auto explicatives but i must say that when the name of the file start with "no_enb" is because i totally disable ENB renaming d3d9.dll for be totally sure ENB can not alter the memory in any way.

mem.rar

 

Take a special look to this images:

mem_pure_vanila => whitout ENB or SKSE

 

mem_enb_false_TRUE => whit ExpandSystem=false and ReduceSystemUssage=TRUE

 

Do you see any important diferences in that images? Where is the big buffer for transfer textures?

The only real diference is the orange zone and that is the zone used by the textures in vanilla game.

Of course, when enable ReduceSystem that zone not exist in the game because is inside enbhost.

 

Why i can have near the same memory map when enable ReduceSystem?

You imaginary buffer for transfer textures not exist. ReduceSystem make NOTHING inside the main executable.

Except remove the mesh and textures, of course.

The big blocks are exactly the Memory Blocks of the base game, the Block1 and the Block2.

If ExpandSystem is not enabled the Memory Blocks are mixed with the rest of the data.

When you enable ExpandSystem the Memory Blocks are moved to the last zone of the memory.

 

 

As i said, ReduceSystem and ExpandSystem are two diferent parameters and each one of them make diferent things and not have any relation. You can enable and disable each one of them in a separate way for see in the memory map what make each parameter.

 

Please, make extensive test as i made for understand that your words not have any sense. Test each diferent parameter and look the result. But not imagine anything, please, talk with consistent results.

[mrsrt]

13 minutes ago, GenioMaestro said:

If the main executable Tesv.exe consume all the available memory we have a sure CTD.

If that happend when you use yours special HD textures can be caused because the textures are bad, in bad format, whithout mipmaps, with bad resolutions... The textures are not simple files and have a lot conditions that must be acomplished. If one of the condition is bad the game must recompute it in ram resizing the textures or computing the mipmpaps and of course that waste a gigantic amount of ram.

Of course, i not discard you can have something bad configured in your game.

Oh, what is it here, imagination? 

By your logic, why it cannot be recompilled in VRAM by GPU for example? Where the mysterious recompilation in RAM disappears when I enable ReduceSystemMemory (no, enbhost doesn't do it)? And what if my textures are ok and tested by several hundreds of players?

 

30 minutes ago, GenioMaestro said:

Then, please call it address.

I start to think you are trolling or kidding here. Memory cell is memory cell, you access from code to memory cell by address, and memory cell contains and gives you value, not memory address. You cannot hold data in address because address is only a number. Find something else to correct.

 

38 minutes ago, GenioMaestro said:

I let the last part only for DEMOSTRATE that yours words not have any sense. When you want discuse about a matter, please, make extensive test for collect the necesary data and speak with consistence.

Stop imaginig things and stop triying justify your words using your imagination.

What the heck are you talking about? What imagination? I gave the real proof of that enbhost does not load textures itself. It means TESV.exe takes the part of proxy here, unless data appear there by magic. Do you have any doubts at this point?

 

59 minutes ago, GenioMaestro said:

Do you see any important diferences in that images? Where is the big buffer for transfer textures?

Where the heck do you want to allocate the block for buffer in unamanged memory? Are you insane? The idea of conflicting wasn't appear in your head? The block for buffer can appear only for managed memory, and in that case ESMx64 does the management.

(ESMx64 on RMSU off)

 

Exactly this block (or another one near) fixes stutterings and it's provided by ExpandSystemMemoryX64 not by ReduceSystemMemoryUsage. Enb can use it as a buffer to transfer resources to enbhost if RSMU enabled, but RSMU doesn't have any buffers in the game process. And exactly this causes freezes with large textures, because memory allocates dynamically, and with ExpandSystemMemoryX64 it's already allocated in a block. All proofs before your eyes.

 

 

[GenioMaestro]

3 hours ago, mrsrt said:

Oh, what is it here, imagination? 

By your logic, why it cannot be recompilled in VRAM by GPU for example? Where the mysterious recompilation in RAM disappears when I enable ReduceSystemMemory (no, enbhost doesn't do it)? And what if my textures are ok and tested by several hundreds of players?

The bad textures can not be recomputed in Vram because the video card can not make that work.

Do you know what is a mipmap? Do you know how is computed?

Do you know that the textures must have specific resolution? Do you know how are re dimensioned?

 

When you enable ReduceSystem you have more free memory inside Tesv.exe and that gigantic amount of free memory is used to recompute the textures.

If you not enable ReduceSystem you have LESS free memory inside Tesv.exe and the gigantic amount of memory need for re compute the textures is not available. When the memory ussage inside tesv.exe touch 3.1 or 3.2 GB have CTD.

Ask to that several hundreds of players what happend when they disable ReduceSystem.

 

3 hours ago, mrsrt said:

What the heck are you talking about? What imagination? I gave the real proof of that enbhost does not load textures itself. It means TESV.exe takes the part of proxy here, unless data appear there by magic. Do you have any doubts at this point?

How do you can think that enbhost can read the textures from the hard disk?

Do you play Skyrim? Do you know what is a BSA file?

The textures, normally, are distributed inside BSA files, at least the base game have it inside BSA files. The most big mods that i know distribute their mesh and textures inside BSA files.

How can enbhost decompres the BSA files on the fly for get the textures? You are crazy?

 

Of course, the textures are managed by tesv.exe because is the only program that know what mesh and textures are need, where are located, if must get it from the BSA or from the loose files.

When ENB enable ReduceSystem activate the hooks for intercept the DirectX calls of the game, get the texture and copy it inside enbhost.

3 hours ago, mrsrt said:

Where the heck do you want to allocate the block for buffer in unamanged memory? Are you insane? The idea of conflicting wasn't appear in your head? The block for buffer can appear only for managed memory, and in that case ESMx64 does the management.

(ESMx64 on RMSU off)

 

Exactly this block (or another one near) fixes stutterings and it's provided by ExpandSystemMemoryX64 not by ReduceSystemMemoryUsage. Enb can use it as a buffer to transfer resources to enbhost if RSMU enabled, but RSMU doesn't have any buffers in the game process. And exactly this causes freezes with large textures, because memory allocates dynamically, and with ExpandSystemMemoryX64 it's already allocated in a block. All proofs before your eyes.

You call that a extensive test? That is all that you have look? Where are the screenshots with ExpandMemory=false? Have you look the size of that blocks? 

You have one block of 512 MB that correspond to the Memory Block1.

You have one block of 256 MB that correspond to the Memory Block2.

 

Your imaginary buffer is exactly the very well know Memory Blocks of the game and are used by the game for store the data of the cells, the data from the npc's, the data of the quest...

 

How can i asure with total security that the Memory Blocks of the game are in that zone?

Because i can change their size with SKSE from the minimun 256-256 to the maximun 1024-512:

Spoiler

 

That memory zone is NOT provided by ENB in any way. ENB can NOT acces that memory zone.

[GenioMaestro]

On 10/24/2019 at 11:05 AM, GenioMaestro said:

But, logically, it shouldn't confilct, the mem patch works for the main process of the game, ExpandSystemMemoryX64 works with only enbhost process.

3 hours ago, mrsrt said:

Exactly this block (or another one near) fixes stutterings and it's provided by ExpandSystemMemoryX64 not by ReduceSystemMemoryUsage. Enb can use it as a buffer to transfer resources to enbhost

That is enougth. I'm bored of you.

I waste two days explaining your conceptual error and you continue saying that ExpandSystem fixes stutterings and help ReduceSystem. I give you the necesary links, explanations and demostrations for show your error.

If you not want see it i can not make more.

 

I can understand that you not want belive me but nobody can understand that you not belive Boris words.

https://enbdev.com/enbseries/forum/viewtopic.php?p=48490&sid=6124e3a0e8880b27f9672fbb21c82262#p48490

Btw, ExpandSystemMemoryX64 do not affect stuttering and performance (at least to be noticable in game), if it do, something is very wrong.

[mrsrt]

5 minutes ago, GenioMaestro said:

The bad textures can not be recomputed in Vram because the video card can not make that work.

Oh really? Then tell me please, what is GPU and what do you think it can and can not, I'm very curious 

Spoiler

 

8 minutes ago, GenioMaestro said:

Do you know what is a mipmap? Do you know how is computed?

Do you know that the textures must have specific resolution? Do you know how are re dimensioned?

Why do you answer my questions with your own questions? : D You are giving so much effort to show yourself as an expert, when I'm just a typical user : D 

 

12 minutes ago, GenioMaestro said:

How do you can think that enbhost can read the textures from the hard disk?

How do you write this post if even cannot read another? Okay, let's read together:

7 hours ago, mrsrt said:

Let's check if enbhost access disk data to load resources. It can be easily checked with perfmon (default windows resource viewer). 

And no activity at all while loading. It means all resources is loading from disk only by the main game process, and from there pushing to the enbhost (proxying).

If you didn't understand yet, I'll help you, enbhost does not load anything itself because it doesn't have any disk activity. Enbhost also does not process anything, because it doesn't consume cpu time. It's just a simple storage, all processes is happening in the TESV.exe. 

 

10 hours ago, GenioMaestro said:

How can i asure with total security that the Memory Blocks of the game are in that zone?

You probably have no idea what I was talking about. Okay I'll test it myself.

ESMx64 on RSMU off

Loading at qasmoke, 1.7Gb consumption

Spoiler

 

 

 

Teleporting to Bee And Barb, 2.6Gb consumption

Spoiler

 

See the difference? Where new resources was allocated? Ofc before blocks. What will happen when the memory reach the blocks area? Yes, CTD. But in this example it would literally means the end of free memory. What will happen if some dll, mod, or game engine itself because of fragmentation will try to allocate anything in this area? Bug, or most probably CTD. How to prevent it? Using custom memory management. Try to play several hours, check fragmentation map and think what would happen if you had blocks at the bottom.

 

Actually, with that setup I cannot even go outside restricted cells because of lack of memory. Any city or open area consumes more than 3.1Gb what lead to simply crash on loading to the area, because of disabled RSMU. 

 

And now the same with RSMU

Spoiler

 

Do you really still think "ReduceSystemMemoryUssage is strictly obligatory only and exclusively when the video card have 2gb of Vram or less and, normally, is not necesary when the video card have 4 gb of Vram or more."?

Do you really still think "If STEP say that the two parameter are incompatible is because the two parámeters works over the main TESV.exe and you must not use the two at the same time."?

 

11 hours ago, GenioMaestro said:

I waste two days explaining your conceptual error and you continue saying that ExpandSystem fixes stutterings and help ReduceSystem. I give you the necesary links, explanations and demostrations for show your error.

If you not want see it i can not make more.

 

I can understand that you not want belive me but nobody can understand that you not belive Boris words.

https://enbdev.com/enbseries/forum/viewtopic.php?p=48490&sid=6124e3a0e8880b27f9672fbb21c82262#p48490

Btw, ExpandSystemMemoryX64 do not affect stuttering and performance (at least to be noticable in game), if it do, something is very wrong.

- You cannot change the fact it helps with stutterings. Nor Boris, nor You. I can give you the link for my texture pack and you can test it yourself with your own eyes. You can build your own pack to meet the same conditions as I have if you don't trust my pack that was texted for hunderds of players (maybe thousands, idk, it's shared).

 

- You cannot change the fact that ESMx64 mentioned even in the ENBoost official page on nexus published by BorisVorontsov in relation of stutterings:

3) If stuttering bother too much, edit enblocal.ini file vriables ExpandSystemMemoryX64, ReduceSystemMemoryUsage(especially this one), DisableDriverMemoryManager.

 

- You cannot change the fact if Boris left the message about ESMx64 and stutterings on which you left link already twice it means several players reported that behaviour to him. 

 

- And you cannot change the fact everybody make mistakes.

 

Yes, probably my idea with block buffering false, this is why it was an idea. And do you know how many possible reasons left? For example:

- ESMx64 may use different method for allocations which works faster, or may not

- With ESMx64 allocations happen in the center of memory area (because bottom already occupied), so the memory area doesn't expand and it may increase allocation speed or may not

- ESMx64 may use some OS optimizations or make it the way for which some optimization exist by OS or hardware, or may not 

And so on.

Do you understand how many parts of OS and harware touch the texture loading process? As I already said, we cannot know for sure how everything works for the game, however, we can make tests and researches that give very interesting and valuable information. You do your tests, I did mine. You correct your knowledge, I correct mine. And please, don't prove that you know and knew everything, and everything you write is right.

And, actually, thank you for the test with sheson patch and ESMx64, my game wasn't able to handle changing values that much.

 

12 hours ago, GenioMaestro said:

That is enougth. I'm bored of you.

Oh, I'm bored of you too. If you stop posing yourself as a Guru here, for whom everybody should kneel, and finally accept that you cannot know everything, things will go much easier.

 

[mrsrt]

I continued the memory research to find out why I was getting CTD with big array allocations when the 3.1Gb limit wasn't reached.

 

Allocation code

Spoiler

Function loop()
	Debug.Trace("[MEMORY TEST] loop started")
	int i = 0
	While true
		Float[] arr = new Float[128]
		i += 1
		If i >= 1000000
			Debug.Trace("[MEMORY TEST] " + i + " allocations happened")
			Return
		EndIf
	EndWhile
EndFunction

 

 

Test 1 - Extreme allocations (1.000.000)

ESMx64: true

RSMU: true

Allocations: none

Spoiler

 

ESMx64: true

RSMU: true

Allocations: 1.000.000 iterations

Spoiler

Memory was surprisingly allocated in the shared area. CTD happens almost after any my action whether it's ESC menu opening, console opening and so on. Garbage Collector does not free* memory at all in this state.

* - free and clear is not the same

 

ESMx64: false

RSMU: true

Allocations: 1.000.000 iterations

Spoiler

No unexpected changes. CTD still happens, GC doesn't free

 

ESMx64: false

RSMU: false

Allocations: 1.000.000 iterations

Spoiler

No unexpected changes again. CTD after ESC clicking, GC doesn't free. 

 

Conclusion: nor ESMx64, nor RSMU affects on this CTD and GC behaviour. Probably GC has some allocation threshold which trespassing completely breaks memory freeing.

 

 

Test 2 - Lesser allocations (42.900)

If engine clears allocated memory each frame, then allocations for 5 minutes of GC work should be safe. As I have 143 fps it means I can allocate 143 * 5 * 60 = 42.900 arrays. Let's test what will happen.

I enabled back ESMx64 and RSMU to make difference more noticable. 

 

Allocations: none

Spoiler

 

Allocations: 42.900 iterations

Spoiler

And no noticable allocations appeard. Then the data must be in some block. Let's listen for block 1.

 

Allocations: none

 

Allocations: 42.900 iteration

And indeed, the script data was allocated in the Block 1. 

 

Conclusion: Script allocations hold in the Block 1. When memory in block 1 ends Papyrus allocates data in the shared memory. 

 

Test 3 - Garbage Collector experiments (42.900)

Now let's test how GC will clear the memory. I'll allocate the same 42.900 arrays and wait 5 minutes to see the difference.

 

State: just after loading

Allocations: 42.900 iteration

 

State: After loading + 5 mintues waited (new game instance to avoid any alt-tab affection)

Almost no change. GC didn't free space from unused arrays. Well, it's typical GC behaviour, because usually they have some threshold at which they start to free memory.

 

Let's allocate 100.000 arrays.

 

Test 4 - Garbage Collector experiments (100.000)

State: just after loading

Allocations: 100.000 iterations

 

State: after 3 minutes*

Some time after loading GC finally started to free memory, what could be easily detected in task manager. After about 3 minutes GC stopped with free() at ~320mb

 

Let's allocate 200.000 arrays.

 

Test 5 - Garbage Collector experiments (200.000)

State: just after loading

Allocations: 200.000 iterations

 

State: after 8 minutes*

After about 8 minutes GC stopped freeing memory at this point. It seems threshold is not determined, or behaviour of calling free() is unpredicted. 

 

Let's test how memory will be reused with 100.000 allocations

 

Test 6 - Garbage Collector memory reusage

To completely clear the 100.000 arrays GC needs 100000 / (60 * 143) = ~12 minutes. Then if I'll allocate 100.000 arrays in 12 mins they must not consume any more memory.

 

State: just after loading

Allocations: 100.000 iterations

 

State: next allocation in 12 mins

GC fully cleared the memory. 

 

Conclusion: GC fully covers its tasks within block 1, but its freeing behaviour quite weird.

Bethesda used very interesting solution with GC clearing, instead of batch clearing they used gradual clearing which will not make freezes, however this solution creates the bottleneck: if allocations happen more than framerate it will lead to inability of GC to clear required amount of memory what will end with some kind of memory leak. 

 

Test 7 - Intersection the block 1 border

As test 1 & 2 shown, if memory in block 1 is not enough the engine allocates script data in shared memory. Let's test how it works.

270.000 iterations should be enough to go out of the block 1 in my case. 

 

State: just after loading

Allocations: 270.000 iterations

Block completely filled, and very few memory allocated in shared area

 

State: after several mintues

And after several minutes it started to free memory in the block

 

Conclusion: GC can clear memory out of block 1

 

Test 8 - CTD reason after large allocation

The reason why I get CTD when pressing Esc button still unclear. Let's make some kind of CTD test.

 

Esc press with 270.000 iterations in qasmoke -> crashed

 

Esc press with 240.000 iterations in qasmoke -> passed

Esc press with 240.000 iterations after "coc whiterun" -> crashed

 

Esc press with 200.000 iterations in qasmoke -> passed

Esc press with 200.000 iterations after "coc whiterun" -> passed

 

And the block 1 after passing esc clicks with 200.000 in the "coc whiterun" zone:

 

It's obvious that for second test with 240.000 allocations block was fully filled after teleport, so...

 

Conclusion: Whenever memory in block 1 ends, eventually it leads to CTD. This results in several conequences:

- Memory area for scripts is literally limited

- When the area border intersected it leads to CTD, so we can say: the more mods allocate the less stable it is

- As the block used not only as a script storage, it means populated zones in the game also reduce available script memory while you're inside

 

[mrsrt]

Thread update

- Changed the memory management section in modmaker recomendations

- Changed the description for ExpandSystemMemoryX64 in enb section. Also the section was a bit formatted and left the link for enboost

[mrsrt]

Played a bit with UseOSAllocators=1 by crashfixes.

At first, it really helps to prevent CTDs caused by block 1 overflow, because block 1 is not exist anymore with os allocators enabled, memory of the block allocated in the shared area. However, for some reason the option doesn't touch other blocks which reserve 600+mb but almost always free.

Spoiler

Also the option seems to be completely incomatible with ReduceSystemMemoryUsage. When render starts the game simply crashes if the option enabled. And it leaves no other way for players who has HQ textures but to disable the option and use ReduceSystemMemoryUsage.

 

I analyzed my existen crashdumps and found that, almost all of them happens because of block 1 overflow, when overall process memory wasn't filled. It's rare, but still possible. I'll try to test my game with DefaultHeapInitialAllocMB=1280 (max), probably, if 512mb for the first block was enough in the vast majority of cases, then 1024mb should fix it completely (if no memory leak exists). However, it will reduce shared memory area, but it doesn't seem to be a problem with ReduceSystemMemoryUsage enabled. Btw, I'll test it for 1-2 weeks to be sure and edit the guide.

[donttouchmethere]

just found this in the skse readme:

* Does SKSE work with a 4GB loader?
 - 4GB loaders are no longer needed.

 

seems the 4GB loader times are over?

[mrsrt]

On 11/5/2019 at 5:03 AM, donttouchmethere said:

just found this in the skse readme:

* Does SKSE work with a 4GB loader?
 - 4GB loaders are no longer needed.

 

seems the 4GB loader times are over?

You mean 4Gb patch I mentioned earlier? If so, yes, several pages ago there was talk about it. The patch marks executable with LAA flag, which is already flagged since some official patch. However, besides LAA flag the patch does some unknown binary changes. I left signatures if someone wants to know what is it. 

[faky]

On 10/27/2019 at 6:12 PM, stingray1995 said:

ExpandSystemMemoryX64 - The REAL Consensus:

 

Everyone should be completely foregoing this setting, as in, act as if it doesn't even exist.  There're so many reddit posts about it out there, STEP forums that discuss how useless and redundant this setting is, that it's not even funny.  Why bother linking?  Just Google something like 'skyrim expand system memory reddit 2019' and everything comes up.

 

Basically, it's a tossup between using the SKSE Memory Patch's increased blocks and Crash Fixes' memory allocation (UseOSAllocators=1), the latter being leagues better as it completely gets rid of the blocks.

 

I'm not kidding:  I literally got a ping of genuine deja vu typing that, as if it were out of a previous life; everyone should know this shit by now.

that solved my memory related CTD issue therefore it deserves it's own topic and a pin so that all may know of this achievement

[mrsrt]

Results of 3 weeks of testing, I hadn't played much, but it's still a dozen of hours.

Setup with 1Gb for Block 1 behaves quite well. Loadings noticable faster, no additional CTDs during gameplay experienced. However, got twice CTD during racemenu that wasn't before, but I'm not sure it has relation. 

Actually, i didn't see consumption more than 420mb for Block 1, so probably it's just a waste of memory.

 

Enabling UseOSAllocators bring additional ctds at the same place: D8309A. Several users around LL and reddit also reported CTDs at this point. Enabling CustomMemoryBlock in crashfix config helps and behaves pretty well, but doesn't cure the CTD totally. I'll continue to find a working setup with os allocators if it's possible.

 

For those who play the game with uncapped fps and use havok fix I pretty recommend to adjust interval update value (HavokFix.ini -> freq option). By default (freq=0) the fix uses a complex update method which:
- works every frame and slows down frame processing what lead to fps drop and increases "input lag"

- brings item jumping when you enter a cell, load a save, exit pause menu, etc. It happens because of bad implemented pause mechanic. 

Both of these can be fixed with the second update method which works with fixed delay time. The method can be activated by initializing the "freq" option where you set the delay between updates (I recommend about 50ms). It will work in its own thread and completely free the render thread what will be pretty noticable. 

[GenioMaestro]

8 hours ago, mrsrt said:

Results of 3 weeks of testing, I hadn't played much, but it's still a dozen of hours.

Setup with 1Gb for Block 1 behaves quite well. Loadings noticable faster, no additional CTDs during gameplay experienced. However, got twice CTD during racemenu that wasn't before, but I'm not sure it has relation. 

Actually, i didn't see consumption more than 420mb for Block 1, so probably it's just a waste of memory.

 

Enabling UseOSAllocators bring additional ctds at the same place: D8309A. Several users around LL and reddit also reported CTDs at this point. Enabling CustomMemoryBlock in crashfix config helps and behaves pretty well, but doesn't cure the CTD totally. I'll continue to find a working setup with os allocators if it's possible.

I not know what more say to you because you simply ignore anything that not match with your ideas. My only additional recommendation is keep investigating how the game really works because if, in 2019, you learn:

On 10/26/2019 at 10:20 PM, mrsrt said:

Whenever memory in block 1 ends, eventually it leads to CTD.

I analyzed my existen crashdumps and found that, almost all of them happens because of block 1 overflow,

You have 8 years of delay because that is the main problem of the game from 2011 and the cause of 90% of the CTD that everyone have in the years 2012-2013 until Sheson publish SSME in 2014.

 

 

But SSME does not solve all the problems because, really, the memory blocks always run out. Your words:

On 10/30/2019 at 7:09 PM, mrsrt said:

512mb for the first block was enough in the vast majority of cases

are only valid when we use default game configuration, we not have BIG mods and we only want play the same match for 2 or 3 months. More or less, your exact situation.

 

If you change the default uGridsToLoad from 5 to 7 or 9 the Memory Blocks run out very fast.

If you install some BIG mods like 3DNPC, RDO, Warzones, SIC, SkyTest, Proyect AHO, MoonPatch, Maid II Deception, Predators Lost Tribes, Wenches... yours Memory Blocks can be totally consumed before start the game.

If you play the same match for 2 or 3 month, one day, whitout any alert and whitout any explanation, you get CTD simply because the Memory Blocks run out, as you has verified.

 

Every day we play the file size of the savegame increase and that increment represent more and more Memory Blocks consumition and, soon or late, the game go to make CTD because the Memory Blocks are exausted.

We can increase the size of the Block1 for solve the CTD but we can not increase the Block2.

When the Block2 is totally filled the game not make CTD. Simply slow down the game.

 

How many?

That depend of the configuration of your game, what mods you have and how many time you have played the same match. 

 

Look the ussage of my Memory Blocks when i start a New Game:

Spoiler

While i'm in the Alternate Cell my game is consuming 435mb from the Block1, 15mb more than the maximun that you ever see, and when i go to any exterior cell the game exced the limit of 512mb and i get CTD. My only solution is put DefaultHeapInitialAllocMB=1024 and that allow me play the game whitout CTD but i must accept a tremendous slow down in the game that is caused because the Block2 is totally filled.

 

How many big is my slow down? Take a look to my logs with and whitout OsAlocators.

Papyrus.1.logPapyrus.0.log

I make exactly the same: Start a New Game, wait the automatic savegame and close the game.

With OsAlocators=1 my game need 1 minute but with OsAlocators=0 need 2 minutes = 50% more.

 

If we talk about my normal savegame with a file size of 50mb and 1 year of history:

With OsAlocators=1 I can load it in 30 seconds but with OsAlocators=0 I must wait 5-7 MINUTES.

 

That is the real diference when use OsAlocators. But that diference is not noticeable until you have a real saturated game. If you only have texture mods, city overhaul, climates, verdant and some simple quest mods your game is not saturated and you not need OsAlocators. If you have a lot of mods that add new npc's to the game, like Warzones, SIC, SkyTest, Wenches plus a lot of Quest mods plenty full of NPC's and dialogs, probably, you need OsAlocators.

 

When a normal user can have a saturated game and fill the Block2? Nobody know.

That only depend of what mods they install and how many time play the same savegame.

But fill the Block2 not cause CTD. Simply slow down the game a bit every day.

Is not noticeable because is CUMULATED a bit every day and everybody think is normal.

But is easy solved simply ussing OsAlocators.

 

The only way for asure to a normal user that NEVER can have problems in the game is use OsAlocators.