XCSV-REFACTOR-MISSION-001 — MISSION INTEGRATION REFACTOR
Parent: #29
Dependency: #30 inventory/wiring map
Primary source: Exile/LiveSource/mpmissions/Exile.Tanoa
Mode: BEHAVIOR-PRESERVING / SMALL SLICES / PACK / RUNTIME VERIFY
Goal
Turn the current mission integration surface into traceable modules without rewriting third-party gameplay.
Current mission source contains a large config.cpp, multiple vendor folders, XCSV functions, custom overrides, UI definitions, HC code, trader changes, and historical residue. The refactor must reduce collision risk while keeping the resulting PBO behavior equivalent.
Lane 1 — config.cpp decomposition
Inventory class boundaries and ownership before extraction.
Extract XCSV-owned/high-collision sections first into includes such as:
xcsv/config/CfgExileCustomCode.hpp
xcsv/config/CfgNetworkMessages.hpp
xcsv/config/CfgXM8.hpp
xcsv/config/CfgInteractionMenus.hpp
xcsv/config/CfgTrading.hpp
xcsv/config/RscTitles.hpp
Names are provisional; reuse existing structure if better.
Rules:
- no class is moved until include ordering/inheritance is understood
- no duplicate class definitions introduced
- preserve preprocessor semantics
- diff unpacked/packed output where possible
- runtime-test after each extraction slice
Lane 2 — custom-code override registry
Create a registry for every CfgExileCustomCode override:
- Exile function
- active file
- original upstream function/version/hash if recoverable
- features merged into replacement
- network/DB/persistence side effects
- tests
Highest concern: functions modified by multiple addons/scripts over time.
Lane 3 — bootstrap/init map
Map and refactor:
- init.sqf
- initServer.sqf
- initPlayerLocal.sqf
- preInit/postInit
- mission event handlers
- Exile thread tasks
- display/key handlers
- HC initialization
Target:
client XCSV bootstrap
server mission bootstrap
HC bootstrap
vendor adapters
Do not hide vendor initialization behind opaque magic. The bootstrap should make ordering/locality obvious.
Lane 4 — network registry
Enumerate CfgNetworkMessages and verify each handler resolves on its target locality.
Capture:
message
module
parameters
request/response pair
authority
handler source
security checks
caller
Detect stale handlers left behind by removed features.
Lane 5 — XM8 registry
For every app:
- appID
- button IDC
- slide/display IDs
- source function
- registration
- teardown
- network dependencies
- player runtime status
Preserve all existing XCSV XM8 app-switching/design-system fixes.
Lane 6 — trader/economy registry
Create one traceable location/index for:
- trader categories
- class listings
- XCSV price helper
- sell/buy contracts
- reputation gates
- drone/electronics category
Do not alter economy values merely as part of structural refactor.
Lane 7 — legacy/cold-path cleanup
Use wiring evidence from #30 to classify folders/files such as Scratchie/MarketByCyunide and any superseded app code.
Possible outcomes:
- still active → refactor/document
- disabled but intentionally retained → mark clearly
- reference only → move only if paths are not runtime-significant
- dead → removal candidate with rollback
Acceptance per slice
- mission packs
- config parses
- wiring audit passes
- PBO drift understood
- fresh server boot clean
- material client behavior runtime-tested
- no new RPT/extDB errors
- rollback hash/source recorded
- commit small enough to bisect
No giant mission-tree rename commit.
XCSV-REFACTOR-MISSION-001 — MISSION INTEGRATION REFACTOR
Parent: #29
Dependency: #30 inventory/wiring map
Primary source:
Exile/LiveSource/mpmissions/Exile.TanoaMode: BEHAVIOR-PRESERVING / SMALL SLICES / PACK / RUNTIME VERIFY
Goal
Turn the current mission integration surface into traceable modules without rewriting third-party gameplay.
Current mission source contains a large
config.cpp, multiple vendor folders, XCSV functions, custom overrides, UI definitions, HC code, trader changes, and historical residue. The refactor must reduce collision risk while keeping the resulting PBO behavior equivalent.Lane 1 — config.cpp decomposition
Inventory class boundaries and ownership before extraction.
Extract XCSV-owned/high-collision sections first into includes such as:
Names are provisional; reuse existing structure if better.
Rules:
Lane 2 — custom-code override registry
Create a registry for every
CfgExileCustomCodeoverride:Highest concern: functions modified by multiple addons/scripts over time.
Lane 3 — bootstrap/init map
Map and refactor:
Target:
Do not hide vendor initialization behind opaque magic. The bootstrap should make ordering/locality obvious.
Lane 4 — network registry
Enumerate
CfgNetworkMessagesand verify each handler resolves on its target locality.Capture:
Detect stale handlers left behind by removed features.
Lane 5 — XM8 registry
For every app:
Preserve all existing XCSV XM8 app-switching/design-system fixes.
Lane 6 — trader/economy registry
Create one traceable location/index for:
Do not alter economy values merely as part of structural refactor.
Lane 7 — legacy/cold-path cleanup
Use wiring evidence from #30 to classify folders/files such as Scratchie/MarketByCyunide and any superseded app code.
Possible outcomes:
Acceptance per slice
No giant mission-tree rename commit.