02 · Engine Model

This is the part most tutorials skip. The 2002-era community documentation is overwhelmingly recipe-shaped — “paste this in and you get a flamethrower” — which works right up until the recipe does not fit what you want to build. These pages explain the machinery underneath so you can write your own recipes.

The mental model in one diagram

flowchart TB
    subgraph disk["On disk"]
        VL2["base/*.vl2 archives"]
        MOD["MyMod/ loose files"]
    end

    subgraph resolve["Resolution layer"]
        STACK["Mod path stack<br/>MyMod → base<br/>first hit wins"]
    end

    subgraph vm["Script VM"]
        COMP["Compiler<br/>.cs → .cs.dso"]
        NS["Namespace table<br/>Class::method dispatch"]
        PKG["Package stack<br/>Parent:: chain"]
    end

    subgraph world["Running game"]
        DB["Datablocks<br/>static descriptions"]
        OBJ["SimObjects<br/>live instances"]
        GHOST["Ghost manager<br/>server → client replication"]
    end

    MOD --> STACK
    VL2 --> STACK
    STACK --> COMP
    COMP --> NS
    PKG --> NS
    NS --> DB
    DB --> OBJ
    OBJ --> GHOST

Read left to right: a name is resolved to a file by the mod path stack, compiled into the namespace table, where packages rearrange which implementation of a function is live; the resulting code declares datablocks, which are instantiated as SimObjects, which the ghost manager replicates to clients.

Every modding technique in this handbook is an intervention at one of those five stages.

Under the community patches

None of the five stages changes. The patches are built on this machinery rather than altering it — console_client_patches is a package, t2csri.vl2 is an ordinary archive on the mount stack, and neither patch modifies Tribes2.exe.

That said, this is the section where knowing the patches matters most, because they occupy the same mechanisms your mod does. Each page carries an “Under the community patches” section; the ones with real consequences are: