Neo Angband 0.24.0

What you can download

Platform	File
Windows (installer)	Neo Angband Setup 0.24.0.exe
Windows (portable, one file)	Neo Angband-0.24.0-portable.exe
macOS	.dmg, or the .zip if you prefer to unpack it yourself
Linux	.AppImage (no install), .deb, or .tar.gz
Self-hosting	neo-angband-web-0.24.0.zip - static files, any web server

The portable Windows build and the AppImage need no installer:
download, run, and the game keeps its saves in a folder beside itself.

These builds are not code-signed

There is no Apple Developer identity or Windows certificate behind this
project yet, so your OS blocks the first launch.

Windows is one click: SmartScreen says "Windows protected your PC",
choose More info then Run anyway.

macOS is not one click, and the dialog it shows you does not contain the
way through - it offers only Done and Move to Trash. Do this:

1. Drag the app out of the .dmg, then double-click it and press Done
   on the refusal. This step is required: it is what makes the permission
   below appear, and it expires about an hour later.
2. Open System Settings -> Privacy & Security and scroll to
   Security, near the bottom.
3. Press Open Anyway on the line naming Neo Angband, authenticate, and
   launch it again.

Or, the same decision in one command:
xattr -d com.apple.quarantine "/Applications/Neo Angband.app"

The old right-click -> Open trick does NOT work: Apple removed that
bypass in macOS 15 Sequoia.

On Apple Silicon take the arm64 build. The x64 one is for Intel Macs,
not a fallback - Apple is withdrawing Rosetta 2, so on a current Mac it is
likelier to refuse to launch than to run slowly.

If that trade is not one you want to make, build it yourself -
docs/INSTALL.md - or play in the browser, which needs no trust decision.

Your save

Saves survive an update. Every save-format change ships the conversion that
reads the version before it, and a save this build cannot open is left
untouched rather than replaced.

---

Current state of the project at version 0.24.0 - a fixes release. Nothing
about the game's rules changed. A game played with random artifacts on now
reloads correctly, which it did not; the desktop build checks a URL before
handing it to the operating system; a mod whose newest release needs a newer
game now offers one that runs here instead of refusing outright; and the mod
consent screen stopped implying that a short permission list bounds what a
mod's code can reach.

Fixed

• Random artifacts keep their created, seen and everseen flags across a reload,
  and a carried random artifact stays an artifact. With birth_randarts on,
  every artifact id in the savefile was matched against the STANDARD artifact
  names rather than the random ones. An id is a slug of the artifact's name and
  the save was written from the random names, so nothing matched: an artifact you
  had already found came back unknown, and a random artifact in your pack, in a
  shop or on the floor came back as its plain base item. The artifact set is now
  rebuilt before those ids are resolved, reading the birth option and the seed as
  the file recorded them, so one resolver serves the save migration, the flags and
  every saved object alike. Upstream writes these fields positionally by index and
  so has nothing to lose here, which makes this the port's own defect rather than a
  wart to preserve. A game with birth_randarts off is unchanged.

• A mod's artifact keeps its provenance when random artifacts are on. The
  whole artifact array is replaced by the generated set, and the clone it was
  built from dropped two fields: the stamp saying which pack contributed the
  record, and the place a mod's own fields on that record live. An artifact's
  savefile id is minted from that stamp, so a mod's artifact was written into the
  save under core's namespace instead of the mod's, and a plugin reading its own
  fields back off the artifact found nothing. Nothing about an unmodded run
  changes: core's records carry neither field, and neither is read by artifact
  generation, which the recorded whole-set vectors confirm.

• The desktop build checks a URL before handing it to the operating system.
  The update page's reveal link and the external-link opener both called
  shell.openExternal with whatever string reached them, and the reveal link's
  string usually begins as GitHub's own release JSON, fetched over the network
  rather than built into the program. Both are also reachable directly from any
  script running in the game page, a mod's plugin.js included, since a mod's code
  is a plain module import into that same page. Neither origin was validated, so a
  scheme other than http or https would have reached whatever program is
  registered for it on your machine instead of a browser. The reveal link is now
  checked against this project's own github.com releases pages and the
  external-link opener against http and https generally; either rejection is
  logged with what was rejected rather than failing silently.

Changed

• The mod consent screen warns about the code for every mod that ships code,
  and the modding docs say what a permission actually gates. The warning used to
  appear only when one of the requested permissions was flagged powerful, which
  made it read as a consequence of the list: a plugin asking for nothing but a
  tile or vocabulary registry got a consent screen with no such line, and a plugin
  asking for nothing at all got no consent screen and a manager row reading Asks for no permissions. That reassurance was wrong. A registry:* permission gates
  one convenience facade, and the same live registries arrive at the plugin a
  second time with no check at all, so a mod that declared no domain can still
  register a room builder, a cave builder, a dungeon profile, a vault glyph, an
  item class, a rune, a randart ability or a message type. Fourteen of the gated
  domains have such a twin. That is inherent in running trusted code inside the
  engine rather than a gap to close, since nothing reachable from inside the engine
  namespace can be withheld from code already inside it, so the words moved instead
  of the mechanism: the screen names the code, the manager row on a code mod that
  asks for nothing says it still runs code, and docs/modding/PLUGINS.md gains
  "What a capability gates, and what it does not" with the table of twins and the
  reason declaring still matters, which is that the player reads the declaration
  and the conflict report is built from it. The boundary that does hold is the
  install, which is where a player decides to trust a mod's code at all. A test
  measures both halves, the gate refusing and the twin reaching, against the real
  bound registries and the real plugin context, so the prose cannot drift back into
  claiming containment.

• A mod whose newest release needs a newer game now offers the newest release
  that does not. The mod screen used to read will not run on this version and
  stop there, even when the same mod still had an earlier release that ran
  perfectly on your build. It now looks back through that mod's earlier releases
  and offers the newest one your game can actually run. It names the newer release
  it stepped past, and it tells you to update the game only when updating the game
  is what would get you that release. A mod with nothing that runs here is still
  refused, and now says how many of its releases were tried instead of leaving you
  to wonder whether the older ones were looked at.

  • Update installed mods stopped offering an update the game would then
    refuse to load. A mod already on the newest release your build can run is
    described that way rather than as out of date, and the row says which newer
    release is waiting on a game update.

---

Found something that does not match Angband 4.2.6? Open an issue or come and say so in the Discord.