NetHack 4.2.0 released!

1721 views
Skip to first unread message

ais523

unread,
Apr 1, 2012, 2:26:52 PM4/1/12
to
Announcement
============

I am pleased to announce the release of NetHack 4.2.0.

You can download the source of this distribution from
<https://gitorious.org/nitrohack/ais523/archive-tarball/nicehack>.
We're still working on getting binary packages worked out, but
it's been so long, we thought you might want to see where we'd got
to so far (and perhaps even offer help).


FAQ
===

Q. What's up with the version number? I thought that the previous
version was 3.4.3?

A. There have been several internal versions of NetHack since, but
none had a public release. The reasons of this vary from version to
version; some weren't released because we didn't finish fixing all
the bugs (for instance, we still don't know what's causing C343-23,
and version 3.8.2 didn't have a working fix for C343-108 even though
it was fixed in AceHack); some weren't released due to missing ports
for the Nintendo Entertainment System; some weren't released due to
most of the devteam not having copies of them (the porting and beta-
test teams were getting particularly bored towards the end, due to
not having access to the code of the major rewrite that was major
version 4). We think that, in the log run, it would reduce confusion
if our internal version numbers are consistent with the numbers that
everyone else sees, even if it means that we're skipping versions.

(Also, NitroHack's taken 4.0.x, much to our annoyance, which left
us scrambling for a new version number to use…)

Q. So why are you releasing it now?

A. The world's gone long enough without a major NetHack release
Sure, people were getting impatient, but we can handle that. But our
development processes have clogged to the point where we can't get
anyone to write code for nontrivial fixes no matter how necessary
they are, so at some point, we have to surrender and ask the
community for help. (Not to mention, I have a feeling the rest of
the devteam would benefit from seeing this code too. We really must
start using a shared repository…)

Q. What happened to all those bugs you said you'd fixed?

A. We did fix them! We just didn't write down any useful amounts of
information about what was causing them on the bug list, so after a
rewrite, we found ourselves often unable to work out what the bug
even meant, let alone what the fix was.

Q. So what's changed in this version, anyway?

A. We have:

- A new interface, because we gave up trying to rewrite all the old
ones. We just have a curses-based tty port at the moment (which
has some striking similarities to NitroHack's, but also some
clear differences; we hope you'll like it, and if you don't like
things like the use of color, you'll be happy to know that you
can turn most of those options off). Hopefully, the new
windowport API will allow people to write their own ports; we've
heard good rumours, like people working on webclients.
- New controls, which are more accessible and hopefully less prone
to typos. Ever lost a game due to typoing into water or lava or a
floating eye? Or blown up your bag of holding? Or eaten an item
on the floor rather than in slot 'y', or vice versa? Not any
more! (For people who feel this takes some of the fun out of your
game, you're welcome to write a script to automatically inject
line noise into your input in order to regain the feeling of
dying to things you really didn't mean to do.)
- A new save file format, which is, again, strikingly similar to
NitroHack's with some clear differences. Disk space not being so
important any more, we save the game state every turn, so that
the game can be reconstructed even on an incompatible binary, as
long as it stores the same information in the save file. (And we
take diffs between the states, to stop the files getting too
insanely large. Unless, perhaps, you're a pudding farmer, but in
that case you deserve what you're putting your disk through.)
- Some new commands. We actually never put #tip in in the first
place; it was a rumor designed to allow us to monitor the NetHack
fanbase for the spread of discussion about the next version, much
like a scientist monitoring a flock of wild geese or the like. On
the other hand, you get the ability to type-name items that
aren't in your inventory (except loadstones, obviously); to view
levels you aren't on; to have the computer automatically go
through the motions of exploring when nothing else interesting is
happened; to view things like your kills/genocides and score
breakdown from within the game; write an Elbereth with one key;
and so on.
- That said, we have a new scoring system, ever since Berry so
convincingly proved the old one to be broken at /dev/null. Have
fun aiming for high scores that actually mean something!
- Of course, there are a whole load of bugfixes too. We're too busy
writing this release message to list them out, though. There are
probably a bunch of new bugs, too; this is always the case, but
who knows, maybe we'll have another 10 or 20 years to fix them
all this time!

Q. Where should we send bugs, praise, criticism, etc.?

A. Probably simplest to send them to me. At least, it's the only
way to make sure that I see them. rgrn might be a good place, too.

Q. Can I have a binary version?

A. Hey, part of the reason we don't normally release source is to
stop people asking that. Surely you can find someone else to bug
about it?

Q. What's your response to rumors that you just merged NitroHack
and AceHack and called it a release?

A. What do you mean, "just"? Merging variants is a lot of work!
And besides, you can't prove anything!

--
ais523
Alex Smith
NetHack 4 developer
Message has been deleted

bcode

unread,
Apr 1, 2012, 4:30:42 PM4/1/12
to
ais523 <ais...@bham.ac.uk> wrote:
> Announcement
> ============
>
> I am pleased to announce the release of NetHack 4.2.0.

Finally!

> FAQ
> ===
>
> Q. What's up with the version number? I thought that the previous
> version was 3.4.3?
>
> A. There have been several internal versions of NetHack since, but
> none had a public release. The reasons of this vary from version to
> version; some weren't released because we didn't finish fixing all
> the bugs (for instance, we still don't know what's causing C343-23,
> and version 3.8.2 didn't have a working fix for C343-108 even though
> it was fixed in AceHack); some weren't released due to missing ports
> for the Nintendo Entertainment System;

Interesting. NetHack 4 introduces support for new platforms? Can
we expect the next version to introduce support for lisp machines?
(This would probably require rewriting much/all of the code, but
not supporting them would mean ignoring a great part of your
potential userbase, as you did with NES users before 4.2.0 was
released. :-P)

Also, I'm sure NetHack will continue to support other platforms
which should _technically_ be considered obsolete but are still in
use for some reason, such as VMS, MS-DOS, (pre-OS X) Mac OS, and
the WinNT family.[1]

[...]

> (Also, NitroHack's taken 4.0.x, much to our annoyance, which left
> us scrambling for a new version number to use…)

Both projects currently use version numbers composed of three
positive integers with dots in between. Maybe one of them
(or indeed the other variants, too) should go another way?

One project might use negative integers, one of them might
use complex numbers, another might use quaternions, and so
on. (This would have additional complications, of course;
but you, the DevTeam, can surely avoid them in some way. After
all, you even succeeded in releasing NetHack 4, which was
long thought to be impossible!)

> Q. So what's changed in this version, anyway?
>
> A. We have:
>
[...]
> - New controls, which are more accessible and hopefully less prone
> to typos. Ever lost a game due to typoing into water or lava or a
> floating eye? Or blown up your bag of holding? Or eaten an item
> on the floor rather than in slot 'y', or vice versa? Not any
> more! (For people who feel this takes some of the fun out of your
> game, you're welcome to write a script to automatically inject
> line noise into your input in order to regain the feeling of
> dying to things you really didn't mean to do.)

I really hope the next minor release will come with an example
script to do this; while I could write a, say, Perl script to
insert the line noise, not everyone is able to produce line noise.
(Lispers typically generate too many parentheses, Pythonists don't
always remember to include punctuation, and C++ coders have a
tendency to go mad while writing the program.[2] I use Perl;[3]
others might use sed or other programming languages.[4])

Will the new development model allow for us to submit our line
noise generation scripts?

> - A new save file format, which is, again, strikingly similar to
> NitroHack's with some clear differences. Disk space not being so
> important any more, we save the game state every turn, so that
> the game can be reconstructed even on an incompatible binary, as
> long as it stores the same information in the save file. (And we
> take diffs between the states, to stop the files getting too
> insanely large. Unless, perhaps, you're a pudding farmer, but in
> that case you deserve what you're putting your disk through.)

Since there now is a new, modern way of punishing pudding farmers,
is the old punishment (pudding farming) going to be removed?

> - Some new commands. We actually never put #tip in in the first
> place; it was a rumor designed to allow us to monitor the NetHack
> fanbase for the spread of discussion about the next version, much
> like a scientist monitoring a flock of wild geese or the like.

I assume even open source developers need to learn about their
target demographic to succeed. Will the next 4.x version allow
us to optionally send our data to the DevTeam automatically so
you can see what could be improved?


Obligatory footnote section:
[1]: Of course I'm joking. Feel free to decide for yourself
which of those OSes are obsolete.
[2]: You should have noticed by now that I frequently code
in C++.
[3]: Using Perl for a line noise generator can have some
advantages; finding out why/how is left as an exercise
for the reader. ;-)
[4]: Don't take this as insults to the programming languages -
I was joking here, too. (In a perfect world, I might not
have to say that... *sigh*)

Capt. Cave Man

unread,
Apr 1, 2012, 7:54:06 PM4/1/12
to
On Sun, 01 Apr 2012 23:18:17 +0300, Jukka Lahtinen
<jtfj...@hotmail.com.invalid> wrote:

>ais523 <ais...@bham.ac.uk> writes:
>
>> I am pleased to announce the release of NetHack 4.2.0.
>
>Nice try, but that isn't convincing before 4.1.0 is released.
>(And besides, Patric got first, even though the difference doesn't seem
>to be many minutes..)
>
>> it was fixed in AceHack); some weren't released due to missing ports
>> for the Nintendo Entertainment System; some weren't released due to
>
>I don't think there ever was a Nintendo port.

And his would need to be released on the 20th at 4:20 in the afternoon.

The file would create a graphic of a bong pipe.

nooodl

unread,
Apr 2, 2012, 3:29:11 AM4/2/12
to
Op zondag 1 april 2012 20:26:52 UTC+2 schreef ais523 het volgende:
> Announcement
> ============
>
> I am pleased to announce the release of NetHack 4.2.0.
>
> <snip>
>
> --
> ais523
> Alex Smith
> NetHack 4 developer

Looks like the devteam was having some difficulties getting this on nethack.org... Oh well.

Doug Freyburger

unread,
Apr 2, 2012, 12:22:53 PM4/2/12
to
Jukka Lahtinen wrote:
>
> I don't think there ever was a Nintendo port.

There was a port for one of those handheld systems available at one
point. Might be great for folks who commute on a train from the 'burbs
to downtown every day.

Corey

unread,
Apr 2, 2012, 12:40:39 PM4/2/12
to
To: Doug Freyburger
Re: Re: NetHack 4.2.0 released!
By: Doug Freyburger to rec.games.roguelike.nethack on Mon Apr 02 2012 04:22 pm
I like the android port myself.
now I can hack whereever I go.

ais523

unread,
Apr 2, 2012, 6:14:16 PM4/2/12
to
ais523 wrote:
> Announcement
> ============
>
> I am pleased to announce the release of NetHack 4.2.0.

I should probably come clean about my intentions now. First, I think
it's obvious to most people that the simultaneous release of all the
actively developed variants on April 1 was not a coincidence (although
some people may have missed it, because Grunt's post went via Google
Groups, which seems to have had technical problems). The version numbers
are all correct too (although there were some version number bumps
involved in order to avoid clashes; bhaak felt like it was time for a
major version bump with Un, I needed to increase the value for NetHack 4
to avoid clashes with NitroHack, and Grunt chose the number for
GruntHack to stay level with the other variants of a similar level of
advances over vanilla). Likewise, the features we advertised as having
in our messages actually exist in the variants (no, NetHack 4 doesn't
run on the NES; I specifically said it didn't in the message, and was
just trying to think of a platform that NetHack has never been ported
to, there aren't many…)

Anyway, while I know that rgrn has seen and played around with NitroHack
before now, I haven't been advertising AceHack here much, mostly because
it was still missing features from the (rather ambitious) vision I had
in mind for it. More recently, I've realised that much of what I was
planning was a bad idea, and reined myself in somewhat when I was
rewriting everything for the latest project. The result is a merged
version of NitroHack and AceHack; it was codenamed NiceHack for what I
hope were obvious reasons, but the project has now been given its
official name of "NetHack 4". (There were variants with names like
"NetHack+" or "NetHack Minus" or "NetHack brass"; thus, I feel that
"NetHack 4" is a valid, if deliberately provocative, name for a
variant.)

Of course, with a name like that, I'm obviously trying to make another
point too. Development of vanilla NetHack has effectively stopped at
this point. I know that it's still being developed behind the scenes;
there's quite some evidence of that, mostly gained from the reply to bug
reports. However, with no visible code and a near-useless bug tracker,
the fact that NetHack is being developed is of no use to a developer or
player. In terms of what's actually available, the vanilla devteam are a
long way behind.

Although obviously I have no hard data on this, I believe the vanilla
devteam are also behind in terms of features. The user interface
improvements in AceHack or NitroHack or even UnNetHack are quite a step
ahead of vanilla NetHack, and one that I don't expect to have happened
in the vanilla codebase (and it doesn't matter even if they have, unless
$NEXTVERSION is released to prove me wrong). Likewise, many forks, like
UnNetHack or GruntHack, have been willing to make extensive gameplay
changes; NetHack 4 has mostly steered away from them so far, in order to
stave off even more controversy than it's going to cause anyway, but
both me and Daniel feel that improvements will be needed, and we'll add
things if they're sufficiently clear upgrades. (Any change at
all will be at least slighty controversial, it, seems, no matter what is
changed…)

Anyway, this marks the point at which I've stopped waiting for
$NEXTVERSION. We're behind on bugfixes compared to the vanilla devteam;
we only have a little over 10% of the known vanilla bugs fixed, although
of course we can make steady progress chipping away on those. The lack
of documentation is making things hard; the variant maintainers have
been emailing all the bug reports they find around to each other, and
placing them on the wiki
(<http://nethackwiki.com/wiki/Bugs_in_NetHack_3.4.3>) when they can't
fix them immediately, but we guess this information pales to the amount
of information sent to the devteam. (Incidentally, the bug list is
rather inconsistently updated; even though the amount of information on
it is relatively useless, many bugs aren't even on there. Perhaps about
half of the ones I've reported personally are, for instance.) The lack
of support from the devteam is really holding things back. (This doesn't
mean I'm going to stop sending them bug reports, of course; if the
vanilla devteam wants to get into the field of NetHack development, I'm
not going to stop them…)

Everyone who dismissed our posts as mere April Fools' jokes, I strongly
advise you to look at the actual variants behind them; you may well
find something you enjoy. We feel that there needs to be a worthy
successor to NetHack 3.4.3, even if the devteam are unable or
unwilling to produce it. Here are the links again, for reference:

UnNetHack 4.0.0:
<https://sourceforge.net/projects/unnethack/files/nethack/4.0.0/>

GruntHack 4.1.0:
<https://github.com/sgrunt/GruntHack/>

NetHack 4 4.2.0:
<https://gitorious.org/nitrohack/ais523/archive-tarball/nicehack> (you
can also get NitroHack and AceHack from the same repository, although
their official repositories are elsewhere)


We had to get some of this ready in a rush to reach April 1, so I
imagine there will be various bugs, instabilities, and missing features
(especially in NetHack 4: I was awake for around 31 hours
continuously yesterday to get it ready in time for April 1). Still, I
hope you forgive any problems you find, and send us feedback so that we
can correct it. Likewise, if you want to play GruntHack or NetHack 4,
you'll currently have to compile them yourself, although we hope they'll
still work on modern platforms (and we can try to fix them if they
dont). Supporting older platforms may be harder due to a lack of ability
to test, but if someone is willing to help port, I'm willing to work
with them.

Finally, a post of this nature wouldn't be complete without a feature
list to encourage people to try it out:

Features from AceHack (note that not all AceHack features are in
NetHack 4; some haven't been ported over to work with NitroHack's
engine yet, some turned out to be bad ideas and were removed):
- Stairs and traps beneath items are visible (in the curses interface,
this is shown using background color, although this can be turned
off); likewise, you can see where you've walked, if a monster is
peaceful/tame/hostile, and whether your character knows whether doors
are locked/unlocked/trapped
- Commands have more consistency in the keypresses required to use them
(e.g. eating from the ground is now always "e,", and eating from your
inventory in slot y is now always "ey"; vanilla's behaviour of using
ey for both has killed a character of mine before now)
- The game gives a warning upon attempting many sorts of obviously
self-destructive actions (like eating corpses old enough to be
tainted, or walking into lava, or attacking a shopkeeper), although
allows you to override it and perform the action anyway if you really
want to
- Doors can be opened simply by walking into them, and the o
command will use an unlocking tool on them for you if you knew they
were locked
- A new autoexplore command tells the game to repeatedly travel to the
nearest unexplored square until something interesting happens (I'm
personally a little dubious about how useful this is for general play,
but it's there if you want it, and I find it great in the Mines)
- You can request many sorts of information that you could calculate
but that vanilla doesn't show from the game, such as kill or genocide
lists, intrinsics, and score breakdowns
- Spellbooks can be read even before your memory of the spell wears out,
and you can see your remaining spell memory from the + menu
- The game now automatically identifies items for you in circumstances
where their identity becomes obvious or could be trivially tested
(e.g. engraving with a wand of cold, or wearing jumping boots, or
finding a potion of oil)
- Floating eyes can no longer be damaged with melee attacks at all, but
there's no penalty for trying to attack them besides the wasted turn
- Amnesia no longer causes you to forget information that could have
been written down, but rather skills and spells
- Swapping between primary and readied weapons no longer costs a turn
- Items inside a container can be BCUed by dropping the container;
items that stack can be BCUed by allowing them to stack with an
identical but BCUed item
- Bags of holding can no longer be destroyed by typos (the offending
item being inserted will be cancelled instead, or for nesting
bags fail unless it's clearly an intentional attempt to nest bags)
- There are many more candles in the Mines (in the inventories of
gnomes), to make it very unlikely that you don't find 7 in a game
- If an item has been charged, or if a wand has failed to work due to
being empty, you'll see the fact in the inventory rather than having
to remember
- Light sources can have their charge count identified (with a formal
identification source or a scroll of charging), so you can see how
long you have left on your oil lamp
- And both AceHack and NitroHack independently made item weights visible

Features from NitroHack:
- A new curses interface that keeps your inventory permanently on
screen, and shows more information in the status area
- Replays of games that don't just show you what the player saw, but
also allow you to query inventory or view in a different terminal size
or even a different interface
- The ability to change options in-game and have them stick, and change
some options that were previously compile-time (such as the existence
of Elbereth) before creating a game instead
- The ability to view an overview of the dungeon, including maps of
levels you aren't on
- Ability to rewind a save file; for obvious reasons, this isn't
available as a command in the game, but it can be automatically used
to recover from crashed games
- And a whole load of internals improvements that you probably don't
care about unless you're planning to make a variant yourself, but
which make further development much simpler

And some special goodness just for NetHack 4:
- The ability to play the game permanently blind or permanently
hallucinating (no more startscumming for blindfolds just to play Zen)
- Quest unlockable before turn 2000 (if you've maxed your alignment, you
don't need to also have 20 alignment)
- No need to press --More-- unless a turn produces so many messages that
some would scroll off the screen
- The vibrating square is now an object in the game rather than a set of
coordinates, so it's permanently visible after you've found it (no
more need to mark the square)
- Recording your choices from menus in the message history
- Save files storing the game state at every point as well as the
commands entered, so you can replay your games even on later versions
as long as save compatibility hasn't been broken

--
ais523
Alex Smith
for the NetHack 4 devteam

Jonadab the Unsightly One

unread,
Apr 2, 2012, 6:51:17 PM4/2/12
to
On Apr 1, 4:30 pm, bcode <betac...@users.sourceforge.net> wrote:
> [3]: Using Perl for a line noise generator can have some
> advantages; finding out why/how is left as an exercise
> for the reader. ;-)

Well, for one thing, Perl is such an expressive language,
a program like this is a very short, simple, and totally
straightforward one-liner:

@for::=map{chr}0..4<<5;print$for::[rand@for::]for 1..$=

See? Couldn't be easier.

Capt. Cave Man

unread,
Apr 2, 2012, 9:36:12 PM4/2/12
to
With their 10 years obsolete handheld?

I want an Android version port!

Screw the damned game consoles. Simply run a DOS emulator and run it
in that.

I want it to work on my Garmin!

Gimmie a firmware hack and port for my Garmin. Hehehehe.

Capt. Cave Man

unread,
Apr 2, 2012, 9:36:37 PM4/2/12
to
Whereisit!???

Jonadab the Unsightly One

unread,
Apr 3, 2012, 1:59:39 PM4/3/12
to
On Apr 2, 9:36 pm, Capt. Cave Man
<ItIsSoEasyACaveManCanD...@upyers.org> wrote:
> On Mon, 2 Apr 2012 09:40:39 -0700, "Corey"
>
> >I like the android port myself.
> >now I can hack whereever I go.
>
> Whereisit!???

I can't imagine. I don't suppose a web search engine would have any
idea either...
https://www.google.com/search?hl=en&q=nethack%20android&btnG=Google+Search

Capt. Cave Man

unread,
Apr 3, 2012, 9:59:29 PM4/3/12
to
I did find it (both actually). Sadly, I need the authors to put them
on Amazon's free repository, because 'google play' is apparently too
stoopid to recognize my android device, since it isn't a phone, or for
whatever reason. Some google lame-o with a boilerplate template set-up,
too stupid to know how to make it see ALL android devices it will run on.
Or they should have a way to tell them to add a known compatible device.

Damn lists simply mean they did something wrong, and backing out will
be costly. Android 2.3 and up should be the only requisite, and I should
also be able to pre-DL it to my PC.

Thanks for the help, but (not aimed at you) WTF!??? It is just a file,
and if it is fee, I should be able to pass it to my device from my PC.

Darn! Can't be that big... somebody write ones and zeros here to
match the file, and I'll reconstruct it. :-)

Dag Nabbit!

tung...@gmail.com

unread,
Apr 4, 2012, 1:39:32 AM4/4/12
to
On Tuesday, April 3, 2012 8:14:16 AM UTC+10, ais523 wrote:
> ais523 wrote:
> > Announcement
> > ============
> >
> > I am pleased to announce the release of NetHack 4.2.0.
>
> (snip)
>
> NetHack 4 4.2.0:
> <https://gitorious.org/nitrohack/ais523/archive-tarball/nicehack> (you
> can also get NitroHack and AceHack from the same repository, although
> their official repositories are elsewhere)
>
> (snip)
>
> --
> ais523
> Alex Smith
> for the NetHack 4 devteam


Ooh, nice. Play-tested it a bit, made some notes.

aimake chokes on Ubuntu 11.10. aimake's output[1] complains about libncursesw.so, so I took a look at them, and... they're text files[2][3]? Those are both stock installs from the standard apt repos. Note I don't have PostgreSQL installed; cmake works as long as I pass it -DENABLE_SERVER=FALSE.

Spotted some bugs:

- #chatting doesn't write the prompt for a direction. It otherwise works as normal.

- The walls of Sokoban aren't mapped, even though the floors, boulders and pits are.

- The floorcolor option doesn't mark empty doorways you step over.

- Altar alignments are recorded wrongly in the dungeon overview. I was playing a lawful samurai, reached a chaotic altar, and saw "a temple to Ameterasu Omikami". On that note, dungeon overview records altars as temples, even though real temples differ from plain old altars. NitroHack has these problems too, but I couldn't confirm it until now.

On gameplay:

- I think gnomes drop too many candles. I understand why they carry them (to avoid players resorting to scumming if Izchak doesn't have enough), but in my first game, I had all 7 candles before I even reached Minetown. Maybe the demon princes could have a chance to carry candles, and the Wizard of Yendor could drop a candle every time he dies?

- I don't know how I feel about having floating eyes not paralyze at all when struck. Their vanilla behaviour makes them typo instadeaths, but being nerfed this much removes their threat entirely. They should still pose a danger, maybe the paralysis duration could be made much shorter (10-20 turns) and/or turned into a sleep gaze, which characters can be roused out of by combat.

- Sometimes the background colors for monster attitudes seem a bit bright/low contrast, e.g. the light brown background for dark green peaceful hobbits.

Overall, NetHack 4 has a lot of potential. I really like the message box behaviour (paging through it, dimming past messages). As a long-time TTY player, the interface here is the first time I can say the Curses UI is better than TTY, and not just a newbie crutch. I'm definitely keeping an eye on this.

Incidentally, on my very first game trying this, that Excalibur-wielding oilskin-cloak wearing samurai hit an ogre lord with a wand of death just after finding Sokoban. That's NetHack for you. :)


[1]: https://gist.github.com/2297909#file_aimake+output.txt
[2]: https://gist.github.com/2297909#file_libncurses.so
[3]: https://gist.github.com/2297909#file_libncursesw.so

--
Tung

B. R. 'BeAr' Ederson

unread,
Apr 4, 2012, 1:34:12 PM4/4/12
to
On Tue, 03 Apr 2012 18:59:29 -0700, Capt. Cave Man wrote:

>>> >I like the android port myself.
[...]
> I did find it (both actually). Sadly, I need the authors to put them
> on Amazon's free repository, because 'google play' is apparently too
> stoopid to recognize my android device, since it isn't a phone, or for
> whatever reason.

http://code.google.com/p/nethack-android/downloads/list

HTH.
BeAr
--
===========================================================================
= What do you mean with: "Perfection is always an illusion"? =
===============================================================--(Oops!)===

Karl Garrison

unread,
Apr 4, 2012, 1:37:46 PM4/4/12
to
On Apr 2, 6:14 pm, ais523 <ais...@bham.ac.uk> wrote:

<snip>

> Anyway, while I know that rgrn has seen and played around with NitroHack
> before now, I haven't been advertising AceHack here much, mostly because
> it was still missing features from the (rather ambitious) vision I had
> in mind for it. More recently, I've realised that much of what I was
> planning was a bad idea, and reined myself in somewhat when I was
> rewriting everything for the latest project. The result is a merged
> version of NitroHack and AceHack; it was codenamed NiceHack for what I
> hope were obvious reasons, but the project has now been given its
> official name of "NetHack 4". (There were variants with names like
> "NetHack+" or "NetHack Minus" or "NetHack brass"; thus, I feel that
> "NetHack 4" is a valid, if deliberately provocative, name for a
> variant.)

It's certainly cool seeing the UI/code modernization of Nitro paired
with a variant like this. I will have to check it out.
Right, and agreed. Without any sign of an upcoming release from the
devteam, someone has to pick up the ball. Variants and patches are
nice, but it would also be nice to see "mainline" development again
with the more popular patches and the better features from various
variants.

The merging of Nitro and Ace seems like a great first step towards
this goal. Has there been any talk of doing more merging from other
variants as well into this tree? To me, I would think that if it's
going to bear the name "NetHack", it should be a combination of the
best additions since 3.4.3 was released.


> Features from AceHack (note that not all AceHack features are in
> NetHack 4; some haven't been ported over to work with NitroHack's
> engine yet, some turned out to be bad ideas and were removed):

> - The game gives a warning upon attempting many sorts of obviously
>   self-destructive actions (like eating corpses old enough to be
>   tainted, or walking into lava, or attacking a shopkeeper), although
>   allows you to override it and perform the action anyway if you really
>   want to

I don't like this one. Doing stupid things and racking up YASDs in
the process is a big part of the game. I suppose it isn't such a big
deal for e.g. pools and lava, but for corpses, that's a learning
experience, and sometimes a calculated risk when you are starving and
uncertain if the corpse is yet too old or not.

> - Floating eyes can no longer be damaged with melee attacks at all, but
>   there's no penalty for trying to attack them besides the wasted turn

I'm not sure I like this one, either, for the same reason: the player
should learn to avoid hitting these in meele! Taking the gaze away
from floating eyes makes them completely uninteresting, and they
almost might as well eb called "floating telepathy balls". I like
UnNetHack's solution of making them bright green to make them more
obvious.

> - Amnesia no longer causes you to forget information that could have
>   been written down, but rather skills and spells

That makes it both more scary and less annoying at the same time. I
like it.

> - Items inside a container can be BCUed by dropping the container;
>   items that stack can be BCUed by allowing them to stack with an
>   identical but BCUed item

On an altar, I assume? I like this - it avoids a tedious manual
process.


> - If an item has been charged, or if a wand has failed to work due to
>   being empty, you'll see the fact in the inventory rather than having
>   to remember

Cool. Does it distinguish between that and a wand of nothing that
still has charges?


--
Karl garrison
kgar...@pobox.com

Patric Mueller

unread,
Apr 4, 2012, 3:17:34 PM4/4/12
to
Karl Garrison <kdga...@gmail.com> wrote:
>
> Right, and agreed. Without any sign of an upcoming release from the
> devteam, someone has to pick up the ball. Variants and patches are
> nice, but it would also be nice to see "mainline" development again
> with the more popular patches and the better features from various
> variants.

How do you define "mainline"? I mean, the longer development is done,
the more it will deviate from Vanilla.

> The merging of Nitro and Ace seems like a great first step towards
> this goal. Has there been any talk of doing more merging from other
> variants as well into this tree? To me, I would think that if it's
> going to bear the name "NetHack", it should be a combination of the
> best additions since 3.4.3 was released.

There are wildly different opinions on what is considered "best". :-)

Bye
Patric

--
NetHack-De: NetHack auf Deutsch - http://nethack-de.sf.net/

UnNetHack: http://apps.sf.net/trac/unnethack/

ais523

unread,
Apr 4, 2012, 7:47:53 PM4/4/12
to
Karl Garrison wrote:
> On Apr 2, 6:14 pm, ais523 <ais...@bham.ac.uk> wrote:
>
<snip>
> Right, and agreed. Without any sign of an upcoming release from the
> devteam, someone has to pick up the ball. Variants and patches are
> nice, but it would also be nice to see "mainline" development again
> with the more popular patches and the better features from various
> variants.
>
> The merging of Nitro and Ace seems like a great first step towards
> this goal. Has there been any talk of doing more merging from other
> variants as well into this tree? To me, I would think that if it's
> going to bear the name "NetHack", it should be a combination of the
> best additions since 3.4.3 was released.

There's been some discussion of wholesale variant merges, but most
variants explicitly try to make NetHack noticeably harder, or add a lot
of controversial features that set them aside from vanilla. Everyone
seems a little dubious about merging in the entirety of, say, GruntHack
or UnNetHack. However, it's very common for variants to take individual
patches from each other (e.g. autoexplore started in AceHack, was copied
by UnNetHack and improved, then the improvements were copied back to
AceHack and the whole thing, plus some added bugfixes, ended up in
NetHack 4). Hopefully, we can get uncontroversially good ideas shared
between all the variants this way.

>> Features from AceHack (note that not all AceHack features are in
>> NetHack 4; some haven't been ported over to work with NitroHack's
>> engine yet, some turned out to be bad ideas and were removed):
>
>> - The game gives a warning upon attempting many sorts of obviously
>>   self-destructive actions (like eating corpses old enough to be
>>   tainted, or walking into lava, or attacking a shopkeeper), although
>>   allows you to override it and perform the action anyway if you really
>>   want to
>
> I don't like this one. Doing stupid things and racking up YASDs in
> the process is a big part of the game. I suppose it isn't such a big
> deal for e.g. pools and lava, but for corpses, that's a learning
> experience, and sometimes a calculated risk when you are starving and
> uncertain if the corpse is yet too old or not.
The uncertainty still matters, because there's some amount of
randomization in corpse rotting. The warning comes at 30 turns, but it's
typically safe to eat considerably beyond then.

>> - Floating eyes can no longer be damaged with melee attacks at all, but
>>   there's no penalty for trying to attack them besides the wasted turn
>
> I'm not sure I like this one, either, for the same reason: the player
> should learn to avoid hitting these in meele! Taking the gaze away
> from floating eyes makes them completely uninteresting, and they
> almost might as well eb called "floating telepathy balls". I like
> UnNetHack's solution of making them bright green to make them more
> obvious.
I find that floating eyes are still quite interesting; if one's blocking
a corridor, you're going to have to find a creative way round if you
can't kill it with ranged weapons. Arguably more interesting, as you can
no longer kill it by stacking a bunch of Elbereths and then meleeing it,
using the Elbereths to survive the paralysis. And attacking floating
eyes is still purely a bad idea, as you're wasting a turn to accomplish
nothing at all.

<snip>
>> - Items inside a container can be BCUed by dropping the container;
>>   items that stack can be BCUed by allowing them to stack with an
>>   identical but BCUed item
>
> On an altar, I assume? I like this - it avoids a tedious manual
> process.
Yes, on an altar.

>> - If an item has been charged, or if a wand has failed to work due to
>>   being empty, you'll see the fact in the inventory rather than having
>>   to remember
>
> Cool. Does it distinguish between that and a wand of nothing that
> still has charges?
It does; for one thing, the message is different, and for another thing,
the inventory will end up saying "a jeweled wand (0:0)" rather than "a
jeweled wand". This is a change from vanilla, but not a particularly
relevant one, except perhaps when encountering bones piles which you
suspect might contain empty wands.

--
ais523

Jonadab the Unsightly One

unread,
Apr 5, 2012, 12:09:31 AM4/5/12
to

On Apr 2, 6:14 pm, ais523 <ais...@bham.ac.uk> wrote:

> Likewise, many forks, like UnNetHack or GruntHack, have
> been willing to make extensive gameplay changes; NetHack
> 4 has mostly steered away from them so far, in order to stave
> off even more controversy than it's going to cause anyway, but
> both me and Daniel feel that improvements will be needed, and
> we'll add things if they're sufficiently clear upgrades.

My thinking would be, if the goal is to provide a clear
successor for vanilla NetHack, gameplay changes should
not be added *lightly* or when they are very new or highly
experimental. A variant that wants to be a mainstreamish,
successor-to-vanilla codebase should not be the first variant
to implement a particular gameplay feature, nor the second.

This is not to say that experimenting with controversial changes
is bad. Quite the contrary, I'm in favor of such experimentation,
but it should happen in variants that are comfortable in their role
as variants, i.e., ones that are specifically not trying to be
vanilla.

For example, I really like the idea that intrinsic resistances
shouldn't all be "either you've got it or you don't" binary
flags. I'm glad to see SporkHack playing around with that.
I agree in principle that it's a direction worth exploring.
But I don't think SporkHack's specific solution to that is
sufficiently settled or non-controversial to be ready to be
adopted by the entire NetHack community. There may yet be
additional or different changes that should be made to it.
(Off the top of my head: perhaps it shouldn't have messed
with reflection; perhaps sleep resistance should protect
you 100% of the time but should time out like hallucination;
perhaps magic resistance should protect you from certain things
100% of the time but not protect you from others, as has been
proposed in other threads. Bottom line, I don't think it's
ready to be merged into vanilla.)

A variant that wants to stand in for the missing next version
of vanilla NetHack should not make those kinds of changes.

I hope that doesn't preclude any gameplay changes at all. I'd
like to see gameplay changes merged in once several major
variants can arrive at something resembling a consensus.

Am I making any sense at all?

> Anyway, this marks the point at which I've stopped waiting for
> $NEXTVERSION. We're behind on bugfixes compared to the vanilla
> devteam;

I think being ahead on *released* bug fixes is relevant.

> we only have a little over 10% of the known vanilla bugs
> fixed, although of course we can make steady progress chipping
> away on those. The lack of documentation is making things
> hard; the variant maintainers have been emailing all the bug
> reports they find around to each other, and placing them on

I have an idea about that. Users other than developers ought to be
able to help gather information about what the bugs are and, more
importantly, how specifically to reproduce them. NitroHack's
determinism, and the inclusion of every single action taken in the
save files, can help with this. Perhaps we could organize an effort
to produce save-game files that demonstrate as many as possible of
the known bugs. Correct me if I'm wrong, but because of the way
NitroHack's save files work (and I imagine your NetHack 4 inherits
this), it shouldn't be necessary to have a save file where the bug
is *about* to happen, as it would have been with 3.4.3. A save
file where the bug *has* happened ought to be enough to allow the
developers to see the bug in action. Right? So any user who has
a copy of the game should be able to create such save files and
send them in, or (dare I hope) attach them in Bugzilla.

> Everyone who dismissed our posts as mere April Fools' jokes,

You know, you kind of did post them on the first.

> NetHack 4 4.2.0:
> <https://gitorious.org/nitrohack/ais523/archive-tarball/nicehack> (you
> can also get NitroHack and AceHack from the same repository, although
> their official repositories are elsewhere)

Is there a web page for this one, other than the git repository?

> Likewise, if you want to play GruntHack or NetHack 4,
> you'll currently have to compile them yourself,

Source-only release is better than binary-only release
or no release at all.

> - Stairs and traps beneath items are visible (in the curses
> interface, this is shown using background color, although this
> can be turned off); likewise, you can see where you've walked,
> if a monster is peaceful/tame/hostile, and whether your character
> knows whether doors are locked/unlocked/trapped

Interesting.

> - Commands have more consistency in the keypresses required to
> use them (e.g. eating from the ground is now always "e,", and
> eating from your inventory in slot y is now always "ey";
> vanilla's behaviour of using ey for both has killed a character
> of mine before now)

That'll take getting used to, but in the long term I expect it
should be on the whole a good thing.

> - The game gives a warning upon attempting many sorts of
> obviously self-destructive actions (like eating corpses old
> enough to be tainted, or walking into lava, or attacking a
> shopkeeper), although allows you to override it and perform
> the action anyway if you really want to

This, too, sounds good. Requiring the player to be careful is
one thing when we're talking about being careful about what you
instruct the character to *do*. Requiring ridiculously excessive
caution against simply hitting the wrong key is merely annoying.
(Stepping into water by hitting the wrong directional key is my
personal pet peeve in this regard.)

> - Doors can be opened simply by walking into them,

Is this different from NitroHack?

> - A new autoexplore command tells the game to repeatedly travel to the
> nearest unexplored square until something interesting happens (I'm
> personally a little dubious about how useful this is for general play,

Yeah, me too. (I've yet to see a computer AI that shares many
of my ideas about how to explore efficiently.)

> but it's there if you want it,

If I don't want it, all I have to do is not use that command, right?
Is it bound to a key I'm going to hit accidentally, or is it #explore
or the like?

> - You can request many sorts of information that you could
> calculate but that vanilla doesn't show from the game, such as
> kill or genocide lists, intrinsics, and score breakdowns

I think I could get addicted to that.

> - Spellbooks can be read even before your memory of the spell
> wears out,

I assume this uses up a reading of the book. Do you get a warning?

> and you can see your remaining spell memory from the + menu

As in, the number of turns? Wow, that's cool. We could, like,
stop tediously using #name to mark each spellbook with when we
read it.

> - The game now automatically identifies items for you in
> circumstances where their identity becomes obvious or could
> be trivially tested (e.g. engraving with a wand of cold, or
> wearing jumping boots, or finding a potion of oil)

Okay. I guess I'm pretty ambivalent about this.

> - Floating eyes can no longer be damaged with melee attacks
> at all, but there's no penalty for trying to attack them
> besides the wasted turn

So they now exist just to provide an easy source of telepathy?

Hmmm... I think this makes them less interesting and detracts
from what they contribute to the game.

Don't get me wrong, I've been killed more than once just because
I was walking down a corridor and tapped the key again before my
brain realized I'd just seen an e, and that always seemed like a
pretty cheap way to kill off the player.

I'm not sure I know what the ideal solution is for floating eyes.

> - Amnesia no longer causes you to forget information that could
> have been written down, but rather skills and spells

Interesting. Do you get your skill slots back, so you can relearn?

> - Swapping between primary and readied weapons no longer costs
> a turn

You realize, of course, that this changes role balance: roles that
start with a bow (or sling) and can gain significant skill with it
will be significantly easier to play with this change.

I'm not saying that's a bad thing. Just pointing it out.

> - Items inside a container can be BCUed by dropping the container;
> items that stack can be BCUed by allowing them to stack with an
> identical but BCUed item

These changes might save a lot of player time.

> - Bags of holding can no longer be destroyed by typos (the
> offending item being inserted will be cancelled instead,
> or for nesting bags fail unless it's clearly an intentional
> attempt to nest bags)

Interesting. I only destroyed a BOH that way *once* so far...
but I've been going to significant effort to avoid it.

1 2 3 4 5 6 7
1234567890123456789012345678901234567890123456789012345678901234567890

> - There are many more candles in the Mines (in the inventories of
> gnomes), to make it very unlikely that you don't find 7 in a game

One side effect of this will be a greatly decreased likelihood of
the player needing to stumble around in the dark.

> - If an item has been charged, or if a wand has failed to work
> due to being empty, you'll see the fact in the inventory rather
> than having to remember
> - Light sources can have their charge count identified (with a formal
> identification source or a scroll of charging), so you can see how
> long you have left on your oil lamp


Nice.

> The ability to play the game permanently blind or permanently
> hallucinating (no more startscumming for blindfolds

Interesting. I recently adapted Andreas Dorn's "Extended Conducts"
patch (for 3.4.3) to add support for a "hallucinating" conduct.

> - No need to press --More-- unless a turn produces so many
> messages that some would scroll off the screen

But, how will I get my thumb exercise? Think of all those Calories
that I won't be burning now.

> - The vibrating square is now an object in the game rather than
> a set of coordinates, so it's permanently visible after you've
> found it (no more need to mark the square)

Okay. Again, I'm ambivalent about this. (Marking the square
wasn't exactly difficult.)

> - Recording your choices from menus in the message history

Nice for replays.

Jonadab the Unsightly One

unread,
Apr 5, 2012, 12:44:38 AM4/5/12
to
On Apr 4, 3:17 pm, Patric Mueller <bh...@bigfoot.com> wrote:

> > The merging of Nitro and Ace seems like a great first step towards
> > this goal. Has there been any talk of doing more merging from other
> > variants as well into this tree? To me, I would think that if it's
> > going to bear the name "NetHack", it should be a combination of the
> > best additions since 3.4.3 was released.
>
> There are wildly different opinions on what is considered "best". :-)

I'd like to see changes rolled in when they've been tried for a
while in a couple of different variants, well tested for balance and
other consequences, tweaked as necessary, and generally found
to be an improvement.

Yeah, I know, there will always be *somebody* who just hates the
change because, you know, they were really attached to the way
things were in NetHack 3.1. That's unavoidable.

But I think it should be possible to strike a balance, to be
conservative about gameplay changes and avoid going off the
deep end, but also avoid stagnating forever in fear of ever
changing anything.

Incidentally, when I say "tested for balance", here are some
of the kinds of things I mean:
* Gameplay changes should avoid making the early game significantly
harder for newbies. The early game is already murder on newbies.
Let the poor noobs finally find Delphi in their thirtieth game,
okay? Sheesh.
* Gameplay changes should avoid making the game, especially the
late game, significantly easier for highly experienced players.
(Note that I would not consider removal of tedium, such as
identifying the beatitude of the contents of an altar-dropped
container, to be making the game "easier". Less tedious is a
distinct concept from easier; I'm not opposed to less tedious.)
* Gameplay changes should avoid making distinct roles playable in
a manner more similar to one another. The roles should retain
as much distinctiveness as possible. (If anything, some of
them are much too similar already.)
* Gameplay changes should avoid removing strategic choices that
the player currently must make. (For example, a new kind of
mail that provides both MR and reflection would be a bad change,
because it removes the need to decide between GDSM versus SDSM
and the associated ascension-kit strategies. Similarly, don't
add an artifact that can be easily wished for by chaotics and
grants MR when carried, because then they could wear both
SDSM and a robe instead of having to choose.)
* Gameplay changes should avoid turning the game into SLASH'EM.
That variant already exists. (I'm not saying no features from
SLASH'EM can ever be imported. Some already have, in vanilla;
but significant discretion was used in selecting which ones.)
* Gameplay changes should attempt to avoid introducing new
highly-tedious-but-highly-advantageous behaviors. As a rule
of thumb, nothing new should be both more tedious and yet
also more advantageous than polypiling.
* Gameplay changes should avoid making survival significantly
more dependant on which random starting equipment you get,
which random dungeon features you encounter, or other factors
over which the player has no control at all. (This is arguably
the largest outstanding problem with the Convict role patch;
specifically, the amount of food on DL1 is a critical issue.
I wish I had a suggestion for fixing that without making the
role easier overall. As it stands, I like it as a patch, but
I don't think it's quite ready to be rolled into the main
codebase.)

Avoiding those sorts of things will mean that some kinds of
changes need extensive balance testing before they're really
ready to be included.

However, some kinds of improvements (e.g., improved conduct
tracking) have almost no impact on the balance of normal play
and can be included after a more pedestrian level of testing
to flush out any major bugs.
Message has been deleted

Grunt

unread,
Apr 5, 2012, 1:17:03 PM4/5/12
to
On Monday, 2 April 2012 16:14:16 UTC-6, ais523 wrote:
> [...] Likewise, if you want to play GruntHack or NetHack 4,
> you'll currently have to compile them yourself [...]

Just wanted to note that this isn't true in the case of GruntHack - there is a public server available at grunthack.org.

ais523

unread,
Apr 5, 2012, 4:15:23 PM4/5/12
to
tung...@gmail.com wrote:
> On Tuesday, April 3, 2012 8:14:16 AM UTC+10, ais523 wrote:
(snip)
>> NetHack 4 4.2.0:
>> <https://gitorious.org/nitrohack/ais523/archive-tarball/nicehack> (you
>> can also get NitroHack and AceHack from the same repository, although
>> their official repositories are elsewhere)
(snip)
> Ooh, nice. Play-tested it a bit, made some notes.
>
> aimake chokes on Ubuntu 11.10. aimake's output[1] complains about libncursesw.so, so I took a look at them, and... they're text files[2][3]? Those are both stock installs from the standard apt repos. Note I don't have PostgreSQL installed; cmake works as long as I pass it -DENABLE_SERVER=FALSE.
Looks like it's having trouble finding libc, from the messages. Also
that it doesn't like whatever version of Perl you're using. I'll look
into this later.
>
> Spotted some bugs:
>
> - #chatting doesn't write the prompt for a direction. It otherwise works as normal.
Now fixed.

> - The walls of Sokoban aren't mapped, even though the floors, boulders and pits are.
Now fixed.

> - The floorcolor option doesn't mark empty doorways you step over.
This wasn't actually a bug, in that it was originally only meant to
affect floor; however, I agree that it makes more sense to color empty
doorways too, so I've changed it to color doorways too.

> - Altar alignments are recorded wrongly in the dungeon overview. I was playing a lawful samurai, reached a chaotic altar, and saw "a temple to Ameterasu Omikami". On that note, dungeon overview records altars as temples, even though real temples differ from plain old altars. NitroHack has these problems too, but I couldn't confirm it until now.
Not fixed yet; I think the same bug has been plaguing several variants.
I should check to see if it's fixed in Un.

> On gameplay:
>
> - I think gnomes drop too many candles. I understand why they carry them (to avoid players resorting to scumming if Izchak doesn't have enough), but in my first game, I had all 7 candles before I even reached Minetown. Maybe the demon princes could have a chance to carry candles, and the Wizard of Yendor could drop a candle every time he dies?
My intent was to drop them in the Mines specifically, to prevent
skipping the Mines becoming the best strategy; this would imply adding
the candles to the Mines. Following your logic too, I guess the most
sensible place to put the additional candles would be Mine's End.

> - I don't know how I feel about having floating eyes not paralyze at all when struck. Their vanilla behaviour makes them typo instadeaths, but being nerfed this much removes their threat entirely. They should still pose a danger, maybe the paralysis duration could be made much shorter (10-20 turns) and/or turned into a sleep gaze, which characters can be roused out of by combat.
I've been thinking about the floating eye problem; from one point of
view, they're much lower threats now, and from a different point of
view, they're identical to vanilla if you don't typo! Perhaps the
solution is to give floating eyes an /active/ attack, either paralysis
or sleep. Probably at melee range. That might be too large a change,
though.

> - Sometimes the background colors for monster attitudes seem a bit bright/low contrast, e.g. the light brown background for dark green peaceful hobbits.
I'm aware of this, but unsure if anything can be done about it.
Terminals just have such a shortage of indicators that can be used.
Arguably, this isn't so bad because if a monster is peaceful, its
identity is mostly irrelevant anyway, but if anyone has any better
ideas, I'd be interested to hear them. (Another thing I'm wondering
about is using inverse for both tame and peaceful, which would be
confusing in a different way.)

Thanks for your bug reports and feedback!

--
ais523

ais523

unread,
Apr 5, 2012, 4:17:54 PM4/5/12
to
Jukka Lahtinen wrote:

> Jonadab the Unsightly One <jonadab.the...@gmail.com> writes:
>> On Apr 2, 6:14 pm, ais523 <ais...@bham.ac.uk> wrote:
>
>>> - Floating eyes can no longer be damaged with melee attacks
>>> at all, but there's no penalty for trying to attack them
>
>> So they now exist just to provide an easy source of telepathy?
>> Hmmm... I think this makes them less interesting and detracts
>> from what they contribute to the game.
>
> In Nethack, if you run out of projectiles but have a blindfold (or
> something else for the same effect), you can blind yourself and kill the
> floating eye in melee. Sounds like that's is not possible with this
> variant.

It is, you're only forced to miss if you would be paralyzed in vanilla.

--
ais523

ais523

unread,
Apr 5, 2012, 4:39:20 PM4/5/12
to
I strongly agree with your views in this message, and in your reply to
Patric. NitroHack and AceHack were both very cautious about gameplay
changes for this reason; and I intend to keep up the tradition. Gameplay
changes are necessary, but doing them without thought and testing tends
to cause problems.

>> Anyway, this marks the point at which I've stopped waiting for
>> $NEXTVERSION. We're behind on bugfixes compared to the vanilla
>> devteam;
> I think being ahead on *released* bug fixes is relevant.
>
>> we only have a little over 10% of the known vanilla bugs
>> fixed, although of course we can make steady progress chipping
>> away on those. The lack of documentation is making things
>> hard; the variant maintainers have been emailing all the bug
>> reports they find around to each other, and placing them on
> I have an idea about that. Users other than developers ought to be
> able to help gather information about what the bugs are and, more
> importantly, how specifically to reproduce them. NitroHack's
> determinism, and the inclusion of every single action taken in the
> save files, can help with this. Perhaps we could organize an effort
> to produce save-game files that demonstrate as many as possible of
> the known bugs. Correct me if I'm wrong, but because of the way
> NitroHack's save files work (and I imagine your NetHack 4 inherits
> this), it shouldn't be necessary to have a save file where the bug
> is *about* to happen, as it would have been with 3.4.3. A save
> file where the bug *has* happened ought to be enough to allow the
> developers to see the bug in action. Right? So any user who has
> a copy of the game should be able to create such save files and
> send them in, or (dare I hope) attach them in Bugzilla.
This is correct; in both NitroHack and NetHack 4, it's possible to
rewind a save file. (NetHack 4 has much more tolerance for the save
being created on a slightly different version than NitroHack.)

In practice, a save file tends not to be even necessary; in most cases,
a verbal description of what happened to cause the bug (e.g. "a landmine
exploded, and the horse I was riding survived the explosion but not the
fall") is typically enough to find the bug in the source code. That's
not to say it wouldn't be helpful, of course. Just that the big problem
tends to be figuring out what the bug description even means, rather
than finding or fixing the bug when we know what it is.

(snip)
>> NetHack 4 4.2.0:
>> <https://gitorious.org/nitrohack/ais523/archive-tarball/nicehack> (you
>> can also get NitroHack and AceHack from the same repository, although
>> their official repositories are elsewhere)
> Is there a web page for this one, other than the git repository?
Not yet. I imagine there will be one before too long.

>> Likewise, if you want to play GruntHack or NetHack 4,
>> you'll currently have to compile them yourself,
> Source-only release is better than binary-only release
> or no release at all.
Indeed. (Grunt has pointed out that GruntHack has a dgamelaunch server
at <telnet:grunthack.org>, incidentally, so I was slightly misinformed
on this.) It's much easier to prepare a binary release from a source
release than the other way round!

(snip)
>> - Doors can be opened simply by walking into them,
> Is this different from NitroHack?
No, but NitroHack originally copied the change from AceHack (or perhaps
UnNetHack; Ace and Un implemented it independently).

>> - A new autoexplore command tells the game to repeatedly travel to the
>> nearest unexplored square until something interesting happens (I'm
>> personally a little dubious about how useful this is for general play,
> Yeah, me too. (I've yet to see a computer AI that shares many
> of my ideas about how to explore efficiently.)
>
>> but it's there if you want it,
> If I don't want it, all I have to do is not use that command, right?
> Is it bound to a key I'm going to hit accidentally, or is it #explore
> or the like?
It's bound to lowercase v, which is one of the least-used commands in
vanilla. If you're worried about hitting it accidentally, you can use
the key rebind menu to turn it off altogether, but I don't think I've
accidentally hitten v for years.

>> - You can request many sorts of information that you could
>> calculate but that vanilla doesn't show from the game, such as
>> kill or genocide lists, intrinsics, and score breakdowns
> I think I could get addicted to that.
It's on a menu accessed via control-X, in case you haven't found it yet.

>> - Spellbooks can be read even before your memory of the spell
>> wears out,
> I assume this uses up a reading of the book. Do you get a warning?
You get a confirmation. (And yes, it uses up a reading of the book.)

>> and you can see your remaining spell memory from the + menu
> As in, the number of turns? Wow, that's cool. We could, like,
> stop tediously using #name to mark each spellbook with when we
> read it.
It shows it as a percentage; because spells wear out after 20000 turns,
each percentage shown indicates 200 turns of remaining memory. So it's
not accurate to the individual turn, but should be close enough. I can
show the exact value if there's demand.

(snip)
>> - Floating eyes can no longer be damaged with melee attacks
>> at all, but there's no penalty for trying to attack them
>> besides the wasted turn
> So they now exist just to provide an easy source of telepathy?
>
> Hmmm... I think this makes them less interesting and detracts
> from what they contribute to the game.
>
> Don't get me wrong, I've been killed more than once just because
> I was walking down a corridor and tapped the key again before my
> brain realized I'd just seen an e, and that always seemed like a
> pretty cheap way to kill off the player.
>
> I'm not sure I know what the ideal solution is for floating eyes.

Neither do I; it's becoming clear that my current situation is
unsatisfactory. What do you think of the suggestion of giving floating
eyes an active (range 1, gaze) paralysis or sleep attack? It's something
I'm considering, but needs a lot more discussion before adding, and
perhaps testing too.

>> - Amnesia no longer causes you to forget information that could
>> have been written down, but rather skills and spells
> Interesting. Do you get your skill slots back, so you can relearn?
Yes, but you lose a random proportion of the skill training, so you have
to practice it again.

>> - Swapping between primary and readied weapons no longer costs
>> a turn
> You realize, of course, that this changes role balance: roles that
> start with a bow (or sling) and can gain significant skill with it
> will be significantly easier to play with this change.
>
> I'm not saying that's a bad thing. Just pointing it out.
I am aware of that consequence; I didn't think it would be hugely
disruptive to the game's balance, though. (Especially as projectile
weapons are comparatively rarely used.)

(snip)
>> - There are many more candles in the Mines (in the inventories of
>> gnomes), to make it very unlikely that you don't find 7 in a game
> One side effect of this will be a greatly decreased likelihood of
> the player needing to stumble around in the dark.
It'd be great if it were actually possible to use candles for light for
once!

(snip)
>> - Recording your choices from menus in the message history
> Nice for replays.
NitroHack already does this for replays, incidentally; however, the
method it used failed when replaying on a version other than the exact
same version the replay was made on, so I had to do it differently for
NetHack 4.

--
ais523

Jonadab the Unsightly One

unread,
Apr 5, 2012, 4:47:00 PM4/5/12
to

Okay, I got around to compiling NH4 after work today, and I have
developed a small handful of (hopefully straightforward) questions...

1. Are there plans for a NetHack 4 public server in the near future?
Is there one already in existence and I missed that info?

2. Does NetHack 4 subsume and replace both NitroHack and AceHack,
or will either or both of them retain an independent existence?
If the latter, will new versions of them be forked off from NH4
(e.g., as a way of testing experimental features), or will their
old, pre-merge codebases be maintained?

3. Has someone taken the list of known 3.4.3 bugs and crossed off
the ones known to have already been fixed in NH4, leaving a list
of ones suspected to be outstanding? If so, where is it? If
not, this seems like something a non-developer could easily do...
would such a thing be useful?

4. Purely hypothetically, if a player collects more detailed
information about an outstanding bug and/or steps to reproduce
and/or a savegame/log that shows it, where should such
information be posted or sent? Here in rgrn? Somewhere else?

5. Is it okay to use the abbreviation "NH4" for this version?

Okay, I guess five questions is enough for right now.

Grunt

unread,
Apr 5, 2012, 4:56:23 PM4/5/12
to
On Thursday, 5 April 2012 14:39:20 UTC-6, ais523 wrote:
> [...]
> Neither do I; it's becoming clear that my current situation is
> unsatisfactory. What do you think of the suggestion of giving floating
> eyes an active (range 1, gaze) paralysis or sleep attack? It's something
> I'm considering, but needs a lot more discussion before adding, and
> perhaps testing too.
> [...]

In my mind, the approach to take is simple: leave it as it is in vanilla.

The floating eye is a monster with a passive paralysis attack, and though there are some quirks specific to that monster, it's not the only monster with such an attack (cf. gelatinous cubes), and far from the only monster with a passive attack. Do all monsters with passive attacks suddenly need to be changed because you might walk into them accidentally?

Learning not to attack monsters with passive attacks is part of the experience, in my view.

ais523

unread,
Apr 5, 2012, 5:02:49 PM4/5/12
to
Jonadab the Unsightly One wrote:
> Okay, I got around to compiling NH4 after work today, and I have
> developed a small handful of (hopefully straightforward) questions...
>
> 1. Are there plans for a NetHack 4 public server in the near future?
> Is there one already in existence and I missed that info?
There isn't one in existence, currently. Some people have expressed
interest in hosting one, though, and if that falls through, or even if
it doesn't, I may host one myself.

> 2. Does NetHack 4 subsume and replace both NitroHack and AceHack,
> or will either or both of them retain an independent existence?
> If the latter, will new versions of them be forked off from NH4
> (e.g., as a way of testing experimental features), or will their
> old, pre-merge codebases be maintained?
daniel_t was interested in the merge between the codebases, but has been
busy recently and hasn't reacted to NetHack 4's release yet. I imagine
he'll move to it rather than NitroHack, but am not sure. From my point
of view, I'm intending to abandon AceHack once I've merged all its
features into NetHack 4 (notably, NetHack 4 doesn't do multiplayer yet),
unless there's huge demand to have it seperate from NetHack 4 (in which
case I've probably done something wrong with the merge).

> 3. Has someone taken the list of known 3.4.3 bugs and crossed off
> the ones known to have already been fixed in NH4, leaving a list
> of ones suspected to be outstanding? If so, where is it? If
> not, this seems like something a non-developer could easily do...
> would such a thing be useful?
I have a list of vanilla bugs not fixed in AceHack, although of course
the list of bugs not fixed in NH4 is going to be slightly different,
due to the different codebases. The list is a bit long and boring to
reasonably post via Usenet, but I'll send it via private email to anyone
who's interesting. A list modified for NH4 would indeed be useful.

> 4. Purely hypothetically, if a player collects more detailed
> information about an outstanding bug and/or steps to reproduce
> and/or a savegame/log that shows it, where should such
> information be posted or sent? Here in rgrn? Somewhere else?
There are several places I monitor for this sort of report: my email;
rgrn; IRC (we're using <irc:irc.freenode.net/acehack> to discuss NetHack
4 because AceHack had a pre-existing IRC community and NitroHack
didn't); channels and codebases of other variants. I'd say that rgrn is
a great place to send descriptions and steps to reproduce bugs; that
way, they're readily available to all the variant maintainers, as well
as the vanilla devteam. Savegames and logs should probably be sent to me
via private email, because they're large, and sending binaries through a
newsgroup not in alt.binaries.* tends to get news servers annoyed.

> 5. Is it okay to use the abbreviation "NH4" for this version?
Sure, it's unambiguous enough.

--
ais523

Jonadab the Unsightly One

unread,
Apr 5, 2012, 5:12:54 PM4/5/12
to
On Apr 4, 1:37 pm, Karl Garrison <kdgar...@gmail.com> wrote:
> > - If an item has been charged, or if a wand has failed to work due to
> > being empty, you'll see the fact in the inventory rather than having
> > to remember
>
> Cool. Does it distinguish between that and a wand of nothing that
> still has charges?

If any wand of that type has been formally identified, or if you've
engrave-identified or zap-identified one, or a monster has zapped
one at you or otherwise used one in your immediate vicinity, then
you know it's a wand of [function], and this is a non-issue. That
would be the most common case, since wands are very seldom
generated empty. But yeah, in the event that you for some reason
don't know what it's a wand _of_, perhaps its emptiness should
not be officially revealed, particularly if you also have not yet
identified any wands of nothing.

Jonadab the Unsightly One

unread,
Apr 5, 2012, 5:17:23 PM4/5/12
to
On Apr 4, 3:17 pm, Patric Mueller <bh...@bigfoot.com> wrote:

> There are wildly different opinions on what is considered "best". :-)

Sometimes a lot of people's opinions converge. There are
a number of patches that almost everyone either likes or is
at least ambivalent about, which have been incorporated into
more than one variant and installed on multiple public servers.
Menucolors springs immediately to mind as perhaps the best
example of this in the time since 3.4.3 was released, but
there are also other patches that have met with widespread
approval.

Granted, gameplay changes are often more controversial
than mere interface changes. Still, some of them get a lot
closer to consensus than others.

Patric Mueller

unread,
Apr 5, 2012, 6:15:06 PM4/5/12
to
Jonadab the Unsightly One <jonadab.the...@gmail.com> wrote:
> On Apr 4, 3:17 pm, Patric Mueller <bh...@bigfoot.com> wrote:
>
>> There are wildly different opinions on what is considered "best". :-)
>
> Sometimes a lot of people's opinions converge. There are
> a number of patches that almost everyone either likes or is
> at least ambivalent about, which have been incorporated into
> more than one variant and installed on multiple public servers.

I think the best example for this is the dungeon overview patch. A
wonderful patch that lay dormant in a UseNet posting, neglected
because there was no visible NetHack until I uncovered this little gem
4 years after it was posted.

Now it's at least in UnNetHack, AceHack, NitroHack (and therefore also
in NetHack 4).

> Menucolors springs immediately to mind as perhaps the best
> example of this in the time since 3.4.3 was released, but

Menucolors is older than 3.4.3. ;-)

> there are also other patches that have met with widespread
> approval.

Do you have something special in mind?

> Granted, gameplay changes are often more controversial
> than mere interface changes. Still, some of them get a lot
> closer to consensus than others.

Again, which ones should that be that aren't already in the actively
developed variants?

I would be surprised if there were any essential patches left, after
all, non controversial changes get applied very quickly, when you have
real *active* development going on.

Jonadab the Unsightly One

unread,
Apr 5, 2012, 8:47:43 PM4/5/12
to
On Apr 5, 4:15 pm, ais523 <ais...@bham.ac.uk> wrote:

> > - I think gnomes drop too many candles.
>
> My intent was to drop them in the Mines specifically, to prevent
> skipping the Mines becoming the best strategy;

Unless you've made major changes I don't know about, skipping the
Mines altogether is not a good strategy. Delaying the Mines until
post-Sokoban is often a good strategy, maybe even a bit later,
depending on role, but there's a lot of good loot to be had in
the Mines, including experience points that you need in order
to qualify for the quest before Gehennom, among other things.

However...

> Following your logic too, I guess the most sensible place
> to put the additional candles would be Mine's End.

Is it not possible to simply guarantee at least seven of them
in Izchak's shop? That would be a highly logical place for them.

> I've been thinking about the floating eye problem; from one point
> of view, they're much lower threats now, and from a different point
> of view, they're identical to vanilla if you don't typo! Perhaps
> the solution is to give floating eyes an /active/ attack, either
> paralysis or sleep. Probably at melee range. That might be too
> large a change, though.

Perhaps the active attack could have a MUCH shorter duration than
the passive attack -- short enough that you necessarily get a
chance to run away before the attack can be used again (unless
you have the grave misfortune to get surrounded by multiple eyes
at once, but getting surrounded is a difficult tactical situation
with other types of monsters as well, and something that the
player must learn to avoid if his character is not highly buff).

I understand the desire to change the way eyes work in vanilla,
because dying due to a typo is highly annoying and does not
really improve the gaming experience or teach the player anything
of value. Nonetheless, I'm not sure just taking away their mojo
is the right answer.

I think some variants ask for confirmation before you attack
floating eyes in melee. That seems less drastic than forbidding
it altogether, but only just.

Perhaps some alternate distinctiveness can be found to make
floating eyes _interesting_. Just nerfing the everliving daylights
out of them seems unfortunate. You might about as well just give
all players permanent telepathy and remove floating eyes from the
game, because they don't really add much to the game without their
interesting unique attack type.

Perhaps their passive attack could have a chance of causing one
of several effects -- confusion, stunning, paralysis, sleep, etc.,
and/or it could be shorter lived than it is currently and/or the
character could have a percentage chance to recover each time
HP damage is sustained, so that a lousy grid bug can't tap you
to death with its feather duster.

I don't know. I'm just thinking out loud here. It's not a
straightforward issue with a single clear obvious solution.

>
> > - Sometimes the background colors for monster attitudes
> > seem a bit bright/low contrast, e.g. the light brown
> > background for dark green peaceful hobbits.
>
> I'm aware of this, but unsure if anything can be done about it.
> Terminals just have such a shortage of indicators that can be used.

Note that almost all terminal emulators -- all modern ones --
allow the user to set up profiles that change the specific colors
that are used. Thus, if the user is using a dark green background
color for the window (say, #244927) and the program calls for
"dark green" for a particular character, the user may have it
set up so that it's actually rendered in a much brighter green
(say, #7CFF00) so that it shows up. Another character, which
calls for light green, may actually be rendered in a very light
pastel shade (say, #E3FFC8). For that matter, light and dark
can even be swapped entirely, or white can be yellow and yellow
can be orange and red can be maroon, or whatever the user wants.

But yes, in any tty port, you only have a grand total of eighteen
colors to work with altogether, including the default foreground
and default background colors, which may or may not duplicate any
of the others.

A web-based UI would be freed of this restriction, even if
using all text and no images, but it should be noted that the
amount of color depth the human visual cortex can distinguish
varies rather enormously from person to person. At least 25%
of the population won't really see the difference between e.g.
#06989A versus #34E2E2 versus #A5A9FF. (Of course, we can
always just tell such people to use a tile-based UI.)

> Arguably, this isn't so bad because if a monster is peaceful, its
> identity is mostly irrelevant anyway, but if anyone has any better
> ideas, I'd be interested to hear them.

Well, the background colors should probably be configurable,
not just the ability to turn them on and off, but to set which
of the terminal's colors to use. (Are they already like that?
I wasn't looking for such an option, because my color depth
perception is rather better than average. The price I pay for
that is, I can't stand to browse the web with page colors
enabled, because of all the Evil Blinding White Backgrounds.
YMMV.) Apart from that, there's only so much the tty port
can do. I imagine someone will want to do a web-based port
at some point, and possibly a tile-based GUI port as well.

> (Another thing I'm wondering about is using inverse for
> both tame and peaceful, which would be confusing in a
> different way.)

Perhaps that could be an option? I don't know that I could decide
whether it was too confusing to use without trying it. It might
depend on whether you normally play the whole game with 0-2 pets
or tend to accumulate more.

ais523

unread,
Apr 5, 2012, 9:05:48 PM4/5/12
to
Jonadab the Unsightly One wrote:
> On Apr 5, 4:15 pm, ais523 <ais...@bham.ac.uk> wrote:
>
>> > - I think gnomes drop too many candles.
>>
>> My intent was to drop them in the Mines specifically, to prevent
>> skipping the Mines becoming the best strategy;
>
> Unless you've made major changes I don't know about, skipping the
> Mines altogether is not a good strategy. Delaying the Mines until
> post-Sokoban is often a good strategy, maybe even a bit later,
> depending on role, but there's a lot of good loot to be had in
> the Mines, including experience points that you need in order
> to qualify for the quest before Gehennom, among other things.
This is based on experience talking to speedrunners; pretty much the
only thing they really care about from the mines is candles, maybe
the altar, and the chance of a magic lamp in a shop. In sufficiently
lucky games, skipping the mines would be best if not for the candles.
(Gametime speedrunners would want as many wishes as possible for gain
level, so wouldn't want to spend a wish on candles.)

> However...
>
>> Following your logic too, I guess the most sensible place
>> to put the additional candles would be Mine's End.
>
> Is it not possible to simply guarantee at least seven of them
> in Izchak's shop? That would be a highly logical place for them.
Hmm, would make sense, at least. It's much more difficult code-wise than
simply changing the initial inventory of a monster, but of course that
doesn't mean it's impossible.

>> I've been thinking about the floating eye problem; from one point
>> of view, they're much lower threats now, and from a different point
>> of view, they're identical to vanilla if you don't typo! Perhaps
>> the solution is to give floating eyes an /active/ attack, either
>> paralysis or sleep. Probably at melee range. That might be too
>> large a change, though.
>
> Perhaps the active attack could have a MUCH shorter duration than
> the passive attack -- short enough that you necessarily get a
> chance to run away before the attack can be used again (unless
> you have the grave misfortune to get surrounded by multiple eyes
> at once, but getting surrounded is a difficult tactical situation
> with other types of monsters as well, and something that the
> player must learn to avoid if his character is not highly buff).
Yes, the active attack would necessarily be very short duration.
Otherwise floating eyes would be much too powerful for their place in
the game.

> I understand the desire to change the way eyes work in vanilla,
> because dying due to a typo is highly annoying and does not
> really improve the gaming experience or teach the player anything
> of value. Nonetheless, I'm not sure just taking away their mojo
> is the right answer.
>
> I think some variants ask for confirmation before you attack
> floating eyes in melee. That seems less drastic than forbidding
> it altogether, but only just.
That was actually a (moderately successful) troll; there's a patch on
bilious that prompts you for confirmation when you attack a floating
eye, but doesn't let you cancel the attack at the prompt. (It was
expressed allong the lines of "allows you to confirm attacks on floating
eyes".)

> Perhaps some alternate distinctiveness can be found to make
> floating eyes _interesting_. Just nerfing the everliving daylights
> out of them seems unfortunate. You might about as well just give
> all players permanent telepathy and remove floating eyes from the
> game, because they don't really add much to the game without their
> interesting unique attack type.
They do; they're the only earlygame monster that can't be beaten in
melee. (In both vanilla and NH4.) I think that's enough of an
interesting niche for them, and much more interesting than most
earlygame monsters.

> Perhaps their passive attack could have a chance of causing one
> of several effects -- confusion, stunning, paralysis, sleep, etc.,
> and/or it could be shorter lived than it is currently and/or the
> character could have a percentage chance to recover each time
> HP damage is sustained, so that a lousy grid bug can't tap you
> to death with its feather duster.
>
> I don't know. I'm just thinking out loud here. It's not a
> straightforward issue with a single clear obvious solution.
I agree, and thinking out loud is exactly the right thing to do here, as
nobody seems to have any easy answers.
They aren't currently configurable; they're actually chosen to avoid
color-based clashes as much as possible, but as you've seen, it isn't
perfect. (The majority of generates-peaceful monsters are brown, gray or
white.) This is the same reason ladders are yellow rather than brown in
NetHack 4, incidentally; it's so they show up nicely on the red
background with bgbranding on. Making them configurable is reasonable,
but a bit of effort as the code doesn't allow you to set an option to a
background color yet. (There are only six possibilities, incidentally;
seven if you count white, which is no good as a default because many
terminals screw up on it, but which would be reasonable for a
configuration setting where the user can simply not use it if it would
confuse their terminal.)

>> (Another thing I'm wondering about is using inverse for
>> both tame and peaceful, which would be confusing in a
>> different way.)
>
> Perhaps that could be an option? I don't know that I could decide
> whether it was too confusing to use without trying it. It might
> depend on whether you normally play the whole game with 0-2 pets
> or tend to accumulate more.
It would be an option; I'm the sort of person who doesn't like options
that nobody uses, though. (There are a lot of those in vanilla...)

Jonadab the Unsightly One

unread,
Apr 5, 2012, 9:10:37 PM4/5/12
to
On Apr 5, 4:39 pm, ais523 <ais...@bham.ac.uk> wrote:

> > This is not to say that experimenting with controversial changes
> > is bad. Quite the contrary, I'm in favor of such experimentation,
> > but it should happen in variants that are comfortable in their role
> > as variants, i.e., ones that are specifically not trying to be
> > vanilla.
[snip]
> > Am I making any sense at all?
>
> I strongly agree with your views in this message, and in your reply to
> Patric. NitroHack and AceHack were both very cautious about gameplay
> changes for this reason; and I intend to keep up the tradition. Gameplay
> changes are necessary, but doing them without thought and testing tends
> to cause problems.

Like I said, some variants exist for the purpose of experimenting
with doing things differently from vanilla, and that's all well
and good. SLASH'EM threw in all sorts of stuff, and that was good,
for SLASH'EM. Some of that stuff eventually made its way back into
vanilla -- after it had been in SLASH'EM for a while so that people
could get a feel for how it worked. Other things in SLASH'EM will
never make their way into vanilla, because when people get a feel
for how they work it will be determined that they don't belong in
vanilla, ever. For SLASH'EM you can substitute any other variant
that introduces a lot of previously-untested gameplay changes.

Such variants are necessary (how else can proposed changes be field
tested to see if they'll work out?), but in the absense of further
vanilla NetHack releases from the 3.4.x dev team we need at least
one variant that isn't like that, to collect the things that have
been tested and found suitable.

> >> a little over 10% of the known vanilla bugs fixed,

> > I have an idea about that. [snip] So any user who has
> > a copy of the game should be able to create such save files and
> > send them in, or (dare I hope) attach them in Bugzilla.
>
> This is correct; in both NitroHack and NetHack 4, it's possible to
> rewind a save file. (NetHack 4 has much more tolerance for the save
> being created on a slightly different version than NitroHack.)
>
> In practice, a save file tends not to be even necessary; in most cases,
> a verbal description of what happened to cause the bug (e.g. "a landmine
> exploded, and the horse I was riding survived the explosion but not the
> fall") is typically enough to find the bug in the source code. That's
> not to say it wouldn't be helpful, of course. Just that the big problem
> tends to be figuring out what the bug description even means, rather
> than finding or fixing the bug when we know what it is.

Ah. I suppose it depends on the bug, and how easy it is to find
in the code, and how obvious the fix is. (I have just enough of
a programming background to understand how the ability to
reliably reproduce a big can allow you to test whether your fix
actually works, among other things.)

> (snip)>> - Doors can be opened simply by walking into them,
> > Is this different from NitroHack?
>
> No, but NitroHack originally copied the change from AceHack (or perhaps
> UnNetHack; Ace and Un implemented it independently).

Ah, I see. I'd been meaning to take a look at those variants but
hadn't gotten around to it yet. NitroHack happened to announce
a release at a time when it could get my attention, so I had played
around with it somewhat.

> It's on a menu accessed via control-X, in case you haven't found it yet.

Yeah, I looked through the key bindings this afternoon. I ended
up turning on the #extended command option for several of the
new features.

> >> - Spellbooks can be read even before your memory of the spell
> >> wears out,
> > I assume this uses up a reading of the book. Do you get a warning?
>
> You get a confirmation. (And yes, it uses up a reading of the book.)

Makes sense to me.

> >> and you can see your remaining spell memory from the + menu
> > As in, the number of turns? Wow, that's cool. We could, like,
> > stop tediously using #name to mark each spellbook with when we
> > read it.
>
> It shows it as a percentage; because spells wear out after 20000
> turns, each percentage shown indicates 200 turns of remaining
> memory. So it's not accurate to the individual turn, but should
> be close enough. I can show the exact value if there's demand.

Knowing within a couple hundred turns should be good enough,
I think. (You usually can't predict how long a trip back to your
book stash will take much more closely than that anyway, unless
you've got a branchport artifact, in which case you can just
go whenever your spell runs out.)

> >> - Amnesia no longer causes you to forget information that could
> >> have been written down, but rather skills and spells
> > Interesting. Do you get your skill slots back, so you can relearn?
>
> Yes, but you lose a random proportion of the skill training, so you have
> to practice it again.

Right, I understood that part.

> >> - Swapping between primary and readied weapons no longer costs
> >> a turn
> > You realize, of course, that this changes role balance: roles that
> > start with a bow (or sling) and can gain significant skill with it
> > will be significantly easier to play with this change.
>
> > I'm not saying that's a bad thing. Just pointing it out.
>
> I am aware of that consequence; I didn't think it would be hugely
> disruptive to the game's balance, though. (Especially as projectile
> weapons are comparatively rarely used.)

I don't think it's a bad thing. If anything, it may lead to more
people
using ranged weapons other than daggers on a regular basis. More
variety in gameplay styles could result, which would be good.

Now if we can just figure out what to do about Gehennom...
But that's another thread for another day.

tung...@gmail.com

unread,
Apr 5, 2012, 11:16:28 PM4/5/12
to
On Friday, April 6, 2012 6:15:23 AM UTC+10, ais523 wrote:
> tung wrote:
> > aimake chokes on Ubuntu 11.10. aimake's output[1] complains about libncursesw.so, so I took a look at them, and... they're text files[2][3]? Those are both stock installs from the standard apt repos. Note I don't have PostgreSQL installed; cmake works as long as I pass it -DENABLE_SERVER=FALSE.
> Looks like it's having trouble finding libc, from the messages. Also
> that it doesn't like whatever version of Perl you're using. I'll look
> into this later.

apt says I have "libc6 - Embedded GNU C Library: Shared libraries" (version 2.13-20ubuntu5.1) installed, plus the dev packages.

perl -v says "This is perl 5, version 12, subversion 4 (v5.12.4) built for i686-linux-gnu-thread-multi-64int".

> > On gameplay:
> >
> > - I think gnomes drop too many candles.
> My intent was to drop them in the Mines specifically, to prevent
> skipping the Mines becoming the best strategy; this would imply adding
> the candles to the Mines. Following your logic too, I guess the most
> sensible place to put the additional candles would be Mine's End.

My logic is that Izchak sometimes lacking candles adds an interesting random element to games, which is what makes NetHack unique amongst roguelikes. It'd be a shame to squelch that for the sake of speed-runners, so I suggested a riskier option to get the missing candles without resorting to scumming.

--
Tung

tung...@gmail.com

unread,
Apr 5, 2012, 11:36:46 PM4/5/12
to
On Thursday, April 5, 2012 9:47:53 AM UTC+10, ais523 wrote:
> Karl Garrison wrote:
> >
> >> - Floating eyes can no longer be damaged with melee attacks at all, but
> >>   there's no penalty for trying to attack them besides the wasted turn
> >
> > I'm not sure I like this one, either, for the same reason: the player
> > should learn to avoid hitting these in meele! Taking the gaze away
> > from floating eyes makes them completely uninteresting, and they
> > almost might as well eb called "floating telepathy balls". I like
> > UnNetHack's solution of making them bright green to make them more
> > obvious.
> I find that floating eyes are still quite interesting; if one's blocking
> a corridor, you're going to have to find a creative way round if you
> can't kill it with ranged weapons. Arguably more interesting, as you can
> no longer kill it by stacking a bunch of Elbereths and then meleeing it,
> using the Elbereths to survive the paralysis. And attacking floating
> eyes is still purely a bad idea, as you're wasting a turn to accomplish
> nothing at all.

To me at least, it makes them almost identical to acid blobs, where "can't hit" is the same difference as "don't want to hit". Floating eyes are the only early-game monster that are actively dangerous to hit, which sets them apart.

--
Tung

tung...@gmail.com

unread,
Apr 5, 2012, 11:50:32 PM4/5/12
to
On Friday, April 6, 2012 6:15:23 AM UTC+10, ais523 wrote:
>
> Thanks for your bug reports and feedback!
>

Oh, I note in the commit logs you use the ID "tunginobi". In future could you use my real name (Tung Nguyen)? I made that ID a decade ago and I hate it; I'm just stuck with it.

Cheers,
Tung

ais523

unread,
Apr 5, 2012, 11:56:29 PM4/5/12
to
That's fine. There just wasn't any other indication as to what your name
was.

--
ais523

Patric Mueller

unread,
Apr 6, 2012, 3:20:13 AM4/6/12
to
tung...@gmail.com wrote:
>
> My logic is that Izchak sometimes lacking candles adds an interesting
> random element to games, which is what makes NetHack unique amongst
> roguelikes. It'd be a shame to squelch that for the sake of
> speed-runners, so I suggested a riskier option to get the missing
> candles without resorting to scumming.

It's not only for speed-runner. It can happen to any player that
either Izchak has too few candles or due to some accident you lose
candles.

Then you're standing on the VS, completely prepared, but you have to
go hunting candles. It's not an interesting twist, it's a punishment.

This is similar to old adventure games, where you had to do some
completely unrelated action early in the game and if you forgot that
you were stuck at the end of the game. It's not this bad in NetHack
but it's really annoying.

tung...@gmail.com

unread,
Apr 6, 2012, 4:31:03 AM4/6/12
to bh...@gmx.net
On Friday, April 6, 2012 5:20:13 PM UTC+10, Patric Mueller wrote:
> Tung wrote:
> >
> > My logic is that Izchak sometimes lacking candles adds an interesting
> > random element to games, which is what makes NetHack unique amongst
> > roguelikes. It'd be a shame to squelch that for the sake of
> > speed-runners, so I suggested a riskier option to get the missing
> > candles without resorting to scumming.
>
> It's not only for speed-runner. It can happen to any player that
> either Izchak has too few candles or due to some accident you lose
> candles.
>

ais523 says in a different sub-thread that he made this change based on input from speed-runners, which is why I mentioned them.

> Then you're standing on the VS, completely prepared, but you have to
> go hunting candles. It's not an interesting twist, it's a punishment.
>
> This is similar to old adventure games, where you had to do some
> completely unrelated action early in the game and if you forgot that
> you were stuck at the end of the game. It's not this bad in NetHack
> but it's really annoying.

...

I was about to protest, but after I thought about it, I agree with you. The candles are the only non-artifact item required to ascend, which means they can break, so the only solution to having too few is to have a surplus of them.

Looking back, the Wizard of Yendor dropping candles on death is a poor idea; I didn't intend to support grinding, backtracking or anything boring. Ideally, you wouldn't be on the vibrating square short of candles, but you'd notice Izchak was short, so you'd plan to detour to, say, the ends of branches or other side locations (e.g. smaller islands on Medusa's Island) you wouldn't need to go to otherwise to collect guaranteed candles at those places. Of course, all of this ignores the surplus needed in case candles get destroyed, and the only way to guarantee that surplus is to make them safe (carried by monsters) and make them common (common monsters).

The general point I was trying to make was that not all problems the player faces are necessarily game flaws; sometimes there are ways of adding it to the game that makes it more interesting. There doesn't seem to be a way for candle shortages though.

--
Tung

Patric Mueller

unread,
Apr 6, 2012, 7:19:38 AM4/6/12
to
tung...@gmail.com wrote:
>
> Ais523 says in a different sub-thread that he made this change based on
> input from speed-runners, which is why I mentioned them.

Ah, it's possible that he got the attention from speed-runners, but I
also remember lots of threads on RGRN about them and what to do when
you accidentally lost them.

Just search for "lost candles" on RGRN and there will turn up heaps of
messages.

> Looking back, the Wizard of Yendor dropping candles on death is a poor
> idea; I didn't intend to support grinding, backtracking or anything
> boring. Ideally, you wouldn't be on the vibrating square short of
> candles, but you'd notice Izchak was short, so you'd plan to detour to,
> say, the ends of branches or other side locations (e.g. Smaller islands
> on Medusa's Island) you wouldn't need to go to otherwise to collect
> guaranteed candles at those places. Of course, all of this ignores the
> surplus needed in case candles get destroyed, and the only way to
> guarantee that surplus is to make them safe (carried by monsters) and
> make them common (common monsters).

UnNetHack has now wax golems that death drop candles. That should make
it relatively easy to get candles if you'd need some.

I kept the change from AceHack where gnomes get random candles,
although I toned down the chance this happening. It's a nice view
in the mines when seeing a gnome with a lit candle on the other side
of the screen.

> The general point I was trying to make was that not all problems the
> player faces are necessarily game flaws; sometimes there are ways of
> adding it to the game that makes it more interesting. There doesn't seem
> to be a way for candle shortages though.

I agree on both accounts. Generally it's not a game flaw but with
candles it's annoying and unnecessary.

Capt. Cave Man

unread,
Apr 6, 2012, 8:26:16 AM4/6/12
to
Dude(s)! (it is more than just you)

Usenet line length, 72 characters or less, not your never hit the
carriage return key idiocy.

I have always had a great disdain for web accessed Usenet interfaces.

It's so easy a cave man can do it.

I still can't believe that google is so stupid that they do not TIE you
dopes... err folks to the right formatting.
I had to "properly" format your quoted crap, before my Usenet account
would allow the post, because their servers ARE set up properly.

Capt. Cave Man

unread,
Apr 6, 2012, 8:29:11 AM4/6/12
to
On Thu, 5 Apr 2012 20:50:32 -0700 (PDT), tung...@gmail.com wrote:

>On Friday, April 6, 2012 6:15:23 AM UTC+10, ais523 wrote:
>>
>> Thanks for your bug reports and feedback!
>>
>
>Oh, I note in the commit logs you use the ID "tunginobi"
> In future could you use my real name (Tung Nguyen)? I
> made that ID a decade ago and I hate it; I'm just stuck with it.
>
>Cheers,
>Tung

Why did you not, "a decade ago", "learn" what the posting conventions
of Usenet were?

Jonadab the Unsightly One

unread,
Apr 6, 2012, 9:21:43 AM4/6/12
to
Okay, I was going to make a separate thread of this, but
Google Groups is being cantankerous this morning, so let's
see if I can even post it at all...

Okay, so I was reading the information that comes with NH4
(specifically, the README file) -- yeah, I know, novel approach --
and I found the list of which known NetHack bugs have been fixed.
Then I started to compare with the list of known NetHack bugs on
the wiki, looking at the ones lot listed as fixed in NH4, and I
made the following notes (listed in the same order as the bug
list on the wiki)...

C341-1 - effectively fixed, since NH4 can't load NH3 bones
C341-4 - dat/opthelp no longer exists as far as I can tell;
libnethack/src/options.c DOES list use_inverse,
so I don't think NH4 has a problem here
C341-5 - status unknown; I plan to attempt to reproduce this
one at some point
C341-7 - I have a wizmode save that demonstrates this in NH4
C341-10 - In general, it's impossible to know whether a -us word
is singular or plural without knowing the etymology, so
unless there are specific fruits that are worth coding
for, I say forget it.
C341-18 - Is that even a bug? I can't see how it has any real
negative impact on gameplay. Couldn't it just be declared
a feature? Our ki-rins are different from the ones in
D&D or whatever source inspired them, so there. Done.
C342-12 - I think I see what you mean about the descriptions on
the bug list being rather vague sometimes. I don't even
know where to start with this one. Triage it for "later",
unless someone files a more specific bug report.
C342-13 - NitroHack's separation of the game and UI *may* have
obviated this one, but we should probably test it.
I'll plan on trying to do that.
C342-16 - Reproduced in NH4. Very easy to reproduce in wizard mode:
Genocide your starting race, then get killed in the
mundane fashion while polymorphed. Death message reads,
You return to [racial] form. DYWYPI?

That's it for this morning. If this sort of thing is at all
helpful, however, I can certainly do more of it.

ais523

unread,
Apr 6, 2012, 9:34:04 AM4/6/12
to
Jonadab the Unsightly One wrote:
> Okay, I was going to make a separate thread of this, but
> Google Groups is being cantankerous this morning, so let's
> see if I can even post it at all...
(snip useful list of comments about individual bugs)

Wow, this sort of thing is indeed useful. (Especially as it helps focus
effort /finding/ bugs onto the ones with useless descriptions.) To save
people a tiny bit of trouble, the following bugs are fixed in Ace but
not NetHack 4 (and thus there's no need for a separate demonstration
of them in NH4): C343-6, C343-267, C343-387. (You can also consult the
list on the wiki, <http://nethackwiki.com/wiki/Bugs_in_NetHack_3.4.3>,
for added explanations about bugs by various people; if a bug has
further information, that's typically enough to reproduce it.)

There's room for debate about individual bugs; for instance, it's
unclear what the intentional behaviour for C341-7 ("Skilled or expert
caster of fireball/cone of cold can't target a monster known only by
infravision or ESP. ") is, as you can't normally aim that spell at an
unlit square. Why is it suddenly a bug to be unable aim the spell at an
unlit square if there's a monster on it?

--
ais523

Jonadab the Unsightly One

unread,
Apr 6, 2012, 11:54:32 AM4/6/12
to
On Apr 6, 9:34 am, ais523 <ais...@bham.ac.uk> wrote:

> Wow, this sort of thing is indeed useful. (Especially as it helps
> focus effort /finding/ bugs onto the ones with useless descriptions.)

In that case, I plan to do the next part of the list this weekend,
and maybe try to test some of the ones I said I should try to test.

> the following bugs are fixed in Ace but not NetHack 4
> (and thus there's no need for a separate demonstration
> of them in NH4): C343-6, C343-267, C343-387.

Cool. Noted.

> if a bug has further information [on the wiki list], that's
> typically enough to reproduce it.)

Okay, that makes sense too.

> There's room for debate about individual bugs;

Yeah, some of them don't really seem like bugs to me either.

> for instance, it's unclear what the intentional behaviour for
> C341-7 ("Skilled or expert caster of fireball/cone of cold can't
> target a monster known only by infravision or ESP. ") is, as you
> can't normally aim that spell at an unlit square. Why is it
> suddenly a bug to be unable aim the spell at an unlit square if
> there's a monster on it?

Well, a player *could* reason, "I can't aim at a square I can't
see, but I *can* see that square, since I have extrinsic telepathy
[or infravision]." Being able to see does seem relevant, since
"your mind fails to lock onto that location" if you are blind,
even if the location is lit. Then again, even if you have telepathy
and can see the monster, you still can't, so it is fairly consistent.

So yeah, debatable. The complaint seems more like a valid
bug where infravision is concerned than telepathy, since with
telepathy you may not have line-of-sight at all (as in, it could
be on the other side of a wall as far as you know); whereas,
with infravision you definitely do have line of sight, just not
as much light as certain rather nyctalopic races seem to think
they need. Why restrict a dwarf from doing something just
because a human cannot?

Either way, only characters with The Eye are likely to find it
genuinely worthwhile to invest any skill slots in the attack spell
school, and dark areas are not particularly an issue that late in the
game (unless a neutral character finds a /oWishing very early or
something), so it's a fairly minor issue one way or the other, IMO.
(Not that it won't ever come up; it will, of course, on occasion.)

Note too that just because I found something on the list and took
the trouble to reproduce it doesn't necessarily imply anything
about my opinion on its validity as a bug. I'm kind of just going
down the list, for the most part. (Although there was one bug that
I kind of skipped on grounds of "is this really a bug?", so I guess
I'm not being entirely consistent there. Maybe I should decide
one way or the other on whether to bother reproducing ones that
I'm not convinced are necessarily bugs.)

Jonadab the Unsightly One

unread,
Apr 6, 2012, 7:30:27 PM4/6/12
to
C342-19 - I managed to get "You are a statue. Your skin begins to
peel away." (by having cockatrices and green slimes going
at me at the same time). NH4 save available on request.
C342-22 - There's an additional note on the wiki.

Jonadab the Unsightly One

unread,
Apr 7, 2012, 1:11:51 PM4/7/12
to
C342-31 - Status unknown. ("Open" on the 3.4.3 list.)
C342-36 - Wizards and Monks can get a book when crowned, but you get
the see invisible intrinsic at the same time, which
prevents the bug from manifesting. Is there another way
to recieve a book as a gift?
C342-46 - Since there's no lightning in the clerical spell school,
I assume this means CLC_LIGHTNING in mcastu.c, and yeah,
there's no blinding (contrast e.g. ZT_LIGHTNING in zap.c).
C342-50 - As a lurker above, if I #monster then #sit then #monster,
I get "You sit on the helm of brilliance. It's not very
comfortable... You are already hiding." If I move to a
place with no objects and try it, "Having fun sitting on
the ground? You are already hiding." NH4 save available.
C342-51 - Yes, trappers hide on the ceiling. Shouldn't they?
C342-54 - Oh, yeah. If a bones level contains a statue of a unique
monster that wouldn't normally appear on that level (say,
if some enterprizing wizard dragged a statue of Vlad up
to Delphi for some odd reason), zapping stone to flesh
at it causes a segfault. I have an NH4 save game.

Grunt

unread,
Apr 7, 2012, 1:42:00 PM4/7/12
to
A few more insights on those comments:

On Saturday, 7 April 2012 11:11:51 UTC-6, Jonadab the Unsightly One wrote:
> [...]
> C342-36 - Wizards and Monks can get a book when crowned, but you get
> the see invisible intrinsic at the same time, which
> prevents the bug from manifesting. Is there another way
> to recieve a book as a gift?
Yes - there is a chance of receiving one as an altar prayer gift independent of crowning.

> C342-46 - Since there's no lightning in the clerical spell school,
> I assume this means CLC_LIGHTNING in mcastu.c, and yeah,
> there's no blinding (contrast e.g. ZT_LIGHTNING in zap.c).
This is also my interpretation of it.

> C342-50 - As a lurker above, if I #monster then #sit then #monster,
> I get "You sit on the helm of brilliance. It's not very
> comfortable... You are already hiding." If I move to a
> place with no objects and try it, "Having fun sitting on
> the ground? You are already hiding." NH4 save available.
My most recent thought on this is that this is only still bug in that you can #sit while hiding on the ceiling, and not anything to do with unhiding (the unhiding itself seems to have alraedy been fixed in 3.4.3).

> C342-51 - Yes, trappers hide on the ceiling. Shouldn't they?
From its source material (i.e. Dungeons and Dragons), a trapper is supposed to hide on the floor. I believe this only crops up in two places: dislodging a trapper with a drum of earthquake and ambushing another monster while polymorphed into a trapper.

Jonadab the Unsightly One

unread,
Apr 7, 2012, 5:58:52 PM4/7/12
to
C343-1 - Status unknown. Description is vague.
C343-2 - Fixed in NetHack 4 (credited to Alex Smith)
C343-3 - Still working on reproducing this one. (On first attempt
I learned that zapping a teleportation at everything
that moves can get you thrown out of the quest.)
C343-4 - If the player tunnels (including without a pick while
polyselfed), it does leave a tunnel, but if e.g. a pet
umber hulk tunnels, it does not. I have an NH4 save.
C343-5 - Unable to reproduce. All I get is "You can't get there
from here", no matter where I try to levelport to.
C343-6 - Fixed in AceHack; additional info on the wiki.
C343-7 - Fixed in NetHack 4 (credited to Alex Smith)
C343-8 - Fixed in NetHack 4 (credited to Patric Muller)
C343-9 - You must be riding at the time. You can get e.g.,
"You lead poor fire giant into a pit!" I have a save.
C343-10 - Trivially reproduced in NH4.
C343-11 - In NH4, ? at a what direction prompt (e.g., when zapping
a spell) makes the game to say "What a strange direction".
C343-12 - Fixed in NetHack 4 (credited to Patric Muller)

Jonadab the Unsightly One

unread,
Apr 7, 2012, 6:08:17 PM4/7/12
to
On Apr 5, 4:56 pm, Grunt <smelenc...@gmail.com> wrote:
[The Dreaded Floating Eye Typo Death]
> In my mind, the approach to take is simple:
> leave it as it is in vanilla.
>
> The floating eye is a monster with a passive paralysis attack,
> and though there are some quirks specific to that monster, it's
> not the only monster with such an attack (cf. gelatinous cubes),
> and far from the only monster with a passive attack. Do all
> monsters with passive attacks suddenly need to be changed
> because you might walk into them accidentally?

Actually, a solution has occurred to me that would A) preserve
all the interesting aspects of the floating eye as per 3.4.3,
B) require the player to learn what kinds of monsters are safe
to attack and what kinds are not and yet C) greatly reduce the
probability of inadvertently attacking them by mistake while
just trying to walk.

It's almost *too* obvious...

Simply introduce an option (called, perhaps, paranoidmelee).
When this option is turned on, simply walking into a monster
(ANY monster) does not cause you to attack it. Any time you
want to melee attack a monster, you use the fight command.

I know, I know, it would make heavy fighting tedious.
Then again, heavy fighting is not safe in the early game,
and in the late game floating eyes and such are much less
of a threat, so you could turn it off when you reach a
point where you're willing to risk it...

Just a thought.

Jonadab the Unsightly One

unread,
Apr 7, 2012, 6:13:17 PM4/7/12
to
On Apr 5, 6:15 pm, Patric Mueller <bh...@bigfoot.com> wrote:
> Menucolors is older than 3.4.3. ;-)

Ah, I didn't realize that.

> > there are also other patches that have met with
> > widespread approval.
>
> Do you have something special in mind?

Not specifically, no. The dungeon overview patch that
you mention is as good an example as any.

Jonadab the Unsightly One

unread,
Apr 7, 2012, 6:22:36 PM4/7/12
to
On Apr 6, 8:26 am, Capt. Cave Man
<ItIsSoEasyACaveManCanD...@upyers.org> wrote:
> I still can't believe that google is so stupid that they do not TIE you
> dopes... err folks to the right formatting.

It's worse than that: Google wraps lines at one place when
you're
editing them and at an entirely different place when they're
actually
posted. This is why you sometimes see posts that look like
this.

HTH.HAND.

Jonadab the Unsightly One

unread,
Apr 7, 2012, 6:34:29 PM4/7/12
to
On Apr 7, 1:42 pm, Grunt <smelenc...@gmail.com> wrote:
> > C342-36 - Wizards and Monks can get a book when crowned, but you
> > get the see invisible intrinsic at the same time,
> > which prevents the bug from manifesting. Is there
> > another way to recieve a book as a gift?
>
> Yes - there is a chance of receiving one as an altar prayer
> gift independent of crowning.

Aha. I will look into that.

> > C342-50 - As a lurker above, if I #monster then #sit then
> > #monster, I get "You sit on the helm of brilliance.
> > It's not very comfortable... You are already hiding."
> > If I move to a place with no objects and try it,
> > "Having fun sitting on the ground? You are already
> > hiding." NH4 save available.
>
> My most recent thought on this is that this is only still bug in
> that you can #sit while hiding on the ceiling,

That does seem odd.

> > C342-51 - Yes, trappers hide on the ceiling. Shouldn't they?
>
> From its source material (i.e. Dungeons and Dragons), a trapper
> is supposed to hide on the floor.

Ah. I played D&D once for about three hours, and my curiosity
about it was fully sated.

> I believe this only crops up in two places: dislodging a trapper
> with a drum of earthquake and ambushing another monster
> while polymorphed into a trapper.

Notably, #monster behaves identically for both members of the t class.

Whether we care about consistency with D&D is left as a question
for the developers to answer. There's no problem about finding or
reproducing any bug here, it's just a question of whether the devs
want to mess with implementing yet another kind of hiding. There
are at least four different kinds of hiding in NetHack already
(being invisible, hiding under an object on the floor, pretending
to be an object or dungeon feature, and hiding on the ceiling),
and that's just off the top of my head. Do we need a fifth way
for monsters to hide? I wouldn't *object* to it, if somebody
wants to put in the effort to make it happen, but I definitely
don't consider it important.

Jonadab the Unsightly One

unread,
Apr 7, 2012, 9:33:25 PM4/7/12
to
C343-13 - Status unknown. May be difficult to reproduce, or
there's a trick I'm missing.
C343-14 - Confirmed, I got "choked on a Demonbane" on my tombstone.
Polyself into a rust monster, eat about two iron balls,
then start with the artifacts, and your chances of choking
to death on one of them are pretty decent. Note that the
artifact has to be FORMALLY identified, not just "a long
sword called Excalibur" or cetera.
C343-15 - Fixed in NetHack 4 (credited to Alex Smith)
C343-16 - There's additional info on the wiki.
C343-17 - There's additional info on the wiki.
C343-18 - Fixed in NetHack 4 (credited to Alex Smith)
C343-19 - Sometimes it's destroyed on the first try. Sometimes it
"boils vigorously" and "you are caught in the explosion"
and still have the potion of acid in your inventory. In
five tries, I twice had ?Acid take three dips to destroy,
and the other three went first try. I have an NH4 save.
C343-20 - Wiki says it mostly doesn't matter.
C343-21 - Yeah, a leashed large dog will go right through a
locked door like it's not even there. I tested this
with a room that had no other exits. NH4 save available.
C343-22 - Trivial to reproduce with pit, magic whistle, and =Lev.
C343-23 - Status unknown. I don't know how to get a vault guard
to fail to lead you out. The 3.4.3 list says "Help".
C343-24 - (Documentation issue, nothing to reproduce.)

Jonadab the Unsightly One

unread,
Apr 7, 2012, 10:26:10 PM4/7/12
to
On Apr 7, 6:34 pm, Jonadab the Unsightly One
<jonadab.theunsightly...@gmail.com> wrote:
> On Apr 7, 1:42 pm, Grunt <smelenc...@gmail.com> wrote:
>
> > > C342-36 - Wizards and Monks can get a book when crowned, but you
> > > get the see invisible intrinsic at the same time,
> > > which prevents the bug from manifesting. Is there
> > > another way to recieve a book as a gift?
>
> > Yes - there is a chance of receiving one as an altar prayer
> > gift independent of crowning.
>
> Aha. I will look into that.

C342-36 - Cannot reproduce in NH4: When unable to see myself,
and granted a spellbook as an altar prayer gift, the
display showed + where formerly it showed an altar.

deltopia

unread,
Apr 7, 2012, 11:32:23 PM4/7/12