From 407c44b1ad7077a46205c678a7be147acd741372 Mon Sep 17 00:00:00 2001 From: Jacob Babor Date: Sat, 20 Jun 2026 21:45:09 -0500 Subject: [PATCH] Probe GPS packed handle resolver --- docs/compaction-handoff.md | 41 ++++++++++--- docs/red4ext-logging-shim.md | 9 ++- red4ext/EdgeWeightGPS/src/Main.cpp | 93 ++++++++++++++++++++++++++++++ 3 files changed, 134 insertions(+), 9 deletions(-) diff --git a/docs/compaction-handoff.md b/docs/compaction-handoff.md index 35ab7d8..e6ba4cb 100644 --- a/docs/compaction-handoff.md +++ b/docs/compaction-handoff.md @@ -45,6 +45,7 @@ Active hooks: - `GPSQueryStatus 0xaa5704` - `GPSSearch 0x44f054` - `GPSRouteProducer 0x44cc7c` +- `GPSResolveHandle 0x44e1a8` - `GPSEdgeCost 0x44f838` - filtered provider filter `0x44ff68` - base provider filter `0x450b08` @@ -85,6 +86,7 @@ GPS pipeline landmarks: - query dispatch: `0x70a570` - route producer: `0x44cc7c` - local search loop: `0x44f054` +- packed-handle resolver: `0x44e1a8` - edge cost: `0x44f838` - query result fetch: `0x7094b8` @@ -117,6 +119,26 @@ Route result records: - The log's human wall timestamp has a millisecond rollover bug around second boundaries. Use the `+Nms` elapsed field for ordering and durations. +Packed-handle resolver: + +- `0x44e1a8` decodes the packed route handle used by the search/materialization + side: + - low 20 bits: point index + - bits 20..47: segment index + - high bits: generation/check value +- 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. +- 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. + ## Latest 23:08 Test Result The user clicked: @@ -182,13 +204,18 @@ Inference: ## Next Work -- Static disassembly around result-drain/producer RVAs `0x520783`, - `0x41be2c`, `0x41be94`, `0x70a42c`, and `0x8d20d4`. -- The plausible patch point is upstream of result copy: find where search - output is converted to 0x28 route records or where candidate lanes are ranked - with enough lane-hash/resource context to prefer highway/major-road lanes. -- Post-`0x7094b8` rewriting would likely only change displayed path records and - risks desynchronizing instructions from the real planner. +- Install the resolver probe and run the usual map route routine. +- Archive the plugin log as `logs/EdgeWeightGPS_resolve_handle_probe_