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.

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 ? uncursedcnt : cnt; 
       for (j = 0; j < MTSZ && j < k - 1; j++) 
           if (nx == mtmp->mtrack[j].x && ny == mtmp->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 (>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->blessed 
                       && (Role_switch == oart->role || !oart->role)); 

Isn't correct. When "no role" is set, it is to NON_PM, which is -1. The "!oart->role" would only apply if role is set to PM_GIANT_ANT (0). It should rather check for oart->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->body armor->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->gloves->rings
• Kicks: boots
• Headbutts: helms
• Touch: gloves
• Hugs: cloak->suit->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

1. 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.)