pub struct ModConfig {
pub name: String,
pub author: Option<String>,
pub license: Option<String>,
pub description: Option<String>,
pub version: Option<String>,
pub rules: Vec<RedirectionRule>,
pub parameters: Vec<ModParameter>,
pub configuration: HashMap<String, Value>,
pub ui: Option<ModUi>,
}Expand description
The on-disk shape of a single mod’s mod.json: metadata, the mod’s
authored (possibly conditional/templated) rules, the parameters it
exposes for configuration, and default values for some or all of them.
Holds no per-user values, though, those live separately in
crate::mods_state::ModConfigurations, keyed by mod directory name, layered on top of
these defaults at resolution time (see
ModConfig::effective_configuration). That split means re-installing
or updating a mod (replacing this whole file, defaults included) can
never take a person’s own overrides for it along with it.
This is distinct from crate::hook_config::HookConfig, which is the merged, resolved
shape the proxy DLL actually consumes, see ModConfig::resolved_rules
for how one becomes the other, given a mod’s current overrides.
Fields§
§name: StringMandatory, also what’s shown in the launcher’s mod list.
license: Option<String>§description: Option<String>§version: Option<String>§rules: Vec<RedirectionRule>§parameters: Vec<ModParameter>§configuration: HashMap<String, Value>Default value for some or all of parameters, keyed by
ModParameter::id. A parameter with no entry here, and no
override in crate::mods_state::ModConfigurations, reads as fully unset: off for
gating, empty string for ${param_id} interpolation. Author-owned
and distributed alongside rules, unlike the per-user overrides
in crate::mods_state::ModConfigurations.
ui: Option<ModUi>Optional launcher-UI schema, buttons shown for this mod and the
popups they open, rendered generically by the Mods page (see
crate::ui::ModUi). None for mods without a ui section:
they keep the plain parameter editor only, and every pre-ui
mod.json stays fully valid unchanged.
Implementations§
Source§impl ModConfig
impl ModConfig
Sourcepub fn load_from_path(path: &Path) -> Result<Self, HookConfigError>
pub fn load_from_path(path: &Path) -> Result<Self, HookConfigError>
Loads a ModConfig from a single JSON file on disk (one mod’s
mod.json).
§Errors
Returns an error if the file cannot be read or does not contain valid JSON matching the expected shape.
Sourcepub fn load_from_path_with_warnings(
path: &Path,
) -> Result<(Self, Vec<String>), HookConfigError>
pub fn load_from_path_with_warnings( path: &Path, ) -> Result<(Self, Vec<String>), HookConfigError>
Like Self::load_from_path, but also returns warnings about
unknown keys in the JSON file. Keys prefixed with _ are
considered intentional private metadata and are never warned about.
Unknown keys at any nesting level are reported with their path
(e.g. "unknown key 'future_field' at parameters[1]").
Sourcepub fn write_to_path(&self, path: &Path) -> Result<(), HookConfigError>
pub fn write_to_path(&self, path: &Path) -> Result<(), HookConfigError>
Serializes and writes this ModConfig to a JSON file on disk,
creating parent directories as needed.
§Errors
Returns an error if parent directories can’t be created, the file can’t be written, or serialization fails.
Sourcepub fn validate(&self) -> Result<(), Vec<String>>
pub fn validate(&self) -> Result<(), Vec<String>>
Structural validation of the whole mod: mandatory name, each
parameter’s own validity (see ModParameter::validate), and
every rule’s enable_if (if any), evaluated as Rhai expressions.
§Errors
Returns every problem found (not just the first), so a mod author or the launcher’s error display for a broken mod, can see the whole picture at once.
Sourcepub fn effective_configuration(
&self,
overrides: &HashMap<String, Value>,
) -> HashMap<String, Value>
pub fn effective_configuration( &self, overrides: &HashMap<String, Value>, ) -> HashMap<String, Value>
This mod’s parameter values for resolution purposes: its own
configuration defaults, with overrides (typically a person’s
entry from crate::mods_state::ModConfigurations) layered on top,
then any parameter whose enable_if evaluates to false is forced
back to its default value (from self.configuration) or the
type-appropriate zero value if no default exists. This ensures
disabled parameters never retain stale overrides that could affect
other parameters’ enable_if evaluations or rule interpolation.
Parameters are resolved in dependency order (parameters with no
enable_if or whose dependencies are already resolved first), so
a chain like A→B→C correctly cascades: if A is disabled, B sees
A’s default, which may disable B, which then also falls back.
Sourcepub fn resolved_rules(
&self,
overrides: &HashMap<String, Value>,
) -> Vec<RedirectionRule>
pub fn resolved_rules( &self, overrides: &HashMap<String, Value>, ) -> Vec<RedirectionRule>
The rules the DLL should actually apply for this mod, given
overrides (see Self::effective_configuration): rules gated
off by their enable_if are dropped outright; within a surviving
rule, individual replacements inside patches are also gated by
their own enable_if the same way, independent of the rule’s own
gating (a rule can be unconditional while only some of its
replacements are conditional, see the “Fast_Start” example this
was built for). Every surviving rule and replacement’s ${param_id}
placeholders (in glob_pattern, target, and any
MemoryPatch::ReplaceString find/replace text) are interpolated
via Rhai’s native string interpolation. MemoryPatch::ReplaceBytes
text is never interpolated, its find/replace are raw bytes,
not text, so there’s no placeholder syntax to look for, but it’s
still gated by its own enable_if.
By the time a rule leaves this function there’s no templating or
conditionality left in it at all, this is the shape
crate::hook_config::HookConfig::load_from_mods_dir merges across mods, and the
shape the proxy DLL consumes.