I had intended to put the Hate_silver patch into the branch as well
as the trunk, but hit too much nonmatching context. When switching it to
be trunk only, I neglected to put the fixes entry into the proper file.
Monster werecritters are vulnerable to silver when in human form as
well as when in beast form, but hero inflicted with lycanthropy was only
vulnerable while in beast form. Add pseudo-property Hate_silver to handle
that correctly. Also, add silver vulnerability to enlightenment feedback.
Lastly, hero vulnerable to silver had Con abused if hit by silver missile
but not when hit hand-to-hand; add an exercise() call to the latter.
Many (most?) non-weapon artifacts show up in inventory and messages
as "the <foo> of <bar>" even when their underlying object type hasn't been
discovered yet. For types which don't use the `known' bit, obj->known is
forced to 1; obj_is_pname() checked that but not the oc_name_known flag
for the type. So you'd see things like "the Heart of Ahriman" instead of
"a luckstone named <the H of A>" or "a gray stone named <the H of A>" even
though it hadn't been identified yet, unintentionally hiding the artifact's
object type from the player.
While testing the figurine timer patch, I observed
The goblin wields a crude dagger.
You see a goblin drop out of your pack!
Rather than try to get the sequencing right, just prevent monsters made
by figurine activation or by the create familiar spell start without any
inventory. This will have a side effect of making wishes for a blessed
figurine of an archon be less powerful, because the subsequent pet A won't
come equipped with a shield of reflection and an artifact--or at least
rustproof--long sword anymore.
From a bug report: having a lit
candle or potion of oil be wielded or "worn" as alternate weapon or quiver
at the time it finished burning up would leave a stale worn object pointer
which could trigger a panic or crash. Need to call useup() instead of
obj_extract_self()+obfree() for objects in inventory, similar to the way
hatching eggs are handled.
From a bug report: attempting to apply
a towel which is currently "worn" in the weapon, alternate weapon, or
quiver slot fails with "you cannot use it while you're wearing it". The
message sounds odd when the towel is wielded, and there's no reason why
you shouldn't be able to use it when it's in any of those weapon slots.
Compare it with current blindfold rather than checking its owornmask.
<email deleted>, escaping from being stuck
by lava via jumping--or simply walking--got you out of the lava while being
at the same location. You could then stay there for as long as you liked
without falling back in. This makes a lava and water check on turns where
time passes but hero hasn't moved, performing a subset of spoteffects().
I think the water case only matters when using wizard mode to wish for a
pool or moat, which gets created at hero's feet without making him fall in
(unlike wishing for lava, where hero does immediately fall in).
From a bug report, trying
to invoke a wielded artifact after changing alignment resulted in "the
<artifact> evades your grasp" but it remained wielded, contradicting the
message. This adjusts the message in touch_artifact() if the object is
already in inventory, and adds retouch_object() to handle cases where
failing to be able to touch ought to force unwearing/unwielding.
From a bug report, applying a stetoscope to
a mimic which was hiding would report that mimic's stats but not bring it
out of hiding, unlike the behavior for other types of hiding monsters.
Guard against buffer overflows when reading in score entries, in case
`record' has become corrupted or been maliciously modified. This addresses
the part of "#Q101: Security bug in nethack 3.4.3" that we have control
over. A Gentoo bug tracking discussion pointed out to us by <email deleted>, describes how that particular Linux
distribution makes users be members of the games group, allowing them to
modify files in nethack's playground directory when it has been set up in
the usual ``setgid games'' manner, thus making score processing in that
environment be vulnerable to buffer overrun exploits.
Part of the final score is doubled for ascension. Some players use
helm of opposite alignment in order to offer and ascend at the first astral
altar they reach. This limits the score doubling to ascending with your
original alignment intact, penalizing (for the subset of players who care
about score) alignment manipulation. Converting to a second alignment and
then using a helm of opposite alignment to switch back and offer to hero's
original deity yields a smaller bonus (one-and-a-half instead of doubling).
Offering to either of the other deities (either via permanent conversion
or temporarily switching via helm or both) gets no score bonus.
There was a report recently about "<pet> is still eating" coming out
on the console at end of game for player using X11 or Qt. That happened
because the end-of-game pet handling takes place after the message window
has been closed. It won't happen with the dev code any more because eating
no longer prevents pets from accompanying on final ascent or escape. But
a pet carrying the Amulet should still fail to tag along and yield similar
result. However, levl_follower() was changed (probably by me...) to have
pets not attempt to follow when they carried the Amulet, rendering code
in keepdogs()--which reported them as being confused--unreachable. This
reverts levl_follower() to have Amulet-carrying monsters other than the
Wizard try to accompany the hero during level changes (and keepdogs still
prevents them from succeeding). It also reorganizes keepdogs() a bit,
giving trapped followers an extra chance to escape from their trap and
preventing those who fail that chance from tagging along (previously,
non-pets ignored being trapped).
After doing that, I got tty to behave similarly to the X11/Qt report:
a message behaved strangely. In my case, it was delivered between a pair
of clearings of the screen and only visible by using terminal emulator's
scrolling buffer. I think there's a wait_synch() missing somewhere, but
haven't tried to figure out where. Instead, this makes the end-of-game
call to keepdogs() take place sooner, while pline() still works normally.
Suggested by <email deleted>. The level compiler allows
MESSAGE directives to provide text given upon initial entry to particular
levels. Modify the code that delivers them to support quest pager text
substitution. It could also be tweaked to support deliver-by-popup-window
in addition to deliver-by-pline, but I didn't go that far.
He also suggested revising the message for the Plane of Air, but it
seems ok to me. Instead, I've changed the message for the Astral Plane to
announce that it holds "the High Temple of <your deity>" rather than the
quite lame "the High Temples of the aligned gods".
Dying at a shop doorway, or at the free spot one step in, while not
owing the shopkeeper anything would yield "<shk> gratefully inherites all
your possessions" but leave those possesions where the next hero could
just pick them up for free. Move them all the way inside the shop, as
happens when the hero dies while owing the shk. Also, if hero has gold
left after shopkeeper takes any payment owed, force it to go into shk's
inventory instead of having it end up in the pile of other stuff.
finish_paybill() duplicated much of drop_upon_death(), but not the
two-weapon hack to avoid curse() causing hero's secondary weapon to be
dropped while in the midst of removing it from inventory (but unlike the
old 3.4.1 panic for that, this one just triggered a warning about nonzero
worn mask). It also lacked the named fruit fixup, whatever that does.
Make finish_paybill() call drop_upon_death() instead of copying it.
Noticed while looking at the dipping code: #dip at a pool location
gives the chance to dip into the pool, and dipping a potion of acid into
such causes the acid to explode, causing damage and posibly killing the
hero. Use-up handling was being done after the dip had finished, so the
potion would remain in final inventory during disclosure and end up in
the resulting bones file if there was one.
There's newsgroup discussion about a mind flayer sucking the brains
of a ghost, plus speculation that the fix for C343-121 has already taken
care of it. I agree with them that ghost's brains are too insubstantial
to be hit by brainsuck damage from mind flayers' tentacles. C343-121 is
vague enough to cover this; the corresponding fixes entry was more specific
and is augmented here.
From a bug report: zapping wand
of speed monster (or slow monster) at an immobile monster would give the
usual '<mon> is moving faster" (or slower) message even though the monster
couldn't move at all. This fixes that for monsters who can never move
and also for monsters who are temporarily paralyzed or asleep, although I
wonder whether speed change magic ought to also snap the latter out of it.
You can't begin or resume locking or unlocking a chest on the floor
while swallowed by a monster, but you could lock or unlock an adjacent
door in that situation.
From a bug report: you could end up
standing on water/lava if you survived being on an open drawbridge while
it was destroyed. This fixes the bridge destruction case; opening and
closing are handled differently and I left them alone.
Trunk and branch, noticed while working on an interface enhancement:
you could use #force to break the lock of a chest that's on the floor
while you're engulfed, also while levitating or mounted w/o riding skill.
Trunk only: refine an earlier fix that bills for breaking the lock
of a shop-owned chest. The item which the hero is forced to buy showed
up in the bill as unlockable, which is accurate after the fact but didn't
reflect the shop's item. Fix by billing for chest before altering it.
Update the brief explore mode section (it hasn't been a conditional
feature for quite some time, there's an extra way to access it now, and
new game started with -X is different from switching via the 'X' command)
in the Guidebook, and add a short debug mode subsection there.
Reported to the beta-testers list by <Someone> last April:
restoring a normal game save file in explore mode let you keep the file,
then after exploring and quitting without saving, you could restore it
again in normal mode and take advantage of whatever information you'd
gained. This makes nethack -X (or playmode:explore) defer the switch to
explore mode when used while restoring a normal mode save file. It now
performs a normal restore (with save file deletion) and then acts as if
the user had given the 'X' command interactively, requiring confirmation
to actually switch into explore mode.
[see cvs log for src/options.c for some additional info]
Relief for the command-line impaired. Allow player to request
explore or wizard mode via run-time config file or NETHACKOPTIONS.
Validation is left to xxxmain() and has been updated for Unix, VMS, and
ports which share pcmain. Mac and Be appear to allow any user to access
wizard mode, and may not need any modification, although they'll continue
to have the old buglet of running with both wizard and discover flags set
if player uses `nethack -X -D'. This may or may not work as-is for the
Qt interface depending upon whether it goes through one of the xxxmain()'s
mentioned above [someone needs to make sure that it doesn't allow Qt on
Unix to bypass the (username == WIZARD_NAME) test when user requests
wizard mode].
Simplify <Someone>'s patch (the part for the secondary weapon wasn't and
still isn't needed since dual-wielding can only occur when both primary
and alternate weapon slots contain weapons or weapon-tools, but we might
as well keep it). There was at least one other case where wielded in-use
leash could be removed from inventory without becoming unleashed first:
a bullwhip-wielding monster could snatch it away.
That lead to some other whip issues: monsters who select disarming
via bullwhip as miscellaneous strategy had 80% chance of not using it on
any given turn, but had no chance to select another misc strategy on such
turns--they always resorted to ordinary nonMUSE behavior and usually just
attacked. The adjacency check missed diagonal locations, also would aim
the disarm attempt accurately even when displacement or invisibility made
the hero's precise location unknown. [I took the easy way out here and
only let them try to disarm when they know the hero's location. It's
tempting to aim at the guessed location and sometimes accidentally disarm
a nearby monster, but disarming is an action which targets a particular
weapon rather than just a location.] Lastly, disarming always targetted
hero's primary weapon, never a dual-wielder's secondary one.
From a bug report, if you polymorph into
something, like a killer bee, that causes you to drop your weapon, but the
weapon is a wielded, in-use leash, the leash would be dropped but retain
it's in-use state. However, the leash was tied to you, so it seems it
should remain attached, just unwielded, just as it would if it hadn't been
wielded. I've changed the behavior to do this. I wonder whether one
should be able to wield an in-use leash.
From a bug report: gelatinous cubes
could engulf Rider corpses, allowing g.cube and cargo to be teleported
away without triggering corpse revival, or to be hit with theft attack by
poly'd hero to get the corpse into inventory so it could then be put into
a container in order to prevent revival (or to be destroyed via bag of
holding explosion or cursed access).
From a bug report: when riding,
#jump command and jumping spell didn't check whether steed is able to move.
This makes #jump command, either magic boots or knight's innate ability,
fail if the steed can't move. Spell still succeeds; its magic overrides
steed's immobility. Fix is trunk only since it relies on a function that
isn't in the branch.
Also, tweak hero movement to avoid an extra function call per move
when not riding.
Noticed while checking out the report that you can #jump when riding
a sleeping steed: hero's sleep resistance or magical breathing prevented
sleeping gas traps from hitting steed. "You are enveloped in a cloud of
gas" but your steed is untouched? That didn't make sense.
From a bug report, applying a bullwhip
towards a monster to try to steal its weapon would report that a cursed
cockatrice corpse was welded to the monster's hands even though corpses
wielded by the player never become welded. Code for monsters deciding
what to wield knew that corpses don't weld; everywhere else seems to
assume that they only wield weldable weapons. Add a routine to check
whether a wielded item is welded, similar to what's done for the hero. I
fixed a couple of other spots besides use_whip() but didn't hunt all over.
From a bug report, putting an object with
really long specific and type names into a container with really long
specific and type names caused the program to crash. pline() overflowed
the buffer it formatted into, and even though it was able to send that
for output and trigger a --More-- prompt, eventually a segfault occurred.
Give vpline and vraw_printf a much bigger working buffer, then truncate
the formatted text to BUFSZ - 1 characters so that we don't just push the
long line trouble into the separate interfaces.
<email deleted> on Monday, January 29, 2007:
>Hero is able to kick a pile of gold (say, 100) and have the entire pile move at
>once in the same direction; very easy to avoid gold on traps. Kicking gold
>should probably scatter the pieces in multiple directions or at least not be
>quite so easy.
From a bug report: if you try to tin a
Rider's corpse and revival fails, you still get the gimicky message about
War not preserving his enemies. Give the suggested alternate message in
that case: The corpse evades your grasp. I hope that we can do better
than that, but I'm too burned out to think of anything.
From a bug report: a shapechanger
which becomes a mimic would always stay as 'm' rather than take on object
or furniture shape. Same applied to monsters which hide in other ways.
The code did that deliberately, but I don't think that it's actually
necessary so this lets them mimic/hide when they're in the right shape.
If they change form to non-mimic/hider while concealed, concealment ends.
It would be fun to have shapechangers-as-mimics actually change their
mimicked shapes periodically, but this doesn't do that. They'd probably
change to non-mimic quicker than they'd mimic something else so it's not
worth the effort.
From a bug report, but
just received: if you choked while eating a cockatrice egg and survived,
the turn-to-stone sequence wouldn't be initiated. For such eggs, turning
to stone starts when the food is finished rather than when it's started,
and fpostfx() wasn't called for food that triggered choking so the egg
went away without actually being finished. Fortune cookies, lumps of
royal jelly, and a few other things suffered from the same situation.
From a bug report, hitting a rust monster with a
fireproof--but not identified as fireproof--weapon caused the rknown bit
to become set, identifying the item as fireproof. That would also happen
for a monster's anything-proof weapon if it hit a rust monster, whether
you could see it happen or not. The code involved is convoluted; I hope
this fix is correct.
From a bug report: you could vomit when polymorphed into a rat but real life
rats can't/don't vomit. The latter was confirmed by <Someone> and <Someone>.
While testing a fix for this, I discovered a couple of other problems.
Healing magic which cured sickness failed to heal Vomiting (potion or
spell; unicorn horn deals with them separately). Enlightenment failed to
report Vomiting (it's not shown on the status line). Most significant was
that vomiting_dialogue() called vomit() twice (also make_confused() and
make_stunned() three times for every once intended). It was dividing the
remaining turns by 3 and then using that value to decide what to do, but
only message display took into account that the same divided value would
occur on 3 consecutive turns (or just 2 for the final countdown to 0,
because dialog routine gets called before timed-property decrement).
From a bug report, but just received:
you can't affix candles to the candelabrum while underwater, because the
underwater check (can't light candles while underwater) is made too soon.
If you somehow managed to get a lit lamp, candle, or candelabrum while
underwater, you wouldn't be able to extinguish it for same reason. The
bug report included a URL for a fix, but I didn't look at that. This
changes use_candle() to rely on use_lamp() for underwater handling, and
changes use_lamp() and use_candelabrum() to check for extinguishing
before making the underwater check.
From a bug report. (Michael forwarded a newsgroup posting about it back
then, but I had trouble reproducing it and didn't figure it out until
trying again now.) If hangup occurred while entering the quest, the magic
portal could be rendered inactive for the hero but still work for monsters.
That's because the hangup save stored the old value of u.uz0 before
goto_level set it to the new u.uz, and a magic portal won't operate when
u.uz0 differs from u.uz (to prevent a pair of portals from getting stuck
sending the hero back and forth). The problem could also occur going from
the quest back to the dungeon, or either direction for Ft.Ludios, but the
--More-- prompt when the quest entry text is being displayed makes hangup
during level change most likely to occur during initial quest entry.
This is just a bandaid, and the SAFERHANGUP config wouldn't be hit
by this situation.
#Q85: Bug: wrest a wand in one turn through engraving
From a bug report: engraving with an empty wand while not levitating, then using
ESC to abort when asked for the text to write, let you attempt to wrest
the last charge without using up a turn. Between the time this report was
sent and received, someone else reported similar issue with levitation,
where no prompting occurs. The fix for it also fixed the original problem.
Somewhat inadvertently though, since you can now no longer write in the
dust with a empty wand. I'm going to leave it this way; all that's needed
is some feedback about failing to engrave.
Set up to be able to use the m command prefix to request menu mode
for commands other than just pickup. As a side-effect, a hardcoded ','
referencing that command is eliminated. Also, the command handling for
pickup was accepting the other prefix characters (F,g,G,M,numpad 5) as
synonyms for m; this reverts all but 'm' to movement modifiers only (it
may be reasonable to retain M and 5, but this doesn't).
Make yellow dragon breath destroy iron bars (unless their wall_info
is marked as non-diggable, which I think is currently impossible for bars).
The shop handling is untested; no shop has iron bars for its walls or
includes them as interior obstacles. (The latter would require changes
to shop repair because lost bars will become solid wall if/when rebuilt.)
Thrown potions of acid and spat or thrown splashes of acid venom
don't affect bars--at least so far--because those always pass through
without hitting. Monsters who have a non-ranged attack which does acidic
damage can't use such attacks against iron bars.
From a bug report: if you
attempted to engrave with an empty wand while levitating, it wouldn't use
a turn unless you successfully wrested an extra charge out of the wand.
So you could always get such charge in a single elapsed turn of game time
if you didn't care about zapping in any particular direction; extremely
useful for wishing.
Noticed when checking this: when you did wrest the extra charge,
the engraving code accessed freed memory for the wand after it had been
used up.
Lastly, wands producing certain effects always become discovered,
even when you don't yet know what they look like. (This part of the patch
is trunk-only since it utilizes the routine which fixes similar case for
zapping.)
From a bug report: if you
were at one of the map edges and kicked away from map center while blind,
you'd get impossible("show_glyph: bad pos ..."). That was due to calling
feel_location() for the out of bounds location, which occurred after the
kick code had made use of invalid data so other problems might occur too.
Now you kick "nothing" as if it was something (hence possibly wounding
your leg, taking some damage, potentially dying). I didn't want to try to
classify the surrounding terrain as rock or air or whatever, and the thing
being kicked only shows up if the kick is fatal.
From the newsgroup: if polymorphed into a metallivore, you could eat
artifacts that you couldn't touch with your hands. Now you can't eat ones
which evade your grasp, and you take some damage from other touchy items
on--actually, prior to--the first bite. (Those still "taste delicious" if
you survive; I'm not sure whether this ought to be changed.)
Attempting to loot while suffering from confusion and not on top
of a container will drop gold if hero is carrying some, but it behaved
differently for GOLDOBJ config (gold dropped over a hole or down stairs
always stayed on current level) than for !GOLDOBJ (gold had a chance to
fall to lower level) when done at some location other than a throne.
This makes GOLDOBJ use dropx() instead of dropy(), same as !GOLDOBJ.
And with access to a throne it can be used to repeatedly summon
monsters until they're extinct. This makes it check for confusion before
finding containers, but the chest/exchequer code doesn't always kick in
so can't be attempted as many times before confusion expires, throttling
summoning a little. Also, when placing hero's gold into a chest, it now
clears the contents-known flag and relocks the chest.
[See cvs log for src/cmd.c for more complete description.]
This turns clearlocks() into a no-op during the period when the UNIX
port is asking the user to confirm whether to overwrite an existing game.
Also, this removes the duplication of code and function between hangup()
and end_of_input(), and it simplifies the check for whether hangups are
supported by adding new macro HANGUPHANDLING. (I don't think global.h is
the best place to be defining that but I couldn't figure out where else
it would fit, other than repeating for individual xxxconf.h files.) And
adds a couple more done_hup checks to try to cope with situations where
rhack() is being bypassed. Lastly, having readchar() return EOF was
ignored for non-UNIX configs; now everybody gets ESC instead of letting
EOF be seen further inside the core.
