Console opens and closes arbitrarily on Windows client

[Caelish]

EDIT: After investigating with Xycaleth, best guess seems to be this is related to ENG INTL keyboard layout setting in Windows. Switching to ENG US keyboard layout seeems to make the issue go away, but switching back to ENG INTL seems to make it come back (albeit intermittently). It's just a best guess though.

---

Operating system and version: Windows 10 x64, set to ENG INTL language. Using external plain Qwerty keyboard, hooked up to a laptop with an internal Czech Qwerty keyboard.

Is this for single player or multiplayer? Only tested multiplayer.

Description of the bug (and if possible, steps to reproduce the bug): Almost every key seems to erratically trigger console opening and closing. It's transient, but occurs very often. This started happening after upgrading from an ancient version of OpenJK. I can press tilda and the console will open/close. I can press wasd keys and console will open/close. Literally every key seems to arbitrarily open/close console until it goes away from time to time. I haven't wrapped my head around the logic behind it yet, but it's a consistently recurring issue with plain OpenJK and no mods installed.

Again: this started happening after upgrading from an ancient version of OpenJK.

What did you expect to happen instead? Shift + tilda should open/close console. Other keys should do ... whatever I bound to them, rather than opening/closing console.

EDIT: I just tried to start OpenJK four times. The first three times, opening console with shift + tilda happened, but the "/" and "." keys mysteriously closed the console for no apparent reason (then I closed the process). The fourth time I couldn't reproduce it. I didn't change anything in between tries. Wat?

[ensiform]

SHIFT requirement was removed. ~~Which keyboard layout are you using?~~

We haven't fully gotten around to the best way to solve universal console key support. And the situation is even worse in the upstream in ioquake/ioq3 too.

The reason this happened after upgrading from ancient is because ancient was not using any SDL backend on Windows, which happened within the last year.

[ensiform]

@Caelish How about with a freshly compiled version with cl_consoleUseScanCode now implemented and default to 1?

Should be fixed with https://github.com/JACoders/OpenJK/commit/0a65fd6a7237f66369e2b3a339b633e0e5f42be3

[deathsythe47]

I can't personally verify this, because I just have a standard QWERTY/American English keyboard. But I had a friend (from Spain) install OpenJK, and he complained that his traditional console key wasn't working. Turns out it was not the "key to the left of 1" but some key on the right side of his keyboard (I can't remember exactly which). So it appears that "the key to the left of 1" may not be the normal binding for all keyboards in vanilla jamp. Having to go through the trouble of helping him with in_keyboardDebug 1, cl_consoleKeys, etc is not ideal for the average user to simply have the key working that they have been used to for years.

[ensiform]

I have a feeling the last Windows build was before the fix though.

Indeed. Was fixed in September, last build was August 22 then Stoiss' windows box was shut down. Self builds are required until builder solution is worked out.

[deathsythe47]

This was 1-2 weeks ago, I built it myself off the latest source. Again, I can't personally confirm this, as I don't have access to anything other than my standard QWERTY/American English keyboard.

[deathsythe47]

I'll get some information from him and post back.

[ensiform]

If the original client had a key that wasn't to the left of the 1 then it's going to be even more corner case because that is how they handled it in the original client as far as I know. It looked for the console scan code. It may not be ideal for the average user, but this is like 1 user out of the rest of the people using any other layouts which work as intended now. cl_consoleUseScanCode must be 1 (is the default so it should be) to avoid in_keyboardDebug and cl_consoleKeys.

You can change your keyboard layout in Windows FWIW so long as you know the exact layout being used.

[CansecoDev]

Adding: Is this for single player or multiplayer? Both

Also, sorry if this is a big wall of stuff, the fact that I can't use the default keybind from vanilla as default, which I used for years, is somewhat a brain-hurt, I really want to help on fix this issue.

First of all, users from Spain out there, this is the easy solution. In order to open the console, use:

Now the useful data and some troubleshooting:

This is not an problem for "only 1 user", I'm sure about it, since we are now at least 2 :), and I can assure that every single user from Spain will have this issue. I'm going to use this legend to explain things:

• Basics; by enabling in_keyboardDebug (as @ensiform noted), you can bring some useful data, with this, I'm going to bring my research on this matter, and hope for a better solution (a way to use the traditional keybind as default on keyboards from Spain).

When you use any key, (i.e. G), this pop up twice on the logger (down ad up state reads):

Scancode: 0x0a(G) Sym: 0x67(G) KMOD_NUM Q:0x47(G)
Scancode: 0x0a(G) Sym: 0x67(G) KMOD_NUM Q:0x47(G)

If you use and hold it for a second, until 4 G's are printed, you'll see 5 log entries: 1 for the first imput, 3 for the holding ticks, and 1 more for the release.

Scancode: 0x0a(G) Sym: 0x67(G) KMOD_NUM Q:0x47(G)
Scancode: 0x0a(G) Sym: 0x67(G) KMOD_NUM Q:0x47(G)
Scancode: 0x0a(G) Sym: 0x67(G) KMOD_NUM Q:0x47(G)
Scancode: 0x0a(G) Sym: 0x67(G) KMOD_NUM Q:0x47(G)
Scancode: 0x0a(G) Sym: 0x67(G) KMOD_NUM Q:0x47(G)

• Research on Vanilla JA: This is what happens with the multiple ways to bring up the console on a keyboard from Spain, on vanilla. Note that when I say "it triggers X" or "happens Y", I'm always talking about the default keybinds.

A1) [4]+[1]

This is the most used method because it just works without any issues.

B1) [4]+[3]

The issue with this one is that it add a ^ mark, i.e. if I bring up the console and type say hola amigo real quick, it will pop an error because on the console it was ^say hola amigo.

C1) [2]+[3]

Problem here, you trigger ALT_ATTACK with [2] (a saber throw), and if you want to use the console as chat without the say command (like JK2), you'll have an error if the first character is vocal because it add the [grave accent] character i.e. if you bring up the console and type aloha, it will be àloha on the console (error), but if you type hola amigo there will be no problem and you'll say hola amigo to the chat output.

• Research on OpenJK: Using this nice in_keyboardDebug feature.

A0) [1] alone

Scancode: 0x35(') Sym: 0xba(Â) KMOD_NUM Q:0x00(0x00)
Scancode: 0x35(') Sym: 0xba(Â) KMOD_NUM Q:0x00(0x00)

Nothing happens, with the console open, it adds a whitespace.

A1) [4]+[1] (the traditional working keybind)

Scancode: 0xe5(Right Shift) Sym: 0x400000e5(Right Shift) KMOD_NUM Q:0x01(SHIFT)
Scancode: 0x35(') Sym: 0xba(Â) KMOD_RSHIFT KMOD_NUM Q:0x00(0x00)
Scancode: 0x35(') Sym: 0xba(Â) KMOD_RSHIFT KMOD_NUM Q:0x00(0x00)
Scancode: 0xe5(Right Shift) Sym: 0x400000e5(Right Shift) KMOD_NUM Q:0x01(SHIFT)

Nothing happens, with the console open, it adds a whitespace.

B0) [3] alone (this is the most interesting part)

Scancode: 0x2f([) Sym: 0x60(') KMOD_NUM Q:0x60(')
Scancode: 0x2f([) Sym: 0x60(') KMOD_NUM Q:0x60(')

This will pop up the console, but there is an issue, also the here called "arbitrary" issue, it is NOT arbitrary since I can reproduce and explain it: This key [3] is an accentuation mark on keyboards from Spain, that means the following; as soon as you use ANY other non-special key after [3] was used, that key will be triggered again ending with the close action of the console. Example of use, bring up the console and type cl:

Scancode: 0x2f([) Sym: 0x60(') KMOD_NUM Q:0x60(') -- [3] down, console opens
Scancode: 0x2f([) Sym: 0x60(') KMOD_NUM Q:0x60(') -- [3] up
Scancode: 0x06(C) Sym: 0x63(C) KMOD_NUM Q:0x43(C) -- [C] down, console closes
Scancode: 0x06(C) Sym: 0x63(C) KMOD_NUM Q:0x43(C) -- [C] up
Scancode: 0x0f(L) Sym: 0x6c(L) KMOD_NUM Q:0x4c(L) -- [L] down, saber stance changes
Scancode: 0x0f(L) Sym: 0x6c(L) KMOD_NUM Q:0x4c(L) -- [L] up

Notice that, when the console closes, the key debugger didn't say anything about that extra [3] action. Also, as I point out here, you can no longer use the console as chat without the say command.

B1) [4]+[3]

Scancode: 0xe5(Right Shift) Sym: 0x400000e5(Right Shift) KMOD_NUM Q:0x01(SHIFT)
Scancode: 0x2f([) Sym: 0x60(') KMOD_RSHIFT KMOD_NUM Q:0x60(')
Scancode: 0x2f([) Sym: 0x60(') KMOD_RSHIFT KMOD_NUM Q:0x60(')
Scancode: 0xe5(Right Shift) Sym: 0x400000e5(Right Shift) KMOD_NUM Q:0x01(SHIFT)

This will pop up the console, but with the issue on an ^ added (like vanilla).

C0) [2] alone

Scancode: 0xe0(Left Ctrl) Sym: 0x400000e0(Left Ctrl) KMOD_NUM Q:0x02(CTRL)
Scancode: 0xe6(Right Alt) Sym: 0x400000e6(Right Alt) KMOD_LCTRL KMOD_NUM Q:0x03(ALT)
Scancode: 0xe0(Left Ctrl) Sym: 0x400000e0(Left Ctrl) KMOD_RALT KMOD_NUM Q:0x02(CTRL)
Scancode: 0xe6(Right Alt) Sym: 0x400000e6(Right Alt) KMOD_NUM Q:0x03(ALT)

Nothing happens as expected with the console open, but with it closed, it makes a kata movement instead of a saber throw.

C1) [2]+[3]

Scancode: 0xe0(Left Ctrl) Sym: 0x400000e0(Left Ctrl) KMOD_NUM Q:0x02(CTRL)
Scancode: 0xe6(Right Alt) Sym: 0x400000e6(Right Alt) KMOD_LCTRL KMOD_NUM Q:0x03(ALT)
Scancode: 0x2f([) Sym: 0x60(') KMOD_LCTRL KMOD_RALT KMOD_NUM Q:0x60(')
Scancode: 0x2f([) Sym: 0x60(') KMOD_LCTRL KMOD_RALT KMOD_NUM Q:0x60(')
Scancode: 0xe0(Left Ctrl) Sym: 0x400000e0(Left Ctrl) KMOD_RALT KMOD_NUM Q:0x02(CTRL)
Scancode: 0xe6(Right Alt) Sym: 0x400000e6(Right Alt) KMOD_NUM Q:0x03(ALT)

The console is now open without any issues (as explained at the top of this report). Notice that [left ctrl]+[3] works too with the same result, but since those two keys are too separate each other, I consider that as a bad workaround compared to [2]+[3].

I want to and a final note, using left shift will have the same results, but with KMOD_LSHIFT used instead of KMOD_RSHIFT, vanilla and OpenJK. Finally, if you need any more research in order to fix this issue, I'll gladly provide it.

• Ignore this (SEO for fellow Spaniards) La consola de OpenJK se cierra No puedo usar la consola de OpenJK OpenJK consola se abre y se cierra

[ensiform]

The key you identify as 1 is what is considered to be the console key in baseJKA (with Shift) and now in OpenJK with cl_consoleUseScanCode 1 regardless of the language. Only the german language keyboard requires shift with this method in OpenJK because it interferes with color code inputting since it is the ^.

[CansecoDev]

Uhmm... I was using an old build because I didn't noticed about the Win build-bot being down... my bad.

With a fresh build it works fine on a keyboard from Spain and without the [SHIFT] requirement, as expected. Also I want to add something to the research:

I said that after using [3] alone makes the [3] key trigger twice when you use ANY non-special key, that was not true, if you start the command with a vocal i.e. addFavorite, it won't close, but you'll trigger an unknown command error and instead say; àddFavorite. But starting the command with a consonant (i.e. cl_***) will close the console.