[Hendricks266]

On Windows, currently EDuke32 and Mapster32 will force the keyboard layout to American English on startup. Recently I added support for toggling it back and forth whenever the Mapster32 window loses focus, but this has the side effect of introducing a stutter on regaining focus, and after reading Microsoft's documentation it will never work on Windows 8 and up.

I believe that interfering with the user's input setup is unnecessarily invasive, so I would like to remove this entirely. Fortunately, SDL2 gives us access to both scancodes, the physical position of keys on the keyboard irrespective of what character is assigned to them, and keycodes, the character that each key is labeled with.

I would like some input regarding in what situations it is better to use the labels on the keys and when it better to use the positions on the keyboard. For example, when entering cheats in Duke, you would probably want to type however you normally do on your keyboard, where the character on the key is what you get. But it might be different when dealing with Mapster's many key combinations. The latter is what the layout switching assumes, but I don't want to repeat a mistake similar to changing the 2D mode sprite colors based on my own preconceptions instead of mapper experience.

[NNC]

I got used to DNKROY and DNSCOTTZ pretty fast, I can't think I would like using them with the hungarian key labels.

Mapster is always better with key positions as well, and Y-Z switch aside, it's barely problematic here. Apostrophe is for example an accent A in hungarian keyboard, and using it is pretty simple.

[evil_presley]

Nancsi, on 04 January 2017 - 02:11 PM, said:

I got used to DNKROY and DNSCOTTZ pretty fast, I can't think I would like using them with the hungarian key labels.

Mapster is always better with key positions as well, and Y-Z switch aside, it's barely problematic here. Apostrophe is for example an accent A in hungarian keyboard, and using it is pretty simple.

i for one would be happy to be able to use hun keys in mapster, for convenience' sake.

[0815Jack]

Question: Will you hard-code the input behavior or will it be possible to adjust it in the ini files?

I would prefer the keycodes method in eduke / mapster.....

[Gambini]

Quote

I believe that interfering with the user's input setup is unnecessarily invasive, so I would like to remove this entirely. Fortunately, SDL2 gives us access to both scancodes, the physical position of keys on the keyboard irrespective of what character is assigned to them, and keycodes, the character that each key is labeled with.

I think the way it always have been (and therefore the way all mappers arae used to) is the physical position.

[oasiz]

I'm happy with how the layout is now, but the switching is just plain awful.
I end up with having to press ctrl some times after I quit playtesting or switching back/forth between layouts if I type something during alt-tabbing.

I'd be much happier if it sniffed straight scancodes, I don't want the layout to change otherwise.

Current workaround is just very hostile.

Any progress with the lockup where inputs stop randomly working after you've been mapping for some hours ?

[necroslut]

Gambini, on 19 March 2017 - 08:07 PM, said:

I think the way it always have been (and therefore the way all mappers arae used to) is the physical position.

I agree that physical position is best - otherwise you might end up with really cumbersome key combinations that could be extremely cumbersome to reach.

[Big Bene]

As most of the keys aren't very intuitive anyway, it's jsut as easy to memorize the key I have to press on my German keyboard as memorizing the original one, so I personally see no benefit in an internationalized keyboard version.

National versions of the manuals (just replace the keycodes) would be convenient by removing the need to find the correct key in the first place by try and error, or by looking it up in the internet (which is not always correct in this). Plus, these would not interfere with the software, not possibly causing any problems.

[Gambini]

Is there a way to disable this on the user end? It´s an annoyance on multitasking and not necessary on my case, and guess many others.

[NightFright]

I would also like to know how. It's really super annoying, and there is no other game or port I use which does this.

[MetHy]

The only time I'd really like to use AZERTY kb layout in M32 is when typing in the console. I can easily remember alphabetical letters which are swapped between AZERTY and QWERTY, but I can never remember symbols.

The problem is that if I switch to AZERTY to type in the console, only letters and a few symbols are swapped, not everything, so I end up with this weird layout that's a combination of the two while apparently doing its own things at the same time, I don't even know.

For instance simply to type _ in the console I always have to pull some stunt.
As it is now if I switch to AZERTY in the console _ will still be next to 0, matching the QWERTY layout, while it should be the same key as 8, yet alphabetical letters like A->Q or W->Z are indeed swapped indicating this is supposed to be AZERTY

Please note that we have two symbols associated with the number keys, the 2nd one should work when using alt-gr

Another weird thing is that when switching to AZERTY in the console the key next to "?" and "," should be "." and ";" but instead it's ":" and ";"
The same thing happens to other symbol keys located on the right of alphabetical letters, and apparently those match neither QWERTY nor AZERTY, so I have no idea what's going on.

Edit: made a shitty MSPAINT edit for this last example

[Hendricks266]

In r8421 I removed the layout switching completely. I tested in the game and in the editor without it and found that "in-game" actions are unaffected by the removal, in that they happen based on the position of the key. Text entry, such as the console and player name setting, more intuitively uses what the keys actually mean in the user's configured locale. If this introduces regressions that are not in r8420 we can revert it.

[TerminX]

Unfortunately, this introduced regressions regarding console input from keyboards that generate scancodes that fall outside of the range of characters EDuke32 actually supports, so it has been reverted for now.