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
Turn alternation failure with 24 movement energy
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.