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.
Drinking any potion full healing or extra healing or non-cursed potion
of healing cures blindness in addition to restoring lost hit points.
Now breathing vapor from any potion of full healing or non-cursed
potion of extra healing or blessed potion of healing will also do so.
Report was for a blinded horse which ate a carrot but remained blind.
This fixes that, and also lets blinded carnivorous pets eat carrots.
Gelatinous cubes now handle carrots too, but since they lack eyses
there won't be any noticeable effect for them.
Fix the SELF_RECOVER part of files.c which was actually in slightly
worse shape than previously fixed recover.c itself.
I think the HOLD_LOCKFILE_OPEN edition of nhclose() is the only
remaining file descriptor leak from the original #H5778 report.
The revised code compiles when SELF_RECOVER is defined, but I didn't
actually force a recovery to fully test it.
This patch includes a couple of reformatting and/or reorganization
bits in addition to the fd leak fix.
Reported directly to devteam: if applying a grappling hook towards
a target past some water ended up pulling the hero toward the target,
hero would drown without any chance of crawling out of the water.
It used hurtle() to move, and hurtle assumed levitation so didn't
check for entering pools of water except on the Plane of Water.
Previously the "fast-moving" when getting a target location
was always by 8 units. If this option is on, fast-moving
will instead skip the same map glyphs. This should be much more
useful for blind players.
Files modified:
include/extern.h
src/pline.c, priest.c, potion.c, mkobj.c
A bunch of calls to pline() in pline.c started triggering warnings
either as-is or possibly after the changes to tradstdc.h. Fixing
them in place would include intrusive VA_PASSx() like in lev_main.c.
Moving them to other files is much simpler (and they didn't
particularly belong in pline.c in the first place, although I didn't
actually find any better place for them....).
The probing/stethoscope feedback went to priest.c, where there's a
comment stating that it should move to wherever englightenment ends
up once that is moved out of its completely inappropriate current
home in cmd.c. (Holdover from when ^X was wizard-mode only but even
the other wizard mode commands don't really belong with the command
processing code.)
Compound option whatis_filter, filters the eligible map locations
when getting a cursor location for targeting. Accepts 'n' (none),
'v' (map locations in view), or 'a' (map locations in the same area,
eg. room or corridor).
Alex mentioned that loops over mons[] were starting at [0], which
should be [LOW_PM] instead. I only found two, and the mvitals[] one
was benign. The special level one might have been too, depending
upon spec_lev's thoroughness--I didn't attempt to check.
Once upon a time there was a possibility of moving 'playermon' from
a separate variable to mons[0], so LOW_PM became the index of the
first valid monster. Instead, 'playermon' went away altogether.
LOW_PM (and NON_PM) could go away too, but I don't see how reverting
to hardcoded 0 and -1 would be an improvement. We have enough
problems as it is with "giant ant" turning up in unexpected places
because someone used 0 instead of NON_PM to mean "none of the above".
This started out as just an attempt to remove some duplicated code,
but mutated. Move health recovery into a separate routine to
streamline moveloop().
Intentional changes:
1) when poly'd hero is at max u.mh (hit points as a monster), do
not recover lost u.uhp (hit points when in normal form). That
was caused by a missing !Upolyd check in the long if..elseif..
elseif..endif logic. If we want to make it deliberate, I think
some u.uhp recovery in rehumanize() would be the way to go.
2) regeneration for poly'd hero in sea monster form (ring worn on
left or right pectoral fin) now counteracts the loss of hit
points for turns spent out of water. [Do eels even have fins?]
3) poly'd hero with moderate or worse encumbrance and lacking
regeneration wouldn't recover any health. Now he/she will do so
if not moving [on the magic (moves%20 == 0) turn when u.mh
recovery takes place].
If there are any other changes in behavior, they're unintentional.
by Excalibur. Noticed on Reddit by Alex, the attempt to fix being
blasted twice by wielded artifact weapon when changing alignment
ended up preventing wielding other role's quest weapons. At the
moment I can't even see how it prevented the double-blast....
This backs out that change and fixes the double-blasting correctly.
When uwep and uswapwep are tested in advance of the rest of invent,
mark them as already processed before entering the loop that checks
all not-yet-processed inventory.
Reported nearly four years ago for 3.4.3, original subject was
\#H3013: NetHack grammar bug when taking unpaid fruit from chest
Player used OPTIONS=fruit:Quorn and the capitalized value confuses
the() into thinking it's a proper name which shouldn't be preceded
by an article, resulting in "Quorn will cost you N zorkmids" when
removing it from a chest in a shop, followed by "X - a Quorn (unpaid)"
as it went into inventory. It is a product name, but when used as a
fruit it shouldn't be treated as a proper name. (Quorn is a meat
substitute rather than anything related to fruit.) Teach the() about
named-fruits, so that we'll get "The Quorn will cost you N zorkmids."
Unfortunately, it means that someone who names their fruit after a
proper name used by the program, for example Mjollnir, can probably
induce other poorly worded messages (about the item rather than the
named-fruit). the() is used all over the place and all it has to work
with is text, not the object whose formatted name produced that text.
I looked through a bunch of old cvs log messages last night, and
spotted one I wrote (in objnam.c) a dozen years ago where I suggested
forcing named-fruit values into lower case as they're being set up.
I don't remember that, but if we'd done it, this bug would have been
avoided.
The object name formatting routines operate using a pool of buffers to
hold intermediate and/or final result. Some routines consume multiple
intermediate buffers, so use releaseobj() to try to reuse just one in
order to avoid churning through too many and maybe clobbering live
data. It worked as intended for routines that use nextobuf() directly
but wouldn't haved worked right for xname(), also doname() and other
xname() callers. This fixes that.
There have never been any reports of garbled messages which could be
traced to clobbering of formatted object names, so this fix is mostly
academic.
Add some new routines for dealing with fruit. I had hoped they would
let the existing fruit handling be simplified quite a bit, but the
improvement wasn't great. However, they're also groundwork for fixing
an old bug.
A couple of days ago when verifying the report about being forced to
pay for a second tin when eating one from a stack on a shop's floor,
wishing for 'tins' (rather than 'tins of foo meat') was repeatedly
producing tin wands instead. The name "tin" and the wand description
"tin" in objects[] were being given 50:50 chance for either one by
the 3.6.1 wishing code. Wishing for "tins of spinach" also gave me
a tin wand on the first attempt. Handle 'tin(s)' more explicitly.
This also does some reformatting.
Add support for filtering by unpaid status for container-in and
container-out actions. When taking out of a container, it works as
expected if you're carrying the container while in a shop, but won't
find any unpaid items if the container is on the floor. That's
because they're only flagged as unpaid while in the hero's inventory.
(And when it doesn't find any unpaid items it won't list 'unpaid' as
a category of item to manipulate, so while that might be suboptimal
for taking items out of shop containers, it shouldn't be a problem.
Typically all the contents are shop-owned anyway, so using unpaid as
a filter wouldn't gain any advantage over just taking stuff out.)
Remove the assumption of property index values from the list of
property names. Move the properties that can't have timed values
in normal play to after those which can. (Mainly only matters for
the #wizintrinsic command.)
Bug fix: #wizintrinsic variable 'any' wasn't initialized properly
if 'a_int' is smaller than a long or a pointer. The separator line
I've added was ending up as a menu choice.
Reported directly to devteam, eating 1 of 2 tins of spinach from a
shop's floor forced the hero to buy both. (1 was gone, the other was
intact and now owned by the hero rather than the shop. Tins of other
contents behaved similarly.) The bug is easy to fix but not so easy
to explain: eating split one from the stack but passed the remaining
stack to useupf(obj,1) which also split one off and treated that as
used up. The second one was billed as used up and the first one was
added to the bill--as being subjected to a costly modification made by
the hero--and kept intact, now marked no-charge with hero obligated to
pay for it.
Eating 1 of N tins, for N greater than 2, billed for two, one gone and
the other now in a separate stack and marked no-charge. The remaining
N-2 stayed as normal shop goods in their original stack.
The fix is communicate the splitobj() for costly modification up-call
so that the use_up_tin code operates on the one which was split off
the stack rather than on the remainder of the original stack.
