Fighting Game · Guides & deep dives

Mod Load Order Management

and BuildModLoadOrderViewModel

5sections2 minread
Markdown source
On this page

This document covers TODOS.phase-72.72.14.1.8: user-configurable mod load order, drag-and-drop reordering, and save/load presets for .mayamod packages.

Runtime Surface#

  • module: V2Modding
  • policy: FV2ModLoadOrderPolicy
  • entry: FV2ModLoadOrderEntry
  • issue: FV2ModLoadOrderIssue
  • preset: FV2ModLoadOrderPreset
  • move request: FV2ModLoadOrderMoveRequest
  • UI model: FV2ModLoadOrderViewModel
  • native screen: UV2ModLoadOrderScreen
  • result: FV2ModLoadOrderResult
  • helper functions: BuildDefaultModLoadOrderPolicy, EvaluateModLoadOrder, MoveModInLoadOrder, BuildModLoadOrderPreset, ApplyModLoadOrderPreset, and BuildModLoadOrderViewModel
  • automation: V2/ue/Source/V2Tests/Private/Modding/ModLoadingSystem.spec.cpp
  • contract: V2/ue/Content/V2/Modding/ModLoadOrderManagement_V2_Contract.json

Order Evaluation#

EvaluateModLoadOrder accepts an installed manifest set and an optional requested order. Empty requests fall back to the dependency-ordered load plan. Requested orders are normalized by removing repeated visible rows, preserving known custom order, and appending any missing installed mods deterministically.

The evaluator blocks unknown mod ids, duplicate requested ids, duplicate installed manifest ids, missing required dependencies, and dependency order violations. Required dependencies must appear before the mods that depend on them. Dependency-locked rows are surfaced in FV2ModLoadOrderEntry so UI can show which entries anchor other mods.

Reordering And Presets#

MoveModInLoadOrder models drag-and-drop movement with before-target, after-target, and absolute-index modes. Each move is immediately re-evaluated, so dependency-neutral mods can be moved freely while moves that would place a required dependency after its dependent mod return a blocking DependencyOrderViolation.

BuildModLoadOrderPreset and ApplyModLoadOrderPreset provide the save/load preset path. Applying a preset validates its id and ordered mod list, stores the active preset on the result, and exposes preset entries in the view model for UI pickers.

Load Order UI#

The default UI model targets the native /Script/V2UI.V2ModLoadOrderScreen screen and uses a cardless operational layout. The view model exposes ordered rows, presets, blocking issues, apply state, drag-and-drop support, save/load preset support, and a selected row index for keyboard/gamepad row movement.

The native screen validates the screen id and widget class path, stores the view model, exposes rows/presets/issues to Blueprint, and provides row selection for dense management surfaces.

Verification#

bash
python3 V2/ue/Tools/check-v2-mod-load-order-management.py
python3 V2/ue/Tools/check-v2-mod-dependency-resolution.py
python3 V2/ue/Tools/check-v2-mod-loading-system.py
python3 V2/ue/Tools/check-v2-ci-workflow.py
python3 V2/tools/validate-v2-docs.py
python3 -m py_compile V2/ue/Tools/check-v2-mod-load-order-management.py V2/ue/Tools/check-v2-mod-dependency-resolution.py V2/ue/Tools/check-v2-mod-loading-system.py V2/ue/Tools/check-v2-ci-workflow.py
python3 -m json.tool V2/ue/Content/V2/Modding/ModLoadOrderManagement_V2_Contract.json