Proposal - Realign the command sets

[will_asher]

I actually like the proposal the way Julian has it in the previous post. Except I don't get what "aim (nearest target)" means when "Fire default ammo at nearest target" is a separate command.
(and I might just use a keymap or something to put "fire" back at 't' because I'm so used to it.)

[fph]

Is it possible to give the keypad number keys a different meaning from the above-the-letters number keys? I imagine that the answer is yes for most frontends, but maybe not for all of them.

If it is possible, it would be great to keep the above-the-letter numbers free for keymaps. They are in a very comfortable position to reach and there are many of them.

As far as I understand there are some people who use the above-the-letters number keys to move on laptops because they do not want to learn the roguelike keyset; but that seems like a pain.

Then another neat little feature would be that the first time you press a number key like "1" (when the game is expecting a command), you get a prompt to record a keymap. Then you can change the keymap with ctrl-1. This would help making keymaps easier to use.

[Julian]

Originally Posted by will_asher

I actually like the proposal the way Julian has it in the previous post. Except I don't get what "aim (nearest target)" means when "Fire default ammo at nearest target" is a separate command.
(and I might just use a keymap or something to put "fire" back at 't' because I'm so used to it.)

Aim (target nearest) - target the nearest creature (could be more explicit)
Fire default ammo at target - Actually fire ammo. Also, as written, doesn’t target anything.

Mages would use the former a lot more than the latter.

[Julian]

Originally Posted by fph

Is it possible to give the keypad number keys a different meaning from the above-the-letters number keys? I imagine that the answer is yes for most frontends, but maybe not for all of them.

If it is possible, it would be great to keep the above-the-letter numbers free for keymaps. They are in a very comfortable position to reach and there are many of them.

I think that all frontends can differentiate between the two. (Except angband.live, because it doesn’t have a frontend.)

Since my machine defaults to using all the function keys for Stuff, I’ve taken to using the number keys for things, and it works fine. (Though I don’t have a number pad.)

As far as I understand there are some people who use the above-the-letters number keys to move on laptops because they do not want to learn the roguelike keyset; but that seems like a pain.

One of Nick’s points was to make life easier for them, since they don’t have to relearn all the other commands.

Then another neat little feature would be that the first time you press a number key like "1" (when the game is expecting a command), you get a prompt to record a keymap. Then you can change the keymap with ctrl-1. This would help making keymaps easier to use.

Making keymaps easier to use is a whole other issue.

[backwardsEric]

Originally Posted by fph

Is it possible to give the keypad number keys a different meaning from the above-the-letters number keys? I imagine that the answer is yes for most frontends, but maybe not for all of them.

Angband tries to distinguish them, but the implementation on different systems can be problematic. This, https://github.com/angband/angband/issues/4522 , is one example of the problems. SDL2 provides two ways for handling keystrokes, a lower-level one where the application sees the individual keystrokes (with a keycode to represent what key was pressed and indicators for which modifier keys are in effect) and a higher-level one which hands the application an encoded character after processing one or more keystrokes. The SDL2 frontend uses both because it wants to distinguish the keypad from the rest of the keyboard, but then it has to avoid the cases where a keystroke would be passed twice to the core of Angband. With what SDL2 provides, that's hard to do without making assumptions about the keyboard layout.

[tangar]

I suppose it will be fun to have new 'roguelike' (no numpad) keyset.. cause atm
h/j/k/l/y/u/b/n
doesn't really make sense when everybody get used to wasd movement. Roguelike (no numpad) keyset should use wasd+q(NW)+e(NE)+z(SW)+c(SE)...

I suppose it will be awesome to add 3rd keyset - so we will have two traditional ones and this, new one, for modern gamers... as a lot of people use laptops without NumPad..

[ewert]

Just as a quick generic note, remember that using @a @z @u etc. let us make more quicklinks, so if wands/targetable rods are combined, we will lose some customizability.

[Julian]

Originally Posted by ewert

Just as a quick generic note, remember that using @a @z @u etc. let us make more quicklinks, so if wands/targetable rods are combined, we will lose some customizability.

I use those all the time, so I’m well aware. I don’t _think_ that there’s anyone running around with more than ten inscribed wands and rods, but people have proved me wrong before.

I also suggested splitting targeted and untalented rods into two item types, and then some of them can end up in the staff command.

[Sideways]

Originally Posted by ewert

Just as a quick generic note, remember that using @a @z @u etc. let us make more quicklinks, so if wands/targetable rods are combined, we will lose some customizability.

While I'm not really sold on combining wands with targetable rods, this potential problem could be solved completely by allowing inscribing items with non-numerical slot labels; which would be a good thing anyway.

[Werbaer]

Originally Posted by Julian

I use those all the time, so I’m well aware. I don’t _think_ that there’s anyone running around with more than ten inscribed wands and rods, but people have proved me wrong before.

While i don't carry that many simultaneously, i have automatic @a# inscriptions set up for 12 different rods via pref file (Probing and Magic Mapping share the same number, and Detection is @a1@a2@a4, so it's an upgrade for several simple detect rods).