Jump to content

Khonkhortisan

Member
  • Posts

    1
  • Joined

  • Last visited

Everything posted by Khonkhortisan

  1. ^ I see I'm not alone I'm putting this in the forums instead of bugtracker because there are multiple problems, some of which are related. My main problem is the same as this thread. Corruption loading keyboard controls in another layout openSUSE Linux 13.2 TDM 2.03 1) Getting it to start in the first place I noticed some new games in my repositories, and this was one of them. It installed fine through yast2. I tried thedarkmod and ~/.doom3/darkmod/thedarkmod.x86, but it was (I think) tdm_update.linux, the one that doesn't start with an underline (which I don't see now), which actually got a runnable game. 2) Window management There doesn't seem to be any way to get the mouse outside of the game window (in KDE) - alt-f3 for window menu, alt-f4 to kill, shift-alt-right to switch desktops, alt-tab to switch windows, alt-dragging the window with the mouse. This makes it difficult to see what the updater is doing, and exactly when it changes the config file. 3) Interrupted window move However, between when the game starts and when it grabs the mouse, I can start moving the window with the titlebar. If it grabs the mouse while the window is low on the screen, instead of being able to move the mouse below the bottom of the screen to hit the close button, I have to press ctrl-alt-f1 and kill it by command line. Also, while it's loading a level, I can move other windows on top of it, which stay when it grabs focus again. 4) Spawning the game before the updater Run thedarkmod, see another terminal appear, see the game appear, close the game. "The Dark Mod was found to be active. The updater will not be able to update any Dark Mod PK4s. Please exit The Dark Mod before continuing." It seems to attempt updating whether I kill the game quickly or not. 5) Typewriters live on through the QWERTY keyboard layout. I currently use the dvorak keyboard layout. It's set as the system-wide layout through yast2. Also, in the KDE desktop environment, I have a keyboard layout switcher between that and qwerty (and others). There are also some options like caps lock is compose key (to make words like café), press both shifts to toggle caps lock (really, who needs three buttons to make capital letters?) 6) Corruption loading keyboard controls in another layout If everything's in qwerty the whole time, there's no problem (it's a singleplayer game, I don't need to be able to type words) If everything's in dvorak the whole time, let's say I assign the first few controls (up down left right) to aoeu (that'd be the same keys as asdf in qwerty). The game is playable until I quit or restart. The controls are saved correctly after the program quits, just as they appear in the controls menu when it was running. I then start it again. When it comes back, it loads the keys as if I had pressed aoeu in the qwerty positions (so euo on the higher row, then a on the home row), then it converts those keys to the letters dvorak has there (so .gr on the higher row, then a on the home row). So I start up the game, set some controls to, say, qwerty's wasd in dvorak (,aoe), play for a while, restart, then all of a sudden it's expecting me to press war. instead. The problem only happens when I'm in an alternate keyboard layout on program startup. 7) Partial keyboard layout to start with! A workaround for this could be replacing the config file before startup with letters which would convert to the correct ones on startup. If I wanted aoeu, I'd put in asdf. Nevermind, I tried typing into the game asdf in dvorak, which is a;hfy in qwerty. Turns out, semicolon and apostrophe don't respect keyboard layout change. I don't even want to know how many keys are missed. This program probably also has that common problem where it reads the keys in two ways (key and symbol) and only proceeds if they're both the original match (which is the opposite of how layouts work, which only change the symbol for the key) 8) Input method resetting to default fcitx is a chinese input method switcher. It applies on top of KDE's keyboard layouts. I have dvorak set as default, qwerty included so the KDE switcher will still work, and google pinyin for chinese (which applies on top of dvorak, so you type ni hao using dvorak, and it converts it to 你好 using google pinyin). Even if I select qwerty in KDE's layout switcher, then when I start the game, fcitx notices there's a new window and switches it back to its default keyboard layout (which is dvorak) instead of keeping the current one, combined with #6 makes it appear to not work in qwerty if it starts in fullscreen and you can't see the layout switcher temporarily being different for the running life of the program. It switches back to its default layout any time I focus on another window, regardless of the state of Share State Among Window [No | All | PerProgram] 9) Workarounds kill fcitx so it doesn't switch back to the default layout, or change the default layout switch to qwerty play the game switch back after the game ends hope the config file never gets corrupted Or, write a script that'll reverse-corrupt the file and hope it's always at the correct ± level of corruption. Or, reverse-corrupt the config file, then set it read-only as above.
×
×
  • Create New...