Probe vehicle data and native passing in game #8

Closed
opened 2026-10-04 20:14:57 +00:00 by haylan · 2 comments
Owner

Part of #1
Blocked by: #6

Question

With the hello-world mod running, log what landVehicleMoveSystem.getVehicleInfo, MovePath and LandVehicle expose for player-owned road vehicles. Also test, in game: (1) whether cars already pass on multilane or bus-lane roads, (2) whether script can bypass vehicle-vs-vehicle blocking at all (so a passer can drive through a blocker), (3) whether oncoming traffic on a two-way road is readable from script. HITL: the human runs the game and shares the log. Outcome: a go/no-go for the visual pass-through mechanism.

Part of #1 Blocked by: #6 ## Question With the hello-world mod running, log what `landVehicleMoveSystem.getVehicleInfo`, `MovePath` and `LandVehicle` expose for player-owned road vehicles. Also test, in game: (1) whether cars already pass on multilane or bus-lane roads, (2) whether script can bypass vehicle-vs-vehicle blocking at all (so a passer can drive through a blocker), (3) whether oncoming traffic on a two-way road is readable from script. HITL: the human runs the game and shares the log. Outcome: a go/no-go for the visual pass-through mechanism.
haylan added the wayfinder:prototype label 2026-10-04 20:14:57 +00:00
haylan self-assigned this 2026-10-05 20:01:49 +00:00
Author
Owner

Progress (not resolved yet): probe ran in game 2026-10-05. Findings: docs/research/vehicle-probe.md on branch prototype/vehicle-probe (log excerpt in docs/research/probe-logs/). Summary: the engine does not pass natively on 2-lane-per-direction or 1-lane-per-direction roads; a faster vehicle stays in its lane at the slower vehicle's speed; MovePath.blocked stays 0. Lane, segment, direction, opposite lane and lane modes are readable, so oncoming traffic is detectable. Next: search for any way to make a vehicle ignore the vehicle ahead before deciding go/no-go.

Progress (not resolved yet): probe ran in game 2026-10-05. Findings: docs/research/vehicle-probe.md on branch prototype/vehicle-probe (log excerpt in docs/research/probe-logs/). Summary: the engine does not pass natively on 2-lane-per-direction or 1-lane-per-direction roads; a faster vehicle stays in its lane at the slower vehicle's speed; MovePath.blocked stays 0. Lane, segment, direction, opposite lane and lane modes are readable, so oncoming traffic is detectable. Next: search for any way to make a vehicle ignore the vehicle ahead before deciding go/no-go.
Author
Owner

Resolution

Two-way roads: no-go (dropped). Multilane roads: go, through a lane switch.

  • Read side: sufficient. Each vehicle's segment, lane, direction, position, speed and opposite lane can be read, and so can each segment's lane layout and modes. getVehicleInfo only reports power and traction. MovePath.blocked doesn't show "held back by the vehicle ahead", so that has to be derived (same segment and lane, small gap, speed below the vehicle's capability).
  • Native passing: none. On a 2-lane-per-direction road, a faster vehicle (power 243) stayed in lane 4 behind a slower one (power 160) while lane 3 was free. On a 1-lane-per-direction road, it was held at exactly the slower vehicle's top speed (16.67 m/s, below the 22.2 m/s limit).
  • Bypassing vehicle-vs-vehicle blocking: no documented way. api.cmd.debug.makeComponentExchangeCmd builds with a MovePath, but the send was never tested in game, because the callback variant fails in engine state.
  • Oncoming traffic: readable (lane plus turnaroundEdges), but no longer needed.
  • Engine lane switching exists (only at segment boundaries, based on a traffic penalty, not exposed to scripts). That's what the multilane approach builds on.
  • Decision (user, 2026-10-05): drop overtaking on one-lane-per-direction roads. Pursue overtaking on multilane roads by switching the held-back vehicle to a lane the slower one isn't in.

Prototype and findings: branch prototype/vehicle-probe (mod/content/overtake_probe.*, docs/research/vehicle-probe.md, log excerpt in docs/research/probe-logs/).

## Resolution **Two-way roads: no-go (dropped). Multilane roads: go, through a lane switch.** - **Read side:** sufficient. Each vehicle's segment, lane, direction, position, speed and opposite lane can be read, and so can each segment's lane layout and modes. `getVehicleInfo` only reports power and traction. `MovePath.blocked` doesn't show "held back by the vehicle ahead", so that has to be derived (same segment and lane, small gap, speed below the vehicle's capability). - **Native passing:** none. On a 2-lane-per-direction road, a faster vehicle (power 243) stayed in lane 4 behind a slower one (power 160) while lane 3 was free. On a 1-lane-per-direction road, it was held at exactly the slower vehicle's top speed (16.67 m/s, below the 22.2 m/s limit). - **Bypassing vehicle-vs-vehicle blocking:** no documented way. `api.cmd.debug.makeComponentExchangeCmd` builds with a `MovePath`, but the send was never tested in game, because the callback variant fails in engine state. - **Oncoming traffic:** readable (lane plus `turnaroundEdges`), but no longer needed. - **Engine lane switching exists** (only at segment boundaries, based on a traffic penalty, not exposed to scripts). That's what the multilane approach builds on. - **Decision (user, 2026-10-05):** drop overtaking on one-lane-per-direction roads. Pursue overtaking on multilane roads by switching the held-back vehicle to a lane the slower one isn't in. Prototype and findings: branch `prototype/vehicle-probe` (`mod/content/overtake_probe.*`, `docs/research/vehicle-probe.md`, log excerpt in `docs/research/probe-logs/`).
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: haylan/tpf3-overtake#8