How to figure out hidden fields in an .ini file?

Question

I'm not sure if this is the right place to ask this, but I can't think of anywhere else that would fit better.

Fallout 4 has just recently released, and I'm wondering what exactly can I edit in the ini. I know you can add certain things that aren't already present in the ini. For example, to change the FOV:

[Display]
fDefaultWorldFOV=100
fDefault1stPersonFOV=100

However, how do I figure out what other 'hidden' fields are? In Skyrim, for example, you can change the camera like this:

[Camera]
fOverShoulderAddY=0.0000
fOverShoulderPosZ=10.0000
fOverShoulderPosX=0.0000
fOverShoulderCombatAddY=0.0000
fOverShoulderCombatPosZ=10.0000
fOverShoulderCombatPosX=0.0000

Surely it's not just trial and error?

Answer 1

Like most reverse-engineering tasks, there isn't necessarily a fool-proof method of accomplishing this.

• In some cases the existence of these features "leak" via customer support (or developer) interactions because they exist to support diagnostics or debugging.

• In some cases, they are discovered through to references in the documentation for modding tools or as references within scripts that can be read with said modding tools.

• Sometimes users can simply guess at their existence based on the fact that a game shares a common engineering lineage with another game that is better understood (Fallout 4, for example, is pretty obviously an iteration of the Skyrim tech).

• Tools like strings can be used to scan a file, such as an .exe, for bits of data that look like text. This is a fairly reasonable, simple way to poke around for hidden .ini settings or command-line arguments, assuming the engine parses them in a straightforward and obvious fashion. Such an approach will general involve a sequence of string comparisons against hard-coded options (like fOverShoulderCombatAddY from your example) and will often show up by running strings. Looking at the text found around known settings may provide some clues about undocumented settings.

The last one is probably the approach you'd take if you were starting from "scratch" trying to dig up any undocumented options. It's not a guaranteed win by any stretch, but it's a nice balance of simplicity and effectiveness that makes a good starting place.