Use LMM Mod Options as the config fallback when ConfigurationManager is absent

[CTristan]

Summary

LMM 1.3.9 ships a built-in mod-options system: mods declare <Option> nodes in their Info.xml (Type = Toggle → bool or Slider → float, plus Name and DefValue); LMM stores values centrally in Application.persistentDataPath/LobotomyBaseMod/ModOptionData.dat (keyed by mod id) and renders the controls in its own mod list. It is always available under LMM, with no extra install.

Separately, ConfigurationManager (a fork of BepInEx.ConfigurationManager) provides a richer, code-first config via Common's ModConfig/IConfigEntry — any value type, AcceptableValueRange, sliders, sections, enum value names, localized labels — surfaced through an F1 settings window. Today, when ConfigurationManager is not installed, a mod falls back to in-memory defaults and the player cannot change anything.

Proposed direction

Make LMM Mod Options the fallback config surface. Precedence:

1. ConfigurationManager installed → its rich F1 window (unchanged).
2. ConfigurationManager absent, LMM present → expose the toggle/slider-compatible bound entries through LMM's native Mod Options UI and storage, instead of static defaults.
3. Neither → in-memory defaults (unchanged).

This gives players a way to change the simple options of any config-using mod even without ConfigurationManager.

Where this lives

The implementation is in the shared config stack — LobotomyCorporation.Mods.Common (ModConfig/IConfigEntry), the ConfigurationManager Integration source generator, and/or ConfigurationManager itself. Consuming mods (e.g. Bad Luck Protection for Gifts) are the motivating users.

Open questions (resolve at implementation time)

• Home: Common's ModConfig, the Integration source generator, or ConfigurationManager?
• Type mapping: LMM exposes only Toggle (bool) and Slider (float), and its <Option> schema parses only Type/Name/DefValue — no min/max/step. Map bool → Toggle and float → Slider; decide how to handle int, enum, string, and range/step metadata LMM cannot express (degrade vs omit from the fallback UI).
• Single source of truth: does the Integration generator emit <Option> nodes into Info.xml at build time, or register them at runtime? Avoid value drift between ModOptionData.dat and ConfigurationManager's own config file.
• Sync/precedence when both ConfigurationManager and LMM Mod Options hold a value for the same key.

Motivating example

Bad Luck Protection for Gifts binds an enum (calculation mode), an int (0–3 decimal places), two bools, and five float sliders (0–100%). Its GlobalInfo.xml declares no <Option> nodes, so without ConfigurationManager it runs entirely on defaults.

Acceptance criteria

• With ConfigurationManager absent but LMM present, a config-using mod exposes its toggle/slider-compatible options through LMM's Mod Options UI, and changes persist.
• ConfigurationManager-installed behavior is unchanged (its UI wins).
• Mapping/degradation rules for non-toggle/slider types are documented.
• A documented precedence resolves values when both stores exist (no double source of truth).