The directory was misnamed — these are wsid-triggered sorting-rule
overlays, not modpack-specific. HellDrinx happens to be a modpack but
RV Interior Expansion isn't; both use the same generic mechanism.
Renames:
data/modpack_rules/ → data/rules/
_MODPACK_RULES_* → _RULES_*
_modpack_rules_for → _auto_rules_for
_parse_rules_with_modpacks → _parse_rules_combined
_emit_modpack_rules_warnings → _emit_rules_applied_warnings
warning tag "modpack-rules-applied" → "rules-applied"
Bug fix: /api/resort was passing {} rules to sort_mods, silently
dropping every auto-injected rule. The frontend runs an automatic
resort after each /api/sort (driven by localStorage branchSelections),
so the user always saw the resort output — where rv_expansion.txt's
loadAfter chain wasn't taking effect. Now resort goes through
_parse_rules_combined and emits rules-applied warnings the same way
/api/sort does.
20 lines
830 B
Plaintext
20 lines
830 B
Plaintext
; RV Interior Expansion (B42) — sorting rules
|
|
; Triggers:
|
|
; - 3618427553 (RVInteriorExpansion, map folder rvupdate)
|
|
; - 3622163276 (RVInteriorExpansionPart2, map folder rv2)
|
|
; Auto-injected by app.py:_auto_rules_for() when either trigger wsid is
|
|
; in the user's input. User-supplied rules are appended afterward and
|
|
; override these on conflicting keys.
|
|
;
|
|
; Authored ordering: PROJECTRVInterior42 → RVInteriorExpansion → RVInteriorExpansionPart2.
|
|
; The expansion mods don't declare these loadAfter relationships in their own
|
|
; mod.info, so without these rules sortof has nothing to base the cluster
|
|
; ordering on (PROJECTRVInterior42 is in PREORDER slot 7 already; expansions
|
|
; just need to chain off of it).
|
|
|
|
[RVInteriorExpansion]
|
|
loadAfter=PROJECTRVInterior42
|
|
|
|
[RVInteriorExpansionPart2]
|
|
loadAfter=RVInteriorExpansion
|