Note to new users

Due to constant spambot issues, accounts on this tracker can now only be created manually. Please contact scshunt ("coppro" on, ais523 ("ais523" on, or jonadab ("jonadab" on for an account. If we aren't online, or you would prefer to use email than IRC, email scshunt@… for an account.

NetHack 4 Bug Tracker

Welcome to the bug tracker for NetHack 4, a branch of the popular game NetHack.

Filing Guidelines


The types of ticket are as follows:

  • A defect is obviously unintended or incorrect behaviour (i.e. a bug);
  • An enhancement is an uncontroversial suggestion for new behaviour;
  • A task is a ticket created without having any specific change to NetHack 4's behaviour in mind (e.g. "ensure that feature X is working correctly");
  • A cleanup is a change to the game's internals that makes the code cleaner without looking at new features or fixing bugs;
  • A YANI (Yet Another New Idea) is a suggestion for adding new or controversial behaviour to the game that might not necessarily be widely accepted.


The various places you might find a bug, or want an enhancement:

  • NetHack Game: All the logic for actual gameplay. Bugs here will act identically between local play and server play, no matter what interface you're using.
  • Server Library: Anything that's specific to play on a server (e.g. connecting to a server, username/password entry, and so on), apart from the initial connection.
  • Client Library: Code specific to connecting to a server (i.e. the server itself works fine, but your client has problems while connected to it). It's quite rare that you'll need to use this, because the client library is comparatively simple compared to the rest of the code.
  • NetHack Client: Anything to do with calculating what's displayed onscreen, or in processing input from the user. This also includes most of the interface outside gameplay (such as the main menu) that isn't part of the server library. If something looks consistently wrong across multiple platforms (e.g. both Linux and Windows), or across multiple platforms, the bug's probably here.
  • Rendering Library: Code for doing the actual drawing onscreen, and reading keys from the user (without working out what they mean in context). This is where you'd report bugs like "pressing Backspace is consistently interpreted as Control-H on terminal foo"; bugs in this component are often going to be platform- or terminal-specific.
  • Tile Utilities: Code for handling tilesets during the build process. Bugs in this component will cause the generated tile images to be wrong.
  • grammartree: Bugs and enhancements in the ongoing project to give NetHack 4 a better idea of what its messages mean.
  • Build and Packaging: Bugs that are not in the code itself, but in the way users get it running. This includes bugs in aimake, NetHack 4's build system.
  • saves/replays: Any problem in writing, reading, or understanding the game's save files.


Generally, the following guidelines should be used:

  • blocker: It would be impossible to release the game without resolving the ticket. An example includes a crash on startup, or something making ascension impossible.
  • critical: The ticket should be fixed if at all possible since it will severely impact the enjoyability or balance of the game. Examples include crashes, or the save system not working well.
  • major: The ticket impacts enjoyability or balance, but not so much as to damage playability. Examples include a section of the game that can be bypassed, or significant interface issues.
  • minor: The ticket is something that would be nice to fix, but is not a serious burden on users. Examples include small interface quirks, a monster's special attack not working, or cockatrice corpses being insufficiently lethal.
  • trivial: This bug is purely cosmetic or otherwise does not make a significant difference. Examples include typos or requests for new YAFMs.


This represents how much effort resolving the ticket would be:

  • unknown: Unknown effort.
  • easy: A straightforward change; a few minutes at most.
  • difficult: A more complex change, possibly touching a few components.
  • refactor: Requires a rewrite of a major subsystem.


The following keywords should be used:

  • reproducible: If there exists definitive steps to reproduce the bug.
  • vanilla: If this is a vanilla bug.
  • grammartree: If this bug can be expected to be fixed as part of grammartree.
  • balance: If the report is about a problem with game balance.
  • windows, unix, linux, osx: Bugs specific to one platform or platform group ("unix" contains Linux and Mac OS X).
  • warning: The report is a compiler warning.
  • savebreak: Making this change would break save or bones compatibility.
  • wizmode: Bug in wizard mode (debug mode, nethack -D)
  • yafm: Suggestion of a funny message.
Last modified 2 months ago Last modified on Jun 26, 2015, 12:02:19 AM