Is there any way for the data stage to effect the settings stage?

[Mernom]

I want to modify my setting's localised description, to show certain values that will be useful for the player to define their settings (since the effect depends on the length of the longest technology dependency chain).
But the data.raw table is not accessible, and the setting itself only provides the value during the data stage, and no global variables are shared between them. Is there nothing I can do for this?

[Rseding91]

No. The reason is: Data stage is defined based off the values of the settings stage. If the settings stage could be defined based off the values of the data stage it would be an infinite loop.

[darkfrei]

No. The reason is: Data stage is defined based off the values of the settings stage. If the settings stage could be defined based off the values of the data stage it would be an infinite loop.

Must be something like (but never will be implemented)
data-pre-settings
settings
data
data-updates
data-final-fixes?

[KiwiHawk]

No. The reason is: Data stage is defined based off the values of the settings stage. If the settings stage could be defined based off the values of the data stage it would be an infinite loop.

This makes sense for startup settings. Not so much for map and player settings. Ideal would be if map and player settings could be modified in data stage. No need for new stages!

[ickputzdirwech]

On a related note: I would really like to be able to conditionally create runtime settings based on the value of a startup setting.

My use case is a startup setting that enables a feature and multiple runtime settings to “fine tune” it. It really makes no sense having the runtime settings available if the startup setting is disabled but afaik there is now way around it at the moment.

And just wanted to add that there is already settings-updates and settings-final-fixes. Incase you want to modify the settings of another mod.

[KiwiHawk]

On a related note: I would really like to be able to conditionally create runtime settings based on the value of a startup setting.

Map and player settings being modifiable in data stage would allow this.

[darkfrei]

My question was: Why we have data.raw? I mean, why not just data? And why not settings.raw or data.settings?

[Pi-C]

My question was: Why we have data.raw? I mean, why not just data? And why not settings.raw or data.settings?

Code: Select all

for k, v in pairs(data) do
        log("k: "..k.."\tv: "..tostring(v))
end

will show:

Code: Select all

k: raw	v: table
k: is_demo	v: false
k: extend	v: function

[robot256]

On a related note: I would really like to be able to conditionally create runtime settings based on the value of a startup setting.

Not saying it won't work, just a thought. Procedurally generated setting names means having to detect what settings exist at runtime. It also means that if you change mods and load the game when that setting isn't created, it will be deleted from the settings file. When you change back and it is created again, you will have to set it again (unless you are loading a save file). For this reason, I try to set hidden=true rather than not create a setting at all, when the names are constant. It also avoids crashing code (often in other mods) that expects a particular setting to exist.

[Mernom]

For my purposes, I only need the setting's `localised_name` and/or `localised_description` to be accessible during data.