salt/2077-gps-mod
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Decode GPS route element records

Browse Source
This commit is contained in:
Salt
2026-06-20 13:43:55 -05:00
parent 56a451a7cb
commit b34f2e2dee
2 changed files with 55 additions and 47 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/red4ext-logging-shim.md
+18 -17
View File
@@ -166,13 +166,11 @@ Latest GPS-query finding:
this is HUD/display lifecycle polling rather than solve completion: it polls
the currently displayed query once per second and pauses when the minimap is
not rendered.
- The current installed probe adds a read-only dump of suspected result-object
fields around offsets `0x20` through `0x5f` on successful active-route
fetches. The field at `outPath + 0x28` is confirmed to be a pointer-sized
route-result member with a count at `outPath + 0x30`, but live data does not
decode as plain `Vector3`/`Vector4` coordinates. The next probe treats it as
an internal route element array and dumps raw bytes instead of assuming a
float-vector layout.
- The current installed probe adds a read-only dump of result-object fields
around offsets `0x20` through `0x5f` on successful active-route fetches.
The field at `outPath + 0x28` is the data pointer for an internal route
element vector, but live data does not decode as plain `Vector3`/`Vector4`
coordinates.
Latest route-result findings:
@@ -185,16 +183,19 @@ Latest route-result findings:
result counts: side job `12`, Sinnerman `23`, Claire's Garage `18`, and the
custom pin `17`.
- Static disassembly of the `0x520783` result-drain caller shows `0x7094b8`
drains one 0x68-byte route result record at a time from an internal vector.
- Inside that 0x68-byte record, `0x41c508` iterates the member at offset
`0x28` as an array of 8-byte pointers, using the dword at `+0x34` as the
live count. The dword at `+0x30` behaves like capacity or retained allocation
size; earlier logs that treated `+0x30` as the point count were reading the
right magnitude only while capacity and count matched.
- The pointed objects appear to be route/lane segment objects rather than
coordinate vectors. The next probe logs the raw pointer array and selected
fields the engine reads from those pointed objects (`+0x68`, `+0x74`,
`+0x90`, and `+0x98`).
drains one route result record at a time from an internal vector, then copies
that record into `outPath`.
- The copied route-result subobject contains a vector at `outPath + 0x28`.
Its live count is the dword at `outPath + 0x34`; in the latest run this
cleanly matched the visible routes: side job `12`, Sinnerman `23`, Claire's
Garage `18`, and custom pin `17`.
- The vector elements are 0x28-byte records, not pointers. `0x41be2c` calls
`0x41be94` with `(data, data + count * 40)`, so the next probe logs each
route element as a compact 40-byte record tuple:
`h00,u08,u0c,u10,u14,h18,h20`.
- A nearby helper at `0x41c508` does iterate an array of 8-byte pointers at
offset `+0x28`, but that is a different route-adjacent object type, not the
`0x7094b8` output record captured in `outPath`.
Autodrive finding: