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. Hand it to your agent; it tinqs pulls 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 (a967d12b) — e64890fd plus parallel draw-list replay (Vulkan secondary command buffers) and parallel draw-list recording (Forward+ render lists over worker threads, every driver)	built-in module	✅ yes (GodotSharp/)
engine/windows-x64/	4.7.2 (a967d12bf) — same hash as macos-arm64: e64890fd plus parallel draw-list replay + recording (both default off; oracle 10/10, one VUID finding recorded); template_release here is still the 1e7be28b tree	built-in module	✅ yes (GodotSharp/)

Mac is engine a967d12b as of 2026-10-19 (--version 4.7.2.stable.mono.custom_build.a967d12bf): e64890fd plus parallel draw-list replay (Vulkan only) and parallel draw-list recording (every driver), both engine-default off and turned on by the game; GodotSharp regenerated; oracle parallel_draw_replay Vulkan 10/10, Metal 5/5 (engine/.agents/wiki/parallel-draw-replay.md). Windows is also engine a967d12bf as of 2026-10-19 — Forge ran the engine-side tests before publishing (engine .agents/wiki/parallel-draw-replay.md § Windows (Forge)): replay+record oracle Vulkan with validation 10/10 exit 0 but 10× VUID-vkBeginCommandBuffer-00050 in the first parallel state (secondary command buffers re-begun from pools without RESET_COMMAND_BUFFER_BIT; feature-off control = 0 VUIDs; NVIDIA tolerates it, MoltenVK never flagged — engine-owner fix owed); draw_indirect_count d3d12 with the newly installed debug layer 22/0 + expected SKIP line (the old 22/2 was the no-layer run where base-instance ran instead of skipping); multimesh_cull_pool d3d12 4524/4524 — parity with Mac. Vulkan SDK + Graphics Tools are now installed on Forge, closing the "--gpu-validation owed" notes. Still owed (same wiki section): the VUID-00050 fix + a --gpu-validation soak, tests=yes unit suites, crash checklist. Before this, Mac was engine e64890fd as of 2026-10-18: 4fde0e94 plus the Apple autorelease-drain fix (Mach-port leak, flat at ~640 ports now) and the G4 mergeable-draw census. Underneath, 4fde0e94 added G2 pooled GPU cull (env gpucull pool), fixed shadow LOD band (env gpucull shadowband) and STATIC_SHADOW_AT_REST (env gpucull staticrest; the game's tree_wind.gdshader uses it); all default off. Underneath is the 9dcc5d458 pair (SSCS contact shadows, hero shadow min-combine, upstream 4.8 shadow fixes #121775/#124348 with the game sun bias 0.014, draw_list_draw_indirect_count).

Long-term: CI (Gitea Actions) builds on push and publishes here / to S3 — docs/ai/plans/build-pipeline-architecture-2026-06-07.md.