CTD and Performance patch ENBoost (by Boris Vorontsov)

[Kuldebar]

Boris seems rather inscrutable at times, partially a language barrier and partially from just not adding remarks to changes to things. I read a lot on the official enbdev forums, so I don't consider myself oblivious. Some helpful peeps like Wolfgrimdark keep a running record of Boris commentary on settings...but it's like going to the Delphic Oracle at times...

 

Take for instance the default enblocal.ini that comes with the latest enbseries_skyrim download from enbdev.com:

 

[MEMORY]

ExpandSystemMemoryX64=false <---- wtf? Isn't that a big deal, if something changed, is this no longer important to have enabled? (PS. counter intuitively, I am running this setting at "false" and I have noticed no detriment/issues). Maybe Boris changed this when Sheson's Memory Patch swept onto the scene?

 

Then there's this which has bothered me:

 

[ENGINE]

EnableVSync=false  <---all those poor slobs out there who used the "PresentInterval = 0 Tweak" have one less chance to have it corrected by the enb.

 

Please take my editorial remarks in the spirit intended. I have huge respect for the irascible Boris but some things create confusion and perhaps contribute to his temperament...like that hard to find download button on his website page... :o

[Nearox]

I believe he said some time ago that he will put all ( or most, I dont remember all of it) settings to false by default.

 

I've always found the STEP ENB Guide to be one of the best sources of info on ENB settings.

[EssArrBee]

I believe he said some time ago that he will put all ( or most, I dont remember all of it) settings to false by default.

 

I've always found the STEP ENB Guide to be one of the best sources of info on ENB settings.

 

That thing is way out of date to be honest. I've neglected it. :(

[Kuldebar]

I believe he said some time ago that he will put all ( or most, I dont remember all of it) settings to false by default.

 

It just seems similar to the decision the SKSE Team made to NOT include a default SKSE.ini file with install. O.o

 

...just asking for problems.

 

Idiot-proof isn't a dirty word, imo.

 

"ExpandSystemMemoryX64=false" makes no sense to me because Boris has stated on the "record" that everyone can benefit from that setting...even non-64 bit OS users. BUT, I am given pause now because he is making it default false...and playing with it on false I have noticed absolutely no detrimental effect on my game...

[Nearox]

I believe he said some time ago that he will put all ( or most, I dont remember all of it) settings to false by default.

 

I've always found the STEP ENB Guide to be one of the best sources of info on ENB settings.

That thing is way out of date to be honest. I've neglected it. :(

A great majority of the explanations of the settings are still valid today... And the quickstart section has recently been updated for ENBoost.

[EssArrBee]

The QuickStart is recent but I forgot to add skyrimpref.ini stuff for regular enb. One day I will get to it in my list of infinite step stuff.

[keithinhanoi]

I believe he said some time ago that he will put all ( or most' date=' I dont remember all of it) settings to false by default.[/quote']

It just seems similar to the decision the SKSE Team made to NOT include a default SKSE.ini file with install. O.o

 

...just asking for problems.

 

Idiot-proof isn't a dirty word' date=' imo.

 

"ExpandSystemMemoryX64=false" makes no sense to me because Boris has stated on the "record" that everyone can benefit from that setting...even non-64 bit OS users. BUT, I am given pause now because he is making it default false...and playing with it on false I have noticed absolutely no detrimental effect on my game...

[/quote']

That change to the included enblocal.ini started with 0.246, if I'm not mistaken - but that version isn't even available to download anymore, so I'm going off of my backup.

 

If you look at the set of values there, it suspiciously looks to me like what Boris may be using for his own system (WinXP x86 & a 2GB GPU). I've read through all of the threads for 0.246, .25, and .251, and there's nothing about the change of ExpandSystemMemoryX64 to false, so I'm just going to ask him. However, I don't expect he'll respond by saying he forgot to mention such an important change in what he thinks people should set it to.

 

As for understanding all the other enblocal.ini [MEMORY] settings go, Phinix's notes included with his Phinix Natural ENB are the best interpretation that I've found of most everything Boris has said. I've got my own set of notes, though, which I've made more explicit for the boolean settings - so exactly what happens if you set them to false, and what happens if you set them to true.

 

I'd be very happy to share this in this thread after I get an answer from Boris on the supposed default ExpandSystemMemoryX64 setting change.

[redirishlord]

"ExpandSystemMemoryX64=false" very interested to know if this should be made true. Thanks for asking, will stay tuned.

[Kuldebar]

As always, clarity is your strong suit, Keith. But that's precisely what bugs me the most about the enb settings...it's not supposed to be voodoo (poor headless chickens) or inexplicably arbitrary. It should be fairly predictable and not wishy-washy. You know, kind of science based? Sure, one can tell people to adjust the setting for their particular machine and configuration, but there has to be some contiguous and shared objective reality...or it's simply chaos lol. I spent my early years editing batch files and trying to finagle ways to get more of that 640k memory available for my games and drivers to run at peak efficiency, lol. So, I am accustomed to the idea that switches do rational things, like an on or an off state.

 

A = A, and not "for some people" A = B.

[Aiyen]

There is no chaos involved.

Just a "simple" matter of many people who start to force their systems to deal with loads they are not capable of dealing with.

And the ones where they are designed for it, then even slight variations in the actual chips can cause issues. (The common example is bad VRAM on graphics cards... even though the cards pass quality control, then they still fail when part of the users system.)

 

It makes perfect sense that when you ask your full system to run at its bandwidth limits then you will get experiences by some people who either have not received the quality of chips they thought, or just have generally lower performance on their chips due to age.

[Kuldebar]

@Aiyen

 

Ah but there is conflict and chaos inflicted when information being released is contradictory. Simply look at what Boris has said:

 

As i don't have x64 OS and heard about 3.1 gb limit (which is 4 gb), couldn't test myself with VMMap, so thought it's bug in game engine when some buffer pointer used in math, so i did this variable to fix issue by using memory range of 3-4 gigabytes. At same time this greatly reduce memory fragmentation, but effective only for x64 systems as they give 4 gb of virtual address space for 32 bit applications (winxp allow to set 4 gb, but it's very buggy mode and not recommended). I don't know how to describe this to users, but seems this parameter always work for everybody, so let it be true always, some users report that even this enough against their problems.

OK, but that flies in the face of the default settings and advice on the enbdev forums that Boris has handed out to some inquiring posters "just use default settings" on more than one occasion, indicating that those settings may have some purpose or benefit.

 

Please don't misconstrue this as me ignoring the various permutations of system hardware and software, obviously bad RAM/VRAM or viruses will skew results.

 

I'm simply suggesting a better communication regarding "best practices" with the underlying assumption that a person isn't using a broken computer. If ExpandSystemMemoryX64=true is universally good, then how about we have it default to true and not false? Why have it default to the "exception to the rule" ?

 

Such things muddy the water.

[keithinhanoi]

As always, clarity is your strong suit, Keith. But that's precisely what bugs me the most about the enb settings...it's not supposed to be voodoo (poor headless chickens) or inexplicably arbitrary. It should be fairly predictable and not wishy-washy. You know, kind of science based? Sure, one can tell people to adjust the setting for their particular machine and configuration, but there has to be some contiguous and shared objective reality...or it's simply chaos lol. I spent my early years editing batch files and trying to finagle ways to get more of that 640k memory available for my games and drivers to run at peak efficiency, lol. So, I am accustomed to the idea that switches do rational things, like an on or an off state.

 

A = A, and not "for some people" A = B.

Yeah, I completely agree. But what seems to happen is due to language limitations, the initial explanations for any added .ini settings have been quite brief and not always self-evident.

 

Then people try setting them one way or another, come back, and say it's not working, and Boris gives suggestions based on their particular setup and problem. So you have to build a picture, as it were, of what the setting does, based on explanations of XXX setting will help users with a ZZZ type of setup.

 

Keep in mind that a big part of the problem here, also, is that Boris has added settings to help users with different systems, but he has no way to set if those settings help on his own system.

 

My approach to these kinds of settings is to know that they definitely do something specific, and I just need to understand what that is. If I know what each setting or switch does, I can decide whether it will help me with my particular system. So in this case, I've been reverse-engineering the explanations.

 

Then, if I'm quite sure about what one of them does, but need confirmation, I've decided to just ask.

 

This worked great, for example, with getting absolute confirmation from Boris about the AutodetectVideoMemorySize switch added with 0.243 - where it seemed that setting it to true would mean that the VideoMemorySizeMb value would be ignored. So I asked and he confirmed it, in no uncertain language.

 

He also explained in a follow up post how AutodetectVideoMemorySize determines the video memory size, though the exact way it's implemented is a bit more elusive to me, and I think I should ask him after I've tested my theory that it is based on the shared video memory value as given in Windows' DirectX Diagnostic (dxdiag) tool report.

 

Anyhow, I strongly feel that the enblocal.ini settings need much better clarification since ENBoost was thrown back into the limelight following sheson's memory patch fix. However I can help towards that end, I will. But, I just haven't put it all together and posted it in one place because I don't feel it's 100% accurate yet.

[keithinhanoi]

Well, that was easy.

 

Boris has changed ExpandSystemMemoryX64 to false in the included enblocal.ini because it conflicts with some anti-virus software, leading people to complain to him too much!

 

Read his funny reply here.

 

Moral of story - If you've read up everywhere else and haven't found a convincing answer, just ask the source.

 

Issues with anti-virus software has been duly noted in my detailed explanation of the ENBoost [Memory] settings. Still not feeling they're finished, but if someone asks, I'll post them here for review.

[redirishlord]

Classic Boris. Now that you mention it, I see that it's true in my Fallout NV enblocal (and hasn't been causing antivirus issues apparently), but not in my Skyrim enblocal (well it its true for both now).

 

It would be great if you shared your detailed explanation here. I'd love to give it a read for my own education. Perhaps the community benefits as well?

 

Thanks keithinhanoi.

[Octopuss]

I agree with his opinion about Avast :D