From the newsgroup (subject: "3 xorn fixes"): casting spell of
protection would report "the air around you begins to shimmer" even when
you were embedded in rock or swallowed. It included a pointer to a patch;
I looked at that but ended up not using it.
Several small related changes that ended up being not quite so small:
Allow the Amulet of Yendor to be offered on the altar in the temple
of Moloch's Sanctum level; doing so is fatal. Fake ones can be offered
too, but that doesn't do anything special (they act the same as they do in
the temples on the Astral level). Unlike in the endgame, the Amulet and
its fakes aren't listed as likely candidate for #offer's pick-an-object
prompt; like the endgame, corpses must be carried rather than being on
the altar in order to be sacrificed.
Prevent non-chaotics from destroying the chaotic high altar on the
Astral level via same-race sacrifice. From a bug report. (Chaotics converting non-chaotic high altars
via same method was already handled. I think the behavior for ordinary
altars if wrong here; why should a chaotic altar be destroyed this way?)
Prevent demon princes and demon lords from being summoned in the
endgame. Lesser demons answer instead. Mostly prevents Yeenoghu from
being summoned by a chaotic who performs same-race sacrified on the
chaotic high altar, but might affect the Wizard and arch-liches too.
Identify (via ':', ';', '/') altars in temples on the Astral and
Sanctum levels as "high altars" rather than just as "altars". '/' and ';'
commands now work on those when you're adjacent, like they do when used on
adjacent high priests; from farther away, the altars' alignment is still
suppressed.
From a bug report: if swallowed and blind
and in quantum mechanic form, hitting the engulfer would yield "the <mon>
disappears" even though you were still swallowed by <mon>. The pre-teleport
criteria for whether you knew the target was there were different from the
post-teleport ones. Make them match; swallower will remain sensed by touch
and won't be described as disappearing.
A couple of months ago Michael forwarded a thread from the newsgroup
about how wielding a cockatrice corpse without gloves while polymorphed
into something capable of that would leave you wielding that corpse
bare-handed if you changed form, turned to stone, then got life-saved.
That got fixed; the corpse becomes unwielded. However, one of the
messages in that described a different bug: if you were wielding such a
corpse as a stone golem and cast stone-to-flesh at yourself, you would
continue to wield it bare-handed as a flesh golem. This makes you revert
back to stone golem once the first transformation has finished.
This also fixes an attribute exercising bug in polymon(). It was
being done after the polymorph was completed, so the attempt to exercise
Con didn't do anything because exercise() of anything other than Wis has
no effect when the hero is polymorphed.
From a bug report: entering lava cures sliming,
but if you got [re-]afflicted by green slime after becoming stuck in lava,
#sit failed to cure it. Fix that, and have sinking farther into lava cure
it too (although not necessarily right away).
Also, suppress leaving the corpse in a bones file for death caused by
being dissolved in lava. Lastly, suppress the "you rise from the dead as
a <monster>" message during bones creation when the game ends due to being
turned into green slime since you transformed rather than died (and sliming
timeout gives "you have become green slime" just prior to that).
Something's wrong with the way lava was being handled in moveloop().
If you were trapped in lava (ie, moved into some but didn't die on the
spot thanks to fire resistance), you could sink and ultimately die without
ever taking another actual turn (typing ``i<space>'' repeatedly is an easy
way to reproduce). [`didmove' was only being checked for the sinking
deeper case and not for the decrement which ultimately leads to the fully
sunk case.] On the other hand, if you could manage to start an occupation
and avoid being interrupted, you would never sink while it was in progress.
[Lava handling followed ``if (multi && occupation) { ...; continue; }''.]
While testing some other code (lava vs slime, coming shortly) I ended
up with the cursor sitting on the status line while the game was waiting
for me to enter my next move. I don't really understand what's going on
there, and moving the lava handling before bot() might have hidden that
particular problem now by changing the point at which Slime will get taken
off the status line, but this attempts to fix it anyway.
From a bug report: you
can dip a worn item such as shirt or suit into a potion of polymorph and
it will become unworn--but as of a couple of days ago, unworn only if the
transformed object's new form can't be worn in the same slot--even if it
is covered by a cursed worn item (suit or cloak). It didn't seem like
trying to fix that special case would be very worthwhile; this fixes the
more general situation of "you could dip worn items even though they were
covered up by other worn items".
In the same report: you could apply grease to rings while wearing
cursed gloves. The code already prevented greasing a suit when it was
covered by a cloak (regardless of whether that cloak was cursed), and a
shirt when it was covered by a suit or cloak or both. This moves that
code into a separate routine which is used for dipping as well as for
applying grease, and now handles rings vs gloves.
Since covered rings, shirt, or suit are no longer eligible to be
dipped or greased, this also makes "?" for the pick-an-item prompt leave
such things out of the list of likely candidates.
From a bug report: zapping a wand of striking or locking or spell of
force bolt or wizard lock up or down when standing at an open drawbridge's
portcullis didn't affect the bridge if the portcullis was positioned north
of the open span. One of the two drawbridges on the Valkyrie quest goal
level has that orientation. is_drawbridge_wall()'s name is somewhat
misleading; it isn't boolean and returns -1 rather than 0 for "no".
From a bug report. That's hard to fix in the general case because armor
and tools might not fit back into the same equipment slot, but most other
types of worn items can be re-worn after being transformed. This makes
any transformed worn item stay worn if it is wearable in the same slot.
simple_typename and obj_typename operate on item types rather than
particular objects so have to assume that the item involved has been seen.
That means that simple_typename(obj->otyp) is not suitable; if obj->dknown
hasn't been set, it gives away information. This adds mininal_xname(obj)
to be used for that purpose. I'm not aware of any straightforward way to
actually expose the original problem; it's more than hypothetical but not
something anyone's likely to have come across.
Not fixed: test driver program reveals that obj_typename(GOLD_PIECE)
and simple_typename(GOLD_PIECE) yield "coin of gold piece". But I don't
think there's any way to get nethack to show that to the user.
Noticed when examining resists_magm() while working on anti-magic
traps: if you were polymorphed, you would be granted magic resistance by
keeping a cloak of same or gray dragon scales/mail in your quiver slot,
your alternate weapon slot, or main weapon slot (ie, by wielding it). And
you obtained light-based blindness resistance regardless of whether you
were polymorphed if you carried a potion of blindness in any of those slots.
Make anti-magic fields do something against targets which have magic
resistance, expanding the functionality of that trap type and giving a
minor drawback to the most valuable intrinsic in the game. Make them work
against monsters too.
Heroes who lack magic resistance lose spell energy as before, except
that if they drop below 0 they don't take as hard a hit against max spell
energy as they used to. Monsters with spell or breath attack and lacking
magic resistance get their ability-last-used field bumped up a little bit,
so they can't cast or breathe for a few turns. Heroes and monsters who
have magic resistance take HP damage instead. I retained the concept of
feeling lethargic when being hit by something which normally drains enery,
and also tried to make it be the inverse of a "magical explosion": the
message refers to torpor/lethargy/sluggishness and cause of death if the
damage happens to be fatal is "anti-magic implosion". The latter suggests
some sort of compression, so creatures who can pass through walls (xorns
and ghosts) have been given partial resistance and take reduced damage.
If a Rider's corpse revival timer ends with failure (presumeably
because the level has become entirely filled with monsters), give it a big
chance to try again in a few turns instead of always rotting the corpse
away. Also, if there is another monster standing on the corpse when it's
due to revive, try to bump that monster out of the way to let the Rider
revive in place instead of having it be diverted to some other location.
High resistance made the Riders unlikely to be polymorphed, but
they were susceptible to being turned into green slime (and then never
reviving if killed in that state). Now they'll be immune to both types
of transformation.
<email deleted>:
> If you enter a magic trap on the same turn that you lose your levitation
> and "float gently to the floor", you are hit by the trap twice.
I don't think this is actually a bug, but it does look fairly strange
if there aren't any monsters attacking (after you move on to the trap,
monsters get a chance to move too before timeouts are run, but if there
aren't any messages triggered by monster activity then it feels like the
timeout and second activation happens immediately). To prevent this, if
levitation is due to time out on the same turn that a trap is being
entered, either extend the duration by an extra move or make it end
immediately instead of waiting until end of current turn. Deferring
timeout is a lot easier but doing that unconditionally would allow player
to move back and forth between adjacent traps without ever descending.
The early timeout might lead to anomalous behavior in obscure cases; it
seems to be working ok so far though.
Noticed while tracking down the "you die..." situation. Duplicating
instapetrify()'s resistance checks is useful here, but there's no need to
also duplicate its death handling.
Eliminate the somewhat redundant "You die..." following "You turned
to stone..." when becoming petrified by touching a cockatrice (reported
by <email deleted> for kicking, but occurs for weaponless hitting too).
Also, if a cockatrice killed you with normal damage, your tombstone would
erroneously report petrification and presumeably there'd be a statue
instead of a ghost in the resulting bones file. This fixes both things.
Using #tip (post-3.4.3 code) on a container that's on a shop floor
didn't handle ownership correctly. Bag of tricks could be emptied for
free, and contents of other containers were being sold to the shop even
when the shop already owned them. This fixes bag of tricks and makes a
first cut at doing so for regular containers.
Message handling when #tipping any bag of tricks was also suboptimal
since the decision about message delivery was made again as each charge
released something instead of waiting until the whole bag was emptied.
So you could get inappropriate "nothing seems to happen" before or after
a monster visibily popped up if something unseen was also produced.
Some code I recently added was misusing count_unpaid() and would
traverse some or all of inventory instead of just container's contents
when looking for unpaid items. Add mew routine `is_unpaid(obj)' to do
what I was intending to do with count_unpaid().
The earlier change involving "you sneaky cad!" got me wondering, so
I looked up cad in the dictionary: "an ungentlemanly man". I can see
that being extended to a male gnome, even to an orc, but not to a women.
Use verbalize instead of pline for shop "thank you, scum" message
(From a bug report. Suppress shop "you sneaky cad" message
when removing a hero-owned pick-axe from a container inside a shop if the
shk is unable to speak; also give it at most one time per move (taking
multiple pick-axes out of a bag at once was way too verbose). Honor
addtobill's silent flag for the bill overflow message when/if that occurs.
Also adds a safe_qbuf usage for the #tip command that I had pending
for pickup.c.
Make objects created by applying or #tipping a horn of plenty which
is owned by a shop also start out being owned by the shop. That's in
addition to the usage charge for using an unpaid item.
I think wishes conferred by unpaid objects, or by entities released
from unpaid objects, should probably work that way too, but have left
that alone.
[I can't get access to my mail at present, but `cvs update' shows
that there aren't any patch notification messages pending for me.]
Extend a pre-3.4.3 fix--for objects picked up in an untended shop--
to container contents. Without it, dropping a bag or box in a tended shop
and declining to sell it, then picking it back up after the shop has become
untended (shk killed or evicted) would leave the contents with no_charge
set. After that it could be sold in another tended shop, picked back up
for free, then kept or sold a second time. (Picking it back up in the
tended shop would clear the bit; afterwards it behaved normally. And it's
not something prone to abuse; if you can make a tended shop become untended
you really don't need to sell stuff twice. But it'd be noticeably wrong if
anyone ever stumbled across it.)
Inventory display adds "(unpaid, N zorkmids)" to carried unpaid
items, but it didn't show anything comparable for indirect unpaid ones
(hero-owned containers holding shop-owned objects). Now it will include
"(contents, N zorkmids)" in such cases.
Allow '#' as a destination slot if you've given '#' as the source
and there aren't any available inventory letters, making it possible to
use doorganize()'s feature of merging compatible items into one slot even
when that slot is #. ('#' won't work as a destination when the source is
from a regular letter. If the player wants to swap something in letter
slot x with whatever is in the # slot, he'll have to use # -> x rather
than x -> #.)
Also, a post-3.4.3 change made it possible to produce an inventory
that used duplicate letters. Giving a count while specifying the source
slot splits the source object. But the extra '?' choice added to show
inventory letters in use didn't undo the split if player hit ESC to quit
early instead of specifying a destination slot.
Lastly, don't prompt forever if the user doesn't give a valid
destination letter; give up after 5 attempts.
Prevent getobj() from overflowing its inventory letter collection
buffer if someone figures out some new way to fill up their inventory with
a huge number of # entries. Inventory manipulation might become crippled
at that stage but at least it shouldn't be able to trigger a crash.
Also, the !fixinv configuration was never taught about # and did
strange things if you had more than 52 items, both for inventory display
and object selection with getobj.
The reassign()/getobj() situation is definitely confused regarding
gold, using GOLD_SYM in some places and def_oc_syms[COIN_CLASS] in
others, and it's schizophrenic about whether the GOLDOBJ configuration
keeps gold in a letter slot or specially named $ slot. I'm sure there
are some problems there but I'm not planning to try to figure them out.
Prevent heroes in giant form from picking up boulders once they run
out of available inventory slots to avoid an uncontrolled number of '#'
entries. There is an exception: if not already carrying any boulders,
they can put one into the '#' slot. Loadstones are treated the same way,
although since they stack and are rare to begin with, someone would have
to have gone far out of their way to have gotten many # entries with them.
Assuming that you can get something other than a boulder or loadstone
into the # slot (which is definitely possible, I just can't remember how),
you could relatively easily get three total # entries by picking up a
loadstone and polying into a giant and picking up a boulder. But I don't
think there's anything wrong with that.
If someone manages to get three or more items with inventory "letter"
'#', compact inventory selection prompts to list "#-#" instead of showing
every #. It isn't possible to selectively pick a particular one anyway,
so this doesn't affect player choices.
1 #: Which item? [$#a-zA-Z]
2 #: Which item? [$##a-zA-Z]
3 #: Which item? [$#-#a-zA-Z]
4 or more #: same as 3.
This doesn't address the fact that picking up enough boulders as a
giant might overflow the BUFSZ buffer getobj() uses to collect inventory
letters prior to calling compactify() on them.
[I accidentally left this out of the previous commit.]
Throwing didn't handle a container owned by the hero which contained
items owned by the shopkeeper. I'm still not quite sure what's going on
there, but throwing the container out of the shop didn't give any feedback
but did add to shop charges which don't show up in ``I x'' (but do get
revealed by ``$'' or ``I $''). Now there's some shop feedback for the
throw and the contents show up for ``I x''.
Try to fix multiple container-in-shop bugs; it seemed as if every time
I tried to investigate one I stumbled into another. billable() (post-3.4.3
code, but already present in branch as well as trunk) didn't handle
containers properly. It sometimes gave the wrong answer and it didn't
clear the no_charge flag of contained items as the old code in addtobill()
it replaced did. stolen_value() didn't use the actual bill price for an
item already on the shop bill; it generated a new price which might be
different if the object was unID'd (3.4.3 had this one). Throwing didn't
handle a container owned by the hero which contained items owned by the
shopkeeper. I'm still not quite sure what's going on there, but throwing
the container out of the shop didn't give any feedback but did add to shop
charges which don't show up in ``I x'' (but do get revealed by ``$'' or
``I $''). (This was intertwined with some of the other stuff and I don't
know how 3.4.3 behaved in this regard. Now there's some shop feedback for
the throw and the contents show up for ``I x''.) An unpaid container which
contained another nonempty unpaid container showed a different price when
picked up and in inventory display [k - a bag (unpaid, NNN zorkmids)]
compared to what was on the bill and showed by ``I u'' because the first
two included double billing of the nested container (just it, not its own
contents). [There where a few recursive calls of the form
x += func(x)
which should have been either
x = func(x)
or x += func(0).] Purchasing used the right amount, I think. I'm not
sure whether 3.4.3 had this particular bug or whether fixes for some of its
other container bugs inadvertently caused this one.
This patch also changes stolen_container() to work like the other
recursive shop routines: it just handles the contents, leaving the outer
container itself to be handled by its caller. It seemed inconsistent, and
changing it simplified the fix for using bill price on stolen unpaid items.
Eliminate a couple of minor redundancies; no change in game play.
dropy() - only check about selling object if there is a shop on the level.
pick_obj() - leave it to addinv() clear object's no_charge bit.
This eliminates a whole bunch of the "Query truncated" entries in
the nethack.alt.org paniclog file by using safe_qbuf() where applicable.
It also makes selling queries and some other shop messages be less verbose
when shopkeepers are invisible (not uncommon after characters achieve see
invisible capability) by using shkname() to get "Manlobbi" instead of
Monnam()'s "Manlobbi the invisible shopkeeper" (something I had planned
to do even before seeing the truncations in that paniclog; repetition of
"the invisible shopkeeper" was very annoying when stepping through
multiple unpaid objects with itemized billing).
This also simplifies several GOLDOBJ conditional sections which
happened to be near the other code I was modifying.
Change safe_qbuf() so that instead of picking one of three strings
for sprintf() to plug into a prompt string, it actually constructs the
full prompt string itself. Also pass in the unformatted object and a pair
of formatting functions instead of performing dual formatting in advance.
The actual formatting is done via new routine short_oname() which also
takes an object and a pair of formatting routines plus a target length.
It uses the first routine, typically xname() or doname(), and formats the
object, then if the result is too long it makes some transformations, and
tries again. If truncating "called foo" and "named bar" down to 12 chars
and omitting "uncursed, rustproof, thoroughly corroded" attributes still
result in a string that's too long, it uses the other formatting routine.
The latter calls one of several jacket routines around simple_typename()
to produce a short result.
This has been through about four incarnations now and has gotten a
bit less testing each time, but I need to get it in place before I end up
running out of gas and abandoning it. I've got some changes to shk.c
(where safe_qbuf is needed but not currently used) that now need to be
redone and will come eventually.
Explicitly truncate the query prompt string to QBUFSZ-1 characters.
For tty and Amiga, no longer include the choices and default within that
length limit; use a bigger buffer to hold them along with the prompt.
[See cvs log for doc/window.doc for more details.]
Explicitly truncate the query prompt string to QBUFSZ-1 characters.
For tty and Amiga, no longer include the choices and default within that
length limit; use a bigger buffer to hold them along with the prompt.
-----
While trying to eliminate the "Query truncated" entries present in
nethack.alt.org's paniclog, I seem to keep going backwards. Allowing
<win>_yn_function() to accept a full QBUFSZ worth of characters will
simplify the existing yn_function() in the core and greatly simplify the
revised safe_qbuf() I've been working on.
Some interfaces don't seem to care how long the prompt string is; I've
left those along. Several of the others already copied the prompt string
into a BUFSZ sized buffer instead of a QBUFSZ sized one, making them
unlikely to suffer from buffer overflows. This changes the rest (just tty
and Amiga, I think) to do the same. Also for all that have any size
constraint, it now truncates the prompt query to QBUFSZ-1 chars as it is
used rather than continue to rely on the caller doing so. This assumes
that appending the set of acceptable choices and the default response won't
overflow, which is a safe assumption unless/until QBUFSZ gets enlarged til
it's too close to BUFSZ.
Only tty's topl.c has been tested. The others should work ok, but
might possibly be bitten by a typo or two. Qt's implementation of the X11
"slow" method (reusing a persistant one-line window for prompts) has been
handled, but its C++ class-based variant is untouched; NetHackQtYnDialog::
Exec() is completely baffling to me but doesn't appear to have any length
issues.
According to a newsgroup followup, a hidden pet summoned via magic
whistle could produce the same effect as the level change case (where
sometimes the glyph for unseen monster would appear unexpectedly). I was
unable to reproduce this one, but I don't see anything in the code to deal
with the situation, so I suspect that the monster is moving immediately
and being revealed before I have a chance to notice anything odd.
I assume that other situations where hidden monsters get teleported
are being handled as attacks which expose them. At least I hope so.
From the newsgroup: if a pet was hiding under an object next to you
when you changed levels, it could arrive hidden at the destination if there
was something available to hide under there too, and sometimes you'd start
the new level with a hidden monster glyph at its location. I was able to
reproduce that once with current trunk code, but while trying to figure
out what is actually happening I've been unable to make it happen again.
However, it doesn't make sense for a monster to be able to remain in hiding
during the level change in the first place, so this patch prevents that.
(I'd still like to know how/why map_invisible() is sometimes getting called.
[The test character was a level 1 tourist without auto-search capability.]
I'm reasonably sure that it won't happen any more once this fix in place.)
This also brings adjacent pets out of hiding when they accompany you
during ascension or dungeon escape, but it seems that that wasn't actually
necessary. The end of game disclosure already lists such by name rather
than as "it", contrary to my expectations. (I had forgotten that end-of-
game forces true names so that blindness and hallucination don't interfere
with disclosure; obviously that ends up handling hidden monsters too.)
From the newsgroup: if you were wielding a cockatrice corpse without
gloves while polymorphed into something capable of doing that, then were
turned to stone when rehumanizing, you'd be left wielding the untouchable
corpse if life-saving kept the game going. This causes it to stop being
wielded if you get that far. Likewise for monsters.
From the newsgroup: it was possible to saddle, mount, and ride on a
sleeping jabberwork without it ever waking up. Movement was checking for
timed sleep (!mon->mcanmove, set when mon->mfrozen contains a timer count
for either sleep or paralysis) but not indefinite sleep (mon->msleeping).
This moves the checking into its own routine which handles both types.
And it gives monsters a chance to wake up when they get saddled or mounted.
Extend the identifying information used to prefix paniclog entries
from version + date to version + date + time + userid + mode (where mode
is 'D' for wizard mode, 'X' for discover mode, and '-' for normal play).
hacklib.c ended up getting more of a revision than I intended, but
the date/time handling routines now have less clutter. I hope I didn't
break anything in the process.
From a bug report: if you
attempted to eat a Rider corpse and got the 1/7 chance that non-yet-rotten
food will be treated as rotten, then also got "the world spins and goes
dark" result for rotten food, you would both survive the eating attempt
and also end up with a partly eaten Rider corpse. This patch treats Rider
corpses like lizard and lichen corpses; they'll never yield rotten food
effects. That way, they'll always be fatal to eat. They'll still end up
being partly eaten if you are life-saved, but since they'll immediately
revive, the only way you'll know that is to use probing or stethoscope to
discover that they've revived at less than full health.
Nearly two years ago, <email deleted>
suggested that lembas wafers and cram rations be treated like fortune
cookies and never yield the rotten food result. I'm guessing that cookies
are handled that way so that rotten food feedback doesn't override false
rumor delivery when they're cursed, rather than because they're considered
to be rot-proof. This implements <Someone>'s suggestion, except that cursed
lembas and cram will still behave like rotten food.
Fido grows up into a large dog.
The soldier becomes a sargeant.
Similar feedback was previously given only when the monster was going to be
killed off due to its new form having been genocided.
The shortest extended commands were being formatted differently in
Guidebook.txt than longer ones, looking a little odd. Force them to seem
longer so that they all end up with similar formatting.
Untested; based on how short option names are handled. And I have no
idea whether the TeX version ought to have something similar done; I lack
the means to view it. (In theory I could format it into Postscript,
transfer the result to a PC [a different one than what I'm using as a
terminal], convert it into PDF there, then use Acrobat to look at it. In
practice, that's more effort than I care to expend for something so minor.)
About six weeks back, <email deleted> suggested that
bear traps should deal out damage and be escapable via opening magic.
This doesn't do anything about the first part, but it does allow opening
magic (wand of opening, spell of knock, blessed Bell of Opening) to get
the hero out of bear traps and webs if zapped either at self or downwards.
Zaps across the floor which hit monsters will free them from such traps,
with a chance that releasing a hostile monster will pacify it (using
existing #untrap code). Conversely, if you are at a web or bear trap
location but not currently trapped, closing magic (wand of locking, spell
of wizard lock) will cause the trap to activate; you may or may not become
trapped. Likewise for zaps at monsters who are at such locations, which
is treated as an attack.
Opening magic which hits the hero or a monster located at a trap door
or falling rock trap spot will cause the trap to activate; as above, it's
an attack for the monster case. At the moment, zapping opening magic
downwards at the hero's location (but not zapping at self or at monsters)
will also cause holes, pits, and spiked pits to activate. (Zapping down
triggers falling rock traps and zapping up doesn't; that'll need to be
changed.) Zapping opening down while mounted will untrap, if stuck in a
web or bear trap, and will trap, for the falling cases, in precedence over
releasing the saddle and forcibly dismounting. The latter still occurs
when there is no applicable trap present though.
Zapping locking magic downwards at a hole location will convert the
hole into a trap door. Zapping breaking magic (wand of striking, spell of
force bolt) down at a trap door location will convert the trap door into a
hole. (Neither conversion currently alters the made-by-you flag for the
trap. However, the rationalization that distinctive style is what makes
made-by-you recognizable suggests that conversion should clear the flag.)
Lastly, the old behavior (which pre-dated bare holes) of destroying trap
doors when zapping down at them with locking magic has been removed--it
didn't seem to fit very well with the new cases. I'm starting to have
second thoughts about that but am going to commit this before discovery of
some more niggling details drags it out for another six weeks.
From a bug report: you could end up with
gravestone/logfile result of "burned by burning" or "drowned in a drowning".
If you get life-saved when drowning in water or burning in lava, the game
tries to teleport you to safety. If the teleport fails for some reason--
such as lack of unoccupied non-water or non-lava locations--you drown or
burn again. But life-saving was resetting the killer reason and the repeat
drowning/burning wasn't setting it up again, so the default got used and
produced a silly result.
From a bug report: you could end up with
gravestone/logfile result of "burned by burning" or "drowned in a drowning".
If you get life-saved when drowning in water or burning in lava, the game
tries to teleport you to safety. If the teleport fails for some reason--
such as lack of unoccupied non-water or non-lava locations--you drown or
burn again. But life-saving was resetting the killer reason and the repeat
drowning/burning wasn't setting it up again, so the default got used and
produced a silly result.
Wizard mode's ^G lets you specify "tame <foo>", "peaceful <foo>", or
"hostile <foo>" to override the created monster's default disposition.
Since it also lets you override the restriction against creating unique
monsters and various other special ones like shopkeepers (a post-3.4.3
change), it became possible to produce tame versions of monsters that
ordinarily are impossible to tame. That's pretty iffy even when it only
applies to debugging, so switch from internal tameness conversion to use
of tamedog() to get the non-tameable cases handled. (Minor side-effect:
full moon might prevent a request for "tame dog" from starting out tame.)
Also, for <N>^G, give up before the specified count is reached if
creation fails when creating multiple copies of a specific type of monster,
on the assumption that the level has become filled up. (When the type is
random, keep trying in case you subsequently get something different which
could survive on water or inside solid rock.)
More explicit control over the behavior of spoteffects() is probably
the way to go in the long run, but this much simpler fix handles the case
at hand. I'm not sure what `thrownobj' was intended to be used for in the
first place, but it came in handy here. (It was being left as a dangling
pointer when thitmonst() reports that the missile has been used up; that's
fixed now.)
Fix the reported problem of lookhere/autopickup not seeing the missile
which just killed the engulfing monster whose death caused the hero to be
put back onto the map and so look/pickup upon arrival. Normally the missile
gets placed after damage has been dealt and the throw has finished. This
overrides that so that the missile is put into the engulfer's inventory as
it is being killed (which will then put that inventory onto the floor prior
to expelling the hero on top of same). If the monster happens to get
life-saved it just ends up collecting the thrown-from-inside object a little
sooner than usual.
This wouldn't correctly handle the same case for a kicked object, if
that were possible. But it isn't possible to kick objects while engulfed,
so that's moot. Other calls to thitmonst() and hmon() don't appear to have
any objects in transit so shouldn't need any comparable fix (I hope...).
A first cut at adding some user-level documentation to dat/symbols.
It should probably include a brief example (not verbose description) of
how to specify values in the various supported formats (decimal, octal,
hexadecimal, simple string, string including escape sequeces?). Perhaps
a pointer to the Guidebook too. :-}
This may become moot if ASCIIGRAPH and/or ROGUE_COLOR setup changes.
But right now, the initialization was failing except when all three of
TEXTCOLOR, ASCIIGRAPH, and REINCARNATION were defined.
Noticed while synchronizing my code: Readme's list of directories
still had sys/amiga/ship, which is long gone, and lacked sys/wince/ceinc
and sys/wince/ceinc/sys, which have been around for quite a while now.
> Give demon lords and other monsters who teleport to your location a
> oneshot arrival message. [...]
> The fixes entry is deliberately a bit vague (and I put it in the new
> feature section rather than the fix section).
And apparently I neglected to commit it with the rest of that patch last
week.
If you get "you have summoned <demon>" after making a same-race
sacrifice, treat that as having been the "<demon> appears" message so that
the latter won't be given if it subsequently teleports to you after you've
moved out of sight of it. There are probably some more cases like this
still lurking in the code.
Give demon lords and other monsters who teleport to your location a
oneshot arrival message. Brought about by the report of the late "<demon>
appears" message delivered during its bribery demand, after the character
had already been able to see it for long enough to extract gold from a bag.
Now, if you can't see or sense a monster before it teleports to you, and
you can see or sense it after, you'll get "<monster> suddenly appears!".
The message will be given at most once for any given monster, and it won't
be shown at all if you already see/sense the monster before it teleports or
still don't see/sense it afterwards. The fixes entry is deliberately a bit
vague (and I put it in the new feature section rather than the fix section).
The change from long to unsigned long for monst.mstrategy may bring
some lint complaints along with it. The various constants (STRAT_xxx) used
to populate it are still signed. I didn't increment EDITLEVEL for this;
existing data should still work ok.
Turn being unconscious (via several reasons, including fainted from
hunger) into a pseudo-property named `Unaware' and use it in several
places where only being asleep was checked. #H202 was about a stunned
character who got the recovery message when it timed out while fainted.
This suppresses messages for several difficulties when they begin or end
while hero is Unaware. Messages about fatal illness, sliming, or
petrification aren't suppressed; they're too important to hide from the
player. "You feel ..." messages come out as "You dream that you feel ..."
when Unaware; fairly lame but hopefully adequate.
From a bug report, being hit with a
yellow light explosion while fainted from lack of food caused blindness
but being hit while sleeping did not. Make being in fainted state become
a protection against light-induced blindness.
A couple of short quotes which needed a good home. The first is a
bit of verse from a short story, the second is part of the opening theme
song of the TV series "Monk". (That's the main character's surname, not
his profession/vocation :-).
Also make the change to the actual monk entry suggested by <Someone>.
From a bug report, the fallback selection criteria
(used when everything is extinct?) in rndmonnum() was excluding hell-only
monsters when outside of Gehennom, but failed to exclude never-in-hell ones
when inside. [Some of the never-in-hell monsters are Angels, but the rest
are all cold based creatures. That must date to when fire resistance was
required for the hero, which is no longer the case. Should those cold
monsters retain their never-in-hell setting?]
This also fixes a latent copy/paste bug in the unused mons[] definition
of Cerberus (it was the only unique monster which failed to specify G_NOGEN).
<Someone> says he reported this five years ago, but I don't think I ever
saw it. Receiving an artifact as the result of #offer would add it into
the discoveries even if the hero was blind and never saw it. It either
needed to have the dknown bit set, as if it had been seen, or else should
not be added to the list. I've opted for the latter.
Mentioned by <Someone>, who suspected that the fix for C343-114 dealt with
this. When a giant picks up a boulder from a location where more than one
is present, line-of-sight would be inappropriately cleared, as if the
remaining boulders were transparent. (He said that he got no pickup
message when the giant picked up the boulder. I do, and have not tried to
figure out whether this is a post-3.4.3 difference.) Pushing a boulder
onto a landmine had the same bug, although you wouldn't notice unless there
were at least three boulders to be pushed (mysterious ability to push more
than one boulder in a turn strikes again: first one triggers the trap and
is destroyed, allowing hero to see through any others; second fills in the
resulting pit; third gets moved to the former trap spot and [probably--I
haven't checked] re-blocks vision; fourth, if any, stays put; if only one
or two are present, the change in vision is expected and the fact that it
happens too soon in the two boulder case would probably go unnoticed.
Polymorph of a boulder also opened up vision without checking whether any
others are present.
An existing, evidently overly optimistic, fixes34.4 entry covers this.
From a bug report, having hallucination time out while
mimicking an orange (instead of gold, after eating a mimic corpse), you'd
still get the hallucinatory end-of-mimicking message about not wanting to
be peeled. If hallucination state is toggled, update the pending message
and change the hero's appearance. In practice, only the orange-to-gold
case can occur. Anything which might trigger gold-to-orange will have
terminated the hero's mimickery befort that happens.
<Someone> reported being swallowed by his pet purple worm during
Conflict, then being stuck inside once Conflict ended. I'm not entirely
sure what dog_move() intended by the "swallowed case handled above" comment.
It returns without letting the pet move when the distance between pet and
hero is 0; that wasn't much in the way of "handling" being swallowed.
Grabbing pets did let go, but peaceful monsters didn't until you actually
attempted to move away from them. Now all four combinations (grabbed or
swallowed by tame or peaceful monster) are handled the same: the monster
will let the hero go next time it gets a chance to try to move, using up
its move in the process.
When the hero arrives on a level and a monster at his destination can't
be relocated to make room for him, goto_level() would place the hero on top
of the monster. From a bug report, who said that the
game panicked (without providing specifics, at least so far). I wasn't able
to reproduce a panic but get a pair of impossible warnings and can confirm
that there is a monster on the same spot as the hero, which could easily
lead to strangeness depending upon what actions the monster attempts to
perform. This fix causes a non-relocateable monster in that situation to
be moved to the migrating monsters list for later arrival back on that same
level. That's inconsistant with the migrating monster arrival routine,
which kills off any monster it can't place; I'm not sure which action is
more reasonable, deferred arrival or outright removal.
There are three or four dozen ``(void) rloc(mon)'' calls which don't
do anything special when rloc fails to move the monster. Those need to be
reviewed and the ones where it's making a space for some other monster have
to do something about failure. (Failed teleport attempts can simply leave
the monster in place, so most of those calls won't need any extra handling.)
Forwarded from the newsgroup by <Someone>: temple priest might
abandon his post via teleport if conditions are obscure enough. Change
rloc_pos_ok() to only accept spots inside the same shop or temple when a
shopkeeper or temple priest is teleported to a random destination. rloc()
tries rloc_pos_ok() 500 times before reverting to goodpos(), so this will
usually succeed for a large room; it may fail for a small one (reverting
to the current behavior, more or less). Shopkeepers or priests who get
polymorphed into a critter which teleports to the stairs when in need of
healing will still leave their shop or temple if wounded (no change).
Priests resist if the player tries to teleport them, but shopkeepers
don't. So for direct attack by the player, this only affects shopkeeper
destination. But it affects both types as far as being hit by quantum
mechanics (probably caused by player's use of conflict) or if polymorphed
into monsters which steal and then flee (again, probably caused by the
player since those strong monsters won't voluntarily polymorph).
From a bug report...): pushing a boulder onto a level teleporter trap
could repeat the
You push the boulder and suddenly it disappears!
message. That would happen whenever the teleport destination was the same
as the current level (20% chance). The boulder wasn't being moved onto the
trap location so was still present when the pushing code tried to handle
the next one in the pile. I've changed so that pushing stops whenever a
pushed boulder is affected by a trap, and also so that the boulder gets
moved as usual when a level teleporter fails to send it somewhere.
I've always thought it's pretty strange that pushing ever operates
on more than one boulder in the same turn in any situation, but I haven't
changed that for the non-trap cases. (Usually the first boulder pushed
ends up blocking the second one, so you get a "you try to move it, but
in vain" message which seems odd since you just moved one. But if there's
a pool of water or lava in the path, you can actually push multiple
boulders successfully.)
From <Someone>:
Pet picks up 8 spears.
Pet wields 8 spears.
Pet thrusts its spear at Foe.
The routine to handle a monster attacking the hero are already uses "mon
thrusts one of its spears" in this case, so make monster against monster
messages do the same. Also, it's no longer necessary to save one monster
name before formatting another when using two monster names in the same
message, so switch to the more straightforward usage here. (The Blind
check is needed in the mhitu case but not in the mhitm one, where it's
redundant because the caller has already verified that both monsters'
locations are visible, but I left it in.)
More tweaking brought about by the report of falling through a
trapdoor above the quest locate level and landing below it (which won't
happen randomly any more, but can still be achieved via controlled level
teleport). You don't get any message for the locate level when arriving
from below, and giving the full initial message if you manage to make a
return visit from above produces silly results. This adjusts the logic
for delivering those messages; once you've been on the level, you won't
get the full initial message later even if it wasn't given the first time.
You will still get the shorter secondary message, up until the nemesis has
been killed. (In some cases it might not make much sense since its wording
is based on the assumption that you've already seen the full message.)
The handling for these messages will never be completely correct
unless the messages themselves are rewritten (and the result would
probably end up with really wishy-washy phrasing so there's not much point).
They assume that you'll be arriving via the stairs, even for the case where
you do come from above rather than unexpectedly from below, and they can
be misleading or confusing if you arrive someplace else. We could improve
things by having alternate FIRSTLOCATE and NEXTLOCATE messages for use when
not on--or next to, for the case where a pet displaces your arrival--the
stairs. But I'm not going to attempt to compose those.
From a bug report, it was possible
to fall from above the quest locate level to below it even though it has
nondiggable floors (hence no trapdoors or holes to pass through). Since
the game can't verify that it is nondiggable (which could vary on a role
by role basis depending upon their quest descriptions) when it is not the
current level, restrict falling past it only when it hasn't been visited
yet. Impose the same restriction for random level teleport. This enforces
proper sequencing of the quest feedback, which was the more significant
thing that went wrong in the reported case (player finally got the full
locate level message on a return visit, when descending from above, after
having already cleared out that level on his way back up from falling).
Once the locate level has been reached or passed, it is no longer a
barrier to falling or random teleport. (When it is eventually visited,
there's no attempt to remember whether it allows holes, since that
information and the corresponding fall check would need to be extended to
every level in the dungeon. Also, controlled teleport is still allowed to
bypass it even when it hasn't yet been visited, so the "enforces proper
sequencing" claim above is an exaggeration.)
From a bug report, the whatis description
for monks (a passage about a monk being invited to a meal) was using "month"
where "mouth" is clearly intended. I think this came up a few years ago
when monk was first added and am not sure why it wasn't changed them, even
if it happens to be an accurate transcription from the quote's source.
From a bug report, applying a pick-axe will
wield it in place of the primary weapon but wouldn't update the alternate
weapon. Make objects which become wielded when applied (pick, lamp, whip,
grappling hook, pole-arm) honor the pushweapon option (where the previously
wielded weapon becomes the alternate weapon without use of 'x' command) the
same as when explicitly wielded. Old behavior matched the documentation,
but that seemed overly restrictive.
I'm pretty sure that some pre-standard compilers don't know how to
apply an initializer to a variable of type union. Unfortunately, I don't
have access to one to check. Fortunately, there's no need to explicitly
initialize `zeroany' since the default value is what we want--the first
field will be set to zero or null as appropriate (null in this case).
Strictly speaking, this isn't adequate; what if long is wider than a
pointer rather than narrower? Using `= {DUMMY}' didn't handle that case
either; the ordering of the union's fields controls which bits get stored.
As a practical matter, it should make no difference. As long as the code
reading a union accesses the same field as the code writing that union set
up in it, anything in extraneous bits should be irrelevant--except perhaps
when a debugger tries to format things. The whole issue has always been
implicitly based on the assumption that null pointers have all bits zero
in the first place; that's typical but not guaranteed.
Hide pointer formatting in alloc.c by eliminating the need for callers
to know how big a buffer is required. I generally prefer the caller to
pass in its own buffer for this sort of thing, but in this case the usage
is almost entirely for debugging so using static buffers results in less
clutter in the rest of the code.
Move the new VOID_ARGS and some other argument manipulation stuff
from global.h to tradstdc.h where it feels like a better fit. Make the
definition of VOID_ARGS more general; it should work nearly everwhere
these days even if it is only needed for one configuration. XXXconf.h
can redefine it as empty if necessary.
For MONST_P and OBJ_P, I left "void*" as is but I'm pretty sure that
the lack of space in between the two components was never part of the
issue there. (The Ultrix system I used to have access to is long gone.
It was chugging along on autopilot, effectively defenseless, at the time
a linux box on the same subnet got hacked. It probably would have been
shut down for Y2K anyway if it had lasted til then.)
From a bug report, attempting to attack
a hidden monster who is revealed by ongoing monster detection (blessed
potion or skilled spell) gave "wait! there's a <monster> hiding there"
response and prevented the attack. Make it behave the same as when the
hidden monster is revealed by telepathy; the monster comes out of hiding
and the hero's attack proceeds.
The recent fix for "breaking glass wand in tool shop" looked suspect,
adding a call to costly_alteration after an existing call to stolen_value.
Either one or the other ought to suffice. (For items on the floor,
costly_alteration() calls stolen_value(); for items in inventory, or just
released from inventory and not placed on floor yet, costly_alteration()
adds a usage fee to the shop bill but doesn't annoy the shopkeeper into
adding surcharges to prices or summoning the kops if already hostile.)
In 3.4.3, stolen_value() wasn't smart enough to charge for an out-of-
shk's-field item (like a wand in a tool shop) taken from a shop container,
and that's the problem the user was reporting. But the post-3.4.3 code was
changed to handle that by checking billable() instead of saleable(); this
bug should have been gone. Unfortunately, billable() treats items already
on the bill as not interesting--from the perspective of adding things to
the bill--so the change accidentally resulted in stolen_value() no longer
handling objects which are marked unpaid, triggering the same symptom for
a different reason. (Other events besides the breakage of thrown objects
suffered from the bug's new incarnation since various places deliberately
call stolen_value() for unpaid objects.) This updates stolen_value() and
stolen_container() to account for the behavior of billable(). And a few
calls to subfrombill() go away since stolen_value() now takes care of that.
Bug in #tip handling for horn of plenty. Emptying one while levitating
would trigger an "obj not free" panic by flooreffects() due to following
hitfloor() with redundant/inappropriate dropy().
<Someone> reported that he applied an unID'd bag and it became
discovered as a bag of tricks even though a spellbook appeared on the floor
next to him rather than having a monster show up (the monster was a mimic).
Suppress the bag discovery unless you can see or sense a monster appear.
(This doesn't really achieve much for most players, who'll recognize the
bag because they know that only one type of container doesn't prompt to
take things out and/or put things in, but I think it does make sense.)
While mucking with bag of tricks I decided that to be consistent with
the behavior of other containers, the #tip command should release all the
monsters in the bag instead of just one.
And after doing that, I realized that horn of plenty ought to behave
much the same, so #tip will operate on it now. However, it won't be listed
as a likely candidate in the "which item?" prompt unless/until it has been
discovered. (Attempting to empty any other type of horn yields "nothing
happens", same as for a horn of plenty with no charges left.) Emptying a
horn of plenty in a shop can be extremely verbose, but I don't think that
qualifies as a bug and don't currently have any plans to alter it.
From a bug report: [ slashem-Bugs-1206099 ] Torches are not extinguished with rust traps).
A rust trap that hits the torso candles causes all lit objects being carried
to be extinguished, but one which hit the weapon arm didn't have same affect
on a wielded light. This fix causes wielded candles or lamps (not Sunsword)
to go out if affected by any rust, such as hitting a rust monster with one,
rather than use his patch that just handled the trap case. It also excludes
wielded lights from the existing torso splash since having them be hit by
both instances is too obviously buggy.
I think brass lanterns ought to be exempt from being extinguished by
water (at least splashing which is less drastic than total submersion) since
there are references to them operating by batteries rather than fire, but I
didn't want to track all the places which would be affected.
Some recent code shuffling introduced an unintended change in behavior
(not observable to the player; just unnecessary deletion and re-creation of
light source with identical radius when polymorphing from one light emitting
form to another). The fixup for light range 1 would need to be repeated for
`old_light' when outside the `if (old_light != new_light)' block; move it
back inside where that isn't required. Also, youmonst.data is valid all the
time so a couple of `Upolyd' tests in the surrounding code can be dropped.
Several polymorph tweaks, most dealing with specifying form under
polymorph control or for wizard #polyself:
1) allow "were<critter>" and "human were<critter>" for your type of
<critter> when you're inflicted with lycanthropy; now you'll toggle
shape rather than be told "you cannot polymorph into that".
2) allow your own role; now you'll become a new man (or whatever race)
rather than get "you can't".
3) allow "human" to force a new man (or whatever) regardless of race.
No change for human characters, but elves, dwarves, and such can now
use either their own race or "human". (They never become humans.)
4) for wizard #polyself only, override the 20% chance of becoming a new
man instead of taking on the selected form. (This implicitly prevents
the annoying "your new form isn't healthy enough to survive" death
since your experience level won't drop below 1.)
5) remove a redundant drowning check in polyself(); it's already handled
in polymon() and polyman(for newman()) via spoteffects().
This also gets rid of an old use of 0 as not-a-valid-monster (not
responisble for any bugs though since giant ants aren't lycanthropes).
The user (<email deleted>) who recently suggested a
dump command for containers also wanted atmospheric sounds on levels which
have altars. Right now we'd have to find unattended altars the hard way
(by scanning the entire level) but we could add a counter (or set of
counters, one per alignment) like for fountains and sinks if we really
wanted to do that. [Now that I think about it, the #overview patch may
have already done something of the sort.] But what noises would an altar
be expected to produce? This only adds sounds for temples, where the
attending priest can be the source of the noise.
I'm not real thrilled with the initial set of sounds, particularly
the hallucinating one, but the implementation works. The "carcass" one is
a little clumsy; it's intended to add a hint for new players who haven't
figured out what the #offer command does.
When testing the spoteffects/drown hack I noticed that draining myself
with Stormbringer (toss up, get hit on head) while in iron golem form gave
messages about it drawing or draining life. (I'm sure that this has come
up before....) I've altered the artifact hit message rather than making
golems become resistant, although the opposite approach seems at least as
valid. The drain life spell uses different wording and isn't affected.
Attempt to fix a buglist item: if hero poly'd into iron golem form
enters a pool of water and drowning triggers reversion to human/whatever
form due to water damage, he will fall into that pool again, crawl or
teleport out, then redundantly crawl or teleport out for the initial entry.
[ spoteffects -> drown -> losehp -> rehumanize -> polyman -> spoteffects
-> drown ]
I don't have a lot of confidence in this fix. It does handle the
reported problem, and hasn't broken a couple of earlier tricky cases
(ice melting to water, land mine turning into a pit). But drown() and
lava_effects() seem to leave a trail of special case handling wherever
they appear so they--or spoteffects, or both--ought to be redone somehow.
I can't find the report about this; I must have deleted it after
reading, or else recently reread something so old that I'm not going back
far enough now. When you perform the invocation ritual to create the
stairs down to Moloch's Sanctum, any trap at your location gets deleted.
But if you were in a trapped state at the time then you got left in that
state. Descending stairs doesn't check for traps so you wouldn't notice
unless you tried to move around on the same level first. Then you'd get
"you're stuck in a pit/beartrap/web" even though it wasn't there anymore.
While testing the hiding vs traps patch, I became a mimic and hid.
It gets stuck to you.
Huh? Nothing was visible; nothing became visible (aside from the ']' at my
position changing back to 'm'). Display the invisible monster glyph when
an unseen monster bumps into you while you're hiding or mimicking gold.
That's usually handled by the hit and miss routines, but they aren't used
when you're just brought out of hiding instead of attacked.
From a bug report, the game gave feedback
about a monster becoming stuck in a web but there seemed to be no monster
around because it immediately began hiding under an object at the web's
location. Prevent monsters--or poly'd hero--from hiding when trapped in
anything other than a pit or spiked pit. Also, prevent them from hiding if
they're holding you or you're poly'd and holding them. I'm not sure whether
either of those cases ever actually happened but big mimics are capable of
both hiding and grabbing on.
Fix the problem From a bug report, where
giving a temple donation of the appropriate amount would fail to restore
protection previously stolen by gremlin attack iff the old protection amount
was big enough that the donation wouldn't have yielded a bonus in the normal
not-stolen case. It shouldn't be checking the magnitude of u.ublessed at a
time when lack of the intrinsic renders that value inoperative. After this
fix, the lost intrinsic will be granted and the old protection value will
be restored, same as happens when a prayer boon yields divine protection
(where no u.ublessed magnitude check is made) and as happened with donations
when the old protection was a more modest amount (magnitude test passed).
Yesterday's change to have enlightenment give "you have a <small,
moderate,&> defense bonus" instead of "you are protected" would yield
"you have a small defense penalty" if the combined protection value (from
rings, divine gift, and spell) was 0. This changes the formatting routine
to give "you have no defense bonus" in that situation, then changes the
caller to only display the protection/defense attribute when non-zero so
the "no bonus" case will never actually happen.
The bug report about losing/regaining the Protection intrinsic reminded
me of a couple of things. First, as an intrinsic, Protection seems to be
completely useless and we ought to redo it. Second, periodically people in
the newsgroup have complained about how it's nearly impossible to figure
out the important--possibly crucial--armor attribute of magic cancellation.
Wearing a cloak greatly increases characters' survival rates, but beyond
that, magic cancellation is just spoiler fodder.
This doesn't do much about Protection other than to change "you are
protected" into "you have a <small,moderate,&c> defense bonus" similar to
how the attributes conferred by rings of increase damage and increase
accuracy are handled. For magic cancellation, it adds new feedback:
You are protected. -- mc factor 3
You are guarded. -- mc factor 2
You are warded. -- mc factor 1
(with no extra feedback for mc factor 0, the normal naked state. The mc 3
case might cause some confusion over the changed meaning of a previously
existing item, but I think it'll be ok and not need re-wording.)
nethack.rankin