# User:FIQ/DevTeam
Below is a list of messages sent to the DevTeam for anyone interested, starting from August 28th 2017. Most, but not all, concern bugs in NetHack 3.6.0.

Contents

1 Sent via mail

1.1 Rogue starting inventory -- "+9" lockpicks
1.2 Wand of teleportation quirks in muse
1.3 Own issues on the dev bugtracker
1.4 Cursesgraphics as a proper symbol set
1.5 curses menu width behaviour
1.6 regarding user-defined SYMBOLS

2 Sent using the bugtracker

2.1 Monks and martial arts
2.2 Lycanthropy and polymorph control
2.3 Github PRs + 3.6.0 statuscolors
2.4 Conflict and player monsters
2.5 No potion handling in thitu
2.6 Vorpal Blade exploit
2.7 Weak from hunger vs sustain ability
2.8 Major pet AI bug
2.9 Minor text issue in data.base for EotO
2.10 Pet displacement during travel
2.11 Minor scroll reading quirk
2.12 flooreffects can credit the player erroneously + panic
2.13 Genociding slimes should stop sliming
2.14 Addressing a MKoT TODO in a commit
2.15 Dormant bug with artifact charging
2.16 hmonas and shades
2.17 Explosions and monsters stuck to you
2.18 recent #adjust changes
2.19 "Count: x" abuses pline
2.20 Genocide exploit
2.21 Improved handling of floor items/features in prompts
2.22 AD_SITM vs AD_SEDU
2.23 Passive aggression and Elbereth
2.24 DECgraphics in the curses windowport

3 Bugs reported by others

3.1 Untamed trapped pet rendering as player
3.2 Some polyforms that can wear armor with P but not W
3.3 Iron golem polyform gets two gushes of water from a rust trap
3.4 Rust damage in iron golem polyform is inconsistent
3.5 whatis behaves weirdly with plurals
3.6 Monsters are sometimes not drawn when they open a door
3.7 Flying monsters are immune to boulder traps, flying players aren't
3.8 Pit trap damage when moving between adjacent pits
3.9 Panic when selection floodfilling large areas

Sent via mail
Rogue starting inventory -- "+9" lockpicks
(Sent 2017-08-27 22:19 UTC)
Status: Fixed in 06d211f75c76a69dcb29e5c5a7c2c10f63cc7d4d
Hi.
Rogues seem to start with a lockpick with the spe 9. Why is that? Is it for historical reason (was introduced with 3.3.1 [wiki note: incorrect, it was introduced in 3.0] it seems), or was it just a typo?
/FIQ

Wand of teleportation quirks in muse
(Sent 2017-08-30 15:58 UTC)
Status: Fixed in 8d1e0d17565ca7567cd6c75565a3e5c6e87f8db1
Hi.
While backporting a FIQhack change into a bilious patch for 3.6.0, I reordered some of the musables (as part of the patch). Notably, MUSE_WAN_TELEPORTATION was changed to 13 from 15. The source didn't like this; this made MUSE_FIRE_HORN and MUSE_WAN_TELEPORTATION the same value which interfered in using offensive items. The MUSE_WAN_TELEPORTATION entry should probably be removed from m.has_offensive, because it can't actually be reached.
Another alternative is to combine the "enums" into a single one, to prevent cases like this, so that you can use one item for several cases.
/FIQ

Own issues on the dev bugtracker
(Sent 2017-09-24 01:52 UTC)
Status: No reply yet.
Hi.
It would be very nice if it was possible for someone to see a list of their own bug reports to the bugtracker, possibly authored by email. This would allow me to later reference my own reports to you without having to remember to save the report. For example, in my last report (potion handling in thitu), I accidentally backed out in my browser, making me unable to gather the bug ID and other relevant info for future reference. Another dev helpfully gave me the bug ID, but not having to do this would be great.
/FIQ

Cursesgraphics as a proper symbol set
(Sent 2019-10-14 09:18 UTC)
Status: Replied. Fixed in d0c4d27a507b390cc13d85a49d5876c3f2428109
Hi!
While I don't know the history of this symset and the reason the original author of the windowport didn't just make DECgraphics work in first place over adding cursesgraphics, one solution would be to add it as a secondary DECgraphics symset, a bit like how IBMgraphics has 3 different variations. Would that work as solution to the problem brought up about the cursesgraphics symset in 027ce7c8b9c04f2ad64632a107536cd173dfb07f?
I could make another patch with such a fix.
/FIQ

curses menu width behaviour
(Sent 2019-10-18 00:55 UTC)
Status: Replied. Implied WONTFIX.
Hi!
Is there a known reason for why menu width
is restricted to half the screen except if a
header is wider than that? Besides the hack
to work-around it recently added for symset
options-wise, it simply doesn't seem like a
reasonable limitation to me in first place.
What if I have a larger inventory with rusty
stuff? What if I am using an 80x24 screen?
That makes the options menu have similar
quirky word-wrapping at times (can be seen
by disabling statushilites).
I was messing with explicit inventory display
in curses when I stumbled upon this, IMO
dubious, feature, trying to allow the inventory
window (partial or full) to appear on top of the
sidebar, to avoid redundant displays. If this is
not a desired feature, please feel free to tell
me that.
/FIQ

regarding user-defined SYMBOLS
(Sent 2019-10-23 14:51 UTC)
Status: Replied. WONTFIX.
Hi.
It was pointed out to me on IRC that the new Curses symset
handling overrides SYMBOLS when it loads the curses symset
as fallback. I also saw a reddit thread about this (which
you seem to have replied to, actually). Would it be
worthwhile to add a parameter to load_symset to still
respect user-defined symbols, or would that be too
invasive? That would allow windowports that want to change
the symset default to still respect SYMBOLS in case the
user changed it but didn't change the underlying symset?
Alternatively, create a new function whose purpose is to
load user-defined symbols only and use it as post-processing
after loading the options file (to also allow the player to
define SYMBOLS before OPTIONS=symset without problems),
reading from a saved user-defined symset loaded in memory.
Basically, have a 3rd symset index (USERSET or something)
that saves the SYMBOLS and just overrides PRIMARY after
loading the options.
/FIQ

Sent using the bugtracker
Monks and martial arts
(Reply: http://sprunge.us/GehF)
Below is what you submitted to The_DevTeam on Wednesday, August 30, 2017 at 12:09:36
The ID number for this message is '#H5955'
mailversion:
master:1.57
nhversion:
3.6.0
nhfrom:
Our git repository - please list branch and ref below
hardware:
Desktop 64bit computer
software:
30aea05f47073bec06127af3d33f7d851ab2fc60
comments:
A lot of players end up using weapons when playing Monks eventually due to their comparably weak martial arts (despite the bonuses). To improve their martial arts, I suggest making the enchantment of your gloves matter if fighting bare-handed, at least if doing so with martial arts with Gauntlets of Power.

Lycanthropy and polymorph control
(Fixed in 5710944258a683ad5219d262ea055ac9a41f0571)
Below is what you submitted to The_DevTeam on Tuesday, September 5, 2017 at 11:55:44
The ID number for this message is '#H5990'
mailversion:
master:1.58
nhversion:
3.6.0
nhfrom:
Our git repository - please list branch and ref below
hardware:
Linux x64 desktop
software:
056ac5fe6428f56b855e78090a2485dc7f2d0687
comments:
Lycanthropy prompts are very sudden, and answering y can potentially destroy armor (werewolf lycanthropy). So it should be possible to set up paranoid for that prompt.

Github PRs + 3.6.0 statuscolors
(This message got stuck in a spam filter at first)
Below is what you submitted to The_DevTeam on Thursday, September 7, 2017 at 21:17:49
The ID number for this message is '#H6006'
mailversion:
master:1.58
nhversion:
3.6.0
nhfrom:
Our git repository - please list branch and ref below
hardware:
Linux x64 computer
software:
70ac8a12af0957844d8078df80f7e227e3ff69b7
comments:
Hi. 
I don't know how frequently (if at all?) you follow the GitHub pull request list for your GitHub mirror at https://github.com/NetHack/NetHack/pulls . There's plenty of PRs there that should be noncontroversial (bug fixes/similar) where merging should be straightforward.
As for more complex/potentially controversial changes, I'd like to bring special attention to: 

The livelog PR at https://github.com/NetHack/NetHack/pull/31
All of tungtn's PRs
 - attack_mode to enhance safe_pet/confirm for various styles of play, https://github.com/NetHack/NetHack/pull/11 
 - colored walls, https://github.com/NetHack/NetHack/pull/6 

Also, I'm not sure if you've seen this bilious patch (also by tungtn). It's basically a rework of the 3.4.3 statuscolors patch, adapted to be more windowport-agnostic (which I think was the merit behind not porting said patch as part of 3.6.0), and contains all of the added configurability that you got with status_highlights (attribute gain/loss highlighting comes to mind), and would likely be very welcomed by the community. 
The patch can be found at: 
https://bilious.alt.org/?477
Sorry if this comes off as redundant or intrusive. I just wanted to remind you about these community enhancements, in case you wasn't aware of them. 
/FIQ

Conflict and player monsters
Below is what you submitted to The_DevTeam on Thursday, September 14, 2017 at 08:20:10
The ID number for this message is '#H6051'
mailversion:
master:1.58
nhversion:
3.6.0
nhfrom:
Our git repository - please list branch and ref below
hardware:
Linux x64 desktop
software:
cd8f0283529f6d66b01547f821cc67ff78d971e2
comments:
Player monsters are flavoured as basically being other advanturing players. Chatting with them even implies they are players. As such, they should ignore conflict, since conflict has no effect on players (for obvious reasons). 
There's also other things that could be done for enhanced symmetry (delayed stoning, skills, casting player spells...) but they're not nearly as easy (and noncontroversial) to change. 
/FIQ

No potion handling in thitu
(Fixed in 719af503e763b316cc6642c7584fff8402dd5955)
Below is what you submitted to The_DevTeam on Friday, September 22, 2017 at 14:52:21
The ID number for this message is '#H6104'
mailversion:
master:1.58
nhversion:
3.6.0
nhfrom:
Our git repository - please list branch and ref below
hardware:
Linux x64 desktop
software:
83056d45d78fba85f98f3ecac2804e1660e5feff
comments:
thitu, which is called from scatter among other things, lacks correct handling for potions, meaning you don't get the proper effect for them (potionhit()). I know at least one case where this matters: landmine scattering items, potions not being destroyed (1% saving throw), flings into the player's direction and has no potion effect.

Vorpal Blade exploit
(Fixed in 78756c9bd6ab760317b26f2d15f3e7a578149a12)
Below is what you submitted to The_DevTeam on Monday, September 25, 2017 at 19:47:26
The ID number for this message is '#H6125'
mailversion:
master:1.58
nhversion:
3.6.0
nhfrom:
Our git repository - please list branch and ref below
hardware:
Linux x64 desktop
software:
596bc643412465261ebffb6e726360e17ff14508
comments:
Hi! 
Due to improper updating of dieroll in uhitm, dieroll is not corectly updated when throwing things. This has several effects, but the major one is that you can "charge up" a behead with Vorpal by beheading in melee and then throwing it. Assuming it hits, it will behead 100% of the time until you do another melee attack, allowing you to behead, pick up, behead, rinse and repeat.
Found by barthouse on the GitHub issue tracker, I am just reporting it here for exposure. 
/FIQ

Weak from hunger vs sustain ability
(Fixed in 024e9e122576db664e37df0937cfb4c06c436e0c)
Below is what you submitted to The_DevTeam on Friday, September 29, 2017 at 17:42:14
The ID number for this message is '#H6144'
mailversion:
master:1.58
nhversion:
3.6.0
nhfrom:
Our git repository - please list branch and ref below
hardware:
Linux x64 desktop
software:
1027eacbcad68a7a402ac732a06429c1c4809125
comments:
Hi. 
When you become Weak, you lose 1Str. This is regained by 
going above weak. By doing this, you can increase your str 
higher than what it was at: 

Be hungry
Put on sustain ability
Become weak from hunger
Remove sustain ability
Eat something
Net result: +1str
This is a well-known issue that I assumed was fixed, but apparently wasn't. 
/FIQ

Major pet AI bug
(Fixed in e4db58bdf3376eddf9ad6416c0664975e7787035)
Below is what you submitted to The_DevTeam on Saturday, September 30, 2017 at 18:28:49
The ID number for this message is '#H6151'
mailversion:
master:1.58
nhversion:
3.6.0
nhfrom:
Our git repository - please list branch and ref below
hardware:
Linux x64 desktop
software:
1027eacbcad68a7a402ac732a06429c1c4809125
comments:
Pets use mtrack to cut down on oscillation. This is very 
problematic, because it causes pets to randomly turn around 
and go in the other direction, away from its master, a lot 
in corridors, especially if they outspeed you. 
Relevant code in dogmove.c: 

       k = has_edog&nbsp;? uncursedcnt&nbsp;: cnt; 
       for (j = 0; j &lt; MTSZ &amp;&amp; j &lt; k - 1; j++) 
           if (nx == mtmp-&gt;mtrack[j].x &amp;&amp; ny == mtmp-&gt;mtrack[j].y) 
               if (rn2(MTSZ * (k - j))) 
                   goto nxti; 

Solution: Remove the code 
This introduces another potential issue, depending on 
whether or not you consider it an issue or not. If a pet is 
far away from you in some corridor, they have the potential 
to get stuck. I see these solutions: 

Do nothing. The result is still much better than the current pet behaviour.
Enable the code if a pet is far away from its master (&gt;8 tiles seems appropriate)
Kill pets' mtrack if you use a whistle (tin/magic), restoring their willingness to follow you
No matter what, the mtrack should never run for leashed pets.
Use the same logic as 'travel' does for players. I can see the merit on not doing this in general due to performance concerns, but doing it only for pets should be OK.
Minor text issue in data.base for EotO
Below is what you submitted to The_DevTeam on Friday, October 6, 2017 at 17:57:09
The ID number for this message is '#H6189'
mailversion:
master:1.58
nhversion:
3.6.0
nhfrom:
Our git repository - please list branch and ref below
hardware:
Linux x64 desktop
software:
9a6c3b4192ddecb0d7ac8c0ab3c03d5b16dad643
comments:
Eyes of the Overworld's database entry contains this wording: "... and finally there is "the Eyes of the Overworld".". From in-game when asking about single artifacts, this wording is a bit odd and should probably be removed. 
/FIQ

Pet displacement during travel
Below is what you submitted to The_DevTeam on Monday, October 9, 2017 at 05:43:55
The ID number for this message is '#H6204'
mailversion:
master:1.58
nhversion:
3.6.0
nhfrom:
Our git repository - please list branch and ref below
hardware:
Linux x64 desktop
software:
024e9e122576db664e37df0937cfb4c06c436e0c
comments:
This commit: 715fd7e3d9aa109284f775f2b334ce96d054c4a2
makes travel displace pets rather than stop at them.
However, there is an issue: it doesn't consider pet
safety. This means that travel can do things like: 

displace pets into water, drowning them
displace pets into traps
Etc.

Minor scroll reading quirk
(Fixed in 4fad1ba3cca44c2a8553c92531912fa05de4ab8a. Note that the bug ID referenced is incorrect)
Below is what you submitted to The_DevTeam on Thursday, October 19, 2017 at 08:27:52
The ID number for this message is '#H6283'
mailversion:
master:1.58
nhversion:
3.6.0
nhfrom:
Our git repository - please list branch and ref below
hardware:
Linux x64 desktop
software:
da9c3f0ed47ca79f28a05994e3b93a1ab433b0d4
comments:
If your current monster form is of one that can normally talk, you will "pronounce the formula" on a scroll if blind -- even if you're currently being strangled.

flooreffects can credit the player erroneously + panic
Below is what you submitted to The_DevTeam on Thursday, October 19, 2017 at 17:51:35
The ID number for this message is '#H6285'
mailversion:
master:1.58
nhversion:
3.6.0
nhfrom:
Our git repository - please list branch and ref below
hardware:
Linux x64 desktop
software:
da9c3f0ed47ca79f28a05994e3b93a1ab433b0d4
comments:
Hi. 
If a monster is inside a pit trap or similar and 
flooreffects runs with a boulder (for example, from scrolls 
of earth -- both by players and monsters), it will run 
hmon. If this call kills, the player is credited -- whether 
he was the source or not. There's also other issues (for 
example, using player damage bonuses/etc). 
While trying to reproduce this issue, this happened. I was 
not able to reproduce this... My only theory for what 
caused this is monster entrapment not being cleared 
correctly when a pit is filled from scrolls of earth in 
some circumstances (I did successfully reproduce the 
original issue mentioned, too). 

Suddenly, the dungeon collapses.

deltrap: no preceding trap!
Generating more information you may report:

[0] /home/fiq/nh/install/games/lib/nethackdir/nethack() [0x48829e]
[1] /home/fiq/nh/install/games/lib/nethackdir/nethack() [0x4890be]
[2] /home/fiq/nh/install/games/lib/nethackdir/nethack(panic+0x229) [0x48b299]
[3] /home/fiq/nh/install/games/lib/nethackdir/nethack(deltrap+0x131) [0x57be8a]
[4] /home/fiq/nh/install/games/lib/nethackdir/nethack(flooreffects+0x3be) [0x459699]
[5] /home/fiq/nh/install/games/lib/nethackdir/nethack(drop_boulder_on_monster+0x94c) [0x53970f]
[6] /home/fiq/nh/install/games/lib/nethackdir/nethack(use_offensive+0x6f0) [0x4f9cff]
[7] /home/fiq/nh/install/games/lib/nethackdir/nethack(mattacku+0x1565) [0x4cd71b]
[8] /home/fiq/nh/install/games/lib/nethackdir/nethack(dochug+0xff3) [0x4f0a44]
[9] /home/fiq/nh/install/games/lib/nethackdir/nethack(dochugw+0x1d1) [0x4f0e38]
[10] /home/fiq/nh/install/games/lib/nethackdir/nethack(movemon+0xd8) [0x4e6141]
[11] /home/fiq/nh/install/games/lib/nethackdir/nethack(moveloop+0x1022) [0x41e342]
[12] /home/fiq/nh/install/games/lib/nethackdir/nethack(main+0x71e) [0x5b1020]
[13] /usr/lib/libc.so.6(__libc_start_main+0xea) [0x7f05effc843a]
[14] /home/fiq/nh/install/games/lib/nethackdir/nethack(_start+0x2a) [0x41d1ba]

Circumstances that might help reproduce the panic above: 

I genesis-ed a gnome and a hill orc
The hill orc was to read a scroll of earth while the gnome was trapped. The gnome should NOT die from the initial blow.
/FIQ

Genociding slimes should stop sliming
Below is what you submitted to The_DevTeam on Friday, October 20, 2017 at 19:39:54
The ID number for this message is '#H6292'
mailversion:
master:1.58
nhversion:
3.6.0
nhfrom:
Our git repository - please list branch and ref below
hardware:
Linux x64 desktop
software:
0bf824a81e67e4a4723f74aa34b3a6370734f1a7
comments:
Hi. 
Sliming consists of green slime slowly taking over your body. 
Thus, if you genocide green slimes during the process, it 
should probably stop. 
/FIQ

Addressing a MKoT TODO in a commit
Below is what you submitted to The_DevTeam on Thursday, November 2, 2017 at 06:30:28
The ID number for this message is '#H6375'
mailversion:
master:1.58
nhversion:
3.6.0
nhfrom:
Our git repository - please list branch and ref below
hardware:
Linux x64 desktop
software:
27e5f025f12c4e0cdde6f023cd63ca10b75252d8
comments:
Hi! 
I made this pull request a while back to address a TODO 
mentioned in a commit by PatR 
(5c77360023f84a9a709f52fac10cf43fd3167d5f). Since, to my 
knowledge (as is clear by the recent pet AI fixes merge), 
not everyone reads pull requests, I add it here too for 
exposure, in case you find it of any use. 
Link to pull request: 
https://github.com/NetHack/NetHack/pull/62
For those unable to use GitHub, I'll also post it below in 
patch format: 
http://home.fiq.se/nethack/0001-MKoT-change-detect-unseen.patch
/FIQ

Dormant bug with artifact charging
(Fixed in c59b7bf11b5fa7cea516f63da0615d8fe7d23072)
Below is what you submitted to The_DevTeam on Saturday, November 4, 2017 at 09:32:28
The ID number for this message is '#H6391'
mailversion:
master:1.58
nhversion:
3.6.0
nhfrom:
Our git repository - please list branch and ref below
hardware:
Linux x64 desktop
software:
647ea55b1ac02f10ab88e4956fd8630d2503261d
comments:
Hi! 
This code in artifact.c for blessed charging: 

           b_effect = (obj-&gt;blessed 
                       &amp;&amp; (Role_switch == oart-&gt;role || !oart-&gt;role)); 

Isn't correct. When "no role" is set, it is to NON_PM, 
which is -1. The "!oart-&gt;role" would only apply if role is 
set to PM_GIANT_ANT (0). It should rather check for 
oart-&gt;role == NON_PM. 
/FIQ

hmonas and shades
Below is what you submitted to The_DevTeam on Thursday, November 9, 2017 at 05:48:18
The ID number for this message is '#H6422'
mailversion:
master:1.58
nhversion:
3.6.0
nhfrom:
Our git repository - please list branch and ref below
hardware:
Linux x64 desktop
software:
c2f767e1feb3a0f06ea66c24ca8e92ee897734a3
comments:
Hi! 
Shade interaction with hmonas has a few issues. Namely, 
only boots for kicking attacks seem to be handled. The 
following is missing: 

Blessed gloves for touch attacks should deal 1d4
Blessed OR artifact helm for headbutts. Artifacts should probably allow the attack to proceed as normal, blessed should just deal 1d4.
Blessed cloak-&gt;body armor-&gt;suit for hugs should deal 1d4
Also, this might just be my opinion, but while I was 
messing with uvm/mvm/mvu combat, I personally decided to 
handle shades like this, for consistency: 
Material touching: 

Weapon attacks: weapon-&gt;gloves-&gt;rings
Kicks: boots
Headbutts: helms
Touch: gloves
Hugs: cloak-&gt;suit-&gt;shirt
Material effects: 

Silver: +1d20 vs silver-haters
Blessed: +1d4 vs undead
Artifacts: allows attacks vs shades to proceed as normal, otherwise they will only take silver+blessed damage
/FIQ

Explosions and monsters stuck to you
(Fixed in 4dbfb4abeb08670719b9d1cdec7257c9de4bf2ad)
Below is what you submitted to The_DevTeam on Sunday, November 19, 2017 at 08:17:55
The ID number for this message is '#H6489'
mailversion:
master:1.58
nhversion:
3.6.0
nhfrom:
Our git repository - please list branch and ref below
hardware:
Linux x64 desktop
software:
c9153a22efbf97ea820113a0d93fb5afa6e6bca4
comments:
Hi. 
Monsters stuck to the player will take double damage from 
explosions. Why? 
/FIQ

recent #adjust changes
(Fixed in d7f26afba85801f41547de49e5564fc21ad38ceb)
Below is what you submitted to The_DevTeam on Saturday, December 2, 2017 at 06:48:14
The ID number for this message is '#H6571'
mailversion:
master:1.58
nhversion:
3.6.0
nhfrom:
Our git repository - please list branch and ref below
hardware:
Linux x64 desktop
software:
90405235e5037d033b90af0af967d290f62225cc
comments:
Hi! 
This commit: 90405235e5037d033b90af0af967d290f62225cc 
(address #H6552 - #adjust behavior) 
Changed it so that you could #adjust 2 a c if a contained 2 
objects, to not touch the content in b. While this works, 
I don't really like this approach because it means you need 
to know exactly how many 'a's there is, meaning you might 
first have to look at your inventory, and then use that 
number. It's not a huge loss,  but IMO it would be far more 
convenient if #adjust a c simply moved everything in 'a' to 
'c' without messing with other mergable stacks. After all, 
you can already merge everything if you want to, like how 

adjust a c behaves, into c, by performing #adjust c c.
Basically, I suggest that #adjust c c becomes the only way 
to merge everything, while #adjust a c only merges a into 
c. I think this would be more straightforward way to handle 
things. 
/FIQ

"Count: x" abuses pline
(Reply: http://sprunge.us/NgPN)
Below is what you submitted to The_DevTeam on Tuesday, December 5, 2017 at 06:18:57
The ID number for this message is '#H6589'
mailversion:
master:1.58
nhversion:
3.6.0
nhfrom:
Our git repository - please list branch and ref below
hardware:
Linux x64 desktop
software:
fdf07f932b237e8c87b776250e528a546aebdbae
comments:
Hi. 
When the user wants to do something multiple times (for 
example, 100s to recover), the engine sends the count output 
as a message line. This can look rather awkward if a 
windowport has more than a single line. However, trying to 
handle this isn't really feasible in any other way rather 
than pattern matching the message output. This introduces 
issues if you, for example, name something "Count: 3". You 
can work-around this somewhat by only matching "Count: \d" 
as a regex, or similar, but the fact that you even have to 
do this is rather silly. I think a better approach here 
would be to create a new windowport function which looks 
something like this: 

   int 
   win_count(int *count) 

which returns the given non-count key (i.e. command), and 
sets *count to the given count, and returns -1 if the 
user cancelled the count. The generic windowport function 
(genl_count) could work similar to how get_count currently 
works for backwards compatibility. 
This allows a windowport to give a special UI for counts, 
without avoiding having to do silly things with risks for 
false positives. As a bonus, you avoid having things like 
this in message history for windowports where you implement 
it: 

   Message History 

   Count: 3491 
   Count: 349 
   Count: 34 
   You see no objects here. 

I could create a patch for this if that's enough to have it 
fixed. 
/FIQ

Genocide exploit
Below is what you submitted to The_DevTeam on Thursday, December 7, 2017 at 13:51:11
The ID number for this message is '#H6597'
mailversion:
master:1.58
nhversion:
3.6.0
nhfrom:
Our git repository - please list branch and ref below
hardware:
Linux x64 desktop
software:
5e7327cb39a25a12896744c3043077f9c8f58c0d
comments:
Hi! 
Making you "dead inside" (genociding your own role/race while 
polymorphed) will completely stop monsters from attacking you 
in any way. This can trivialize the game if you know what you 
are doing. 
/FIQ

Improved handling of floor items/features in prompts
Below is what you submitted to The_DevTeam on Sunday, January 7, 2018 at 17:30:25
The ID number for this message is '#H6722'
mailversion:
master:1.58
nhversion:
3.6.0
nhfrom:
Our git repository - please list branch and ref below
hardware:
Linux x64 desktop
software:
03f8a487d1d889784437f9a0da27a6d2b4cac46f
comments:
Hi! 
Something that I've always found rather awkward/annoying 
when playing anything NH3, or variant thereof (except for 
SLASH'EM) instead of something that is based on NH4 is that for various object prompts such as eating, dipping, and so 
on, you are always prompted for each individual item and 
answering ynq to it. There is 2 major problems with this: 

If there is several corpses on the floor when eating,
 offering or similar, and you just want to mess with 
 things in the inventory, you first have to dismiss each 
 and every prompt. A similar thing happens if you want to 
 eat/offer the last possible thing in the selection. 

There are dangerous potential typos involving things with
 the letter 'y' in the inventory. "Eat what?" when the 
 player expected a corpse on the floor, 'y', 
 "The cockatrice corpse tastes terrible!  You turn to 
 stone..." 

There are other issues, but those are by far the worst 
offenders. 
I took the time and decided to write a patch against 3.6.1 
to address this issue, in case the major reason stopping 
this was technical in nature. 
The patch can be found at: http://home.fiq.se/getobj.patch
It refactors getobj to be able to handle floor items and 
dungeon features. It isn't based off any code, but rather 
was written from scratch. It changes the objclass array 
approach and special casing every single prompt, into using 
a callback instead for whether objects are valid or not, or 
whether they're encouraged (show in the [foo] prompt), or 
valid but not encouraged (can be selected, but doesn't show 
in said prompt). This makes getobj somewhat cleaner and 
easier to read, and easier to extend without having to add 
special cases to it. If menustyle is set to anything other 
than full, floor prompts work as they worked previously. 
Screenshot of the thing in action, if anyone cares: 
http://home.fiq.se/nh/getobj.html
/FIQ

AD_SITM vs AD_SEDU
Below is what you submitted to The_DevTeam on Thursday, January 11, 2018 at 11:41:20
The ID number for this message is '#H6746'
mailversion:
master:1.58
nhversion:
3.6.0
nhfrom:
Our git repository - please list branch and ref below
hardware:
Linux x64 desktop
software:
f9144fa57658db9b5893434f511e64e28b78139b
comments:
Hi! 
This is a minor concern, but I think that instead of having 
an animal check for AD_SITM/AD_SEDU that it would make more 
sense to make AD_SITM the "animal steal" attack, and having 
AD_SEDU be the nymph stealing attack. This enables creation 
of monsters that aren't animals with monkeysteal (muggers?) 
and vice versa for some kind of strange animal. Not exactly 
a critical bug, just figured I'd suggest it. 
/FIQ

Passive aggression and Elbereth
Below is what you submitted to The_DevTeam on Monday, March 19, 2018 at 15:45:04
The ID number for this message is '#H6978'
Subject:
Passive aggression and Elbereth
oldver:
3.6.1
nhfrom:
Our git repository - please list branch and ref below
hardware:
Linux desktop
software:
7238803b2509cd8d7b7a316b1c1c214c0a0a2b92
comments:
Hi! 
Elbereth vanishes if you anger a monster. Makes sense. However, there needs to be a check for flags.mon_moving, because otherwise, Elbereth can vanish from something passive (from your side), like them stumbling into a trap you made (This might be the only one, not sure).
Also, some minor feedback for the bug reporter: It would be useful if "NetHack came from" included a public server to clarify reports coming from NAO, hardfought, or similar. 
In addition to this, the new NetHack version field for recent releases in the form seems a bit flawed. I build NetHack releases using `make install` after fetching the updated source tree. After doing this, version is still rather unspecific (moreso than I assume you want, at least): 

[682][fiq@fiq-desktop ~/NetHack]$  
../nh/install/games/nethack --version 

Unix NetHack Beta Version 3.6.1-0 - last build Mon Mar 19 20:35:42 2018. 
/FIQ

DECgraphics in the curses windowport
Below is what you submitted to The_DevTeam on Saturday, October 12, 2019 at 10:52:18
The ID number for this message is '#H9299'
Subject:
DECgraphics in the curses windowport
oldver:
(please select version)
gitver:
6cbf10d97447970daa3e1e75a1ccece11bd5a2ed
nhfrom:
Our git repository - please list branch and ref below
hardware:
Desktop
software:
Arch Linux, using Konsole 19.08.2 with working Unicode support
comments:
Hi.
Curses attempts to disable DECgraphics configuration but doesn't quite succeed. In addition to this, you can (uselessly) enable it ingame. Instead of properly removing the option (or just removing the checks, since that wouldn't really be any different from how tty handles it), I removed the checks that tries to disable it, but also made the Curses windowport able to handle DECgraphics correctly. This was done by slightly modifying the curses_convert_glyph function to have a operation mode that handles DECgraphics fully.
Here is a GitHub pull request: https://github.com/NetHack/NetHack/pull/230
Here is a .patch of the changes: http://home.fiq.se/decgraphics.patch
Also, a minor typo I found while doing this: dat/symsets confuses the up/dnladder symbols with each other in DECgraphics for the comments (but I believe the actual symbol used is correct).
/FIQ

Bugs reported by others
Untamed trapped pet rendering as player
(Fixed in 3f9522041c3b57daf30361ecbf5e4a24c2c4b6e0)
Below is what you submitted to The_DevTeam on Thursday, December 7, 2017 at 23:10:20
The ID number for this message is '#H6598'
mailversion:
master:1.58
nhversion:
3.6.0
nhfrom:
Our git repository - please list branch and ref below
hardware:
Bug should be unrelated to hardware
software:
Latest vanilla NetHack 3.6.1-dev, as of commit 5e7327cb39a25a12896744c3043077f9c8f58c0d
comments:
Untaming a pet by trying to displace it out of a trap diagonally, when the pet cannot travel diagonally (due to NODIAG movement or it not being able to squeeze), causes the player's symbol to be rendered where the pet was.
To reproduce: get a tame grid bug to become trapped in a pit or bear trap, and attempt to displace it out of the trap diagonally until it untames. When this happens, it will render as the player's symbol.
This is caused by the logic that untames a pet displacing out of a trap, and calls newsym() on the pet's location so it doesn't render it as tame anymore, happening before the logic that checks whether the player and pet can actually swap places. At the time, though, domove() has also assumed that the player has already moved to that spot (it needs to get unmoved later), hence newsym() renders the player there instead.
Unrelated issue I noticed and am not sure whether it is a bug - there is a spoteffects() call later in domove that always gets called regardless of whether the player moved. In situations like this where the player did not move, this can lead to messages such as "You stop. Your grid bug can't move diagonally. There is a bear trap here. A bear trap closes on your foot!" (which also involves pets that can't move diagonally).
--Phol ende wodan (talk) 04:13, 8 December 2017 (UTC)

Some polyforms that can wear armor with P but not W
(Fixed in 062748c69554e276ad798e92c69ce13a27f2985f)
Below is what you submitted to The_DevTeam on Tuesday, December 19, 2017 at 10:48:47
The ID number for this message is '#H6648'
mailversion:
master:1.58
nhversion:
3.6.0
nhfrom:
Our git repository - please list branch and ref below
hardware:
Bug should be unrelated to hardware
software:
Latest 3.6.1-dev, as of commit 876d50992175e15e1ada648397ab6996102af727
comments:
There are at least some polymorphable forms that can wear armor (that they possibly shouldn't be able to) by using the P command. 
This was tested with a polyself to quivering blob and putting on boots. In this form, the W command prints "Don't even bother." without even trying to let the player pick an item, whereas the P command asks the player what they want to put on (listing jewelry and not armor, as usual) but still accepts the inventory letter of armor as valid, and allows the character to wear that armor.
--Phol ende wodan (talk) 15:49, 19 December 2017 (UTC)

Iron golem polyform gets two gushes of water from a rust trap
(Fixed in 66242a0691e41a3104a696a5087c2c95a9aa6a7f)
Below is what you submitted to The_DevTeam on Monday, January 1, 2018 at 10:25:01
The ID number for this message is '#H6707'
mailversion:
master:1.58
nhversion:
3.6.0
nhfrom:
Our git repository - please list branch and ref below
hardware:
Intel x64 laptop
software:
Latest vanilla 3.6.1-dev, as of bb9738ff0ea3722b8cdac03bc712260a7cbbfb33
comments:
When the player is polymorphed into an iron golem, a rust trap gives the impression of triggering twice. The first gush of water hits an armor slot like normal, and doesn't deal any damage to the iron golem form. The second gush of water always hits "you" and causes the guaranteed-kill rust damage. This causes message combinations such as "A gush of water hits your left arm! A gush of water hits you! You are covered in rust!" --Phol ende wodan (talk) 15:26, 1 January 2018 (UTC)

Rust damage in iron golem polyform is inconsistent
Below is what you submitted to The_DevTeam on Tuesday, January 9, 2018 at 10:20:37
The ID number for this message is '#H6735'
mailversion:
master:1.58
nhversion:
3.6.0
nhfrom:
Our git repository - please list branch and ref below
software:
latest commit 03f8a487d1d889784437f9a0da27a6d2b4cac46f
comments:
The sources of rust damage to a player polymorphed into an iron golem are oddly inconsistent.
Immersion in water deals 2d6 damage to mh and mhmax, and will not rehumanize if you are unchanging. Continued immersion in water will repeat this damage on 20% of movement turns, but if you decide to rest in one place underwater, you will take no further damage.
A rust trap will deal full maximum monster form HP (saved by half physical damage), and will not rehumanize if you are unchanging.
A rust monster's touch attack always instantly rehumanizes you, without bothering with damage, and ignoring any unchanging you have.
There appears to be no code handling rusting from a rust monster's passive attack, so you can hit a rust monster barehanded as an iron golem with no problems.
This is not necessarily a problem that needs to be fixed, but is there a good justification for keeping the behavior this way?

whatis behaves weirdly with plurals
Below is what you submitted to The_DevTeam on Saturday, February 17, 2018 at 14:29:57
The ID number for this message is '#H6861'
Subject:
whatis behaves weirdly with plurals
nhversion:
3.6.0
nhfrom:
Our git repository - please list branch and ref below
software:
latest commit 544b9015ff78a73ac91b5e76f6c3a1405e6f703f
comments:
When the whatis command is used with a plural string, it behaves oddly. The code that produces the overlaying window with the encyclopedia text runs twice, which in most cases leads to a second, empty, window being displayed after the first one.
This can be seen with e.g. typing "kittens" into the prompt - the first window shows up with the encyclopedia entry for "kitten", and then after dismissing the --More-- prompt, another --More--, as part of an empty window, shows up on its own.
It is also rather more prominent when using the whatis command to look at a plural object. For instance, I dropped two arrows on the ground and looked at them with the / command. It first prompts for 'More information about "2 arrow"?' (and answering yes brings up the arrow encyclopedia entry), and then prompts for 'More information about "2 arrows"?' (and answering yes brings up the empty window). 
The code decides to check the encyclopedia for both the singularized and non-singular forms if they differ, which makes sense, but I'm not sure why it decides to call display_nhwindow() twice.
Actually, looking closer, it seems that this is partially a result of found_in_file not being reset to FALSE properly on the second pass, but applying that fix results in "I don't have any information on those things." being printed instead of the second window being displayed.

Monsters are sometimes not drawn when they open a door
Below is what you submitted to The_DevTeam on Thursday, March 1, 2018 at 16:46:12
The ID number for this message is '#H6928'
Subject:
Monsters are sometimes not drawn when they open a door
gitver:
Fresh build of ee64ef548264cde0ea3de2bfe5e7064fb3588aa4
nhfrom:
Our git repository - please list branch and ref below
hardware:
software:
Linux, gcc, etc.
ee64ef548264cde0ea3de2bfe5e7064fb3588aa4
comments:
When a monster opens a door and walks onto it, depending on where the player is positioned, the monster may not be drawn on the open door though the door symbol does gets updated to its open state.
To reproduce, find a corridor leading into a room, preferably one that doesn't branch in the vicinity or have multiple doors. Make sure the door is closed and unlocked, create a hostile gnome or goblin out in the corridor, then teleport into the room and position yourself anywhere along the same wall as the door is on, but not adjacent to the door. (I tested this 8 squares away from the door and it still happened, so I doubt the distance matters as long as it's not adjacent.)
Example layout: 

###o##
-----+--
@......|
.......|

(Note that the monster is in fact opening and stepping onto the door square; this can be confirmed by the presence of "The monster opens a door" message, and quaffing uncursed monster detection immediately afterwards will show the monster on the door. This might be a vision bug rather than a monmove bug - the message shouldn't display unless the monster passes a canspotmon() check.)

Flying monsters are immune to boulder traps, flying players aren't
Below is what you submitted to The_DevTeam on Thursday, March 15, 2018 at 10:17:10
The ID number for this message is '#H6963'
Subject:
Flying monsters are immune to boulder traps, flying players aren't
oldver:
3.6.1
gitver:
c28b44c27c7adb2f48bab495f12e81229f57a062
nhfrom:
Our git repository - please list branch and ref below
software:
c28b44c27c7adb2f48bab495f12e81229f57a062
comments:
Rolling boulder traps behave inconsistently between monsters and players; specifically, a levitating or flying player will trigger the trap but a flying monster won't. (A monster that levitates but doesn't fly will in fact trigger the trap; however, I think the code assumes that all floaters have M1_FLY.)
The exact mechanism of what causes the "Click!" and the trap to be set off isn't made clear, but the fact that flying monsters are immune implies that it's a ground-based trap.

Pit trap damage when moving between adjacent pits
Below is what you submitted to The_DevTeam on Friday, April 20, 2018 at 18:11:46
The ID number for this message is '#H7074'
Subject:
Pit trap damage is triggered whem moving from pit to pit
gitver:
01abfa8c3dfa5eb4da7275266ac49f7fdd057062
nhfrom:
Our git repository - please list branch and ref below
hardware:
software:
01abfa8c3dfa5eb4da7275266ac49f7fdd057062
comments:
When moving from a pit into an adjacent pit, you "fall into" the pit and take damage. This happens even when you are walking back and forth between two pits, repeatedly, where you should have no way to fall.
The intent seems to be that you can move into the adjacent pit without having to climb out of the first one, and this works properly - the only problem is that the pit gets triggered when you ought to have no distance to fall.

Panic when selection floodfilling large areas
Below is what you submitted to The_DevTeam on Saturday, August 11, 2018 at 10:49:05
The ID number for this message is '#H7352'
Subject:
panic when selection floodfilling large areas
oldver:
(please select version)
gitver:
469fb27e2fc78a5f206d67974a9c2c92abbf0775 (latest)
nhfrom:
Our git repository - please list branch and ref below
hardware:
x86_64 laptop
software:
latest 3.6.2-dev
comments:
The panic("floodfill stack overrun") in selection_floodfill is being triggered when the floodfill area encompasses most of the level, even though the function is intended to support a full-level floodfill. To reproduce, add FLAGS:inaccessibles to the Bar-fila level which will trigger a floodfill from the stairs. Bar-fila is just a big open rectangle so it's ideal for making this happen, though it would probably also work in the Big Room too.
This is caused by points being added to the stack multiple times, which on a mostly open level will of course exceed ROWNO * COLNO. The way the function is organized, it refuses to add a point to the stack if it already exists in the /selection/ - but it doesn't check whether it's already in the stack.
Possible fixes are either adding that check for whether a point exists in the stack, or maybe just moving the "add to selection" code into SEL_FLOOD.
(And if anyone could tell me why there's a do... while(0) loop in there with no other control statements besides an if/else inside it, that'd be great.)