Wbd/distance without collision

[WaelDLZ]

Add the distance without collision metric.

I used the fact that the Agent datatype already had a cumulative_displacement field but it was never updated in drive.h

So I updated it in move_dynamics (and I set it at 0 in set_start_position)

Then I log distance_without_collision, in c_step:

if (collision_state == NO_COLLISION) {
            env->logs[i].distance_without_collision = agent->cumulative_displacement;
 }

Validation run:

Important notes to consider between merging this:

• I guess that if collision_behavior isn't set to "STOP", this metrics will stop making sense. But it is easy to also add a variable to track if the agent did collide at least once in the episode. I didn't add it yet because it depends on your intended usage of the metric.

• If an agent goes back and forth without really moving, he can artifically increase the metric a lot. I think it's okay because it's not a reward but a metric, but let me know what you think

• I took the liberty to make a little refactoring of move_dynamics, nothing wild

[greptile-apps]

Greptile Summary

This PR adds a distance_without_collision metric to the driving simulation by:

• Tracking cumulative_displacement on the Agent struct (already existed but was never updated), computing it as the Euclidean distance traveled per step in both CLASSIC and JERK dynamics models
• Resetting cumulative_displacement to 0 in set_start_position and respawn_agent
• Logging distance_without_collision in c_step when no collision is detected, and propagating it through add_log and the Python binding

The PR also includes a clean refactor of c_step replacing verbose env->agents[agent_idx].field accesses with a local agent pointer, and refactors move_dynamics to use incremental dx/dy variables.

• The metric value resets after agent respawn due to cumulative_displacement being zeroed in respawn_agent while distance_without_collision uses absolute assignment — this may not match expectations for episode-level metrics
• As noted by the author, the metric may be misleading when collision_behavior is not STOP_AGENT, since agents can continue accumulating displacement after collisions

Confidence Score: 3/5

• The PR is functionally safe but has a semantic concern with the metric value resetting on respawn, which could produce misleading data.
• The code changes are mechanically sound — displacement tracking is correctly computed in both dynamics models, initialization/reset paths are covered, and the refactoring is clean. However, the distance_without_collision metric has a logic concern: it silently resets to near-zero after respawn because cumulative_displacement is zeroed while the log uses absolute assignment. This could produce confusing metric values in GOAL_RESPAWN mode without being obvious to consumers.
• Pay close attention to pufferlib/ocean/drive/drive.h — specifically the interaction between respawn_agent resetting cumulative_displacement and the absolute assignment to distance_without_collision in c_step.

Important Files Changed

Filename	Overview
pufferlib/ocean/drive/drive.h	Adds distance_without_collision metric by tracking cumulative_displacement on Agent and logging it when no collision is detected. Also refactors move_dynamics to use incremental dx/dy and cleans up c_step to use a local agent pointer. One logic concern: the metric resets silently on respawn due to absolute assignment combined with cumulative_displacement reset.
pufferlib/ocean/drive/binding.c	Adds distance_without_collision to the Python log dictionary. Straightforward one-line addition consistent with existing patterns.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[c_step: move_dynamics called] --> B[Agent moves: dx, dy computed]
    B --> C[cumulative_displacement += sqrt dx² + dy²]
    C --> D{collision_state?}
    D -->|NO_COLLISION| E["logs[i].distance_without_collision = cumulative_displacement"]
    D -->|VEHICLE_COLLISION / OFFROAD| F[agent.collided_before_goal = 1]
    F --> G{collision_behavior?}
    G -->|STOP_AGENT| H[agent.stopped = 1, velocity = 0]
    G -->|REMOVE_AGENT| I[agent.removed = 1]
    G -->|default| J[Agent continues moving]
    H --> K[Next step: move_dynamics returns early]
    K --> L[cumulative_displacement frozen]
    E --> M{Goal reached + GOAL_RESPAWN?}
    M -->|Yes| N[respawn_agent: cumulative_displacement = 0]
    N --> O["Next NO_COLLISION step overwrites distance_without_collision with near-zero value"]
    M -->|No| P[Metric preserved until episode end]

Loading

_{Last reviewed commit: a8f57d8}

[greptile-apps]

_{2 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[WaelDLZ]

@greptileai can you reevalute the PR ?

[greptile-apps]

_{2 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Metric resets to 0 after respawn

When GOAL_RESPAWN is active, respawn_agent resets cumulative_displacement to 0 (line 2177), but distance_without_collision is set via absolute assignment (not +=). This means on the next collision-free step after respawn, distance_without_collision is overwritten with the new (near-zero) cumulative_displacement, discarding the value accumulated before respawn.

This differs from other log metrics like episode_return and collisions_per_agent which accumulate across respawns. If the intent is to track total collision-free distance over the full episode, you'd want to either:

1. Use += instead of = and accumulate the delta, or
2. Not reset cumulative_displacement in respawn_agent

If the intent is only "distance since last respawn without collision," the current code is correct but the semantic may surprise consumers of the metric.

[eugenevinitsky]

we can improve it later but this seems useful relative to the current state of the world so we should just merge it