# tinqs/builds Build artifacts for the Tinqs stack — engine editor binaries (+ their GodotSharp C# bindings). **Binaries and GodotSharp are stored via Git LFS** (see `.gitattributes`). Source lives in `tinqs/engine`, `tinqs/ariki-game`, `tinqs/ariki-sim`. See `manifest.json` for exact versions. > **Use `tinqs pull` / `tinqs push`, never raw git** — these are LFS-heavy. ## Installing / updating the engine **Don't copy files by hand — run the `update-engine` skill (it lives in the game repo, which everyone has):** [tinqs.com/tinqs/ariki-game · .agents/skills/update-engine](https://tinqs.com/tinqs/ariki-game/src/branch/main/.agents/skills/update-engine/SKILL.md). Hand it to your agent; it `tinqs pull`s ariki-game + builds, installs the binary + GodotSharp into `../engine/bin/`, wipes stale caches, and verifies. Covers macOS + Windows. ## ⚠️ The one rule: binary + GodotSharp are a MATCHED PAIR Each engine binary ships with a `GodotSharp/` folder (Godot's C# bindings) **generated from that exact engine build**. You must install them **together** and replace any old `GodotSharp`. - The engine does **NOT** regenerate GodotSharp at runtime. If it's missing you get a **`.NET assemblies not found`** dialog pointing at `engine/bin/GodotSharp/Api/Debug`. - A **stale** GodotSharp (from an older engine) against a newer binary throws **`Wrapper class not found for type: Terrain3D`** → terrain renders as water, animals don't animate. This matters now because **Terrain3D and `agent_skinned` are native engine modules** (no separate `addons/terrain_3d` GDExtension `.framework`). Built-in module classes need their wrappers baked into GodotSharp, so GodotSharp had to be regenerated — and must ship here alongside the binary. ## Current contents | Platform | Engine | Terrain3D | GodotSharp shipped? | |---|---|---|---| | `engine/macos-arm64/` | **4.7.2** (`615e852f`, code `c76f2ecc`) — GPU-driven MultiMesh culling Stage A+B+B2 (CPU band skip) + real Metal GPU timestamps, on top of the shadow diet (tile budget, size cull, inverted contract), `get_video_adapter_memory()`, device-lost diagnostics | built-in module | ✅ yes (`GodotSharp/`) | | `engine/windows-x64/` | **4.7.2** (`b1bc0aef`) — upstream bugfixes + static shadow cache (no memory query yet) | built-in module | ✅ yes (`GodotSharp/`) | Mac is engine `615e852f` (code `c76f2ecc`) as of 2026-10-05 evening (`--version` prints `4.7.2.stable.mono.custom_build.615e852fc`): Stage B2 CPU band skip for GPU-culled MultiMeshes (the x4.7 draw explosion of `gpucull veg on` is gone; the path still stays off by default) on top of everything 51ed21d5 had (shadow diet incl. tile budget / live caster size cull / inverted-contract switch, video adapter memory query, GPU device-lost diagnostics) plus GPU-driven MultiMesh culling Stage A (compute frustum cull + indirect draws, `multimesh_set_gpu_cull`) and Stage B (per-instance GPU LOD bands, `multimesh_set_gpu_lods`), real Metal GPU timestamps (`renderGpuMs`), staggered far cascades, fit-to-visible-depth (SDSM-lite, default off), the Metal argument-buffer copy-queue stall fix and the Vulkan breadcrumb barrier fix (#185). Windows is `b1bc0aef` (2026-09-28, 4.7.2 + static shadow cache) and gets all of the above when Forge rebuilds from main - do not pin `required_engine_build` before that. Windows is `b1bc0aef` (2026-09-28, 4.7.2 + static shadow cache) and gets the memory query when Forge rebuilds from main. The engine source repo stays private. Check `manifest.json` for sha256. The 4.7 Windows cutover handoff is resolved: [`.agents/handoffs/forge-windows-4.7.md`](.agents/handoffs/forge-windows-4.7.md). Long-term: CI (Gitea Actions) builds on push and publishes here / to S3 — `docs/ai/plans/build-pipeline-architecture-2026-06-07.md`.