Jump to content
  • 0

STEP guide missing misinformation on moding ENBlocal.ini


Question

Posted

Hello,

 

I am following the latest STEP guide and I just downloaded ENBoost.

I am tweaking the ENBlocal.ini file as instructed and there is a warning at the bottom that says:

 

40px-Warning-Logo.png Warning: Do not change the settings in the [THREADS] section! These are for special case use only. You are 99% not likely one of those special cases! The section should remain as follows:

[THREADS]
DataSyncMode=0
PriorityMode=0
EnableUnsafeFixes=false

 

The warning assumes that my ini says that but when I open it for the first time all it has under [THREADS] is

 

DataSyncMode=1
PriorityMode=0

 

I have not touched and will not touch it but I just wanted to let you know. This is from the latest version of ENBoost (v0.305)

Should I leave it like that?

14 answers to this question

Recommended Posts

  • 0
Posted

What the hell, Boris?! Why is DataSyncMode defaulted to 1? I'll notify him that it should be changed. Values should reflect what is in the note. I had no idea it was defaulted to being 1.

 

EDIT:

I've posted a message to him to see if he'll change it.

  • 0
Posted (edited)

As long as you have EnableUnsafeFixes=false, DataSyncMode and PriorityMode are ignored anyway.

EnableUnsafeFixes is set to false by default. If not written in the enblocal.ini at game-start, it'll be considered false and added as such to the enblocal.ini under [Thread] like you'd expect.


So long story short : Nothing to worry about, everything is properly disabled with the default file.

Edited by Kesta
  • 0
Posted

When I download ENB v0.305 and extract the enblocal.ini file from the WrapperVersion folder, it tells me DataSyncMode=0.

Correct. When I checked before messaging Boris, it was indeed set to 1. I messaged him and he's set it to 0 now saying this:

 

Okay. But DataSyncMode=1 is better in general, 0 - disables fix. It's all about messing with skyrimprefs.ini and cpu/os combo.

 

 

As long as you have EnableUnsafeFixes=false, DataSyncMode and PriorityMode are ignored anyway.

 

EnableUnsafeFixes is set to false by default. If not written in the enblocal.ini at game-start, it'll be considered false and added as such to the enblocal.ini under [Thread] like you'd expect.

 

 

So long story short : Nothing to worry about, everything is properly disabled with the default file.

With the given quote from Boris, are you sure about that statement?

  • 0
Posted (edited)

 

With the given quote from Boris, are you sure about that statement?

Can you link the "given quote" you're talking about ?

I'm just relying on programming logic and general observation of how the whole enbseries work (i.e. for everything else but a single exception it follow the programming logic I'm relying upon) :

For everything, you have an on/off toggle. When toggle is off, the whole feature is disabled, when the toggle is on, parameters are used to configure this feature.

Edited by Kesta
  • 0
Posted

Hmm interesting that he would say that 1 is better in general, considering the number of cases we have had lately where it caused issues.

 

And the EnableUnsafeFixes setting is for some other fixes that cause issues with other things, notably the map, when enabled and is separate from the other settings. See the various news posts on his site for details.

  • 0
Posted

I knew that. Was just letting Kesta figure it out on his own. Haha!

 

He only says 1 is better because it fixes one or two places he found that the game crashes 100% of the time. If users run into that, they can turn it on for that part of the game and then turn it back off after.

  • 0
Posted (edited)

Actually, EnableUnsafeFixes is not related to DataSyncMode nor PriorityMode. 

The [Thread] section was introduced in the very first release of v303, then he added those fixes enabled by default in a ghost version (v303 from feb 22th), but due to some bugs reports, Boris removed it (all without changin versions).


 

Added


 

Removed


 

Then I requested (complained) to add it again (he have it removed because some users had problems scrolling the worldmap, but I didn't and that fix improved the stuttering a lot), so he added it again in v304 as a toggeable parameter

 

Added back


 

 

Edit: note to self, read the entire thread before posting

Edited by Hackfield

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

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