Repository navigation
feat/fix: transport load order bug + engineer-neutral building capture + tests - #62
Merged
Merged
Conversation
…e fix + tests Fix 1 (Unit.ts): In the 'load' order handler, when the unit is already within range of the transport, `processNextOrder()` was never called after emitting `request_load_unit`. The order would remain as `currentOrder` forever, leaving the unit stalled. Fix: add `processNextOrder()` after the close-range load attempt. Also tighten the proximity threshold from TILE_SIZE*2 (64px) to TILE_SIZE*1.5 (48px) so it stays inside the transport's actual loadRangeTiles=1.85 load range (59.2px), preventing silent rejections in `loadUnitIntoTransport`. Fix 2 (Combat.ts): The engineer-vs-neutral-building logic incorrectly repaired ANY damaged neutral structure, including hospitals and repair depots. Only bridges should be repaired (they are infrastructure); tech buildings (hospital, repair depot) should be capturable regardless of HP. Restructured the if/else so only `isBridgeStructure` triggers the repair/no-capture path. Tests: Add 34 unit tests in tests/transport-and-neutral.test.ts covering: - Transport load gating (player, category, capacity, distance, state) - Transport unload (drop tile placement, dying passengers, edge cases) - findNearestOpenDropTile spiral algorithm - Engineer vs neutral building branching (bridge repair, hospital capture, damaged-hospital capture regression) - Neutral building effects post-capture (hospital/repair depot heal range, faction checks, heal cap) tsc: clean | vitest: 96/96 pass (34 new) Co-Authored-By: Claude Sonnet 4.6 <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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary
case 'load'order handler never calledprocessNextOrder()when the unit was already in range of the transport, leaving the unit permanently stalled with a danglingcurrentOrder. Also fixed proximity threshold inconsistency (TILE_SIZE×2 → TILE_SIZE×1.5) to stay inside the transport's actual load range.Verification findings
amphibious_transport(naval, cap 8, infantry+vehicles) andnighthawk(aircraft, cap 5, infantry) — both fully defined ✓handleTransportHooks) fire on a 4000ms interval and correctly issue load/unload orders ✓updateNeutralEffects✓Test plan
npx tsc --noEmit— cleannpx vitest run— 96/96 pass (34 new)🤖 Generated with Claude Code