Bugs in NetHack 3.4.3/Reports
Jump to navigation
Jump to search
The official list of bugs in NetHack 3.4.3 gives very little information about the bugs in question. This page archives the known original bug reports sent to the DevTeam, to give more information and insight into the bugs.
Contents
C343-403
Reported by ais523, although it was well known in the NetHack community before the report
The ID number for this message is '#H2161' mailversion: 1.41 nhversion: 3.4.3 nhfrom: Our 3.4.3 source release, unmodified hardware: Probably irrelevant, but it's a Toshiba Satellite netbook with 3 GB memory and 4 GB swap, and an Intel U2700 1.3GHz processor. (The bug has been verified on multiple patched/unpatched versions of NetHack, on multiple sets of hardware, including public servers.) software: Ubuntu Lucid, running Linux 2.6.32, using a NetHack binary compiled from unmodified (apart from config.h/unixconf.h and makefiles) official NetHack 3.4.3 sources compiled for Unix-like systems using gcc 4.4.1. (Also probably irrelevant, given the above.) comments: There's a huge inconsistency in the way that writing scrolls via magic marker works; in particular, it depends on interface details that should be irrelevant. These checks were done as an unlucky non-wizard to minimize the chance of false positives due to writing the scroll by chance rather than due to having a 100% chance: 1. trying to write unIDed scroll by label: "What type of scroll do you want to write? KIRJE" fails 2. trying to write unIDed scroll by actual type: "For what do you wish? scroll of fire" "What type of scroll do you want to write? fire" fails 3. trying to write called scroll by label: "Call a scroll labeled KIRJE: X" "What type of scroll do you want to write? KIRJE" succeeds 4. trying to write called scroll via user-given name: "Call a scroll labeled FOOBIE BLETCH: wished-for" "What type of scroll do you want to write? wished-for" "There is no such scroll!" 5. trying to write called scroll via actual type: "What type of scroll do you want to write? fire" succeeds 6. trying to write an IDed scroll via label: (identify YUM YUM as magic mapping) "What type of scroll do you want to write? YUM YUM" succeeds 7. trying to write an IDed scroll via actual type: "What type of scroll do you want to write? magic mapping" succeeds The major inconsistencies here are between cases 1 and 3, and between cases 2 and 4. Case 3 implies that it's possible to copy a scroll you've ever owned, even if you don't know what it does; case 1 implies that it isn't. It's also incredibly unintuitive, if it makes sense at all, that giving a nickname to a scroll is necessary to be able to copy it. The inconsistency between cases 2 and 4 is much worse, and I've seen people exploit it on public servers. Suppose a player has ten unidentified scrolls, and doesn't know what any of them do, but suspects, say, that at least one is enchant armor. All they have to do in order to write an enchant armor scroll is to name all ten of those scrolls via #name-n, and then write enchant armor; if they had one in inventory to name, they write the scroll correctly, even if they didn't know /which/ of those ten scrolls it was. This doesn't make a whole lot of sense, especially as a mechanism for identifying items. The culprit is line 200 of write.c, which checks to see if a scroll of the type given by the player has been called (i.e. given an oc_uname). This check is dangerous without additional safeguards, as it can let the scroll be written even if the player has no idea what it is.
C343-409
Reported by ais523
The ID number for this message is '#H2210' mailversion: 1.41 nhversion: 3.4.3 nhfrom: Our 3.4.3 source release, unmodified hardware: Probably irrelevant, but it's a Toshiba Satellite netbook with 3 GB memory and 4 GB swap, and an Intel U2700 1.3GHz processor. software: Ubuntu Lucid, running Linux 2.6.32, using a NetHack binary compiled from unmodified (apart from config.h/unixconf.h and makefiles) official NetHack 3.4.3 sources compiled for Unix-like systems using gcc 4.4.3 comments: If a player applies an unlocking tool (key, lockpick, credit card) at an empty doorway containing a mimic pretending to be a door, the game says "that doorway has no door", rather than reacting appropriately to the presence of the mimic (say, by waking it and making the player stick to it, or adding the lockpick to the mimic's inventory with an appropriate message). The easiest way to reproduce this is in wizard mode, by standing next to a doorway without a door, and repeatedly doing control-G large mimic. The bug's caused by a logic problem in src/lock.c. The check starting at line 364 checks for mimics, but only for the purpose of not printing any monster-related messages. Some time before line 385, there needs to be code to allow for the possibility that in addition to having a doorway on the square (accomplishable via having a doorway without a door, which is still IS_DOOR internally), there's also an apparent door in the doorway which is actually a mimic; the character would believe there was an intact lock on the square even though they game knows there isn't. I would make and supply a patch for this bug, but as the README says, "we will assume your code is synchronized with ours"; and I don't have anything newer than 3.4.3 handy to patch against (and I suspect patches against 3.4.3 wouldn't apply; you've likely changed your code as extensively as I've changed my local copy in an attempt to make a fork, but I test all bugs I report against the official 3.4.3 source). If you think a patch would help, let me know and I'll try to provide one.
C343-421
Reported by ais523
The ID number for this message is '#H2142' mailversion: 1.41 nhversion: 3.4.3 nhfrom: Our 3.4.3 source release, unmodified hardware: Probably irrelevant, but it's a Toshiba Satellite netbook with 3 GB memory and 4 GB swap, and an Intel U2700 1.3GHz processor. software: Ubuntu Lucid, running Linux 2.6.32, using a NetHack binary compiled from unmodified (apart from config.h/unixconf.h and makefiles) official NetHack 3.4.3 sources compiled for Unix-like systems using gcc 4.4.1 comments: Even after 6 years, it seems that new bugs, or at least buglike behaviour, is still being discovered in NetHack. Is it intentional that it's possible to avoid going through all the levels in Gehennom on the "ascension run" (bringing the Amulet to the surface)? The issue in this case is that it's possible to use the magic portal leading to the Wizard of Yendor's Tower to skip several levels on the way up. Although the player is incapable of leaving the tower (via any method that works whilst holding the Amulet other than going back the way they came) and thus this would seem to prevent this being used for a shortcut, it's possible to drop the Amulet, then teleport it out of the tower (with a wand of teleportation). Because the player's no longer holding the Amulet, they can then #sit back on the portal to leave the tower, level teleport back to the level the Amulet is on (possible because they aren't holding it), and pick it up, this time /outside/ the tower. (As an amusing aside, the fact that it's possible to level-teleport past the intervening levels on the way down makes it possible to not generate the levels in question at all.)
C343-425
Reported by ais523
mailversion: 1.42 nhversion: 3.4.3 nhfrom: Our 3.4.3 source release, unmodified hardware: Probably irrelevant, but it's a Toshiba Satellite netbook with 3 GB memory and 4 GB swap, and an Intel U2700 1.3GHz processor. software: Ubuntu Lucid, running Linux 2.6.32, using a NetHack binary compiled from unmodified (apart from config.h/unixconf.h and makefiles) official NetHack 3.4.3 sources compiled for Unix-like systems using gcc 4.4.3 comments: A bug which was just discovered today in my unfinished NetHack fork AceHack: a player was riding through the dungeon and stepped on awel landmine, and his warhorse survived the explosion but died from the fall. This lead to his dexterity permanently decreasing by one point. Investigation on an unmodified version of NetHack shows that the bug was inherited from there. The culprit is src/steed.c, line 527 (in NetHack 3.4.3; it's line 532 in AceHack, and I have no idea what line it is in NetHack 3.5, even though obviously that would be the most useful line number to give), which sets the wounded legs intrinsic and extrinsic values to 0 without removing the dexterity adjustment. Although this could be fixed at that point in the code, it's probably easier to do it by calling the appropriate functions instead (adjusting for the change in ride state).
C343-426
Reported by ais523
mailversion: 1.42 nhversion: 3.4.3 nhfrom: Our 3.4.3 source release, unmodified hardware: Probably irrelevant, but it's a Toshiba Satellite netbook with 3 GB memory and 4 GB swap, and an Intel U2700 1.3GHz processor. software: Ubuntu Lucid, running Linux 2.6.32, using a NetHack binary compiled from unmodified (apart from config.h/unixconf.h and makefiles) official NetHack 3.4.3 sources compiled for Unix-like systems using gcc 4.4.3 comments: If a level is almost but not entirely full of monsters, then a player hiding on the ceiling (after using #monster in any p or t form), then when a monster moves onto the player's square, the player falls to the nearest unoccupied square that the monster didn't come from, even if it's over the other end of the level. There are no restrictions on this, so it can be used to, say, cross the Plane of Air or Astral in one turn, or escape from the Wizard of Yendor's tower (or phase into it, but that's less useful because there are various standard ways of luring him out, which as far as I know are intentional; let me know if they're bugs and I'll report them). The culprit is a use of enexto() without any sort of check, on src/mhitu.c line 362 (in NetHack 3.4.3); the check is made before moving the monster, even though the monster vacates the square in question, so it won't hit the square that the monster was occupying. (Every other use of enexto() in the 3.4.3 source to find a location to place the player also has a check on the maximum distance that the player can be moved; I obviously can't check to see if more buggy uses have been introduced in a development version.) The most obvious fix is simply to make the player and monster swap places, although that would have issues where long worms were involved.
C343-428
Reported by ais523
mailversion: 1.42 nhversion: 3.4.3 nhfrom: Our 3.4.3 source release, unmodified hardware: Probably irrelevant, but it's a Toshiba Satellite netbook with 3 GB memory and 4 GB swap, and an Intel U2700 1.3GHz processor. software: Ubuntu Lucid, running Linux 2.6.32, using a NetHack binary compiled from unmodified (apart from config.h/unixconf.h and makefiles) official NetHack 3.4.3 sources compiled for Unix-like systems using gcc 4.4.3 comments: This bug was found in a collaboration between me and dwangoAC (we're trying to determine the theoretically fastest turncount you can get for a game of NetHack). When a cockatrice nest (the special room) generates, all the statues in it are always of giant ants. This is because the code just doesn't initialise the monster type (corpsenm) of the statues anywhere; mkroom.c:346 calls mk_tt_object requesting a STATUE, yet mk_tt_object explicitly asks for no initialisation on the statues it creates (mkobj.c:1043). The comment on the line above is incorrect, or at least incomplete; it states that it prevents generation of statue contents, but the lack of initialization also prevents the statue's corpsenm being set by mksobj like it normally would be. (In case it matters, and in _tt_-related functions it might, my test case was with a blank high score table.) It's kind-of interesting that this wasn't noticed earlier; perhaps players tend not to pay attention to the statues around cockatrice nests because they're too busy worrying about the cockatrices?
Unnumbered bugs
Wielding potions of blindness confers blindness resistance
Reported by arxanas, confirmed by ais523 and ishanyx
nhversion: 3.4.3 nhfrom: Not presently known hardware: Model Name: MacBook Pro Model Identifier: MacBookPro8,2 Processor Name: Intel Core i7 Processor Speed: 2.5 GHz Number of Processors: 1 Total Number of Cores: 4 L2 Cache (per Core): 256 KB L3 Cache: 8 MB Memory: 8 GB Boot ROM Version: MBP81.0047.B27 SMC Version (system): 1.69f3 Serial Number (system): [redacted] Hardware UUID: [redacted] Sudden Motion Sensor state: Enabled software: Unmodified 3.4.3 comments: My dearest devteam, I write to inform you of a most pressing bug in your game. 'Tis present in the source release (nethack-343-src.tgz, MD5 21479c95990eefe7650df582426457f9), and as such remains present in all compilations of our beloved game. To reproduce the bug, one might partake in the following steps: 1. Get a potion of blindness. 2. Wield it (as your primary or alternate weapon), or ready it in your quiver. 3. Allow a yellow light to explode at you. Despite the expected behavior of a yellow light causing you blindness, you remain unaffected. This is a most grievous error, as one could simply saunter through the dungeon with nary a thought for the poor yellow lights, who give their lives in vain. Even worse is that archons too cannot blind you, for the issue resides in resists_blnd, and archons call this function to gaze. I know that you are all hard at work making the next version of NetHack for us all, so I deigned to save you some time by providing a possible patch. It took me the better part of an hour to devise, as the coding involved is rather in-depth and hard to follow. I hope you incorporate it into the forthcoming new version of NetHack (which I am sure will be here sometime soon), as I would hate to play the game immune to yellow lights. Thanks for all your hard work, [redacted] (attached documents): patch.diff: Only in nethack-3.4.3-patched/: .DS_Store diff -r nethack-3.4.3/src/mondata.c nethack-3.4.3-patched/src/mondata.c 126,127c126 < if ((o->owornmask && objects[o->otyp].oc_oprop == BLINDED) || < (o->oartifact && protects(AD_BLND, o))) --- > if (o->oartifact && protects(AD_BLND, o))
- Won't your patch make blindfolded heros susceptible to yellow lights? --Tjr (talk) 07:37, 15 October 2012 (UTC)
Turn alternation failure with 24 movement energy
Reported by ais523
mailversion: 1.45 nhversion: 3.4.3 nhfrom: Our 3.4.3 source release, but modified hardware: Using a qemu virtual machine with QEMU Virtual CPU version 0.12.3, with 614196 kilobyes of disk space, and 56364 kilobyes of memory. (We're using snapshots of the virtual machine for more easily reproducible bug testing.) software: Using a version of 3.4.3 modified to show the remaining movement points of players and monsters, in order to more easily track the bug down. I don't think I modified anything that would affect the bug (and besides, I've already tracked it down from the source). Compiled with gcc 4.4.3. The virtual machine is running Linux 2.6.32. comments: A short and sweet bug report: turn order becomes inconsistent with the rest of the game when a player has 24 movement points exactly, and a monster has at least 24. Normally, after the player takes their action, monsters will get one action in response, then (if the player has actions left in the turn) the player will get to take another action. However, if the player has 24 movement points exactly, their action will take them down to 12, at which point the monsters will get to take all their remaining actions at once, and the player will get the last action in the turn, rather than alternating turns like usual. The dependence on the exact number of movement points is weird and seems to be a bug. The offending line is, in 3.4.3, src/allmain.c line 79 (sorry I can't give you a line number from the bugfixed and feature-added version of NetHack you're presumably working from, but I haven't seen it). "youmonst.movement > NORMAL_SPEED" should be "youmonst.movement >= NORMAL_SPEED". Thanks to dwangoAC, who found this bug, and the testing system he made to help me reproduce events in NetHack games under controlled circumstances. Obviously, being able to rewind games and do something else is even worse than savescumming from an ascension perspective, but it helps very much when finding bugs.
Reported by Grunt
mailversion:
1.45
nhversion:
3.4.3
nhfrom:
Our 3.4.3 source release, unmodified
hardware:
Probably unimportant, but: Intel Core 2 Quad Q8400 @ 2.66 GHz, 4GiB
memory, 2TB disk space.
software:
Gentoo Linux; NetHack 3.4.3 built using GCC 4.6.2.
comments:
During development of a variant, I've come across the following which
may constitute bugs in NetHack 3.4.3, as checked against a build
unmodified except for one configuration option (#define LINUX).
* When reverse-genociding a nearly-extinct monster, sometimes only one
monster is generated, but the message is still "Sent in some <plural
of monster>.", suggesting more than one is generated. This is best
illustrated with Nazgul - generate eight Nazgul and then
reverse-genocide them to see "Sent in some Nazgul[s]." (depending on
if you're looking at this in a build that has fixed C343-8 or not).
Under these cases, a more accurate message would be "Sent in a
Nazgul".
* When attacking a monster carrying a stack of destroyable items with a
weapon that destroys them (e.g. scrolls/spellbooks/potions with Fire
Brand, potions with Frost Brand), if exactly one item of the stack is
destroyed, the object name is plural, but the message indicating that
it was destroyed is not (e.g. "The dwarf king's scrolls labeled ELAM
EBOW catches fire and burns!"). Perhaps the message should use the
same logic as when the player is hit by an item-destroying attack,
yielding, e.g., "One of the dwarf king's scrolls labeled ELAM EBOW
catches fire and burns!".
* The death reason given for choking on an artifact is "choked on {a|an}
<object>", which can be inappropriate when quest artifacts are
involved - e.g. "choked on an Eye of the Aethiopica", inconsistent
with the use of "[Tt]he" as a prefix everywhere else they are
mentioned. In the case of quest artifacts, this probably should be
"choked on The Eye of the Aethiopica", and for other artifacts,
perhaps "choked on Grayswandir" (skipping the article). (It could be
argued that a further bug is treating the unidentified and identified
cases of artifacts differently, e.g. "choked on a silver saber named
Grayswandir" in some cases as opposed to "choked on [a] Grayswandir"
in all cases, particularly when working in a build where objects are
able to be named after artifacts - "a silver saber named Grayswandir"
without actually being Grayswandir - as the deaths in those two cases
would be indistinguishable.)
* When a player zaps a wand of striking or casts force bolt at a monster
that is magic resistant, no "Boing!" message is generated; all other
cases (player against self, monster against player, and monster
against monster) generate this message, which is inconsistent.
I hope that pointing out these bits of behaviour is useful to all of
you.
