Reported for nethack.alt.org where impossible events in to-be-3.6.1
trigger a panic instead of just a warning, being polymorphed into a
vampire and draining something to 0 HP (rather than killing it with
the bite attack) didn't properly kill off the victim unless it was
also being drained from level 0 to level -1, resulting in impossible
"dmonsfree: 1 removed doesn't match 0 pending". If the hero got
another move before dead monsters were purged, applying a stethscope
to the victim could trigger an actual crash rather than an impossible
escalated to a panic. Other actions such as attacking again probably
could too.
A followup included a diagnosis and one-line patch. I expanded the
adjacent comment when manually putting the patch into place.
Show the original line from the config file, followed by the line number and
a specific error message. Also show all errors from the config file before
waiting for key press.
Theoretically we still support implementations which don't have %p.
Even if we didn't, it requires a 'void *' argument rather than an
arbitrary pointer, so casts would have been needed.
Allows the user to define arbitrarily named optional sections
in the config file, and select which of those sections are used.
For example:
OPTIONS=color
CHOOSE=char A,char B
[char A]
OPTIONS=role:arc,race:dwa,align:law,gender:fem
[char B]
OPTIONS=role:wiz,race:elf,align:cha,gender:mal
The previous version of this would lead to big warnings and
impossibles. This doesn't seem like a useful case, but it's still
better to have better warning messages just in case it does
happen.
The previous behaviour was to mention the missing file, but then to
try and fail to lock the nonexistent file 10 times, which rather
obscured the original cause of the error as it took up so much more
room on the screen.
This patch also changes the error message. Failure to lock a
nonexistent file is almost always the result of a mistake during
the install process (e.g. running from the wrong directory, or
running without an install). We should give the user a hint about
that.
Reported directly to the devteam. Set hilite_pile on, become
invisible, pick up all but one item from a pile on the floor,
the pile symbol was still there afterwards.
This is yet another case of evil hack, because the gbuf doesn't
distinguish between object piles and single items, see
commit 854fe40609
Reported directly to devteam, the starting inventory for rogue chars
specified that their lock pick be +9, but the 'spe' enchantment field
is meaningless for that type of item. A followup report indicated that
it had been this way since at least the 3.0 era.
It might have been a typo, since 9 and 0 are next to each other. Or
perhaps before lock picks were introduced, rogues started with a
skeleton key. That assumes spe==9 meant skeleton key back in the days
when each key and lock had a designated shape and a non-skeleton key
had to match the lock's shape to work. I don't know whether that was
how skeleton keys were flagged and don't care eough to delve deeper....
Blessed scroll of fire allows to choose the explosion location like
scroll of stinking cloud does. This should make it somewhat useful
in the early game.
From the newsgroup, remarking on an usual cause of death seen at NAO.
Surviving a gas spore's explosion (via hit points, not from life-saving)
left "gas spore's explosion" as stale killer.name. Being killed by
opening a drawbridge (but not by closing or breaking one) only assigned
killer.name if it didn't already have a value, so the stale reason got
used: crushed to death by a gas spore's explosion.
This fixes it two ways: clear the stale value after surviving the
explosion, and assign a specific reason when opening the drawbridge.
This also removes stale reason for death set up by various drawbridge
activity. For the usual case, the hero only survives by life-saving
which does its own clearing of killer.name. But there might have been
cases where it was being set for the hero when operating on a monster,
so no life-saving involved. The drawbridge code is not the easiest
code to navigate....
The BONES_POOLS implementation added an extra dot to the bones file
name (only when enabled) which would be a problem on some filesystems.
This changes the name from "bonD0.15.3" to "bon3D0.15" which avoids
the second dot and also fits within 8.3 characters. To enforce that,
the maximum value for BONES_POOLS is now 10 (yielding single-digit pool
numbers 0 through 9).
BONES_POOLS==1 will omit the pool number (that's not a change, just a
reminder), yielding "bonD0.15" and so on. Right now, BONES_POOLS==0
is equivalent to BONES_POOLS=1, but it could be changed someday to
mean that bones files shouldn't be used if we decide to support that.
The pool number as a suffix was being included in content validation,
so it wasn't possible to move "bonD0.15.3" to pool 2 by renaming it to
"bonD0.15.2". I'm not sure whether that was intentional, but it seems
overly draconian. "bon3D0.15" can be renamed to "bon2D0.15" and then
be loaded by a game assigned to pool 2. Also, pre-pool bones can be
retained by renaming to any valid pool and should still work.
The three letter filecode for quest bones has made the bonesid be
broken since 3.3.0 introduced it (the three letter code, not bones-id).
"QArc.2" for level 2 of the Archeologist quest was being written into
the bones file as "rc.2", but worked as intended because validation
when loading bones had the same mistake. This fixes it to use "QArc.2"
when saving and accept either "QArc.2" or "rc.2" when loading, so 3.6.0
bones files (and existing to-be-3.6.1 bones) will continue to work.
Reduce the chance of a player playing on a public server encountering
their own bones, by implementing separate bones pools. The pool a player
belongs to is determined at game start, and only bones in that pool
are used. The sysconf BONES_POOLS allows the sysadmin to define how
many pools there are.
