Apothicon plans and runs the installed BO3 toolchain. Build previews expose commands, working directories, prerequisites and expected outputs. Native execution requires the local build setting and the call’s explicit execution argument.
Inspect the installation
Begin with installation_doctor. It checks tool executables, source directories and build prerequisites. Having every executable present is different from build readiness: a fresh installation may still need its GDT database generated.
Avoid running an Apothicon build and a separate Launcher build against the same installation at the same time. Apothicon coordinates its own jobs; it cannot coordinate a process started independently in the official Launcher.
Find and inspect assets
rebuild_asset_index catalogs local scripts, maps, prefabs, zone sources, GDT entries and common asset-source files. search_assets returns names with paths and source lines. Indexing does not modify those source files.
Use inspect_gdt, inspect_zone and check_dependencies before changing references. More detailed tools include gdt_check, gdt_refs, zone_explain and zone_contents. Static dependency analysis has bounds and cannot resolve every dynamic or shipped-fastfile reference; an absent local file is an investigation lead.
edit_gdt and edit_zone preserve unrelated source and reject ambiguous changes. Sound alias editing preserves existing game columns, but an alias CSV alone does not configure conversion, sound banks and zone inclusion.
Original custom-asset tools create editable mesh, UV, texture, model and GDT source plus pipeline manifests. Native conversion and rendered appearance are later checks. BO3 assets and proprietary documentation are supplied by your own installation.
Deploy and build
If you use a separate workspace, preview deploy_project before applying it. Differing destination files need explicit overwrite=true. Inspect the proposed changes before replacing installation source.
Review plan_build, then start the build with start_build and execute=true. The normal pipeline is:
- GDT update, when needed after installation or asset changes.
- Compile, producing geometry and navigation outputs.
- Lighting, exporting the map’s LED.
- Link, producing
usermaps/<map>/zone/<map>.ff.
Use build_status for progress, diagnostics and log evidence; cancel_build stops the owned process tree. A server restart loses in-memory job handles, while written logs remain available.
Full compilation is the default. Entity-only builds require an existing BSP and cannot establish that geometry, lighting or prefab placement stayed unchanged. Use a full build after those changes.
Read the result
Apothicon checks fresh, nonempty build artifacts rather than treating a process launch as completion. Lighting also needs completion evidence for the exact requested source. Linking retains native return codes and warnings; only a narrowly checked warning-count convention can succeed with a nonzero return.
Inspect warnings in context. A successful linker establishes accepted inputs and a fresh package, not gameplay acceptance. Troubleshooting covers common prerequisite and evidence failures.
Record runtime evidence
start_test_session previews or launches a managed Radiant, APE or game session. Game sessions need the game executable and a linked fastfile. test_session_status reports process state, bounded logs, diagnostics and recorded checks.
Use record_test_check to save a check with its observer, evidence and status: passed, failed, blocked or not_run. stop_test_session stops only the application’s tree owned by that server.
A running process does not establish map load, collision, navigation or purchases. Observe the relevant behavior, record what passed, and leave other checks pending. When game and Mod Tools live in separate installations, inspect the deployment requirements before launching the retail game.