Best practices with ini changes

[traenol]

From what I have been seeing, a lot of people are recommending changing values in the default files, as opposed to the files in the my games folder ... why?

E.G. DefaultGameData as opposed to XComGameData

 

Do the defaults override the customs, or mod changes for that matter?

[eXecator]

All ini changes I made so far have been XCom*.ini changes.

 

I'm not sure how simultaneous changes to Default and XCom files will work out, but I'm under the impression, that the XCom change will win. As I understand, thats what the XCom files are for in the first place, to modify the Defaults.

 

I have no Idea why anyone would want to edit the Default files. Is there a usecase for that?

[davidlallen]

The use case for changing the default*ini files is not "real modding". If I am a solo, non-modding player and I just want to give myself a thousand supplies, I can edit the default*.ini files to do it. Players who are making, or probably using mods, should never modify their game distributed files.

[Amineri]

Another tidbit about ini files and modding.

 

When using XCom*.ini files that will be merged, and when you've defined a new dynamic array, always be sure to preface each of your array config entries with a +. If you don't, each of your subsequent entries will delete the previous, and you will end up with a merged dynamic config array with only a single element -- the last one. As an alternative, you can directly specify the index, which makes the merger recognize them as different.

 

So, with a config variable defined like so:

var protected config array<float> TrainingDaysForRank; 

XCom*.ini config entries that work:

TrainingDaysForRank[0] = 0.0f
TrainingDaysForRank[1] = 8.0f
TrainingDaysForRank[2] = 8.0f
TrainingDaysForRank[3] = 8.0f
TrainingDaysForRank[4] = 8.0f
TrainingDaysForRank[5] = 16.0f

+TrainingDaysForRank = 0.0f
+TrainingDaysForRank = 8.0f
+TrainingDaysForRank = 8.0f
+TrainingDaysForRank = 8.0f
+TrainingDaysForRank = 8.0f
+TrainingDaysForRank = 16.0f

Example that DOES NOT WORK :

TrainingDaysForRank = 0.0f

TrainingDaysForRank = 8.0f

TrainingDaysForRank = 8.0f

TrainingDaysForRank = 8.0f

TrainingDaysForRank = 8.0f

TrainingDaysForRank = 16.0f

If you have a config entry like this in an XCom*.ini, you will end up in-game with an array with just a single element, value 16.0;

[davidlallen]

Can you comment on whether this syntax is supposed to work for arrays in localization files? At least myself and one other person have beaten our heads against this for hours, before deciding it just doesn't work. See here:

http://forums.nexusmods.com/index.php?/topic/3831180-how-to-debug-loading-not-loading-of-localization-file/

[mccordrm]

I absolutely do not mess with the Default files. I use them to fix errors, though.

Some Mods, and I've noticed with mine as well, will "perma-write" data into the XCOM Ini files, so that when you Unsubscribe from, or uncheck, a Mod it leaves behind some of it's changes. When this happens, I go into the:

\Documents\My Games\XCOM2\XComGame\Config directory and delete ALL the Ini files there. Then I start the game, uncheck every Mod, and then let the game load. This will rebuild the Ini files fresh and remove any errors. Trying that with the Default Ini files will only cause more errors trying to load the game.

Edited February 24, 2016 by mccordrm

[Zyxpsilon]

On every Patches/HotFixes/Updates (rare or not) by Firaxis... all of your default**.INI files would be re-written. Upon starting (or Loading saves) your very next gameplay, such newest Defaults would then proceed re-constructing the XCom**.INI structure and files with the latest details as well.

 

BUT -- that doesn't stop there, AFAIC.

 

Here comes the Steam-Launcher and its auto-validation steps to hook each and every MODs you have installed!

 

Guessing where i'm going with this? The data-flow battles are raging for priority calls and instructions that should affect such fresh values directly and transparently.

Thus... here comes the various Modders as well. I can already predict a rush phase of obligatory verifications towards every oblivious facts contained in as many custom files (INI included) as there is on the Workshop. (Oh -- the familiarity scans that LW_Betas kept offering to my huge Re-CLR mod and its hack jobs.) :wink: Parenthesis closed.

 

Welcome to the chaotic world on compatibility checks & balances, my friends!

 

Performance issues you say? Imagine the pains on these dreaded updating Day(s)... i'd rather think of it all as a gambling machine where everyone wins eventually.

 

What was the question again? :D

 

1) ((\\Documents\\Bla-Bla...)) XCOM*** == Modding assets. Dot. EOF.

 

2) ((Installed XCom2\\Bla...)) DEFAULTS == Local temporary gimmicks & (more importantly) Firaxis official ruleset devices and solidly protected control.

Edited February 24, 2016 by Zyxpsilon

[Amineri]

Can you comment on whether this syntax is supposed to work for arrays in localization files? At least myself and one other person have beaten our heads against this for hours, before deciding it just doesn't work. See here:

http://forums.nexusmods.com/index.php?/topic/3831180-how-to-debug-loading-not-loading-of-localization-file/

 

Localization files are really just a particular type of config file, according to Epic's documentation : https://udn.epicgames.com/Three/LocalizedTextFiles.html

 

I've used dynamic arrays in localization files, without any difficulties. There are also examples where Firaxis has done so. Since localized text files are really just config files the same rules for merging apply.

 

The main difference I've noted is that you can't break your localization text file into separate pieces like you can with config -- instead, it's always going to be based on your mod script package name, with the "XCom" prefix.

 

As an example, in the LWS Officer mod, in the class LWOfficerUtilities, I defined a localized dynamic array of strings as follows :

var protected localized array<string> LWOfficerRankNames;   

Because the mod name is LW_OfficerPack (with corresponding script package LW_OfficerPack.u), the localization text file MUST be named XComLW_OfficerPack.int -- or the various other file extensions for other languages.

 

Within the localization file, I set up the values using the "explicit indexing" method :

[LWOfficerUtilities]
;   there should be one name for each rank; e.g. Rookie, Squaddie, etc.
LWOfficerRankNames[0]=NCO
LWOfficerRankNames[1]=Fireteam Leader
LWOfficerRankNames[2]=Squad Leader
LWOfficerRankNames[3]=Section Leader 
LWOfficerRankNames[4]=Troop Leader
LWOfficerRankNames[5]=Field Commander

Note that the class name is put before the relevant localization values, but that the package name is NOT included (as is the case for config files, since multiple packages can read data from the same config).

[Amineri]

Going to post the information on configuration files from here again :

 

 

 

• + - Adds a line if that property doesn't exist yet (from a previous configuration file or earlier in the same configuration file).
• - - Removes a line (but it has to be an exact match).
• . - Adds a new property.
• ! - Removes a property; but you don't have to have an exact match, just the name of the property.

 

I think that if you don't include any prefix, the behavior seems to be "Add a line of that key value doesn't exist". Whereas the + prefix checks both key and value, so using + for dynamic arrays works as long as the value is different.

 

However, if attempting something like this :

 

+MyArray=5
+MyArray=5
+MyArray=5
+MyArray=5
+MyArray=5

The merging would match both the key and value, so the result would be an array with a single value of 5. To create an array with 5 identical values, you'd need to use :

 

.MyArray=5
.MyArray=5
.MyArray=5
.MyArray=5
.MyArray=5

This always adds the new line, even if both the key/value matches with a previous value in the config you are merging to.

[davidlallen]

 

 

the localization text file MUST be named XComLW_OfficerPack.int

 

#@^)(#*^)%(! And furthermore ^&)%$#%%^ and #@$%)*#$% they #@$)%$(#*%)(. !