pub struct ModsState {
pub active: ModsPreset,
pub presets: HashMap<String, ModsPreset>,
}Expand description
The full persisted state of a game’s mods directory: the currently- active configuration, and any named presets saved for later.
No launcher UI surfaces presets yet, the field exists so the format
doesn’t need to change again once that lands.
Fields§
§active: ModsPresetThe live, currently-applied configuration, what the game actually
uses, and what the launcher’s Mods page displays and edits
directly. See ModsPreset for its shape.
presets: HashMap<String, ModsPreset>Named presets a person has saved, keyed by preset name. Applying
one (ModsState::apply_preset) replaces active wholesale.
Implementations§
Source§impl ModsState
impl ModsState
Sourcepub fn sync_active_order<I, S>(&mut self, discovered: I)
pub fn sync_active_order<I, S>(&mut self, discovered: I)
Reconciles ModsState::active’s order against discovered, see
ModsPreset::sync_order. A thin forward to the active
configuration specifically; a saved-but-inactive preset in
presets is never touched by this, since its order should stay
frozen exactly as saved until it’s applied.
Sourcepub fn apply_preset(&mut self, preset: &ModsPreset)
pub fn apply_preset(&mut self, preset: &ModsPreset)
Applies a saved preset as the new active configuration: active
becomes an exact copy of preset, same order, enabled, and
configuration. This can drop locally-installed mods the preset
doesn’t mention from active.order entirely; they aren’t lost,
they’re just no longer part of this configuration until the next
ModsState::sync_active_order call (part of every
discover_mods scan) re-appends every installed mod not already
present, so the launcher’s list still shows every installed mod,
the preset’s own mods first, in the preset’s order, then everything
else appended after.
presets itself is untouched, applying a preset doesn’t consume
or modify it, so it can be applied again later.