DebugConfiguration (at a quick glance)

[ww2commander]

This is a kind of placeholder thread for things relating to the DebugConfiguration.sqlite file.

• The DebugConfiguration database controls all the mod settings and start options. This allows modders to tailor almost all aspects of game setup whether single or multiplayer.
• Mod options are control via RuleSets as you may have noticed the similarly labelled field when starting an advanced game.
• Within these RuleSets, the game knows what to change via the Parameters table which controls all the various options and drop-down fields. Each option is referenced as a Parameter and the list of values associated with a Parameter (i.e. Map Sizes, World Age) are referred as Domain items.
• The actual value for each Domain entry is set via the Key2 value.

Obviously this is a start and I hope others will contribute to this post. I will continue posting more info when I next get a chance.

 

[Gedemon]

Good idea, you'll find some example of use in the already released mods (including the scenarios in the game's installation folder)

There is 2 database know, there are tags in the modinfo file () to explicitly update one or the other (because for example there is a "Map" table in both, but with a very different content)

For example, from one of the scenario modinfo:

    <Components>
        <UpdateDatabase id="COLDWAR_COMPONENT">
            <Properties>
                <RuleSet>RULESET_SCENARIO_COLDWAR</RuleSet>
            </Properties>
            <Items>
                <File>ColdWarScenario_Victories.xml</File>
                <File>ColdWarScenario_Projects.xml</File>
                <File>ColdWarScenario_Units.xml</File>
                <File>ColdWarScenario_WMDs.xml</File>
                <File>ColdWarScenario_Eras.xml</File>
                <File>ColdWarScenario_GlobalParameters.xml</File>
                <File>ColdWarScenario_Policies.xml</File>
                <File>ColdWarScenario_Features.xml</File>
            </Items>
        </UpdateDatabase>
        <GameplayScripts id="COLDWAR_SCRIPT_COMPONENT">
            <Properties>
                <RuleSet>RULESET_SCENARIO_COLDWAR</RuleSet>
            </Properties>
            <Items>
                <File>ColdWarScenario_StartScript.lua</File>
            </Items>
        </GameplayScripts>
    </Components>
    <Settings>
        <Custom id="COLDWAR_SETTING">
            <Items>
                <File>ColdWarScenario_Config.xml</File>
            </Items>
        </Custom>
    </Settings>

the files listed in <UpdateDatabase> under <Components> will update the gameplay database, the file in <Custom> under <Settings> will update the configuration database

note the addition of a <GameplayScripts> tag that is working as intended, but it's another subject.

 

[ww2commander]

Developing a custom setup screen for YnAEM shouldn't be too hard now

note the addition of a <GameplayScripts> tag that is working as intended, but it's another subject.

This section, from what I can tell, is where you specify the actual game file changes.
GameplayScripts = game mechanic changes (i.e. XL, SQL, lua)
Settings = configuration file changes (the above db tables)

 

[Gedemon]

Developing a custom setup screen for YnAEM shouldn't be too hard now

Working on the UI was a nightmare for me on 5, I fear it will be worst on 6... That's one of the part where I'd love a friendly editor.

This section, from what I can tell, is where you specify the actual game file changes.
GameplayScripts = game mechanic changes (i.e. XL, SQL, lua)
Settings = configuration file changes (the above db tables)

not exaclty, it's <UpdateDatabase> for the gameplay "rules" using XML or SQL, <GameplayScripts> is for scripts (Lua only), ie in the first case you change the value of an unit ranged attack for example, in the second case you create a new gameplay feature.

and there is <UserInterface> for the UI (an XML file linked to a Lua file with the same name) attached to a context in game. For "gameplay scripts" in civ5 we used that with a blank or (none) XML file attached to the InGame context.