Viewing Issue Simple Details Jump to Notes ] Wiki ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0011095 [DCSS] Bug Report minor always 2017-06-08 19:18 2018-05-03 03:14
Reporter moxian View Status public  
Assigned To advil
Priority normal Resolution done  
Status resolved   Product Branch 0.21 ancient branch
Summary 0011095: Polearm and ranged tabbing is broken when 1-9 keys are bound to CMD_TARGET_*
Description I have the following bindingsin my rcfile (because my numpad is weird and I have no numlock):

bindkey = [4] CMD_TARGET_LEFT
bindkey = [2] CMD_TARGET_DOWN
bindkey = [6] CMD_TARGET_UP
bindkey = [8] CMD_TARGET_RIGHT
bindkey = [7] CMD_TARGET_UP_LEFT
bindkey = [9] CMD_TARGET_UP_RIGHT
bindkey = [1] CMD_TARGET_DOWN_LEFT
bindkey = [3] CMD_TARGET_DOWN_RIGHT

With this, when I have a monster to the north-west of me with 1 or more spaces between us (but see note below), when I press Tab wielding a polearm or a launcher, I do not get to attack the monster. See attachment.

I haven't figured all the details, but depending on the positioning, I can end up targeting not only myself (and fail to do anything at the prompt as a result), fail to attack because "you cannot see that place" or because "you can't reach that far". I also think I witnessed (but cannot reproduce) a dangerous "you attack empty space" one (when this is not only an inconveniece, but the turn is actively wasted).

Removing the bindings solves the problem. I haven't checked whether removing only some of them would help.

I'm not sure when exactly this happens, as *sometimes* I can Tab stuff just fine, but othertimes I get this weird glitch. When reproducing it locally, wizmode-blinking around monster, I get the bug 100% of the time when not adjacent, but in real game some attacks work fine.
Additional Information
Tags No tags attached.
Attached Files png file icon tab-fail.PNG [^] (323,376 bytes) 2017-06-08 19:18

- Relationships

-  Notes
(0032222)
advil (administrator)
2018-05-03 03:14

Thanks for the report, this is fixed in https://github.com/crawl/crawl/commit/d5c8bedc3321 [^]

The trick with reproducing this bug was to use the *exact* bindings, which I suspect contain a mistake relative to what was intended (or it's definitely a weird numpad) - 6 and 8 are swapped relative to the usual position on a numpad, and the bug resulted in up getting mapped to 6 and then (incorrectly) mapped to right, and right getting mapped to 8 and then to up, swapping the two. (So the bug doesn't manifest unless the keymapping does something different than a numpad would.) This still shouldn't break autofight, of course.

- Issue History
Date Modified Username Field Change
2017-06-08 19:18 moxian New Issue
2017-06-08 19:18 moxian File Added: tab-fail.PNG
2018-05-03 03:14 advil Note Added: 0032222
2018-05-03 03:14 advil Status new => resolved
2018-05-03 03:14 advil Fixed in Branch => 0.22 development branch
2018-05-03 03:14 advil Resolution open => done
2018-05-03 03:14 advil Assigned To => advil


Mantis 1.1.8[^]
Copyright © 2000 - 2009 Mantis Group
Powered by Mantis Bugtracker