GUIDE Guide:Skyrim Configuration Settings

[Octopuss]

Discussion thread:
Guide:Skyrim Configuration Settings by STEP
Wiki Link

---

This thread is for discussion and improvement of Skyrim Configuration Settings Guide on the wiki.
 
 
 
OP:

That page lists some extra tweaks not present in the guide. Which one of them is up to date?

[TechAngel85]

Those are the tweaks we took out of the Guide. You can still use them, but we felt many didn't fit into our vision or could cause more issues so they were removed and put into an auxiliary guide.

[DoubleYou]

I would like this guide to be renamed. How about...

Skyrim Configuration Settings Guide

[z929669]

No need to rename it if there is a way to smoothly incorporate this information into the new INI guides you are making. Ideally, we should have a detailed guide from which we extract information for the STEP Guide, rather than your new and highly detailed guides as well as the existing detailed guide, which I am thinking will be effectively redundant once the new ones are complete. Then we can just delete it.

 

If it is not interfering with your current work, we can just leave it until you are finished with your guides. Then I will figure out a way to merge everything and delete this guide.

[DoubleYou]

No need to rename it if there is a way to smoothly incorporate this information into the new INI guides you are making. Ideally, we should have a detailed guide from which we extract information for the STEP Guide, rather than your new and highly detailed guides as well as the existing detailed guide, which I am thinking will be effectively redundant once the new ones are complete. Then we can just delete it.

 

If it is not interfering with your current work, we can just leave it until you are finished with your guides. Then I will figure out a way to merge everything and delete this guide.

I disagree. We need a portal to talk about tweaks as a whole, and I was thinking of turning it into a guide for the effective use of the configuration settings.

 

 

Guide Scope

This guide is intended to be a general guide to the configuration settings for The Elder Scrolls V: Skyrim game as set through INI files, including Skyrim.ini, SkyrimPrefs.ini, Plugin INIs, and MO INI Tweaks. Its purpose is geared toward how these will affect the game rather than being a comprehensive resource. See the advanced Skyrim INI and SkyrimPrefs INI guides for an advanced and comprehensive review of the configuration settings.

[z929669]

OK, I see what you are doing on your User page, but why replicate there? Just edit the Skyrim INIs guide itself (it will not break anything unless you mess up the transclusion tag references for the STEP Guide).

 

Then I am fine with renaming it to "Skyrim Configuration Guide" (with redirect)

[DoubleYou]

-Name changed to Skyrim Configuration Settings Guide

-Added Under Construction warning

-Added Nomenclature

-Added Under the Hood

-Added The Prefixes

-Added Changing Settings In-Game

-Renamed INI Tweaks to Recommended Changes

-Standardized Comments inside Recommended Changes

[Spock]

I would highly recommend against increasing the grass draw distance without increasing ugrids. The reason is that you get more popping on cell transitions, it is imho one of the few very well tweaked ini setting by bethesda.

 

The maximum value for object and item fade without popping at ugrids 5 is 10.5 btw :)

Personally I use 10 for items because I don't want daggers to fade in at the same time rocks do.

 

You can also try fTreesMidLODSwitchDist=14000, it is a trade off which eases popping a little but makes trees switch to full foliage as you close in on them (still as far away as possible).

Edited May 30, 2015 by Spock

[DoubleYou]

Some INI facts to chew on that I've added to this guide:

 

INI syntax

The INI files follow this basic format:

[Section]setting=value

There are some rules about this structure that must be observed generally and specifically.

General rules

• Spaces are ignored before and after [sections], settings, values, equal signs (=), and square brackets ([ and ]). That means that setting=value will do the same as setting = value .
• A setting cannot accept a value that is on a new line. That means that the following value will not be used:

setting=value

• Comments do not exist, yet they do exist, because they do not exist. In essence, a comment is read as a setting that merely does not exist, and therefore does not affect anything, allowing it to exist. Comments should only be placed on a line that does not contain a setting, lest it be mistaken for a value of a setting.

[section] rules

• [section] names are case insensitive. That means that [Display] and [display] will be read as the same.
• There may only be one [section]. Duplicate sections will not be used in any case. If more than one section exists, only the first one will be used. This means that if [Grass] exists at the top of the INI, and another [Grass] exists at the bottom of the INI, only the top section will be used, even if the second section contains settings not listed in the top section.

Setting rules

Setting names are case insensitive. That means that iPresentInterval and ipresentinterval will be read as the same.

• There may only be one setting. Duplicate settings will not be used in any case. If more than one setting exists, only the first one will be used. This means that if iPresentInterval exists at the top of [Display], and another iPresentInterval exists at the bottom of [Display], only the top setting will be used, even if the first setting is blank.
• The setting's name is defined as all characters between the start of the line and the equal sign (=) underneath a [section].

The prefixes

Each setting has a lowercase prefix and a name. The name identifies what the setting modifies. The prefix determines what kind of value the setting can accept. Below is a list of the different prefixes and their meanings.

• b-prefix settings accept a Boolean value of 1 (true) or 0 (false).
• f-prefix settings accept a floating point numeral value (any rational number, positive or negative, with or without a decimal, such as 5, 0, or -38.0003). Some default values for these settings can only be estimated with decimal numerals (think Ï€). Floating point values may use exponential (e) notation. In exponential notation, the number before the e is multiplied by 10 to the power of the integer after the e (e.g., 1e7 equals 1 with 7 zeros after it, i.e., 1,0000,000 and 1e-7 equals 1 with 7 zeros before the decimal point, i.e., .00000001).
• i-prefix settings accept an integer value (any whole number, positive or negative, without a decimal point, such as 5, -38, or 0). Integers are limited between -2147483648 and 2147483648 (2 x 1024 x 1024 x 1024).
• r-prefix (including some s-prefix) settings accept a color value in RGB (e.g. 93,216,234) or possibly even RGBA (e.g. 93,216,234,1) format.
• s-prefix (also str) settings accept a string value (usually text, but may contain numbers, punctuation--anything really).
• u-prefix (also ui) settings accept an unsigned integer value (any whole number, only positive or 0, without a decimal point, such as 5, 38, or 0). Unsigned integers are generally limited between 0 and 2147483648 (2 x 1024 x 1024 x 1024), however some may incorrectly recognize negative values.

Value rules

• The value is defined as all characters between the equal sign (=) and the end of the line within 255 characters prior to the first character that the setting will not accept.
• A setting will accept whatever value is given it, but will stop accepting that value if it goes outside the range which that setting is allowed to accept, determined by the type of setting it is defined as per its prefix (e.g., iPresentInterval=1;disable is read as iPresentInterval=1 and sIntroSequence=BGS_LOGO.BIK;disable is read as sIntroSequence=BGS_LOGO.BIK;disable).
• If a setting has a blank value in the INI, the default value will be used instead of a blank value except for string settings (those with an s-prefix), where setting it blank will cause the string value also to be blank.

[DoubleYou]

Revised Recommended changes section to follow a better format that will allow more INI tweaks to be added easily and prevent possible errors.

[z929669]

Comments are valid in any INI and any position as long as you begin the comment with a semicolon. It can be on the same line as an INI setting itself without issue.

 

INIs are case INsensitive, yes, but suggest using camel case for readability and consistency.

[DoubleYou]

Wrong. You may not put a comment after a string setting, as it will be considered part of the string. This can be proven via the example I have provided.

 

What is camel case?

[z929669]

Wrong. You may not put a comment after a string setting, as it will be considered part of the string. This can be proven via the example I have provided.

 

What is camel case?

Google "camel case"

 

What example? I have placed comments like this just after many settings in my INIs without issue:

iPresentInterval=0   ; this controls blah, blah

... affects only string settings? Like the archive setting? Maybe that is why I never noticed?

[DoubleYou]

Google "camel case"

 

What example? I have placed comments like this just after many settings in my INIs without issue:

iPresentInterval=0   ; this controls blah, blah

... affects only string settings? Like the archive setting? Maybe that is why I never noticed?

 

sJustGoogledCamelCaseAndGotIt=true

 

See here:

https://wiki.step-project.com/Guide:Skyrim_Configuration_Settings#Value_rules

 

Comments don't exist in the Skyrim INI files... there is no parser that removes things after the semicolon. They only exist because the following statement is true:

 

A setting will accept whatever value is given it, but will stop accepting that value if it goes outside the range which that setting is allowed to accept, determined by the type of setting it is defined as per its prefix (e.g.,

iPresentInterval=1;disable

is read as

iPresentInterval=1

and

sIntroSequence=BGS_LOGO.BIK;disable

is read as

sIntroSequence=BGS_LOGO.BIK;disable

).

 

Comments in INIs that are on the same line will cause Wrye Bash to throw errors at times, as well as Mod Organizer's Configurator.

[Greg]

I think you're mostly right, but there appears to be something that is causing the GetPrivateProfile* functions from reading lines that begin with a semicolon. To put this into concrete terms, I created a sample.ini file with these settings:

[General]
Test1=Test Value 1
;Test2=Test Value 2
*Test3=Test Value 3 ; comment

 Using the GetPrivateProfileString API function, I can read Test1 and *Test3, but GetPrivateProfileString always returns null for ;Test2 as if that entry doesn't exist.

 

I do get "Value 3 ; comment" when I read *Test3.

 

EDIT: I think the reason that comments seem to work on numeric values is mostly because the C++ library functions stop parsing when it finds a non-numeric value.