Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Dwarvenhospitality]

Hello!

I have a very minor control issue that doesn't necessarily affect gameplay, but one that I find so strange I'd like to know what's going on. I complained about this on Reddit earlier, but didn't get much of a response, so I thought I'd try here.

Basically my problem is that shift+numpad 5 no longer works. Shift+ controls with any other button work, and if I press numpad 5 before shift it moves me up a z-level as intended. It used to work until recently and there's absolutely no other problem. I'm playing with LPN, which I've also redownloaded with the problem persisting, so I assume it's not a problem with the game. Does anyone have any ideas?

[PatrikLundell]

I've had similar problems with shift+numpad comparatively recently (started during 0.47.04, I think) resulting in defining areas (digging, stockpiles, etc.) in 10 step increments don't really work (pressing shift while a num pad key is already pressed causes a jump, but that's basically useless). I'm using LNP as well (and thus, obviously, Windoze), but it also happens without LNP and without DFHack (using an installation of DF I use to try DFHack I tried both with DFHack enabled and without it, and both behave the same). Thus, I suspect a Windoze update broke it.

[Thisfox]

My z-level control is < and >, and I don't use a numberpad keyboard all that often, but perhaps you changed your key bindings? Try changing the control to something else in the key bindings, then changing it back to what you want it to be, and see if that fixes the problem.

[Bumber]

Does it work with non-numpad numbers? I'm having an issue where just the numpad ignores shift, though it might just be an issue with my laptop.

[PatrikLundell]

Does it work with non-numpad numbers? I'm having an issue where just the numpad ignores shift, though it might just be an issue with my laptop.

That was a very good question!

It prompted me to test with the regular number keys, and yes, it did actually work (I didn't expect that, as I'm not using a US keyboard, and thus the shifted keys aren't the same). I then went back to the numpad, which, unsurprisingly, still didn't work properly. I then DISABLED the num lock, after which the numpad did actually start to work properly, both with shifted and non shifted numbers (I've encountered cases in the past where games wouldn't pick up numpad keys unless the num lock was engaged, so this is the first case I've seen where disabling it is useful). I didn't test other numpad functions beyond the number for movement, though...

[Starver]

If you disable the NumLock, then the NumPad acts (at least cardinally) as a secondary set of CursorKeys. If the diagonals (which in this mode are copies of PageUp/Down, Home and End, yes?) and the '5' in the centre (not entirely sure what that is a duplicate of, if anything, until I get back to an actual physical keyboard) are working then they obviously get 'caught' by the keybindings. Maybe differently from Shift+<PageUp^{the 'real' one in the dedicated 6-key block}>, but that'd be an interesting test to try, too.

It wouldn't surprise me if the Keybindings are intended to treat NumPad numbers the same whether NumLocked or unNumLocked (with possible mode-driven exceptions when digits are actually useful, like when setting suitably numeric worldgen parameters), for your convenience. Because I know I rarely deliberately toggle NumLock for any reason. When I do, it's for software that does distinguish (passively or actively) and the problem is as obvious as CapsLock is if it's accidentally (un)toggled. For much of my keyboard time, though, it's as unimportant as ScrollLock[1] and it only gets toggled by an accident of typing, manhandling or dropping something on the keyboard. Which I'll not realise until and unless the status of it starts to matter again.

Spoiler: Some rather cascading thoughts on the 'mechanics' behind it (click to show/hide)

Because, mostly, digits do nothing, the QWERTY-topping numbers may also be keybound to cover other odd circumstances, like the FNkey-'powered' conversion of NumPad-on-QWERTY to digits, as compact laptop keyboards might use, the OS only being informed that the equivalent keytop in the regular Digit Strip had been pressed so unable to differentiate.

It certainly sounds that DF doesn't care what the Shifted-Keytop is under any given localisation, so Shift-2 can be " (for me, UK layout) and Shift-3 as £, or whatever they are on US/other-national layouts, and it still deals with them only as Shift-<digit> for cursoring purposes, rather than trying to also cater for @, #, etc in back-forming the intentions in ways that suits every internationalisation, without ambiguous overlapping with the possibility that the bits of the keyboard where my @ and # exist (on a proper UK keyboard, in the cluster of punctuation over near the Enter key. On this Android onscreen keyboard, long-pressing 'a' and 's' with (because it's UKified) long-'d' being £ and 'x' for "... Not that I can play DF directly on Android, of course.

I know that there are various different ways an executable can capture keyboard input, from just taking a stream of characters (including being piped/redirected) to actually getting keyboard interupt data (used to be easy direct memory access, before HALs and the like forced de-HALling libraries to intermediate in most circumstances, which always seems inefficient from my POV). There's also far too much lazy programming (such that a streamed &GBP; symbol can often be seen rendered as # instead of £ when there's no longer any need for that old '70s-and-earlier incompatibility replacement) so I greatly admire that Tarn has apparently found the sweet-spot of input-wrangling that (mostly) works exactly as intended, where so many others have failed to do so.

But then whatever it was that allowed the NumPad-as-numbers to be a copy of NumPad-as-cursors has been messed up in a way that you're (among) the first to detect/mention the newly emergent re-inconsistency of purpose to which the keys get put.

But this is just my immediate thoughts, and might need further checking. Perhaps comparisons of older DF versions and checking the respective keybindings (which I've never really messed with myself) are or are not consistently defined. Maybe it's instead some rather sneaky (but unintended) OS update that flipped a keyboard driver behaviour while sorting something else out, but good luck in trying to establish that. Never mind reverting it.


(If I understand properly what is and isn't happening at the moment, for you, and remembering what my own experiences are - of never actually being bothered by wrongly-locked keyboards - without immediate testing of my own. Which won't be LNP anyway, if that's a factor at all.)


[1] I can think of two or three actual interfaces where scroll-toggling is actually respected by the system, and I use the distinct AltGr functionality much much more.

[Dwarvenhospitality]

Does it work with non-numpad numbers? I'm having an issue where just the numpad ignores shift, though it might just be an issue with my laptop.

It works with non-numpad numbers. Also, the control is mapped. Interestingly though, if I remove the mapping and try to map it again to shift+numpad 5 it maps it to numpad 5, ignoring the shift. This also only affects the combination shift+numpad 5.

[Bumber]

I then DISABLED the num lock, after which the numpad did actually start to work properly,

Same for me.