Input gets eaten during continuous rewinding (was: during right-click scrolling)

[Simon]

CE 1.0.1
NL 12.14 and other versions from years ago.
Wine 10.6

• Start a level.
• If it's a small level, zoom in until you can scroll.
• Scroll with the hold-to-scroll feature. E.g., map this to the right mouse button in NL's options, then scroll by holding the right mouse button.
• While you hold-to-scroll, press a skill hotkey to select a different skill.

Practically everything is wrong in this OP, see my next post instead.

Observed: You have a ~50 % chance to select the new skill. Otherwise, the skill key has no effect and the old skill remains selected. (The hold-to-scroll will always continue to scroll correctly, whether the new skill selects or not.)

Expected instead: The new skill gets selected for certain. (And the hold-to-scroll will always continue to scroll.)

-- Simon

[WillLem]

Very strange. I'm not currently at my laptop so I can't test this immediately. Has anyone with a Windows machine noticed this?

Best guess is that it's something to do with hotkey priority, I'll take a look at it soon.

[Simon]

Sorry, this one is on me, I confused practically everything in OP. I should have consulted my notes.

The correct repro is:

• Play any level.
• Fast-forward 5 minutes.
• Press and hold the 1-physics-update-rewind hotkey.
• During this rewinding,
  • start to right-click scroll (press and hold),
  • or zoom with the wheel (rotate several notches),
  • or select skills by hotkey.

Observed for right-click scrolling:

• You have a 50 % chance that the starting click for hold-to-scroll fails. If this click fails, the subsequent holding also fails, guaranteed. You have to release right mouse button and re-click-and-hold.
  
• Rewinding continues correctly, it doesn't depend on the scrolling's failure or success.
  

Observed for zooming with the wheel:

• For each of the mouse wheel notches individually, you have a 50 % chance that it will fail.
  
• Rewinding continues correctly, it doesn't depend on the zoom's failure or success.
  

Observed for skill selection by hotkey:

• The skill has a 50 % chance to get selected.
  
• Rewinding stops. It doesn't depend on the skill selection's failure or success; it always stops.
  

Expected: Rewinding always continues, and the second input always succeeds.

The 50 % probability is on small levels: Automaton Maintenance, or Save Our Souls. On big, laggy levels, the probability of failing increases. I fail to right-click scroll with 70 % or 80 % on Space Program 10,000 BC.

The probability of failure increases during in-game times such as x:x9, x:x8, x:x7. It's lower immediately after an internal 10-second savestate around x:x1, x:x2.


I'll copy this into OP in a few days.

As WillLem says: Who can repro this on Windows?

-- Simon

[WillLem]

From reading the updated description, best guess is that it's a simple case of not being able to process more than 1 keypress per physics update.

So, for instance, if the hotkey for 'Rewind 1 Frame' is Z, and the hotkey for 'Select Builder' is 5, the input (if holding the Z key as described in your example) would be something like:

zzzzzzzzzzzzzzzz5zzzzzzzz

In this example, the 5 press was registered during the repeated z presses because it happened to be pressed "first" on that particular frame (i.e. before the automatic repeated z input). Sometimes, though, the z gets through first, and we just get:

zzzzzzzzzzzzzzzzzzzzzzzzz

The only solution i can think of is to implement some sort of hotkey queue which checks for keypresses and actions them on the next possible physics update (maybe NL already does this, I'd have to check).

Possible bugs that could arise: both "z" and "5" would be added to the queue , but if the 5 is actioned on the next available update, the z would be actioned on the update after that. Result: an extra physics frame rewind, possibly unwanted.

I have to ask: how often does this come up, and is it a major issue?