Dynamic Mod Settings

WHY?

Let's say your mod adds damage number markers and healthbars.

You want to allow users to customise both features, but you don't want to show customisation options for the feature the user disabled.

So you add a checkbox/dropdown that says e.g. "Enable Healthbars", and control visibility of "Healthbars Customisation", based on the state of "Enable Healthbars".

INSTRUCTIONS

Here's an example of an implementation of hiding healthbar_customisation_group if enable_healthbars = false:

-- ../scripts/mods/my_mod/my_mod_data.lua

setting_id = "enable_healthbars",

type = "checkbox",

default_value = true,

setting_id = "healthbars_customisation_group",

type = "group",

sub_widgets = {

visibility_function = function ()

return mod:get("enable_healthbars") == true

The key part is visibility_function - a callback defined on the widget/widget group that returns true or false. If it evaluates to false, the widget/group will be hidden, if true, it will remain visible.

LIMITATIONS

-  I would not recommend overusing this feature. Hiding options is generally bad UX, especially with the unavoidable 'flash' when a selection changes.

- Will not work on top-level groups, only sub-groups (intentionally) and widgets

! Do not put compute-heavy logic into the callback

MOD LOAD ORDER

Alfs_DMF_Extensions -- optional, but must be above if it's a dependency

dynamic_settings

INSTALLATION

At the top of your main mod file:

--  ../scripts/mods/your_mod_name/your_mod_name.lua

local mod = get_mod("your_mod_name")

get_mod("dynamic_settings").enable(mod)Where your_mod_name is, well, your mod name.

That's it. Then follow instructions in the intro.

You don't need to add this mod as a dependency. You can copy the logic in this mod into your mod as a module, but then it's your responsibility to fix it if, for example, DMF changes how it builds widgets.