[?][BUG][PL] Input gets eaten during continuous rewinding

[Simon]

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

• 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.

-- Simon


For the record only: WillLem's first reply (= reply #1) was for my old and wrong report:

• 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.

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.)

[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.

Correct bug description is now in first post, or in here

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 I have copied this into OP.

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?

[Simon]

process more than 1 keypress per physics update.

Hmm. Do you really mean 1 per physics update, and not 1 per graphics frame, or 1 per program loop? Surely we can pause and select several skills during that (rather: between these same two) physics updates?

how often does this come up, and is it a major issue?

I habitually rewind (number 2 key in the number row) and scroll (right mouse button) at the same time, and it's niggling every time my input overlaps. It's never hugely annoying, but it's nagging a couple times every session. It's annoying enough that I'm willing to inspect the code with you. Every time I had tried to provoke it conciously, it had a 50 % chance to ignore input, and a higher chance to ignore on huge levels.

I'm busy this weekend, but we can find an evening in August/September. Focus on other bugs first. I'll play more CE when the contest levels release in September/October.

The better the software is, the more people will use it, and the more bugs they will file.

-- Simon

[namida]

I recall there being code to intercept certain keyboard or mouse inputs (I'm fuzzy on the exact details) and not pass them on to further handlers under certain circumstances. My hunch is this relates to the code for treating MMB / RMB as "just another keyboard hotkey" though I'm far from certian on this (eg. it might also have been to do with the minimap or skill panel). This might be worth looking at here.

Before that though: I'd test if Lemmix and/or very old versions of NL (before hotkeys were customizable) also has this issue. If it does, it's very likely something relating to Delphi's input handling rather than NL-specific code. (This does not mean there won't be a workaround of some kind, of course. It just helps figure out where to focus efforts.)