Skip to content

[XCSV-REFACTOR-MISSION-001] Exile.Tanoa config/bootstrap/network/XM8 integration refactor #32

Description

@x-cessive

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions