Keyboard bug in 4.1.0.1

Found a bug in R'n'D? Report it here!

Moderators: Flumminator, Zomis

Post Reply
filbo
Posts: 647
Joined: Fri Jun 20, 2014 10:06 am

Keyboard bug in 4.1.0.1

Post by filbo »

I am used to starting a level, then immediately putting it into single-step mode ('1' with my keyboard setup); basically I'd hit ' 1' (space, one) as quickly as possible. This no longer works; the '1' is not seen.

So I tried some other things, like ' ->' (space, right-arrow), holding down right-arrow. The player does not start moving even if I hold right-arrow down for many game cycles.

In effect, something is eating the first character after the level is started.

This seems like an obvious enough bug that you'd have seen and fixed it, which implies it depends on some other config difference I have. What can I provide to help debug it?
filbo
Posts: 647
Joined: Fri Jun 20, 2014 10:06 am

Re: Keyboard bug in 4.1.0.1

Post by filbo »

There seems to be a similar issue during play, but I haven't fully characterized it yet. It feels like it's probably caused by the same change (whatever that is).

As a reminder, my play style involves a lot of switching between live, pause, and single-step modes, 100% keyboard driven.
User avatar
Eizzoux
Posts: 567
Joined: Wed Oct 30, 2013 5:32 am
Location: Russia
Contact:

Keyboard bug in 4.1.0.1

Post by Eizzoux »

Yeah, I found problems like these either. You could click or press a button while the game fades to the gameplay, but now these's a bit stiff and kind of annoying system of ingnoring these "pre-clicks", so now you need to time it right when the game starts. Yeah, it saves from moments when you could spam one button to make game enter and close any screen itself over and over without you. It might be useful for future versions, but when you've used to exit game by quickly double pressing Enter and game cancels second clicking, it just becomes... kind of annoying :D
𒈟
filbo
Posts: 647
Joined: Fri Jun 20, 2014 10:06 am

Re: Keyboard bug in 4.1.0.1

Post by filbo »

Another instance, probably the same cause: I am accustomed to quitting a game in progress by hitting <ESC><Enter> in quick succession. Now the <Enter> is eaten; I keep ending up doing <ESC><Enter>(pause, realize nothing happening)<Enter>.
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: Keyboard bug in 4.1.0.1

Post by Holger »

Do you use "quick menu doors: on" to deactivate the door animations, or do you use the default settings (normal door animations)?

I've added a change to discard input events entered during those door animations, to prevent errors like holding keys or buttons pressed a bit too long when answering door requests and returning to the main menu, where those accidental input events could cause unwanted further actions.

But yes, I've also noticed that this change also prevents fast, intentional input events like those you described.

I will have a look at this again and check if it is possible to fine-tune the behaviour of discarding those input events...

Update: It's this commit that causes the problem you encountered:

commit ba20bcc8b425b7addb2bd1bfc4ef3661e56ccd43
added clearing event queue after fading and after door/envelope requests

This change was added to handle repeatedly reported problems like leaving the high scores screen by pressing a key a bit too long, therefore entering the high scores screen again immediately after entering the main menu. I tested this, and had to confirm that (depending on your personal key repeat settings), this behaviour could indeed easily occur (apparently some sort of "clumsy finger syndrome" ;-) ... never really happened to me with R'n'D, but I see that this can happen when not releasing a pressed key in time).

As written above, I will check if this can be improved somehow...
filbo
Posts: 647
Joined: Fri Jun 20, 2014 10:06 am

Re: Keyboard bug in 4.1.0.1

Post by filbo »

Yes, I use quick menu doors.

I think it's a mistake to discard input during those 'doors' in any case. You have a short or long delay, then the game starts without any opportunity for the player to make their first move -- unless they use typeahead, which you are now discarding. You've stolen initiative like some sort of D&D thief! :)
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: Keyboard bug in 4.1.0.1

Post by Holger »

Have a look at the update to my previous post -- apparently it's not the door animation, but the fading, but the effect is the same.

Maybe it's possible to keep all input events, but disable key repeat during fading (and door animations), to prevent accidentally entered key events.
filbo
Posts: 647
Joined: Fri Jun 20, 2014 10:06 am

Re: Keyboard bug in 4.1.0.1

Post by filbo »

Ah, thanks! I commented out those 4 instances of

Code: Select all

ClearEventQueue()
and all is well again.
Post Reply