maybe some problems

[nameearly]

1. AnimationManager.js – Incorrect condition in removeMix
   Location: src/animations/AnimationManager.js:211‑239
   Issue: if (animB) incorrectly evaluates falsy values (empty string, 0), preventing proper removal of mix configurations.
   Consequence: Memory leak; invalid data accumulates in the mix configuration table.

2. AnimationManager.js – Incomplete cleanup in remove method
   Location: src/animations/AnimationManager.js:975‑989
   Issue: Only one‑directional mixes are cleaned up; configurations from other animations → current animation are not removed.
   Consequence: Memory leak; invalid entries remain in the mix table.

3. Systems.js – Incorrect property name in destroy causes memory leak
   Location: src/scene/Systems.js:788‑818
   Issue: 'camera' in the cleanup list should be 'cameras'; plugin references are not cleared.
   Consequence: Plugin resources leak after scene destruction.

4. KeyboardManager.js – Deprecated API used in event handling
   Location: src/input/keyboard/KeyboardManager.js:200, 220
   Issue: Uses event.keyCode instead of event.key or event.code.
   Consequence: Unreliable keyboard input capture in modern browsers.

5. AnimationState.js – Incorrect queue order in playAfterDelay
   Location: src/animations/AnimationState.js:720‑746
   Issue: Uses unshift, resulting in last‑in‑first‑out (LIFO) behavior; should be first‑in‑first‑out (FIFO).
   Consequence: Chaotic execution order in chained animation calls.

6. AnimationState.js – Reference comparison failure in setCurrentFrame
   Location: src/animations/AnimationState.js:1610‑1618
   Issue: Uses === to compare frame object references, which fails when frames are cloned.
   Consequence: Unreliable stopOnFrame functionality.

7. AnimationState.js – Hardcoded frame skip limit in update
   Location: src/animations/AnimationState.js:1542‑1560
   Issue: safetyNet < 60 is hardcoded, preventing catch‑up after long pauses.
   Consequence: Animation desyncs from expected timing.

8. AnimationManager.js – Incorrect boundary assumption in generateFrameNumbers
   Location: src/animations/AnimationManager.js:766‑774
   Issue: Assumes a __BASE frame always exists via end = texture.frameTotal - 2.
   Consequence: Miscalculations with certain texture formats.

9. TouchManager.js – Loose pointerId property check
   Location: src/input/Pointer.js:753‑756
   Issue: Checks for touch['pointerId'], but the Touch object should not have this property (it belongs to PointerEvent).
   Consequence: Unstable multitouch pointer ID assignment.

10. Error handling in the smoothDelta method (approx. lines 576–584)

if (delta > this._min)
{
    // Possibly a very bad start time or browser tab context loss,
    // so use the last "sensible” delta value
    delta = history[idx];
    // Clamp delta to the minimum (in case history is corrupted)
    delta = Math.min(delta, this._min);
}

Issue: When frame processing time exceeds the minimum allowed time (meaning FPS drops below the minimum threshold), the code replaces the currently measured delta value with a historical one and then clamps it again. This is illogical, as the historical value may already have been clamped, and replacing the actual measured value with a historical one masks real performance problems.
Correct approach: Directly clamp delta to this._min.

---

11. History array initialization bug in the resetDelta method (approx. lines 505–508)

// Pre‑fill the smoothing array
for (var i = 0; i < this.deltaSmoothingMax; i++)
{
    this.deltaHistory[i] = Math.min(this._target, this.deltaHistory[i]);
}

Issue: When resetting the timestep (e.g., resuming from pause), the code updates the history array using the smaller value between this._target and the existing history entry. This is logically meaningless. On reset, the history array should be initialized to a known good value (such as this._target), rather than potentially lowering existing values.
Correct approach: Follow the pattern in the start method: this.deltaHistory[i] = this._target;.

---

12. Seamless wake‑up time adjustment bug in the wake method (approx. line 804)

else if (seamless)
{
    this.startTime += -this.lastTime + (this.lastTime + now);
}

Issue: This line simplifies to this.startTime += now;, which incorrectly adjusts startTime during seamless wake‑up.
Correct approach: Account for elapsed time during sleep: this.startTime += now - this.lastTime; (wake time minus time at sleep) to preserve continuity of game time.

[samme]

3. Issue: 'camera' in the cleanup list should be 'cameras'; plugin references are not cleared.

This looks valid. 🙂