Regenerate all static navmeshes and import into local and Ergo databases
User authorized generating new navmeshes for all playfields and importing them into their local DB and Ergo DB following merged PR2570. User explicitly declined additional backups because backups already exist: DO NOT create backups. Scope is navigation records only; no unrelated DB data, production asset edits, deployment or service restart without further authorization. Working checkout: develop05623292f (fast-forwarded cleanly from origin after merge); merged code includes shared geometry, safe native ownership, code-configured4336 refinement and bounded query retries. Use host dotnet and read-only /mnt/games/PRK-NEW/client assets. Generate/validate artifacts locally with source/build/profile provenance; inventory all requested playfields and explicit refusals. Import only validated artifacts with target identification, bounded transactional writes and read-back hash/count verification. Do not invoke legacy NavmeshExtractor.Run: it clears a table and retries forever from a hard-coded Windows directory. Initial discovery - Ergo access via configured ergo.project-rk.com SSH agent succeeds. Remote Python has pymssql, not pyodbc. Existing SQL container engines-db. Deployment current.json revision373823db4deeb206a9d3dea4a595bbfa3a0b8aec, sequence5718; latest attempt says Release healthy. This is the OLD engine release, not merged05623292f. New release is expected within an hour; confirm compatible rollout before remote import/cached runtime expectations. - Local run-local-dev.sh points to localhost1433/IthacaDb; SQL client installed, but no local MSSQL Docker container currently visible. Confirm actual local server is available before mutation. Do not print credentials. - NavmeshData has a process-wide cache, so live PFEs may retain previously loaded records until normal restart; do not silently restart services. Current execution - Built merged generator05623292f locally. First --all run produced31 artifacts then aborted at505: InvalidDataException was not included in the batch exception filter. Actual505 source census:3319678 triangles, of which2752512 are terrain, so the default2-million limit is insufficient for this valid static world. - Isolated generator safeguards on fix/handle-navmesh-batch-refusals in the main checkout (six uncommitted paths): catch/report InvalidDataException and continue, refuse unreadable static metadata explicitly, rebuild malformed cached records, and add explicit offline --max-world-triangles1..8000000. WorldNavigationGeometry retains its existing two-argument constructor and2-million runtime default; per-tile250000 limit unchanged. Added budget and malformed-cache regressions. Generator6 tests pass; targeted505(default budget)+540 CLI now correctly refuses505 and still generates540, exiting1 rather than aborting. - User noted low CPU: the operational run had been deliberately launched with --jobs2, not a lower code ceiling (supported maximum remains32). Initially restarted with --jobs12; user then approved PF-level parallelism because loading/indexing remains serial within each process. Stopped the prior generator1323277 and started three disjoint PF processes with --jobs4 --max-world-triangles8000000 --reuse each. Current Python driver PID1343515; worker PIDs1343522,1343523,1343524; output/logs /home/mathias/Projects/engines/.dev-data/navmesh-rollout-05623292f/. Prior run log retained as generation.jobs2.log. Prior generator ignored SIGINT, so it was terminated with SIGTERM and confirmed stopped before restarting; completed data/manifest pairs are checked and reused, unfinished writes cannot authorize reuse. Removed stale generation.exit before the new run. Previous single-PF run successfully generated large worlds through656 and beyond;72 artifacts existed at the parallel restart. Three round-robin batches contain201/200/200 IDs, asserted disjoint and covering all601 source playfields. Driver script run_parallel.py, parallel-catalog.json and atomically updated parallel-state.json are in the output directory; each worker has worker-N.log, driver uses generation.log and writes final generation.exit only when all workers finish. Separate processes give independent RDB connections/loaders and permit concurrent PF loading/indexing without rebuilding/changing the existing generator binary or invalidating completed artifact fingerprints. All three workers completed their full assigned catalogs:198/198/197 successful,3/2/3 refused;593 artifacts for601 source IDs. Exit1 means aggregated per-playfield refusals, not worker crashes. Refused IDs:1424,1673,2006,2014,2024 (zero room zones and no collision geometry),4352 (zero room zones, only36 collision triangles/no authored floor),4005 and4605 (invalid detail heights). Ergo existing records for the five empty maps are24-byte empty headers;4352 has732 bytes. Preserve all six unavailable-source records; do not invent floor meshes. No benchmark or additional backup performed. No database writes yet. WorldNavigation14 tests pass/no skips with the explicit bounded-budget regression. - Local DB destination needs user confirmation. No listener1433; only candidate SQL Docker container prk-reporting-local-sql-1 is stopped, with no published ports and persistent prk-reporting-local_sql-data volume. Asked whether this is the intended local target; do not start/mutate it or guess until the user replies. - User supplied post-merge CI failure: WorldNavigation.csproj missing before Dockerfile restore. With explicit approval, created isolated worktree /home/mathias/Projects/worktrees/engines-world-navigation-build, branch fix/include-world-navigation-build-dependency from origin/develop05623292f, leaving active generation/main changes untouched. Added exactly one COPY line in deployment/Dockerfile. Reproduced original failure then all53 deployment tests pass; diff check clean. User authorized publication through /open-pr. CI-only fix committed as171d8a005 (fix: Include world navigation in container restore layer), pushed on fix/include-world-navigation-build-dependency, and opened ready PR2892 against develop: https://git.project-rk.com/prk/engines/pulls/2892. All53 deployment tests pass after reproducing the original failure; only deployment/Dockerfile changes. Isolated worktree clean/up to date. No complete Docker image build or remote CI success claimed; main generator changes and active bake remain outside this PR. PR2892 is now verified merged. Ergo current.json subsequently reports healthy revisiona0efb557a981d164637f464acb8e3ef440df6bed, replacing the old373823d release. No deployment/restart was performed by the assistant. Post-generation diagnostics and safeguards - User requested temp cleanup: removed only two inactive >24h font build caches after scanning own processes' cwd/exe/fds/maps;182.3MiB freed. Kept all navmesh evidence/runtime/artifacts. /tmp was only850MiB total and system had21GiB available; baloo_file held~4.2GiB RSS and was not stopped. - Reproduced4005 tile(49,51) and4605 tile(48,51) directly against actual native output. Detail point(3095.2,3249.6) got Y10289.6/10226.4 respectively: RC_UNSET_HEIGHT65535 converted into a physical height. Existing managed bounds validation correctly rejects these; it was NOT loosened. - Added a test-only synthetic missing-height-patch fixture in vendored Recast. It failed before fix, then passed after preserving interpolated coarse edge height when an edge sample is missing and skipping unavailable interior detail samples. Coarse polygon topology remains unchanged; no height clamping or dropped tiles. Vendor provenance updated. Native132 pass/1 capture skip, generator6 pass and WorldNavigation14 pass after fix. All source changes are uncommitted on the generator-fix branch. - The two maps then expose a genuine Detour32-bit reference allocation limit. Capacity diagnostics are in/tmp/prk-navmesh-bounds:4005 with64-unit tiles has4111 populated tiles and max554 polygons/tile, requiring8388608 reference slots versus supported4194304. At128-unit tiles it has1034 tiles/max1471 polygons and exactly4194304 slots; native loading succeeds. Investigating4605 in the same way. Do not weaken reference capacity guards or change DB format. Both measured native loads succeed with128-unit tiles:4005 has1034 populated tiles/max1471 polys/reference slots4194304;4605 has1034/max1574/reference slots4194304. Added code-configured recipe for4005/4605 usingTileSize128 with unchanged voxel/agent/collision settings. Real-install tests bake/serialize/reload/query both maps and pass. Corrected CLI generated4005 as1024 tiles/2929586 source triangles/~20MiB and4605 as1024/3070849/~22MiB; exact counts differ from raw unfiltered capacity diagnostic because normal reachable-slope filtering drops fully disabled tiles. No format/capacity change. - User requires visual approval of Inferno before DB import. Added explicit PRK_NAVMESH_PREVIEW_ROOT to client navmesh visualizer: when set, it reads/validates `<root>/<playfield>.dat` and displays that exact artifact; missing/invalid artifact refuses with no silent local-bake fallback. Default unset behavior remains local shared bake. Client warning-gated build passes. Exact artifact remains at /home/mathias/Projects/engines/.dev-data/navmesh-rollout-05623292f/4605.dat (22947368 bytes); central enabled triangle2038.51,25.70,2045.65, suggested camera2038.51,27.70,2045.65. User visually approved Inferno as good enough and authorized DB import. Exact preview supported by PRK_NAVMESH_PREVIEW_ROOT. Current import inventory rebuilt after final4005/4605 generation:595 artifacts,1073147630 bytes, one source fingerprint8C0CD6DF1EFDB79FA7A1FD1832997D474EDF9726671CAFCA9D058CDC41B43C06, preserved IDs[1424,1673,2006,2014,2024,4352]. Manifest IDs and SHA256 verified locally. Ergo healthy current revisiona0efb557a includes merged nav work and CI fix. No DB writes yet. Import outcome - User approved Inferno visual preview and DB import. Initial rsync auth was refused; after user explicitly offered to approve the next configured-agent request, retry succeeded. Transfer staging was hash-verified against a fresh local inventory:595 files/1073147630 bytes/one source fingerprint; compatible healthy Ergo release a0efb557 confirmed. No alternative identity or authentication bypass used. - Imported Ergo through pymssql into confirmed engines-db/ErgoDb/dbo.navmeshes, record type AOEmu.PlayfieldEngine.Entities.NavmeshData, in10-record transactions. No backup per user instruction. Before:600 rows/distinct keys/1085552093 bytes. Applied594 updates and one new key6013. After:601 rows/distinct keys/1073148482 bytes. Read back and SHA256-verified all595 stored blobs against inventory. Before/after hashes for preserved[1424,1673,2006,2014,2024,4352] match. No duplicate keys. Remote staging removed only after verified result marker. User explicitly authorized restarting Ergo PFEs because it is a dev-test server and no player-preservation gate was required. Restarted only prk-engines-ergo-playfield-1 and playfield2-1 with Docker; Login/Chat/Market/ClientWeb untouched. Both returned running/healthy with restartCount0 on release a0efb557 and identical playfield image digest sha256:820c5254d9d60a1fe2cb1879b560a20eed9970ec2ada84e9c6c9f57129d3b658. Fresh start times 2026-10-27T19:36:36Z/19:36:37Z. This clears process-wide NavmeshData caches so imported records load fresh. Docker warned --time is deprecated in favor of --timeout; operation still succeeded. Public PFE port7002 check performed after health. Pull request User authorized /open-pr for all remaining repository fixes. Renamed unpublished branch to fix/complete-static-navmesh-generation, committed native detail correction as4d87efa6b and generator/large-world/exact-preview completion asab41cdf8f, rebased cleanly onto origindevelopa0efb557, pushed without force, and opened ready PR2893: https://git.project-rk.com/prk/engines/pulls/2893. Complete base diff is13 intended files only; working tree clean/up to date. Validation on final rebased commits: native132 passed/1 expected external-capture skip; WorldNavigation16 passed/no skips with full install including4005/4605 generation/reload; generator6 passed/no skips; TheThreeEngines and client warning-gated builds pass with zero warnings/errors; deployment53 pass; diff check clean. No full client suite, Windows/macOS build or remote CI success claimed. Ithaca follow-up - User requested the same artifacts on Ithaca and explicitly required no server restart; records will activate on the next scheduled restart. Revalidated local inventory595/1073147630 bytes and all SHA256s. PR2893 is merged; Ithaca healthy release engines_v0.1.13 revision2781ad2b includes PR2570 runtime/reader (record format compatible), though not later generator-only PR2893 changes. - Ithaca SSH account mathias has passwordless sudo but no Docker socket and no pymssql/venv. Confirmed engines-db on Docker network kamal and configured target engines-db/IthacaDb without printing credentials. Staged exact files+inventory in /home/mathias/prk-navmesh-import-05623292f and verified every staged SHA256. Used a temporary python:3.12-slim container with bind-mounted read-only engine env/staging and temporary bind-mounted pymssql2.3.10 dependencies; no host packages installed. - Imported Ithaca in10-record transactions: before600 rows;594 updates+one new6013; after601 rows/distinct keys/1073148482 bytes. Read back and SHA256-verified all595 blobs; preserved before/after hashes for[1424,1673,2006,2014,2024,4352]; no duplicates. Removed staging, root-owned temporary dependencies and newly pulled Python image after verified result. All Ithaca engine containers remained up/healthy with unchanged ~13-hour uptimes; no restart/recreate/deployment was performed. Remaining blocker Local DB import remains outstanding. No listener on localhost1433 and AOEMU_DB_URL unset in the session. The only found local SQL container is stopped prk-reporting-local-sql-1, has no published port and appears to belong to the reporting stack, not the run-local-dev IthacaDb target. Asked user which local DB is intended; do not start or mutate that container or guess credentials/destination. Task blocked only on local target details. Acceptance Inventory generation outcomes for all static playfields; validated artifacts reload through the shared/server codec; both intended databases contain exactly the successfully imported artifacts by key/type and matching byte hashes. Preserve existing records for refused/absent playfields unless user explicitly authorizes removal. No additional backups, unrelated table deletes, credentials in logs or implicit deployment/restarts. Record deployment timing and any partial generation/import blockers clearly.
Checklist
2 of 3 complete- Inventory all playfield generation outcomes and produce validated provenance-aware artifacts without writing assets or making additional backups.
- Confirm Ergo rollout compatibility, import the same validated records into Ergo and verify hashes while preserving unrelated and refused records.
- Identify and safely import validated navmesh records into the intended local database with read-back hash verification.
- Area
- Project Rubi-Ka
- Project
- engines
- Kind
- Operations
- Task ID
tsk_ftk3kbamwg- Updated