How to Add Settings to a .ini

[LyTning94]

How do you add settings to the .ini, or even better create your own .ini that you can then add settings to? There are several mods that do this, so I know it's possible, I just need some pointers on where to start.

 

[LyTning94]

I did some research on my own and found that .ini settings can be read using the GetPrivateProfilexxx() functions in kernel32.dll. I searched the SDK for calls to these functions but could not find them.

Then I discovered the CvDLLIniParserIFaceBase.h file in the SDK, but this included only pure virtual functions which are (of course ) defined in the .exe, and never called in the SDK. I can see how Firaxis could read the game's INI from the EXE, but how do other mods (like BUG) add their own .ini's to the game if this is the case?

 

[LyTning94]

Okay, now I see that the .ini's are controlled by the corresponding XML files. Where do the XML files get read though?

 

[deepwater]

For XML files I would suggest

• CvXMLIFaceBase.h
• CvXMLUtility.h
• CvXMLLoadUtility.cpp
• CvXMLLoadUtilityGet.cpp
• CvXMLLoadUtilitySet.cpp and
• CvXMLLoadUtilityInit.cpp

 

[God-Emperor]

BUG does it all in Python, loading and parsing the its config files (which are XML) itself as well as ini files (which are in windows ini file format). The main file for it is BugOptions.py, but it imports various other Python files (it is also some 1500 lines of code that may be a tad difficult to understand). Extracting what you need from BUG may be difficult due to its size and complexity.

 

[Baldyr]

Perhaps the BUG modules can be used as-is? So you wouldn't have to extract anything from them, rather incorporate them in your mod. Or rather, use BUG as the basis of your mod and get the technical features you need built-in.

 

[LyTning94]

I'm already basing my mod off of BUG (RevDCM actually, but that includes BUG), so I hope to be able to use BUG's system.

From what I've gathered, I need to create my .ini and and my config .xml file. Then I'm assuming I have to add it to BUG's init.xml file in the "load mods" section. Is there anything else I need to do to get it read into python?

After it gets read by BugOptions.py, when and where does it get sent to the DLL? I'm finding lines in CvGlobals.cpp like

m_bDCM_BATTLE_EFFECTS = (getDefineINT("DCM_BATTLE_EFFECTS") > 0) ? true : false;

DCM_BATTLE_EFFECTS is included in RevDCM's XML config file

			<option id="DCM_BATTLE_EFFECTS" key="DCM_BATTLE_EFFECTS"
				type="boolean" default="False"
				get="isDCM_BATTLE_EFFECTS" set="setDCM_BATTLE_EFFECTS">
        <change module="RevDCM" function="changedDCM_BATTLE_EFFECTS"/>
      </option>

but I have no idea how the XML setting gets through python to the DLL?

 

[Baldyr]

You might wanna consider reading the BUG documentation, unless you already have. You'd end up saving time on trial-and-error.

 

[LyTning94]

Thanks for the suggestion, Baldyr. I wasn't even aware that BUG had a sourceforge tutorial devoted simply to modding with BUG. I've looked through a lot of it and it explains pretty much everything I wanted to know.

For now at least...

 

[God-Emperor]

A call in the DLL to getDefineINT is retrieving a value that was defined in GlobalDefines.xml or GlobalDefinesAlt.xml (as it is in this case).

These values can also be gotten and set via Python, as per the line

gc.setDefineINT("DCM_BATTLE_EFFECTS", RevDCMOpt.isDCM_BATTLE_EFFECTS())

that appears a couple of places in RevDCM.py, where the "RevDCMOpt.isDCM_BATTLE_EFFECTS()" function is defined by BUG and as per the RevDCM.xml as the function to retrieve the setting of the DCM_BATTLE_EFFECTS boolean option (not the defined int of the same name) - BUG creates this (and other) functions based on the <option ...> data in the config XML file.

This would be a little less confusing if the RevDCM BUG option did not have the exact same name as the XML value in GlobalDefinesAlt.xml.

 

[Baldyr]

These values can also be gotten and set via Python, as per the line

gc.setDefineINT("DCM_BATTLE_EFFECTS", RevDCMOpt.isDCM_BATTLE_EFFECTS())

Say what now?

 

[God-Emperor]

That's right, you can change all those defined settings via Python.

This could let you do some pretty weird things. Example: a magical future tech enabled project called "The Green Bomb Project" that causes nukes to no longer produce fallout, but produce forests instead (in the onProjectBuilt event handler, change the NUKE_FEATURE defined string value from FEATURE_FALLOUT to FEATURE_FOREST) - it would still kill people and such, but instead of an area of fallout you'd get an area of forest. Note: I have not actually tried this, but I see no reason why it wouldn't work.

There are a lot of these values and it isn't clear what effect changing some of them would have (probably bad in a lot of cases), but there are a bunch that could be interesting, or amusing, to change. The ability to change them is mostly useful for modder defined values rather than the base game's values. Note that they are global settings, not per-player.

 

[LyTning94]

A call in the DLL to getDefineINT is retrieving a value that was defined in GlobalDefines.xml or GlobalDefinesAlt.xml (as it is in this case).

These values can also be gotten and set via Python, as per the line

gc.setDefineINT("DCM_BATTLE_EFFECTS", RevDCMOpt.isDCM_BATTLE_EFFECTS())

that appears a couple of places in RevDCM.py, where the "RevDCMOpt.isDCM_BATTLE_EFFECTS()" function is defined by BUG and as per the RevDCM.xml as the function to retrieve the setting of the DCM_BATTLE_EFFECTS boolean option (not the defined int of the same name) - BUG creates this (and other) functions based on the <option ...> data in the config XML file.

This would be a little less confusing if the RevDCM BUG option did not have the exact same name as the XML value in GlobalDefinesAlt.xml.

Thanks for clearing this up. I had seen the value in the GlobalDefinesAlt file, but thought the two values were connected somehow. I guess I should have looked closer and seen getdefineINT() for one value and type="boolean" for the other.

Who came up with the idea to have two values of different types with the same name anyway? It reminds me of overloading functions .