Animation Sync Issues

Scenario: The player has a sword attack animation. Visually the sword swings through an enemy, but no damage is dealt. The attack hitbox (Area3D) is supposed to activate mid-swing and deactivate after the swing. The timing seems correct in the animation timeline editor, but hits are not registering.

Setup

• Player/AnimationPlayer: has an attack animation, 0.6 seconds long
• Player/WeaponPivot/HitArea: Area3D with monitoring toggled by the animation
• The animation should set monitoring=true at 0.1s and monitoring=false at 0.4s
• Enemy Area3D is set to monitorable=true

Step 1: Record an attack sequence

Click Start Recording in the Spectator dock, perform 5-6 attacks against an enemy, including some that visually connect, then click Stop Recording.

Step 2: Find frames where the attack should land

I recorded attacks against the enemy. Hits should happen when the player swing connects visually but damage is not registering. Investigate.

Found 6 attack animation windows across the recording. Checking HitArea monitoring state during each window.

Step 3: Check hitbox timing

First attack (frames 340-378, 0.63 seconds):\n\n- Frame 340: animation starts (position=0.0s), HitArea monitoring=false\n- Frame 346: animation position=0.10s — HitArea monitoring should be true here per animation design, but monitoring=false\n- Frame 360: animation position=0.33s — HitArea monitoring=false still\n- Frame 366: animation position=0.43s — HitArea monitoring=true (just activated)\n- Frame 374: animation position=0.57s — HitArea monitoring=false (deactivated)\n\nThe hitbox activates at 0.43s instead of 0.10s. The keyframe timings in the animation are wrong — the monitoring=true keyframe is 330ms late.

Step 4: Verify the keyframe data

So the monitoring keyframe is at the wrong time? Check the actual animation data.

AnimationPlayer confirmed: current_animation="attack", length=0.6. Let me get more detail on the animation tracks — I need to read the scene file directly to see keyframe times.

Found the attack animation data. The monitoring track (WeaponPivot/HitArea:monitoring) has keyframes at: 0.0s (false), 0.43s (true), 0.57s (false). The design intent was 0.10s (true), 0.40s (false). The keyframes are set to the wrong times. This looks like the keyframes were set when the animation was half-speed (speed_scale=0.5 testing) and then speed_scale was reset to 1.0 — the time positions were not rescaled.

Step 5: Fix the animation keyframes

Fix the monitoring keyframe times: true at 0.10s, false at 0.40s.

Updating the keyframes via Director. I need to find the track index first.

Done. HitArea monitoring keyframes updated: false@0.0s, true@0.10s, false@0.40s. Reload the scene and test attacks.

Step 6: Verify

Tested. Hits are now registering correctly. Can you verify the timing in the next recording?

Attack window analysis: HitArea monitoring activates at animation position 0.10s (frame 206) and deactivates at 0.40s (frame 224). Timing matches design intent. The 0.33s active window gives the player 330ms to register a hit — appropriate for a melee swing.

Key takeaways

• Property condition filtering (property_equals: current_animation: attack) isolated exactly the frames of interest across a 2,400-frame recording in one call.
• Frame-by-frame animation position tracking revealed the hitbox was activating 330ms late — impossible to see from code, easy to see from spatial data.
• Animation bugs often come from speed_scale testing. If you test at half speed and set keyframes by feel, then reset speed_scale, all your keyframe times are effectively doubled.
• Use clips + spatial_inspect together. The clips query found the timing anomaly; the scene read confirmed the actual keyframe values. Both were needed.