Fix seacat cannon trajectory boat point bug #51
Merged
Conversation
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
The issue was that ship's Y-velocity was being added to projectile's Y-velocity, causing trajectories to be corrupted when the ship moved north or south: - South-moving ships: projectiles went straight into water - North-moving ships: projectiles went way too high Root cause: In isometric coordinates, ship.velocity.y represents horizontal movement along the map's Y-axis (north/south in 3D space), not vertical elevation. The cannon's verticalComponent represents actual Z-axis velocity from elevation angle. Mixing these in screen space incorrectly affected the projectile's vertical arc. Fix: Remove ship.velocity.y from projectile calculations. Only inherit ship.velocity.x for proper east/west moving platform physics. The projectile's Y velocity is now determined solely by firing angle and elevation, giving consistent trajectories regardless of ship direction. Closes seacat TODO item: "Fix the bug in cannon trajectories"
Fixes cannon trajectory bugs where shots traveled inconsistent distances based on direction (3 tiles south vs 20+ tiles north). Changes: - Server: Add Velocity3D type with groundVx/groundVy/heightVz - Server: Convert screen-space fire angle to ground-space azimuth - Server: Update hit validation to use 3D physics replay - Client: Separate ground position from height in projectile state - Client: Apply gravity only to height, not ground movement - Client: Add deck height threshold for ship collisions - Fix: Correct inverse isometric coordinate transformation All cannons now fire equal ground distances (~10-12 tiles) in all directions with consistent ballistic arcs. Related: p2v-projectile-velocity proposal (Option 2) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Cannonballs were arcing in the opposite direction when elevation was adjusted. Root cause was incorrect sign convention for heightVz. Changes: - Server: Change heightVz sign from negative to positive for upward shots - Client: Change gravity integration from += to -= (gravity reduces upward velocity) - Client: Fix water collision check (heightVz < 0 means descending, not > 0) - Server: Fix hit validation physics to match client (subtract gravity term) - Client: Zoom out camera from 1.5x to 0.8x for better projectile visibility Physics now uses correct sign convention: - heightVz > 0: moving upward (heightZ increasing) - heightVz < 0: moving downward (heightZ decreasing) - gravity reduces heightVz over time (standard ballistics) With elevation at 30°, ball now correctly arcs upward then falls down. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Create detailed research document outlining the full 3D combat system architecture for seacat ship combat. Documents: Core Entities: - Distributed multi-ship architecture (each ship = MEW participant) - Cannon control points with aim/elevation - Projectile 3D physics (ground + height separation) - Client-side player controls Message Flows: - Cannon firing and projectile spawning - Client-side projectile physics simulation - Two-phase hit validation (firing ship validates, target applies) - Ship sinking and respawn lifecycle - Water impact detection Key Design Decisions: - Distributed trust model: firing ship validates trajectory, target ship applies damage - Client-authoritative hit detection with server validation - Idempotent duplicate claim handling for multi-client scenarios - Ships do NOT track other ships (target state from client claim) - Full 3D physics eliminates direction-dependent bugs - Isometric coordinate transformations This research clarifies the actual implementation and will inform the formal c3d proposal. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Create comprehensive research document detailing the complete lifecycle of projectiles on the client, covering both data state and visual representation. Covers: - Data structure (Projectile interface with 3D physics state) - Complete lifecycle phases: 1. Network event reception (game/projectile_spawn) 2. Spawn (coordinate transform, sprite creation, data object) 3. Active simulation loop (3D physics, screen projection, trails) 4. Collision detection (ship hits, water impacts) 5. Despawn scenarios (hit, water, timeout) Key Details: - Tight data-visual coupling (sprite embedded in data object) - 3D physics: ground position + height separation - Isometric coordinate transformations every frame - Transient effects (blast, impact, splash, trails) managed by Phaser tweens with auto-cleanup - Map<string, Projectile> for O(1) operations - State flow diagram showing data→visual updates Includes performance considerations, memory management, and design pattern analysis (Active Record with embedded visual). This provides foundation for understanding client-side combat implementation details for the c3d proposal. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Fixes critical desync between client-side projectile physics and server-side hit validation that could allow invalid hits or reject valid ones. Changes: - Replace analytical ballistic formula with iterative Euler integration to exactly match client's frame-by-frame physics simulation - Add heightZ validation to prevent high-arcing shots from claiming hits on ships they pass over (enforces 30px deck threshold) - Add comprehensive unit tests (11 tests) to ensure physics stay in sync Technical details: - Server now simulates at 60 FPS like client using Euler integration - Constants synchronized: GRAVITY=150, DECK_HEIGHT_THRESHOLD=30 - Both now use: heightVz -= GRAVITY * dt; heightZ += heightVz * dt This prevents client-server disagreement on hit validation and closes an exploit where clients could claim impossible hits. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
This PR is being reviewed by Cursor Bugbot
Details
You are on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle.
To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.
|
|
||
| // Height position and velocity (vertical elevation in 3D space) | ||
| heightZ: number; // Height above ground (0 = water/ground level) | ||
| heightVz: number; // Vertical velocity (negative = upward) |
There was a problem hiding this comment.
Bug: Vertical Sign Convention: Up Is Down
Sign convention mismatch: the type comment says heightVz is "negative = upward" but the implementation in ProjectileManager.ts:169 and ShipServer.ts:709 treats positive values as upward. The water collision check at line 260 uses heightVz < 0 to detect descending projectiles, which contradicts the type definition. This inconsistency will cause confusion and potential bugs when the code is maintained or extended.
Consolidates two separate proposals (p2v and c3d) into a single coherent proposal that accurately documents what was implemented. Changes: - Add proposal.md with problem statement and solution overview - Add research.md with isometric coordinate system research - Add implementation.md documenting actual build steps - Update decision-p2v-projectile-velocity.md to mark Option 2 as implemented - Document server hit validation sync fix - Remove c3d-combat-3d proposal (consolidated into p2v) - Remove old implementation-prompt.md The proposal now follows CONTRIBUTING.md structure and accurately reflects the code changes in this PR. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
| // TODO: Convert ship velocity to ground-space as well in future refactor | ||
| const vel: import('./types.js').Velocity3D = { | ||
| groundVx: groundVx + this.state.velocity.x, | ||
| groundVy: groundVy + this.state.velocity.y, |
There was a problem hiding this comment.
Bug: Coordinate System Mismatch Distorts Projectile Trajectories
Ship velocity in screen-space is being added directly to projectile velocity in ground-space. The projectile groundVx and groundVy are calculated in ground coordinates via isometric transform, but this.state.velocity.x and this.state.velocity.y remain in screen-space. This coordinate system mismatch causes incorrect projectile trajectories when ships are moving, as screen-space and ground-space use different coordinate systems in isometric projection.
Integrated the true 3D isometric projectile physics implementation from proposal p2v-projectile-velocity into the seacat specification: Changes: - Added projectile physics overview to "Coordinate Systems" section - Completely rewrote Milestone 9 Phase 2 with detailed 3D implementation: - 3D coordinate system (groundX, groundY, heightZ) - Server velocity calculation with inverse isometric transforms - Client iterative Euler integration (60 FPS) - Server hit validation with physics replay - Constants synchronization table - Benefits and rationale for iterative vs analytical physics - Updated Related Proposals to reference p2v-projectile-velocity The spec now accurately reflects the implemented physics system that ensures uniform projectile trajectories in all directions by separating ground movement from height and applying gravity only to the vertical component. Related: spec/seacat/proposals/p2v-projectile-velocity/
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.
Fix seacat cannon trajectory boat point bug