Some keys are occasionally "locked down" to the ga
Posted: 28 Sep 2007, 21:13
Occasionally, at random points in the game, one or more of my controls will be interpreted as being held down constantly. This is not a problem with the keyboard, and in fact The Mana World is the only program in which this occurs; even while it's happening, switching to another program will not result in the locked key being exhibited there.
Sometimes the lock is on attack, so that I automatically attack any enemy directly in front of me; this is invariably accompanied by autopickup (a separate key). I don't really mind this, since it makes some actions more convenient, but I'd like to know a dependable way for enabling/disabling it as I choose.
What really hampers play is when I get auto-lock on the down arrow. This plagues me a lot more often than auto-fire/pickup has been available to me. It becomes impossible to stand still except by finding a wall object to prop myself up against. Pressing up during auto-lock overwrites the down for as long as it's held, making it at least feasible to move places, but in this state it is not possible to avoid having at least one of up or down guiding my movement at absolutely all times. Furthermore, talking to N/PCs is far more difficult, and in general a game like this with the player having the down control involuntarily held would not be considered a playable game, especially in this genre.
While down is locked, the joystick cannot override this (up still works, but left or right alone cannot exist; they only result in diagonal movement). Adding to the removal of playability, there's no option to "disable keyboard controls" or at least those that are replicated in function by the joystick. The mouse can override this, resulting in straight left or right movement but only as long as the mouse is continuously held down. Once it's released and the player stops at the last pointed position, keyboard down lock kicks in immediately. On one occasion I was briefly afflicted with a lock on "down being overridden by up", rendering the entire Y-axis worthless and making it completely impossible to get anywhere meaningful without using the mouse.
So I'd like to know...what's the cause of all this nonsense? Sometimes it goes away on its own, but when it doesn't, this affliction can live through disconnect and reconnect, making me wonder if it's even possible for something on the client side to be behind this. After I started looking for information on this problem, I've tried:
-disconnecting for 15 minutes and coming back: problem was not fixed
-disconnecting for 30 minutes: problem was fixed
-After the problem had come back, I left for several hours and came back, to find that it wasn't fixed...
-but a short 1 minute disconnect and return had the problem fixed again.
-It returned yet again (this time accompanied by autofire) and I disconnected twice for short periods then once for a long period. Neither of the first two had it fixed on reentry. It was fixed briefly after the long disconnect, but returned after less than a minute.
I'm running Fedora 7 Linux with manaworld-0.0.22.2, the most recent version of the package to appear in the Fedora Extras repository.
Anything we can figure out to erase this control flaw and prevent it from coming back would be appreciated.
Sometimes the lock is on attack, so that I automatically attack any enemy directly in front of me; this is invariably accompanied by autopickup (a separate key). I don't really mind this, since it makes some actions more convenient, but I'd like to know a dependable way for enabling/disabling it as I choose.
What really hampers play is when I get auto-lock on the down arrow. This plagues me a lot more often than auto-fire/pickup has been available to me. It becomes impossible to stand still except by finding a wall object to prop myself up against. Pressing up during auto-lock overwrites the down for as long as it's held, making it at least feasible to move places, but in this state it is not possible to avoid having at least one of up or down guiding my movement at absolutely all times. Furthermore, talking to N/PCs is far more difficult, and in general a game like this with the player having the down control involuntarily held would not be considered a playable game, especially in this genre.
While down is locked, the joystick cannot override this (up still works, but left or right alone cannot exist; they only result in diagonal movement). Adding to the removal of playability, there's no option to "disable keyboard controls" or at least those that are replicated in function by the joystick. The mouse can override this, resulting in straight left or right movement but only as long as the mouse is continuously held down. Once it's released and the player stops at the last pointed position, keyboard down lock kicks in immediately. On one occasion I was briefly afflicted with a lock on "down being overridden by up", rendering the entire Y-axis worthless and making it completely impossible to get anywhere meaningful without using the mouse.
So I'd like to know...what's the cause of all this nonsense? Sometimes it goes away on its own, but when it doesn't, this affliction can live through disconnect and reconnect, making me wonder if it's even possible for something on the client side to be behind this. After I started looking for information on this problem, I've tried:
-disconnecting for 15 minutes and coming back: problem was not fixed
-disconnecting for 30 minutes: problem was fixed
-After the problem had come back, I left for several hours and came back, to find that it wasn't fixed...
-but a short 1 minute disconnect and return had the problem fixed again.
-It returned yet again (this time accompanied by autofire) and I disconnected twice for short periods then once for a long period. Neither of the first two had it fixed on reentry. It was fixed briefly after the long disconnect, but returned after less than a minute.
I'm running Fedora 7 Linux with manaworld-0.0.22.2, the most recent version of the package to appear in the Fedora Extras repository.
Anything we can figure out to erase this control flaw and prevent it from coming back would be appreciated.