Mac numpad issue

[kirnamat]

I have been playing Qud for 1,276 hours so far, and obviously over many years. (And it is my all-time favorite game, so my immense gratitude to you, devs.) I have played exclusively on Mac, and I have used three different external keyboards over the years. My latest external keyboard is older than the pandemic, and I managed to play very successfully until recently.

I took a break for a couple months because life, and I fired the game up this morning, eager to try all of the awesome new stuff on the beta branch. But I discovered that I can no longer move, because my built-in numpad is no longer recognized differently from the horizontal number row across the main keyboard. This has literally always worked before, and was recently working on the same hardware.

I am running macOS Venture (13.0.1) on a 2018 MacBook Pro. Do you know if Ventura introduced any incompatibilities with keycode generation/recognition? Or perhaps something broke during the new UI updates? These are the main variables since I last played Qud, i.e., new OS, new Qud build.

I am very eager to be able to use my numpad again for moving and my number row for abilities. After 1,276 hours, I think it would be pretty hard for me to learn a new set of keybindings; I've been playing by muscle memory for a long time now.

I am happy to try anything that you recommend, including waiting for a new build to address the issue. Thanks, guys. Really appreciate anything you can do to get me back to the rust wells. Live and drink.

[AlphaBeard]

Does rebinding it work? You should just need to bind the movement in key bindings to whatever its reporting.

What if you toggle numlock?

(This does seem to be an issue with Unity 2021 that the beta is on and MacOS 13, so I'm trying to track down the specifics/workarounds)

[kirnamat]

Thanks for the quick reply; sorry my own wasn't as quick.

I am using a standard external Apple keyboard, and it doesn't have a numlock. I perused System Preferences extensively, but couldn't find anything to emulate numlock functionality. I also don't have any accessibility settings enabled that would interfere with ordinary keycode generation, nor am I using any virtual layouts. It's all pretty vanilla.

I can rebind the keys, but currently the numpad is generating the same keycodes as the number row, which creates a direct (ergonomic) conflict between movement and mapped abilities. Without something like numlock that I can toggle, I can't get the numpad to generate different keycodes, so I can't resolve that conflict directly.

I could probably map movement to number keys and my abilities to function keys, but while I'm rewiring my brain I'm going to get a lot of stupid deaths by thinking that 4 dismembers but actually it walks to the left. ;)

I haven't built anything with Unity for a few years, so I'm afraid I don't know anything helpful about the newer builds that could point you in the right direction. But I'm also a career software developer (26 years and counting), so I'm savvy enough to follow orders and provide feedback if there's anything specific that you want me to try in order to help you debug.

[AlphaBeard]

(high five from another 3 decade veteran)

try pressing shift delete maybe?

https://support.apple.com/guide/mac-help/if-a-numeric-keypad-doesnt-work-mchlp2366/mac#:~:text=If%20you%20have%20a%20separate,%2C%20try%20pressing%20Shift-Delete.

[AlphaBeard]

This seems to be either osx 13.x serving num keybinds to unity (which I can't really do anything about) or something with the new unity version which maybe i could but would be pretty problematic (major version upgrade right before release), so it'd be nice to find a workaround that isn't either heh.

[AlphaBeard]

https://www.lineal.co.uk/number-keypad-not-working-on-a-mac-keyboard-its-a-simple-fix/

[kirnamat]

Awesome, I'll try these as soon as I can. I got completely slammed with work (two 14-hour days). I'll report back when I've tried (hopefully tonight). I really appreciate the help.

Not stoking your ego, but Qud really is my favorite game of all time. I grew up on PC Rogue, discovered (and abandoned) Nethack, moved to Angband (and the variants), played ADOM and ToME for over a decade, and then settled very happily on Caves of Qud. For all the enjoyment I've gotten from this game, I feel ashamed that I didn't pay you a lot more for it.

Anyway, that's why it's important enough to me to bother you about it. So really, thank you a lot, both for the game and your help.

[kirnamat]

Well, unfortunately neither worked for me. I used Qud's control mapping screen to check whether it believed that either Shift+Delete or Shift+Clear behaved as numlock. Qud actually reports Shift+Clear as Shift+NumLock — which I thought was promising — but then actually pressing Shift+Clear doesn't seem to toggle numlock. The control mapping screen shows number row 1 and numpad 1 both as D1, before and after doing Shift+Clear (or Shift+Delete). I am using a full-size wired Magic Keyboard, just as in the second article that you linked (www.lineal.co.uk), but their advice simply does not work for me. I also eliminated the possibility of Mouse Keys before I reached out to you at all. If I were 100% confident that buying a more recent Magic Keyboard would fix the problem, then I would absolutely just buy one and call it a day. I will see what else I can discover about this problem, hopefully over the weekend. I might need to write a key reporter (probably in Rust or Kotlin) just to take Unity out of the equation, to check what keycodes it reports before/after Shift+Clear/Delete.

[kirnamat]

I whipped up a Rust app and I checked it against a developer utility called Key Codes on the App Store. Just picking on 7, because it's in the number of magic and mystery (and also the upper left corner of the num pad), here are my results:

Num row 7 produces:
- characters: 7
- unicode: u0037
- keys: 7
- key code: 0x1a
- modifiers: 0x100 (NX_NONCOALESCEDMASK)

Num pad 7 produces:
- characters: 7
- unicode: u0037
- keys: #7
- key code: 0x59
- modifiers: 0x200100 (NX_NUMERICPADMASK)

I obtained comparable results for all other keys on and off the num pad, e.g., keyboard + and num pad + produce different results. All num pad keys have NX_NUMERICPADMASK as a modifier, and no other keys set this modifier.

Using both utilities, I verified that Shift+Delete and Shift+Clear have no observable effect on the key codes produced. So I don't seem to be able to access anything like numlock functionality from my (old) Magic Keyboard. But it would appear to be that numlock is off anyway, since by default I am receiving different key codes that the num row produces.

So… this is strong evidence that we can rule out macOS Ventura as the root cause… and medium evidence that Unity 2021 is the culprit instead.

I'll see what I can dig up in the Unity forums. I might try to build a key code reporter — or see if there's already a free utility in the asset store.

[AlphaBeard]

Ah this is super helpful, thank you!; I'll check if anything is dependent on actual char generation over keycode improperly.

[AlphaBeard]

One other quick test without custom code would be to see if the enabling the prerelease input manager fixes the issue.

[kirnamat]

I couldn't tease out anything useful from the forums, beyond that people started complaining about this issue in 2020, so instead I built a demo project in Unity 2021.3.15f1, using the basic 2D template. For simplicity in my description, I am just going to describe my experiment in terms of numpad 7 (though I also tried with other num pad keys).

I created a single object, which I named InputSolicitor, and I attached a script whose Update method used UnityEngine.Input (what Unity is apparently calling the "old" system) to write to the console log (Debug.Log). Per the official guidance[docs.unity3d.com] and my own memory from 2 years ago, I used Input.GetKeyDown with both KeyCode.Keypad7 and "[7]", which should both represent numpad 7. I verified (with breakpoints and logging statements) that Update was really being called, but the immediate mode input conditionals never triggered for any numpad 7 (or any numpad key).

So then I installed the Input System package (version 1.4.4), went to Project Settings > Player > Other Settings > Configuration > Active Input Handling and changed it from Input Manager (old) to Input System Package (new). I added a Player Input component to InputSolicitor, attached an Input Action Asset, and configured the asset to have a single input map (Player) and a single action (Move). I added an Up\Down\Left\Right Composite to Move, and I set the individual bindings to Numpad 8/2/4/6, respectively. I also went to Window > Analysis > Input Debugger > Keyboard, where I observed that the keyboard table listed different code values (labeled BIT) for 0–9 and numpad0–numpad9. I then nixed the Update method from InputSolicitor, imported UnityEngine.InputSystem, and added an OnMove method. In the method, I just added logging statements to print the Vector2 that I bound in the input action asset. OnMove only gets called if Unity routes the key codes correctly, and I verified that with an unconditional logging statement at the beginning. I observed that I could use the numpad — well, only 8/2/4/6 — but not the corresponding number row keys. And the Vector2 was set to (0.0, 1.0), (0.0, -1.0), (-1.0, 0.0), and (1.0, 0.0) as appropriate for numpad 8/2/4/6, respectively. Here's the complete implementation of OnMove:

private void OnMove (InputValue v)
{
	Debug.Log("OnMove");
	var vector = v.Get<Vector2>();
	Debug.Log($"input = {v}\nvector={vector}\n");
}

Conclusion: The old input manager (UnityEngine.Input) in Unity 2021 no longer supports the numpad … on macOS? I can't test anything but macOS Ventura, so I can't scope the issue precisely … but the new input manager (UnityEngine.InputSystem) does support the numpad correctly on macOS (with the same scope caveat).

I'm really sorry I can't attach the Unity project or any screenshots to this for you; if you need them badly, let me know, and I'll set up a repo on GitHub with the whole project and some screenshots.

Let me know if there's anything else that I can do to support you. I am happy to contribute to a solution in any way that I can.

[kirnamat]

No, I'm afraid not. I tried the prerelease input manager before I wrote the input bug report, but I forgot to mention; sorry. Just in case I was misremembering, I just tried it again, and I can verify that it exhibits the same bug with numpad recognition.

[AlphaBeard]

Ok, ill put a couple testers together this weekend and see if I can pin down the issue then! Though prerelease manager also not working makes me strongly suspect a unity side issue.

Appreciate the patience, we'll get it sorted!

[AlphaBeard]

Ok, here's the simplest test I can rig; there's two apps which show which key unity thinks is being held, 7, numpad 7 or home, built with 2019 (which pre-beta uses) and 2021 (which beta uses). This should cut the culprit list down significantly depending on behavior.

https://www.dropbox.com/sh/y7qos8jbzpko5gb/AADv_-DSOYD5DOh7aJg1QXsca?dl=0

e: Ah I totally missed the post 2 above this, which answers this question clearly!

[AlphaBeard]

Ok so given we know what to expect from my testers, I'm going to go ahead and submit a unity bug for this. We do have a new version using the new input manager in the works, but it's a fairly big change under the covers. So to resolve this I'll probably need

1. to get Unity to fix the bug
2. go forward to a newer version, or add the new input manager
3. roll beta back to older unity

So no great options; but I'll pick one and keep you updated.