Changing settings based on other settings (and their values)

[BraveCaperCat]

I want to be able to change a setting based on the value of another setting, or at least disable+hide different settings based on the value of a setting, like a dropdown menu selected by another dropdown menu. This would be very useful, as it allows other mods to add other things to my mod which i am making, which enables different recipes based on a setting. I then use another setting to chose which of the new recipes to unlock in control.lua, which is all implemented in the library the mod creates (it also adds some examples)

[Rseding91]

This is technically not possible. Settings defined based off the value of settings is the definition of an infinite loop. Every time it would run it could get a different result.

So sorry, but this can never be done.

[A.Freeman]

When I found this post I thought "okay..." and then "wait a moment, that's not true" :D So I've been thinking of writing this post for a while.
Basically, I wanted to do 2 things: a) hide settings that weren't relevant while some others were disabled (also, using this mechanism you can show/hide sets of settings like expand/collapse sections); b) use settings presets (like easy/hard, or different progressions for some parameters).
The problem with possible loops isn't really a problem. Just forbid them D For example by using order field - a setting can affect another if its order is less than the order of an affected. In that case, if you processed all settings with order less than the current, it won't be changed/affected later.
How such mechanism can work or be implemented:

1. There will be a new field in settings "depends", that can contain one or more settings names. Their order must be striclty less than order of the current record.
2. There will be a mechanism to register a callback function (maybe another field "update" with function for a value). When called, callback can read all settings, but will be able to update only the record it was called for. Besides, it cannot change name, settings-type, order and depends fields (and callback). And it can be registered or replaced any time during settings stages, see *.
3. After settings-final-fixes, we iterate over all settings taking into account settings order. If setting has a registered callback, call it once. This paragraph might not be necessary as you can call callbacks directly during settings stages, see *.
4. When player changes an option, if there are dependent options with callbacks, add them to some sort of a collection (heap, ordered map), and process them in lexicographically increasing order. If a callback changes the option, and it has dependent option(s), add them to the collection to be processed.

• Because it's possible to change settings of other mods during settings stages, it should be possible for a mod to integrate options from several mods in one (or more) directed acyclic graph(s), so that mechanism can work on all mods at the same time and not be limited to one mod at a time. Basically, ui will use existing ordering for displaying purposes, but for settings dependencies the order field will be used globally.

So... Any thoughts?

[curiosity]

So... Any thoughts?

viewtopic.php?f=28&t=105003