This document explains how to approach FOnline builds without hard-coding assumptions from one project into another.
../CMakeLists.txt../BuildTools/README.md../BuildTools/Init.cmake../BuildTools/validate.sh../BuildTools/validate.cmd../BuildTools/buildtools.py../BuildTools/cmake/stages/Init.cmake../BuildTools/cmake/stages/ProjectOptions.cmake../BuildTools/cmake/stages/EngineSources.cmake../BuildTools/cmake/stages/Codegen.cmake../BuildTools/cmake/stages/ScriptsAndBaking.cmake../BuildTools/cmake/stages/Applications.cmake../BuildTools/cmake/stages/Packages.cmake../BuildTools/cmake/stages/Finalize.cmake../BuildTools/cmake/helpers/*.cmake../Source/Applications/TestingApp.cpp../Source/Tests/README.md
FOnline is normally built through a game repository that embeds the engine as Engine/. Configure and build from the game root unless a focused engine-only command explicitly says otherwise.
Reasons:
- Target names are project-defined.
.fomaincontrols game-specific configuration.- Generated scripting APIs are project-dependent.
- Package names, signing, resources, and deployment settings belong to the product.
- Platform presets usually live in the embedding project's
CMakePresets.json.
- Open the game repository root.
- Inspect available presets with CMake or the IDE integration used by the project.
- Configure the smallest preset that covers your change.
- Build the narrowest relevant target.
- Run the corresponding test, package, or launch target.
- Update documentation if the workflow or behavior changed.
The exact list depends on host OS and target platform, but common tools include:
- Git
- CMake
- Python 3
- A C++20-capable compiler/toolchain
- Platform SDKs for the targets you build
- Visual Studio or Build Tools on Windows-oriented workflows
- Emscripten and Node.js for Web builds
- JDK and Android NDK for Android builds
Prefer the embedding project's documented setup because it may pin specific SDK/tool versions.
- ../BuildTools/README.md — BuildTools overview.
- BuildToolsPipeline.md — staged CMake pipeline and change routing.
../BuildTools/cmake/— reusable CMake modules and staged generation/build/package logic.../CMakeLists.txt— engine-level CMake entry points.- Embedding project root — product-level presets, configuration, and target selection.
- Runtime C++: build and run the project unit-test target; use Testing.md to choose focused suites and understand generated test targets.
- CMake/BuildTools: reconfigure from a clean or relevant build directory and run the affected build/package target; use BuildToolsPipeline.md for stage ownership.
- Generated API: rebuild generation targets, verify scripts compile, and consult GeneratedApiAndMetadata.md.
- Resource baking: run the relevant normal/forced bake path and consult BakingPipeline.md.
- Updater: follow ClientUpdater.md.
- Web: follow WebDebugging.md.
- Android: follow AndroidDebugging.md.
- Mapper/tooling: follow Tools.md and MapperTools.md.
- Nullability/script boundary: follow Scripting.md, ScriptMethodsMap.md, and Nullability.md.
- Configuration/resources: follow ConfigurationAndDataSources.md and BakingPipeline.md.
- Essentials/low-level utilities: follow Essentials.md and run the matching essentials tests from Testing.md.
Do not copy a full preset list into engine docs. Presets change per game and per branch. Instead, explain ownership and link to the concrete project document that owns exact commands.
- Confirm the command or preset belongs to the embedding project before documenting exact names in engine docs.
- For BuildTools changes, reconfigure the smallest affected preset and run the generated target that exercises the changed stage.
- For runtime changes, run focused tests first and then the project
RunUnitTeststarget when practical. - For package/platform changes, validate the owning package/debug doc in the same change.
- Update BuildToolsPipeline.md, Testing.md, or platform docs when the build workflow itself changes.