-
Notifications
You must be signed in to change notification settings - Fork 1
Description
The enforcer currently evaluates inputs in raw event order (including rollback/resimulation snapshots), not on a collapsed linear frame timeline.
This can produce violations that are artifacts of rollback ordering (e.g., frame IDs like 6619 -> 6618 -> 6619), even when finalized gameplay progression would not violate the rule.
Violations are triggered in windows where frame IDs are non-monotonic due to rollback.
In coord output, index order is monotonic, but frame IDs can go backward/forward because multiple snapshots of the same simulation frames are present.
Example pattern:
frame_index,slp_frame_index
6933,6617,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0
6934,6618,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0
6935,6619,112.0,0.0,1.0,0.0,112.0,1.0,0.0,0.0,0.0,0.0
6936,6618,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0
6937,6619,112.0,0.0,1.0,0.0,112.0,1.0,0.0,0.0,0.0,0.0
6938,6620,112.0,0.0,1.0,0.0,112.0,1.0,0.0,0.0,0.0,0.0
The right input at 6935 is counted as right -> neutral -> right because the evaluation includes resimulated states (neutral from rollback), not only final states.
Why this happens:
Parser/check pipeline consumes the raw per-snapshot stream from replay data.
Rule logic (especially SDI cadence rules) assumes sequential frame progression when counting transitions.
Rollback creates duplicate/resimulated frame snapshots, which will: inflate transition counts, create apparent rapid toggles, and trigger false positives relative to a finalized timeline.
In other words: the algorithm is correct for raw snapshot order, but that order is not equivalent to “what actually happened once” in a collapsed timeline.