Zima - Deterministic mod integration & patching system.

Zima works seamlessly with Hytalor when in the same pack!

Zima is a deterministic mod integration & patching system.
It lets mods safely modify game assets without overwriting each other or breaking load order.

Instead of replacing files, mods declare “intents” describing exactly what they want to change. Zima then applies those changes in a predictable, conflict-aware way.

Documentation:  Check Out the Github

Core Behaviour

Predictable Load Order

Zima decides which changes run first using clear rules:

1. Dependency rules (dependsOn, loadAfter, loadBefore)

2. Mod role (core, content, tweak, compat)

3. Priority value

4. Mod ID (as final tie-breaker)

This means results are stable and reproducible.

Asset Changes

Mods don’t replace entire assets.
They specify targeted operations like:

set → change a specific value

removePath → delete a field or property

mergeObject → combine data without destroying existing values

For arrays (lists), Zima supports:

Add / remove elements

Insert before / after

Replace or merge entries

Upsert (update if present, add if missing)

Intents

An intent can modify:

A single asset

Many assets via patterns (*, **, etc.)

Specific elements inside arrays

Filtered matches (e.g., entry with id="foo")

This avoids brittle hardcoding.

Conflict Detection

If two mods try to change the same exact data path, Zima can:

Deny the change

Merge safely

Require explicit overrides

No silent corruption.

Validation & Safety

Zima rejects invalid specs at load time with clear diagnostics.

It also supports:

Assertions / requirement checks

Strict schema enforcement

Versioned compatibility guarantees

No Double-Apply Issues

Zima does not read Server/Patch, preventing duplicate modifications when combined with other patch systems.

How Mods Use Zima

Mods place specs inside their asset pack:

intent files → describe desired changes only

Compatibility Promise

Zima uses a strict versioned schema:

zima.integrate.v1

Minor updates stay backward-compatible.
Breaking behaviour always requires a new schema version.