You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the unloader moves away from a blocking CP combine (AIDriveStrategyUnloadCombine:onBlockingVehicle), the parallel course offset is computed as own width/2 + work width/2 + 2 around the combine's AI direction node. Articulated harvesters (e.g. the spinach harvester) can stand bent, with the rear component sticking out sideways well beyond that offset - the unloader then keeps touching the rear part and never gets past it.
Solution
Scan the actual, current extents of the blocking vehicle with the existing VehicleSizeScanner (relative to its AI direction node) and use the larger of the scanned half width and the half work width for the offset. For rigid vehicles the scanned half width stays at (or below) the work-width-based value, so behavior there is unchanged. The scan runs once per blocking event, the same pattern PathfinderUtil.VehicleData uses at pathfinder start.
Testing
Reproduced with a tractor + trailer blocked by a bent articulated spinach harvester; with the wider offset the unloader clears the rear component. (Originally verified with a component-position-based approximation; updated to VehicleSizeScanner per review - in-game re-test of the scanner version pending, will report here.)
When the unloader moves away from a blocking CP combine, the parallel
course offset was computed from the work width around the AI direction
node only. Articulated harvesters (e.g. the spinach harvester) can
stand bent, with the rear component sticking out sideways well beyond
that, so the unloader kept touching the rear part and never got past.
Include the lateral extent of all components of the blocking vehicle
in the offset calculation.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Instead of approximating the widest point from component node positions
(which assumes full vehicle width for every component and ignores how far
a bent rear section really reaches), scan the actual current extents of
the blocking vehicle with the existing VehicleSizeScanner, as suggested
in review. One-time scan on the (rare) blocking event, same pattern as
PathfinderUtil.VehicleData.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When the unloader moves away from a blocking CP combine (
AIDriveStrategyUnloadCombine:onBlockingVehicle), the parallel course offset is computed asown width/2 + work width/2 + 2around the combine's AI direction node. Articulated harvesters (e.g. the spinach harvester) can stand bent, with the rear component sticking out sideways well beyond that offset - the unloader then keeps touching the rear part and never gets past it.Solution
Scan the actual, current extents of the blocking vehicle with the existing
VehicleSizeScanner(relative to its AI direction node) and use the larger of the scanned half width and the half work width for the offset. For rigid vehicles the scanned half width stays at (or below) the work-width-based value, so behavior there is unchanged. The scan runs once per blocking event, the same patternPathfinderUtil.VehicleDatauses at pathfinder start.Testing
Reproduced with a tractor + trailer blocked by a bent articulated spinach harvester; with the wider offset the unloader clears the rear component. (Originally verified with a component-position-based approximation; updated to
VehicleSizeScannerper review - in-game re-test of the scanner version pending, will report here.)🤖 Generated with Claude Code