From 1d77b8483fe78ce049532d23f5f40e5849bfa3fb Mon Sep 17 00:00:00 2001 From: Jacob Babor Date: Sat, 20 Jun 2026 21:56:36 -0500 Subject: [PATCH] Trace GPS resolver during map queries --- docs/compaction-handoff.md | 83 ++++++++++++++++---- docs/red4ext-logging-shim.md | 12 ++- red4ext/EdgeWeightGPS/src/Main.cpp | 119 +++++++++++++++++++++++------ 3 files changed, 171 insertions(+), 43 deletions(-) diff --git a/docs/compaction-handoff.md b/docs/compaction-handoff.md index e6ba4cb..6c63540 100644 --- a/docs/compaction-handoff.md +++ b/docs/compaction-handoff.md @@ -4,12 +4,13 @@ Current date/time context: 2026-06-20/21, local timezone America/Chicago. ## Current Installed State -- Latest installed probe commit: `54f014b Trace full GPS query results`. +- Latest installed probe source: resolver-window probe. Use `git log -1 + --oneline` for the exact checkpoint. - Installed RED4ext plugin: `Cyberpunk 2077/red4ext/plugins/EdgeWeightGPS/EdgeWeightGPS.dll`. - Installed build is read-only. It should not alter route behavior. - Latest archived test log: - `logs/EdgeWeightGPS_query_route_probe_2308.log`. + `logs/EdgeWeightGPS_resolve_handle_probe_4650.log`. - Game is cold as of the latest user message. ## New Toolbox Tools @@ -129,15 +130,23 @@ Packed-handle resolver: - It resolves the handle into a 0x68-byte segment record and a 0x14-byte point record. The point record's `+0x13 & 0x3f` is the search-side class consumed by `0x44f838`. -- The current probe logs selected resolver calls at return RVAs `0x44d26c`, - `0x44d304`, `0x44d99f`, `0x44d9cd`, `0x44db50`, `0x44db88`, and `0x44dd92`, - plus the first 64 successful calls as a guard against a bad static address - assumption. Logs are capped at 512 calls. +- Live logging corrected the selected post-call return RVAs to: + - `0x44cb9e`: 0x38 intermediate-record builder. It writes packed handle, + `point+0x10` mask, `point+0x13` class, and coordinates from + `segment+0x18`. + - `0x44dd97`: geometry/materialization path. It walks the `segment+0x28`, + `segment+0x30`, and `segment+0x38` arrays for the resolved point. +- The current probe opens a five-second resolver trace window before the + original `0x70a42c` submitter runs when the caller is `0x8d20d4` and + `query_fcc=5`. Inside that window it logs selected resolver callsites with + per-return-site caps instead of spending the whole budget on startup noise. - Each resolver line includes the decoded handle, segment/point pointers, - segment pointer fields `+0x08` through `+0x38`, raw segment bytes, and raw - point bytes. The goal is to determine whether the selected-path segment still - carries, or points to, the traffic lane hash/resource flags before the final - 0x28 route records are emitted. + segment pointer fields `+0x08` through `+0x38`, raw segment bytes, raw point + bytes, raw `segment+0x08` metadata, the `segment+0x28` point-index record, + and small raw dumps from `segment+0x20`, `+0x30`, and `+0x38`. The goal is to + determine whether the selected-path segment still carries, or points to, the + traffic lane hash/resource flags before the final 0x28 route records are + emitted. ## Latest 23:08 Test Result @@ -202,14 +211,60 @@ Inference: highway-heavy. Therefore final route-record `u08` low byte and search point `point+0x13` class are different domains. +## Latest 46:50 Resolver Test Result + +Archived log: +`logs/EdgeWeightGPS_resolve_handle_probe_4650.log`. + +User timing: + +- 46:50 Continue on main menu +- 47:23 Space to continue +- 47:35 map open +- 47:43 side job +- 47:51 Sinnerman +- 47:57 Claire +- 48:09 custom +- 48:2x Aldecaldo camp +- 48:57 game cold / `OnExit` + +Route summary: + +- routes=6, records=170, matched route records to lane hashes=170/170. +- qid 1: startup/minimap, 18 records, 43 ms, 1216.5 pavement. +- qid 2: side job, 12 records, 34 ms, 578.6 pavement. +- qid 3: Sinnerman, 23 records, 45 ms, 897.4 pavement, 160.4 highway, + 89.8 road. +- qid 4: Claire, 18 records, 35 ms, 1216.5 pavement. +- qid 5: custom, 19 records, 45 ms, 1006.3 pavement, 343.4 highway, + 38.0 road. +- qid 6: Aldecaldo, 80 records, 340 ms, 5853.5 road, 1492.9 highway, + 1111.5 pavement, 24.6 gpsonly. + +Resolver sample findings: + +- The first resolver probe captured only the startup guard window because the + guessed return RVAs were post-call-off by a few bytes. +- It still proved `GPSResolveHandle 0x44e1a8` attached successfully. +- Actual resolver returns in the first 64 logged samples: + `0x44dd97:57`, `0x44cb9e:7`. +- Resolver point classes in those samples: `4:60`, `5:4`. +- The 0x68 segment header contains generation/counts/pointers; final + `nodeRefHash` values are not inline in those 0x68 bytes. +- Static disassembly shows `segment+0x10` is the 20-byte point array, + `segment+0x18` is the coordinate array, and the materializer indexes + `segment+0x28` by `pointIndex*12`. + ## Next Work -- Install the resolver probe and run the usual map route routine. -- Archive the plugin log as `logs/EdgeWeightGPS_resolve_handle_probe_