Cross Mod State Experiments

Cross-Mod Internal-State Persistence Experiments

Historical page: original version facts are retained. Current stable 4.0.0 supports targeted offline combination/state restoration; see Home and Preset guide. Universal live-state experiments are not re-enabled.

1. Research Goal

The manager was intended to remember clothing parts, colors, toggles, variants, and other internal options separately for each mod, then restore them when returning to that mod or applying a combined profile without requiring the user to repeat every in-game hotkey operation.

All research was performed on independent experimental branches created from the stable v3.8.0 baseline. The prototypes did not automatically replace the stable source, original library mods, or the real EFMI directory.

2. Key Technical Facts

Third-party mod state may be stored in several different places:

• .ini, .json, .cfg, or other state files inside the mod folder;
• the shared root-level EFMI d3dx_user.ini;
• numeric variables registered through global persist;
• state that exists only in memory while the game is running;
• state produced by hotkeys, command chains, post commands, or runtime calculations.

There is no universal per-mod serialization and restoration interface across these forms. A folder name also cannot reliably identify a variable namespace, registration time, or reload sequence.

3. Experiment Summary

Version	Approach	Observed result	Status
v3.8.1 Hot Injection Lab	Snapshot and replace the complete d3dx_user.ini, then request an F10 reload	Also overwrites other mods and loader state; F10 may write stale in-memory values back first	Unreleased; discontinued
v3.8.1 Persistent State Lab	Parse and merge scalar global persist values; separately test a temporary bridge INI and two manual F10 reloads	Handles only some numeric variables and cannot cover in-memory state, complex types, later command overrides, or loader-specific sequencing	Unreleased; discontinued
v3.8.2 EFMI Resident Lab	Generate resident controlled mod copies and gate profiles through $active_profile	Only supports standard structures with provable complete gating; arbitrary compatibility, resource usage, and real-game behavior cannot be guaranteed	Unreleased; not generally viable
v3.8.3–current directory junctions	Let the loader and library reference one physical mod directory	Works for configuration actually written inside the mod folder; does not cover root-level d3dx_user.ini or in-memory-only state	Released as an optional mode and retained in v3.9.0

4. v3.8.1 Hot Injection Lab

Implementation

1. Read the original bytes of the complete d3dx_user.ini.
2. Store each named snapshot with its file length and SHA-256 digest.
3. Back up the current file and restore through an atomic temporary-file replacement.
4. Request an EFMI/3DMigoto configuration reload through F10.

Why It Was Discontinued

• d3dx_user.ini is a shared user-state file for multiple mods and the loader, not an isolated save file for one mod.
• Restoring one snapshot also restores or overwrites the state of every mod captured at that time.
• Some EFMI/3DMigoto flows write current in-memory values to disk before reloading, overwriting the newly restored target values.
• F10 save and reload behavior is not identical across loader branches.

Whole-file hot replacement is therefore not a safe, isolated, or universal per-mod restoration method.

5. v3.8.1 Persistent State Lab

Implementation

• Scan enabled mod INIs and capture only valid scalar variables explicitly declared as global persist.
• Wait until the length and modification time of d3dx_user.ini remain stable before reading it.
• During offline restore, merge only target variables, preserve unrelated state, verify every value, and then start XXMI.
• During runtime restore, create a marker-protected temporary bridge INI, require two manual F10 reloads, remove the bridge, and verify the result.

Why It Was Discontinued

• State that is never written to disk cannot be captured.
• Strings, vectors, commands, and runtime expressions cannot be handled universally.
• Later post commands may overwrite restored values again.
• Correctness depends on namespaces, registration order, load order, and loader-branch behavior.
• The two-F10 bridge requires user interaction and still cannot guarantee arbitrary third-party compatibility.

6. v3.8.2 EFMI Resident Lab

Implementation

• Scan every mod referenced by multiple desktop profiles.
• Recognize $mod_enabled, $object_detected, and registration commands in standard EFMI Tools structures.
• Generate controlled copies without modifying original library mods.
• Gate standard runtime conditions and hotkey entries through a controller.
• Use global persist $active_profile and an EFMI [Key] type = cycle controller to switch profiles in game.

Validation That Remained Incomplete

• Arbitrary handwritten or legacy INIs cannot prove that every TextureOverride, ShaderOverride, and command entry is fully gated.
• VRAM, memory, frame-rate, and conflict behavior with several complete resident mods was not sufficiently verified.
• Broad real-game validation and failure rollback were not completed.
• Generated copies introduce additional synchronization work after an original mod is updated.

7. Currently Supported v3.9.0 Approach

Directory junctions solve the deep-copy deployment problem: the junction in the target Mods folder and the library mod refer to one physical directory. When the loader writes configuration inside that mod folder, it modifies the library files directly.

What It Can Preserve

• .ini, .json, .cfg, and other files actually written inside the mod's own directory;
• state files that remain in the original library mod after switching;
• safe replacement of the previous managed junction when linking another mod for the same character.

What It Cannot Guarantee

• global persist state stored in EFMI's root-level d3dx_user.ini;
• temporary state that exists only in game-process memory;
• hotkey, command-chain, or runtime-calculation results that are never written inside the mod folder;
• restoration of arbitrary third-party internal variables.

8. Safety Boundary

The released v3.9.0 application:

• does not read or write game-process memory;
• does not inject DLLs;
• does not automatically simulate F10 or other game keys;
• does not bypass anti-cheat systems;
• does not package the v3.8.1/v3.8.2 prototypes as usable features;
• removes only a junction reparse point and never recursively deletes its library target.

XXMI/EFMI and third-party mods remain third-party game-modification environments. This project cannot promise zero account risk; users must follow the rules of the game, platform, and mod authors.

9. Final Conclusion

Universal, automatic, and reliable persistence of internal $variables across arbitrary third-party XXMI / EFMI mods is temporarily infeasible.

The feature should only be reconsidered after the upstream environment provides a stable per-mod state serialization interface, reliable mod identity and namespace mapping, documented runtime reload ordering, and isolated transactional restoration with rollback.

10. Related Links

• Wiki Home
• Experiment Archive
• 中文报告
• v3.9.0 Release
• Complete source conclusion document
• CHANGELOG