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.)
From a bug report, specifying role and race
along with invalid alignment for that role/race combination resulted in a
prompt of "pick the alignment of your chaotic human Valkyrie". This fixes
that particular problem, but the role selection code is incomprehensible
and I don't have a lot of confidence about whether other combinations have
similar trouble.
This also fixes an obvious typo in ok_align(). Unfortunately I can't
figure out what to do with the if-then-else block in root_plselection_prompt
which has identical code for its `then' and `else' halves (in the alignment
code that the new ok_align() test skips).
From a bug report, monsters with the wait
strategy (described as "meditating" by stethoscope probing) could be
affected by music but left meditating. Various wake up attempts shared
the same situation. Finish waiting if the monster would have been woken
(or pacified). I didn't search for places that diddle the msleeping bit
directly instead of calling one of the assorted wake() routines.
A fair bit of this is making usage of DEADMONSTER() be consistent.
Sooner or later there'll be another monster movement overhaul and those
if (DEADMONSTER(mon)) continue;
statements will all go away. (Probably just wishful thinking.)
When high priests have their affiliation suppressed to avoid giving
away which altar is which on the Astral level, the name formatting also
bypasses the code that converts "priest" into "priestess" for females.
(The bug report was about Moloch's high priestess; the occupant of the
Sanctum's temple gets similar handling to those on Astral.)
Also a tidbit for a change made a couple of days ago. Avoid using
"Manlobbi the invisible shopkeeper" or "Asidonhopo the newt" in the message
given when a shk refuses an attempt to be renamed via the 'C' command.
From a bug report, the 'C' command wasn't reporting that
"<shopkeeper> doesn't like being called names" even though the user's
supplied name was ineffective. Same thing for temple priests and other
minion monsters; the name was accepted but didn't do anything. Make such
monsters reject new names.
Fix a bug described in the slash'em bugs page at Sourceforge. When
attributes are undergoing adjustment (from drinking a potion of gain
ability, for instance), don't display "you feel wise" or "you feel weak"
messages if worn equipment is keeping the relevant attribute at some point
below max or above min and the current value doesn't actually change.
The old logic just checked whether you were at max or min and assumed that
when not, the value would be changing. Now it checks whether the value
actually did change. But it doesn't intercept attempts to go over max or
under min at the same point any more; I hope it hasn't introduced any new
bugs in the process.
Add a patch attached to one of the bug reports sent by <email deleted>
which prevents shopkeepers who have been polymorphed into animals from
speaking. Some messages are altered so that the player gets informed about
shop interactions without it seeming to be spoken by the shk, other messages
are suppressed outright. I cleaned it up a bit (mostly formatting, but the
``getcad'' section seemed to have a logic error--using goto to jump into
the middle of an if-then-else is evil...) and implemented a TODO comment he
added (to use mbodypart() when second shopkeeper at end of game shakes his
head; also, skip that phrase if shk is in headless form--futility while
attempting to test this led to discovery of the misplaced parenthesis bug).
Fix something I accidentally broke nearly three years ago (post 3.4.2,
so the bug appeared in 3.4.3). A misplaced closing parenthesis caused an
in-sight check to always fail, so the "<shk> looks at your corpse, shakes
his head, and sighs" message when game ends would never occur. That
situation is extremely rare anyway; it only happens after some other shk
has taken the hero's possessions.
Add the capability of sorting the entire spellbook by various criteria,
augmenting the existing ability to swap pairs of spells. In the menu that's
put up for the '+' command, add a non-spell entry after the last known spell
+ - [sort spells]
Selecting that brings up a new menu
View known spells list sorted
a + by casting letter
b - alphabetically
c - by level, low to high
d - by level, high to low
e - by skill group, alphabetized within each group
f - by skill group, low to high level within group
g - by skill group, high to low level within group
h - maintain current ordering
z - reassign casting letters to retain current order
'a' corresponds to the normal ordering; 'b' through 'g' cause the order
to change, but during the current invocation of the '+' command only.
(Entry 'h' is a no-op, something aside from ESC to get out without doing
anything. 'a' is only a no-op if you haven't picked any of 'b' through
'g' yet.) After making a choice, you're taken back to the '+' command to
view the spells in the requested order. And once back there, you can pick
'+' again to come back to this menu, where picking 'z' will cause casting
letters to be shuffled such that present display order becomes the actual
spellbook order. Newly learned spells get appended to the end as usual;
the most recent sorting order isn't sticky even if finished off with 'z'.
No doubt seeing it in action will be clearer than this description.
This also updates the Guidebook to mention the spell retention field added
to the '+' menu some weeks back.
When the hero receives the quest artifact "got it" message, set the
artifact's dknown bit in case the hero is blinded. That message describes
the object by name, effectively the same as seeing it up close. (This
would have prevented the "now wearing an Eyes of the Overworld" grammar bug
for monks but not for non-monks, so the previous fix is still necessary.)
Putting on the Eyes while blind causes sight to be regained, which in
turn causes xname() to set the dknown bit and start using the previously
unseen object's name. But obj_is_pname() was being called before xname in
the "you are now wearing ..." message, while dknown was still clear. So
obj_is_pname thought the name was being suppressed and returned false,
resulting in "an Eyes" instead of "the Eyes". Fix is to call xname first.
This patch by <email deleted> was released
when 3.4.1 was current and has been incorporated into slash'em. It is
extremely useful while using ranged weapons. When both autopickup and
pickup_thrown are enabled, walking across previously thrown objects will
pick them up even if they don't match the current pickup_types list.
[See cvs log for patchlevel.h for longer description.]
This patch by <email deleted> was released
when 3.4.1 was current and has been incorporated into slash'em. It is
extremely useful while using ranged weapons. When both autopickup and
pickup_thrown are enabled, walking across previously thrown objects will
pick them up even if they don't match the current pickup_types list.
(Autopickup exceptions weren't around when the patch was first developed
and while those can be used for this purpose if you're willing to name
every object prior to throwing it, pickup_thrown is much more convenient.
Especially when you run out of weapons and resort to throwing pick-axes,
unicorn horns, and spare suits of banded mail at that floating eye who
rudely refuses to die.) If you drop a previously thrown object (after
getting it back into your inventory again, of course), its was_thrown bit
will be clear and subsequent walking over it behaves in the regular
autopickup manner. There's no special stacking handling; if a thrown
object lands on a compatable object and they stack, the combined stack is
subject to pickup_thrown handling.
The original patch updated makedefs to add an entry for pickup_thrown
patch to the options list displayed by #version; I've left that out. It
also cleared the was_thrown bit in the pickup code, resulting in being
sticky for boomerangs and Mjollnir (where throwing, catching, and then
dropping those would result in behaving as if they had most recently been
thrown rather than dropped). I've moved that to the add-to-inventory code
instead to fix this. The original patch also put the pickup_thrown bit
into iflags instead of flags in order to avoid invalidating save files;
I've moved it to flags where it belongs and added a patchlevel.h update.
I've also reworded the Guidebook entries slightly. [The original patch
can be obtained from <Someone>'s "NetHack Patch Database" at
http://bilious.homelinux.org/ under the "browse" heading. I didn't hang
on the exact URL; sorry.]
I think objects stolen from the hero should have their was_thrown bit
set (or else add a new was_stolen bit, which seems like overkill) so that
recovering stolen objects will become simpler after the thief has been
tracked down and dealt with, but I haven't done that here.
The code to have Izchak recognize the Candelabrum of Invocation
instead of just being uninterested in an item not stocked in his shop was
being skipped when the character is hallucinating. Make it work for any
lighting store (slash'em sometimes has another candle shop, run by a
randomly named shopkeeper), and make it recogize Izchak even when
hallucinating. Also, have him give a message about the need for 7 candles
if the candelabrum doesn't already have them attached.
Fix the bug From a bug report.alt.org server, where killing a monster by closing the
castle drawbridge resulted in a panic after the dead monster's possessions
were dropped into the moat and a potion of acid exploded in the process.
water_damage() deleted the object but had no way to tell flooreffects()
that it was gone, so flooreffects() couldn't tell its own caller not to
place and stack the object. After that, a chunk of freed memory became
part of the floor objects chain and eventually triggered a panic which
tried to make a save file but whose reason didn't get logged properly.
This fix should work for both DLB and non-DLB without forcing binary
mode for the latter. And it should continue to work even if we later
decide to force that mode (which I think we should do...). Use actual
file positions to calculate the size of the true and false sections,
rather than counting the bytes of each rumor (that counting has been left
in place but it gets overridden now.) Those two sizes will be bigger on
platforms which use CR+LF line ends and maintain dat/rumors as non-DLB
text file. But due to the way that nethack uses the sizes, such size
differences don't matter.
The branch variant shouldn't need any corresponding fix. It uses
the counting method when the output is binary, where the accumulated
value is accurate, and the check end-of-file shortcut when using text,
which should not be affected by stdio converting CR+LF into \n for text
input and back to CR+LF again for text output. (The original bug was due
to starting out with the EOF shortcut when input had CR+LF line ends, but
then writing less data due to binary output keeping just LF instead of
putting CR back.)
I've forgotten who pointed this out recently, but the hero was having
wisdom exercized (if true rumor chosen) or abused (for false one) whenever
level creation made a random floor engraving which used a rumor for its text.
To fix the gibberish rumor observed by at least a couple of players on
Windows (where if rumors.tru had <cr><lf> line ends and DLB was defined,
makedefs built a file that caused nethack to end up in the wrong place when
it reached EOF and tried to jump back to the first false rumor), change
the way that makedefs builds the rumors file. It now will collect more
information about the true and false rumors. Instead of one hex value on
the second line, there are nine values (three groups of three).
1,2,3;4,5,6;7,8,9
1 = number of true rumors; not previously collected and not currently used
2 = size in bytes for all true rumors (in decimal, as is #1)
3 = offset to first true rumor (in hexadecimal; not previously collected)
4,5,6 = same as 1,2,3 but for the false rumors section
7,8 = always 0 (imaginary third section has no entries, no size)
9 = offset to end-of-file (could be used for sanity checks; currently isn't)
Adding #2 with #3 yields #6; adding #5 with #6 yields #9. The old format's
lone entry was the same as the new format's #6. #2, #3, and #5 are values
which nethack was previously calculating on the fly after opening the file.
This also extends rumor_check() a little bit (displays the last rumor
for both sections in addition to the first), but I think it can probably
now be demoted to ``#if 0'' and removed from the extended commands list.
Axes can't dig through the floor, but attempting to dig down with one
shouldn't just "scratch the floor" if there is an armed land mine present.
Have it set off a land mine or bear trap, in addition to the possibility
of chopping your way out of being stuck in a bear trap (a recent change).
From a bug report, a steed hit by disintegration
breath survived via life-saving, but the program was confused about whether
the hero could still ride and issued some impossible warnings. The code
to disintegrate a monster's inventory didn't bother to unwear worn items as
it destroyed them, presumeably assuming that the monster was sure to die,
so steed was left with a flag bit set claiming it was saddled even though
the saddle was gone. This fixes that, and the rider will end up being
dismounted as the saddle gets destroyed, regardless of whether the steed
ultimately survives. [Since the steed is still present at the time of
dismounting, the hero will get bumped to some other location, possibly to
the next spot about to be hit by the same black dragon breath attack which
just vaporized the steed. That's suboptimal, to put it mildly....]
I couldn't test the circumstances of the original report. Post-3.4.3,
ki-rin has been marked no-hands and is no longer capable of wearing armor
or amulets. I looked to see whether any other potential steed could wear
an amulet of life-saving and couldn't find one. But the original bug also
applied to conferred properties of special armor worn by non-steed monsters
too, so the fix was needed anyway.
The branch and trunk patches are different. For the trunk, I moved a
big chunk of code out of buzz() into a seperate routine. That actual fix
is the same in both variants.
Move part of the recent "munstone fixes" patch to the branch code
since one of those fixes prevents accessing freed memory. The part that
lets monsters eat tins of lizard meat or tins of acidic monsters in order
to get the same benefit as the corresponding corpse has been left out.
The revised newmail() wouldn't compile (Strncpy doesn't exist, `buf'
was an array of pointers rather than of char). Simplify it substantially,
and adjust the one caller (vms) that relied on the old convoluted bit.
From a bug report, a monster who eats a lizard
corpse in order to cure confusion was treated the same as one who did so
to cure petrification, losing intrinsic speed in the process. In the same
report by <l>, monsters wouldn't eat lizard corpses to cure being stunned,
and those who ate them for another reason weren't cured of stunning, even
though the hero gets that benefit. While fixing those, I added some code
to let monsters who are carrying tins of lizard or acidic monster use them
if they're also carrying a tin opener, dagger, or knife. I don't think
any monsters except for nymphs are willing to pick up tins, so it won't
have much effect. It now works for nymphs though.
Examining the code while testing showed that mon_consume_unstone()
has been accessing the potion (acid) or corpse (lizard or acidic monster)
after the item had been used up, so that has been fixed too. I never saw
any detectable problems due to this, but folks using a debugging malloc
implementation which overwrites freed memory may have not been suffering
collateral acid damage or receiving intended confusion cure, or perhaps
did get either or both of those effects when they shouldn't have. Since
it only applied to monsters it wouldn't have been easy to observe.
<Someone> suggested that digging down on a land mine with a pick-axe ought
to set if off. I agree; this implements that and also for bear traps. In
the bear trap case, if you dig down once trapped, you will destroy that
trap explicitly rather than replace it with a pit, so it's now possible to
escape from one without leaving another trap in your wake. Once the bear
trap is gone, further digging there will make a pit as usual. While stuck
in one, digging down poses a modest risk of harming yourself.
|You now wield a pick-axe.
|You start digging downward. A bear trap closes on your foot!
|You start digging downward. You destroy the bear trap with your pick-axe.
|You continue digging downward. You dig a pit in the floor.
|You start digging downward. You dig a hole through the floor.
|You fall through...
[It seems a bit strange that finishing a pit discards all digging context,
so that resuming within the pit in order to make a hole "starts" digging
rather than "continues" it.]
Digging down with a wand or spell will disarm these two types of traps
and then leave the corresponding object (which may or may not fall through
the resulting hole, like any other object there). Digging to the side via
magic while trapped in a pit will also disarm such traps when it encounters
them. (When not in a pit, a digging beam which simply passes over an armed
bear trap or land mine won't have any effect on the trap.) Digging to the
side via tool behaves somewhat oddly ("no room for the rubble"?) and will
probably need some tweaking before eventual release; at present it doesn't
reach adjacent traps so didn't need any land mine or bear trap handling.
I put the fixes entry in the new features section.
<Someone> reported that thitu() was adding d20 damage for silver object
hitting silver-hating hero even though all the callers were using dmgval()
which also does that, resulting in doubled silver bonus/penalty. This
fixes that (including for boomerangs thrown by player, which weren't using
dmgval(), to handle a hyptothetical silver boomerang). While testing it,
I noticed that there was no "the silver sears your flesh" message when a
monster hit you with a wielded silver weapon, so this fixes that too.
(How did we miss that? And how did <Someone>? :-)
From a bug report, moving into a trap
during a failed untrap attempt didn't autopickup any objects there or
report about objects which aren't picked up. Although that appears to have
been intentional, change move_into_trap() to behave more like a regular
move. (I wrote this bit of code and don't remember whether the no pickup
aspect was deliberate; I suspect it might have been to avoid the redundant
"there is a trap here" message which you get when pickup checking is done
but not everything on the spot gets picked up. This patch suppresses that
message.)
Move some internals-related code out of port-specific main so that
it isn't duplicated a bunch of times. One minor side-effect of this
change is that if you auto-pickup something at the very start of a game,
it will happen after any full moon/new moon/Friday 13th message rather
than before. There's a second change for some: the shared main() used
by several of the micro ports had a small difference in game play--if you
saved a game while on an engraving, it would automatically be read when
you resume--that will now occur for everybody [Elbereth weenies rejoice!].
pcmain() was also calling update_inventory() at start of play. That's
unnecessary for new games, where inventory initialization triggers a call
to it for each item added to your pack; but I wasn't sure about restored
games, so everybody gets it there now.
The Mac and BeOS ports evidently haven't been touched it some time;
they still referenced flags.move which got replaced by context.move quite
a while back. The Windows GUI code has a declaration for mswin_moveloop()
which appears to be non-existant, but I left it alone. I assume that the
Qt interface uses the existing main() routines; at least I couldn't find
any start of game code specific to it. vmsmain's revised main() is the
only one which has been tested.
I've been using this for a while; it is occasionally handy. #terrain
is a new wizard mode command which brings up a text display where the map
topology is revealed, similar to the obscure #wmode command but showing
different information. Also, #wmode has been tweaked a little so as to
actually overlay the tty-mode map exactly, rather than being off by one
line and one column. (That shouldn't really matter for other windowing
schemes where the map and a text rendition of it aren't very likely to
have a given location be displayed at the exact same screen position.)
The line of formatted flags info below the terrain display probably
belongs in a separate debugging command altogether where it wouldn't have
to be displayed in such a terse fashion.
Something I encountered while playing slash'em a while back, but
relevant to nethack: "Its orcish spears shatter from the force of your
blow!". I was using a two-handed weapon (at skilled or expert level) to
fight an invisible monster which was wielding a stack of multiple spears
(slash'em gives them out in groups of 3 for monsters' starting inventory).
After killing it, I found 2 orcish spears along with an invisible corpse
of somebody-or-other the Kobold King. The message suggested that the
whole spear stack had been destroyed (and the weapon shattering code in
hmon_hitmon() clearly expects that to be the case), but only one of them
had actually gotten used up.
I can't recall whether "shatter" was actually given as singular or
plural at the time; nethack handles that aspect correctly. Only object
destruction needed tweaking.
From a bug report, making engulf time longer for high AC
didn't make sense for non-digestion attacks: taking longer to die from
being digested (high AC lets you last longer there) is much different from
being stuck inside a vortex or elemental and suffering extra buffettings
or whatever. Calculate swallow time differently for non-digestion than
for digestion. (The adjustment based around level 25 doesn't make much
sense either, but I left that in.)
If you survive total digestion via life saving, you get a message
about the monster not liking your taste. I don't think that's appropriate,
but haven't tried to figure out how to fix it.
Responding with '?' to the "what level?" prompt when using ^V in
wizard mode brings up a menu of special level destinations that lets you
move across dungeon branches. But getting in and out of Fort Ludios
didn't work, and jumping to the endgame forced you to arrive on the Plane
of Earth. Now Fort Ludios will not be selectable in the menu until after
the portal ordinarily used to reach it has been created (so you'll need a
level between Bigroom and Medusa with a vault on it to be created before
you can bypass the magic portal and jump directly to the Fort), and you
can go directly to any of the elemental planes, including Astral, without
stopping at Earth first (the Wizard will be there to greet you, whichever
level you pick). Also, this limits the menu to endgame entries once you
are in the endgame. (Previously, picking a non-endgame level would yield
"you can't get there from here"; you can still get that, if you really
want to see it for some reason, by giving a destination level number
outside the range of -1 to -5 instead of using the menu.)
I hadn't realized that this feature has been around since 3.4.2 until
I couldn't find any new feature entry for in the current fixes file....
While testing some pending teleport changes, I was baffled by having
my adjacent pet sometimes vanish when accompanying me on a level teleport.
Tracing through parts of execution: keepdogs() kept it; losedogs() called
mon_arrive() which called place_monster() for it, but then right after that
kill_genocided_monsters() removed it. Turns out that `kill_cham' was left
uninitialized for the first iteration through the fmon loop (and pet had
always just been inserted as first entry of the fmon list).
No fixes entry; this revises a post-3.4.3 revision.
From a bug report: when creating a
level, anthole rooms can be generated even when no ants are left, unlike
beehives which get suppressed once killer bees are gone. Also, if some
ants are available but the type chosen for the current level isn't (in his
case, soldier ants had been genocided), the anthole was filled will random
monsters instead of picking another type of ant. This fixes both issues.
Random monsters will only occur if the last type of ant gets used up while
filling an anthole that was started when some ants were available, same as
how monster generation for beehives and barracks works.
The recently revised scroll of charging left out making it become
discovered. When fixing that I decided to remove all the early returns
from seffects(), so that its logic is easier--at least for me--to follow.
I think the return values of seffects(), chwepon(), and the various
xxx_detect() routines are backwards (True denotes failure, False indicates
success), but they're all consistent with each other so I left those alone.
Remove a couple of false comments about Luck, and an unreachable
switch case based upon them. I don't know if the comment in you.h was ever
true, but it was false by the time Kevin brought across assorted changes
from slash'em however many years ago. Full moon does not change the range
of possible Luck values, and ``rn2((Luck + 6) >> 1)'' produces a value
between 0 and 8 for prayer result, never 9. Natural luck is always within
the range of -10 to +10, and extra luck from carrying blessed or cursed
luckstone can add or subtract another 3. Full moon and Friday the 13th
change the equilibrium point for luck timeout but do not change the overall
range of possible values, which remains at -13 to +13.
On the first move of the game and the first move after each level
change, the "previous position's coordinates" <u.ux0, u.uy0> had bogus
values: zero at start, last location on old level otherwise. They're
never used to undo a level change, so the last location on the old level
isn't interesting. Set them to match current location, as if you'd just
rested on the new spot. I'm not aware of any bugs attributable to this.
Change the description of leather spellbook to leathery. Eating it
does not violate vegan or vegetarian conduct. [By shear coincidence, I got
``Blecch! Rotten paper!'' for it while testing this.]
Between the addition of worm body parts and the phrasing of engulfing/
digesting status, I remembered an oddity with the vanquished monster list:
it shows baby long worms right next to adult long worms; both were defined
as level 8 monsters. It also turns out that babies dealt more damage per
attack than adults; that was counterintuitive, to put it mildly. Boost
long worms from level 8 to 9; drop baby long worms from level 8 to 5, half
rounded up just like the relationship between baby and adult purple worms
(who are levels 8 and 15, respectively). And increase the damage for adult
long worm attack (was 1d4, now 2d4); drop it for baby (was 1d6, now 1d4).
From a bug report, feedback of the form
Status of the fog cloud (neutral): Level 2 HP 5(5) AC 0, engulfed you.
sounds odd. "Engulfing you" seems a little odd as well, since the engulf
has already taken place, but I think it works out better. For symmetry,
replace "swallowed you" by "swallowing you". But that one will never
occur, because all the animals with engulfing attacks will now yield the
more precise and much more significant "digesting you".
The code formatting is strange. Lining up the text parts works out
a lot better than attempting to fit the associated tests within the space
left after the large indentation being used.
My recent patch included a typo in a pline() call which broke compile,
and much worse, was accessing scroll of identify after using it up. Cache
scroll->otyp, scroll->blessed, and scroll->cursed instead of re-re-ordering
the identify scroll/spell code.
Something I noticed during a level change in slash'em:
You hear the sounds of civilization. You fly down the stairs.
The first message ought to follow the second. Our only arrival messages
that are handled via the special level loader occur in the endgame where
travel is by magic portal, and the transit message given for portals is
for entering one rather than exiting at the far side, so this sequencing
problem can't currently be noticed in nethack. But sooner or later there
will be levels reachable by stairs and having entry messages, or there'll
be some feedback added when magic portal transport finishes, and then we'd
get bitten by this.
Tested by adding an arrival message to each of the bigroom variants.
Make a not-very-robust fix for the report from <email deleted> about
being told a scoll disappears as you read it, then for the case of cursed
remove curse being told that the scroll disintegrates. He missed similar
case for scroll of fire erupting into flames after it had disappeared.
This suppresses the "disappears" part of the scroll reading message for
those two cases, but won't be very reliable if other scroll messages
referring to the scroll itself get introduced in the future. [Several
paths through scroll of fire won't report that it burns, and now it doesn't
give the disappears message any more. I don't think that's worth worrying
about; the scroll leaving inventory after burning up is implicit.]
Also cut down on redundant feedback for several scrolls (genocide,
charging, identify, stinking cloud) that start off by informing the player
what they are. That's only needed when the the player doesn't already
know the type of scroll. I've always felt it silly to be told that I've
"found a scroll of genocide" when I'm intentionally reading a known scroll
of genocide. All these types of scroll give a subsequent prompt which
makes them recongizable if you somehow manage to choose the wrong object
when picking the one to read.
Lastly, make spell of identify behave like ordinary uncursed scroll of
identify by default instead of ususally ID'ing multiple items. Now you'll
need to be skilled or better in divination spells skill in order to get the
blessed scroll effect out of it. And give some feedback if the spell is
cast when not carrying any inventory; it was just silently moving on to the
user's next command in that case.
I doubt if many players in nethack ever have pet ghouls (in slash'em
they're the necromancer's starting pet), but if so, provide them with a
portable food source by letting ghouls eat dead eggs in addition to tainted
corpses. Also, let them eat fresher varieties of either when they're about
to starve to death. Treat lizard & lichen corpses as always fresh since
they never become tainted (probably ruining slash'em necromancers' present
pet food of choice, though they'll still be able to eat lizard corspes if
starving).
I set the omnivore flag in their monster definition. Previously they
had been left as non-eaters despite the fact that they need to eat. When
the flag wasn't set, a hero who poly'd into one and then put on an amulet of
unchanging could go a very long time (thousands of turns) before the hunger
imposed by wearing an amulet finally made him/her become hungry. (Same as
with any other truely non-eating monster, so not really a big deal.)
Also, avoid the expression &mons[obj->corpsenm] for objects where the
corpsenm field isn't applicable, in case the default value ever changes from
0 (PM_GIANT_ANT) to NON_PM (-1).
A bit of web searching quickly reveals that Evil Iggy was a unique
monster added to Moria after a player using a character named Iggy refuted
the author's claim that the new version (of that time, early '80s) was
unbeatable. So flag our hallucinatory monster Evil Iggy as a personal name
so it won't get formatted as "the Evil Iggy".
Move NO_SPELL and MAX_SPELL_STUDY from hack.h to spell.h. I didn't
even remember that the latter existed when I put MAX_SPELL_STUDY in the
former recently.
Add a couple of new "spell is almost gone" messages that occur when
casting spells. One matches up with yesterday's change for when you can
re-read a spellbook to reinforce memory of a known spell.
When "too hungry", you can't cast any spells, except detect food so
that you can find something to eat. When "too weak" you couldn't cast any
spells at all; now you can cast restore ability so that you can recover
lost strength. [We still need to come up with a better crowning bonus for
monks than spellbook of restore ability.] I couldn't think of a reasonable
exception for the "can't cast when carrying too much" restriction. If we
can come up with one (levitation?), then remove curse could/should become
an exception for the "no free hands" restriction.
Instead of just marking forgotten spells with an asterisk, add a new
column to the '+' spell menu which gives an estimate of how well the spell
is remembered. Precision of the estimate depends upon the hero's skill in
the category of spell; expert gets the most detail with a low-to-high range
spanning just 2%, such as 19%-20% or 75%-76%; skilled sees 5% ranges; basic
10%, and unskilled the least detail with 25% ranges (ie, one of 1-25, 26-50,
51-75, or 76-100 for percentage of time left available for the spell).
[The tab-separator variant for the menu is untested.]
This fixes an off by one bug for spell retention. It got set to 20000
as intended when a spellbook was read, but then it would be decremented to
19999 before the player had a chance to do anything else, cheating him out
of 1 turn of memory. Spells known at game start last exactly 20000 turns.
Also, adjust the point at which you're allowed to reread a spellbook
and refresh your memory of the spell. When the current spell system was
instituted, that was 10% of the retention period (1000 turns or less left
out of 10000); when retention got doubled to 20000 turns, the relearn point
was left as is. Increasing it to 10% (ie, doubling to 2000) makes it fit
better with the displayed retention percentages. Otherwise expert casters
would be left to guess when they've hit that point (1000 is 5%, falling
within their 5%-6% range, which really indicates (4%+1) to 6%). At 10%,
it's the threshold for the 9-10 range for experts, 5-10 range for skilled,
and 1-10 range for basic so the player can see when it has been reached;
only unskilled, with a bottom range of 1-25, is left to guess. Players
will likely prefer to wait until later, when the spell is nearly expired,
to refresh, but if they're about to abandon their books on the way to the
endgame then being able to re-read sooner is beneficial.
This fixes the monnam() family of functions so that hallucinated
personal names, such as Barney, won't be prefixed by "the". It uses the
same hack as is used for shopkeeper names: single character prefix on
names which warrant some handling other than the default. rndmonnam()
strips that off, so unmodified callers (which is almost all of them...)
retain the same behavior has before.
There are several capitalized names that I have no idea whether need
to be treated as personal names:
Evil Iggy - name, or type of monster named after someone?
Totoro - no clue
Invid - ditto
Vorlon - just guessing that it's a species rather than an individual.
I couldn't remember whether Godzilla was baby Godzilla's mother or father,
so I went with female there. So far, no callers of rndmonnam() care about
gender so it doesn't make any difference. Because of that, I didn't look
though the non-capitalized names to see whether any should be all male or
all female and need one of the other prefix codes.
I've added "were-rabbit" from the Wallace & Gromit movie. The recent
ads for its DVD release reminded me that I was going to add that back when
the movie first came out. I haven't seen it but the creature name fits.
I also fixed Smokey Bear. Smokey the Bear is a common misspelling;
I thought we had fixed that ages ago, back when people still had some clue
as to who in the world he was.
> This makes monsters marginally smarter--independent of their defined
> intelligence levels--by skipping their remaining attacks when the first
> turns out to be targetted at nothing. The exception is for monsters with
> both melee and spell attacks; they'll keep going in case they end up
> choosing a spell which doesn't need a target location. (It's rather
> ironic that the most intelligent monsters are the ones who'll foolishly
> continue swinging at thin air. This could be improved by forcing then to
> skip ahead to their spell attack.)
This implements the improvement for spellcasters. After they make
a wildmiss, they'll skip any further physical attacks but eventually try
their spell. (Titans have multiple physical attacks followed by a spell;
other high-end monsters probably do too.)
Refine last week's change dealing with polymorphing spellbooks: when
a spellbook has faded to blank after multiple readings, randomize its
spestudied value so that it doesn't always polymorph into another blank
book on the first subsequent transformation attempt.
From a bug report... some
special case handling for polymorph of spellbooks never worked as intended.
It's possible to polymorph a spellbook, use it to learn a new spell, and
then repeat as many times as you like unless/until you run out of polymorph
magic or the small chance of "object shuddering" causes it to be destroyed.
Polymorph was incrementing the book's ``number of times read'' field with
the intent that it would fade to blank after being read 3 times (which
turns out to the 4 times since the check is actually for re-reading 3 times
after the first). That didn't work because the spestudied field was ignored
when learning a new spell, only checked when relearning a known spell.
Now it will be checked when learning a new spell, and also the book
tweaking during polymorph is slightly more elaborate. If you happen to
get a blank book during the item selection, it will have a read counter
of 0 and can be re-polymorphed into something readable. But if you get
some other book, its read counter will be set to one greater than than the
original book's (same as before). And then the counter will be checked
to see if it has gone over the limit, in which case the book will be made
blank and its counter will be reset to a random value. Re-polymorphing
that blank book again has 1/4 chance apiece among the following cases
book gets blanked again; goto step 1...
book is non-blank but too faint to read; reading attempt will fail
book can be read normally and then re-read once
book can be read normally and then re-read twice
which is more inline with the intent of the original special case code.
It's actually slightly nastier since you'll occasionally get a book for a
spell you don't know yet but then not be able to learn it from that book.
From a bug report, floating down onto an engraving
due to levitation timeout would yield "You read: <engraving text>" even if
you were asleep at the time. Random teleport while asleep could produce a
similar result. The problem was actually a little bigger: you'd also get
"You see <object> here" if there was an object instead of or in addition to
an engraving.
Reduce verbosity for monsters with multiple attacks who "swing wildly
at you and miss" or "miss your displaced image" due to their confusion or
your invisibility or displacement. It's aggravating to sit through that
three times for claw/claw/bite or swing/swing/kick when those longer
descriptions of why such missing happened guarantee multiple --More--
prompts. (Can't simply use Norep() to deal with this because wildmiss()
varies its messages.)
This makes monsters marginally smarter--independent of their defined
intelligence levels--by skipping their remaining attacks when the first
turns out to be targetted at nothing. The exception is for monsters with
both melee and spell attacks; they'll keep going in case they end up
choosing a spell which doesn't need a target location. (It's rather ironic
that the most intelligent monsters are the ones who'll foolishly continue
swinging at thin air. This could be improved by forcing then to skip ahead
to their spell attack.) Exploding monsters aren't affected because they
don't have multiple attacks. Offhand I can't think of any other situation
where a wild miss on the first of N attacks could still yield a successful
result on any of the other N-1 actions.
Monsters attempting ranged attacks who get multiple shots (due to
multiple weapon attacks per turn rather than to multi-shot volley during
a single attack) will end up conserving ammo when they stop after seeing
that the first shot didn't find a target. Note that trying to attack you
but accidentally attacking some other target isn't affected since that
doesn't yield the wild miss outcome. Intelligent monsters probably ought
to recognize that their attack against you ended up hitting someone else
and refrain from repeating that mistake N-1 more times. Whether feedback
from that ought to carry over to their next turn is not so clear cut.
Noticed recently when a user reported that an unseen monster zapping
an unseen wand caused wand of striking to become discovered. [That was
because the zap also hit a door and the code for the latter didn't check
whether the wand had been seen, and it got fixed a couple of weeks ago.]
When the player zaps wands while the hero is blinded, it was discovering
(for the cases where the effect can be observed without sight) the wand
even though the wand's description was unknown (showed in inventory as
"a wand"). This replaces the calls to makeknown() in zap.c with calls to
new learnwand(), which checks whether the wand description is known; you
no longer discover something you've never seen. Reverse effect has also
been added: if the type of wand has been discovered earlier, zapping an
unseen wand (another of the same type, picked up when blind and zapped
while still blind) will now mark it as seen (to show up in inventory as
"a wand of <whatever>" instead of just a "a wand"). The latter aspect
really ought to be independent of prior discovery, but we currently have
no way to record "we know what this particular item does even though we
don't know what type of item it is yet". [If we add that, it would be
applicable to potions (when operating on stacks) and rings too.]
Minor change: zapping yourself with wand of opening or spell of
knock will remove attached ball&chain rather than give a "chain quivers"
message. Explicitly zapping the chain already did that; if the unlocking
magic works on the chain connected to your leg then it really should also
work on your leg connected to the chain. Zapping unlocking at yourself
probably should also scan inventory to check for carrying locked chests,
but I didn't add that. (If added, then locking magic will need to be
augmented likewise.)
This also fixes <Someone>'s recent complaint: zapping an unknown
wand of teleportation at yourself didn't make it become discovered.
Now it will be, under the same circumstances as when you're riding: if
teleport control causes you to be prompted for destination, or if random
destination moves you more than jumping distance away from your original
position. (The Stunned exception to teleport control, which was missing
in zap_steed, perhaps ought to be moved into the macro definition of
Teleport_control itself so that all code always handles it consistently.)
From a bug report, the placement
of random doors by the code that loads special levels would attempt to
evaluate rn2(0) and either get a divide by zero crash (normal build) or an
impossible warning (DEBUG enabled when compiing rnd.c, done automatically
when BETA is defined). The problem was only noticable for random door in
a 1x1 room; none of our distributed levels specify such a thing so regular
users won't have encountered this bug. It's a one line fix.
Altar placement in temples also had a quirk of a similar nature. It
wouldn't trigger rn2(0) problems but would always place the altar to left
of mid-point in rooms with even width and above the center point in ones
with even height. Now the placement is randomized so that sometimes it'll
be to the right and/or below mid-point in such cases.
This also simplifies a couple other instances of similar expressions
that I spotted.
Cut down on the excessive verbosity generated when entering a temple.
The first time you enter a particular temple (or more accurately, the
temple attended by a particular priest), you still get the three message
sequence
The <priest of foo> intones:
Pilgrim, you enter a sacred place!
You have a strange forbidding feeling...
or
You experience a strange sense of peace.
except that the last one doesn't say "strange" any more. On subsequent
visits to the same temple, you usually won't get the first introductory
message any more, often won't get the second entry one, and sometimes
won't even get the final one, depending upon how much time has elapsed
since the previous entry. The old verbosity could really be infuriating
when attempting to lug corpses to the altar before they spoil. Even
though the messages don't affect the passage of time, it always felt as
if they were slowing you down. And even when you weren't in any hurry,
it required at least one and often 2 or even 3 responses to --More--
depending upon the length of the deity's name and whether some other
message was also delivered on the same turn (fairly common in minetown).
Saving and restoring, or leaving the level and returning, resets
the priest's memory of when the messages were last given, so the next
entry after that behaves similar to the very first. This was initially
intended for cleanup prior to saving bones data, but it seemed reasonable
to have it apply to the current game too. Unattended temples now also
have a 25% chance of not giving any message when entering. That one is
random rather than based on the passage of time since last entry; there's
no priest available to track the latter data.
Cleanup up a couple of priest and minion allocation/conversion bits.
Also, restrict minion naming so that "guardian <foo>" is only applied when
<foo> is an Angel. (That restores old behavior from before a change I made
last October; it prevents the guardian Angel from being recognized while
hallucinating. It probably affects slash'em too, where they have tame
minions besides the astral level's guardian Angel.)
Add an introductory comment for each type of extension. Also move
ANGRY/NOTANGRY shopkeeper macros from old eshk.h out of the common header
and into shk.c so that their use doesn't end up spreading into other code.
Not fixed: entry #9 in the block comment at the top is truncated
mid-sentence.
Replace the fixes entry with one which mentions the magic word "panic".
That'll make it easier to find in the future when looking back for the
nasiest bugs (which I seem to end up doing periodically).
Add new_mname/free_mname functions to make monster name handling be
more like the other extended data and to hide mextra details a bit more.
Add some casts where int and unsigned are being intermixed. Simplify
christen_monst(); it ought to be changed to have type `void' but I wanted
to avoid modifying another ten or so files.
From a bug report: while hero
was blinded, monster zapped him with a not-yet-discovered wand of striking
and the wand type became discovered. The report was slightly off; the
described case is already handled correctly. However, if the zap happened
to hit a door, the wand would incorrectly be made known even when not seen.
From a bug report: dwarvish mattock was
subject to breaking when attempting to force a lock, because it is treated
as a bladed weapon. So is pick-axe; they're both defined as blunt (WHACK
attack mode), but the definition of is_blade() erroneously includes them
since P_PICK_AXE falls between P_DAGGER and P_SABER. That skill should be
renumbered, but I haven't investigated what else might happen when that's
done so this fix uses a special case instead.
I noticed that there was an unnecessary old check for rubber hose;
it's excluded along with whip by the skill > P_LANCE test. When fixing
that up, I realized that the obscure feature of forcing via statue was
broken; it always failed the skill < P_DAGGER test. Also, I took away the
exception for aklys; even though designed as a throwing weapon, it is used
as a club. I wasn't sure about the exception for flail; it is perfectly
capable of bashing things but the code apparently excludes it for use as
a prying implement. Switching its check to P_FLAIL catches grappling hook
along with it.
When looking at name_to_mon() to teach it how to cope with possessive
suffices, I discovered that it already knows how. But while looking at
it, I remembered a newsgroup complaint from a while back by someone who
accidentally committed suicide by attempting to genocide "master mindflayers"
(when he meant "master mind flayers"). name_to_mon() didn't recognize that
misspelling but it did match "master" as a role title. Unfortunately for
the player, his character was a monk; the game allowed him to genocide his
own role and he died. That's kind of harsh for such a likely misspelling.
(I don't think a monk is very likely to ever use "master thief" as a mistake
for "master of thieves", but catch that one too just in case. Conversely,
recognize "master of assassins" as an alternate for "master assassin".)
Also, wishing for "the <something>" strips off "the" and finds (or not)
<something>, but genociding didn't. You could specify "a wolf" to wipe out
all wolves, but "the wolf" yielded "such creatures don't exist", and ^G had
similar unfriendly behavior. This extends name_to_mon() to handle it.
Extend the capabilities of corpse_xname() so that various callers can
be simplified. It can how handle an article prefix, effectively turning it
into corpse_doname() (not quite; still need doname() to see a count when
quantity is more than one, or to see bless/curse state). It can also handle
inclusion of adjectives like "partly eaten" or "bite-covered". For unique
monsters those come out in the form
the Chromatic Dragon's partly eaten corpse
instead of the old
partly eaten Chromatic Dragon corpse
[so wishing probably needs to be taught about potentially finding a monster
name before assorted adjectives such as blessed; also, name_to_mon() needs
to learn how to cope with the possessive suffix].
A sizeable chunk of this patch deals with consolidating some of the
redundant "petrified by a cockatrice corpse" handling. It may be possible
to consolidate all remaining instances together since they're quite similar,
but I didn't think about that until just now and I want to get this patch
over with.
From a bug report, "You have summoned it!" (when human
sacrifice brings a demon which you can't see) is poorly worded, to put it
mildly. I'm sure there are plenty of other places where "it" seems odd,
but this one is now fixed....
From a bug report, amorphous creatures can fit underneath
closed doors but could still be considered too big to fit through diagonal
gaps. Let them and several other shapeless or flexibly shaped critters
squeeze through provided that they pass the not-carrying-too-much check.
From a bug report: the Call command's
prompt is careful not to include "of <deity>" when asking what name to give
a high priest on the Astral level, but the resulting rejection message of
"the <unique monster> doesn't like to be called names" did not, resulting
in feedback of "the high priest of <deity>" and giving away which temple it
is from afar.
These should have been included with a "#dipping from steed" patch
three years ago. I don't know whether I missed them outright, neglected
to cut diffs at the time, or just forgot to apply the diffs to my cvs
directory prior to committing the rest of that patch.
From a bug report, "The leprechuan quickly snatches some
gold from between your feet!" doesn't make much sense when you're riding.
Fix started out simple, but "between" isn't right if you're above the floor,
and "rear hooves" for horse or "rear claws" for dragon didn't sound right
for steed (or poly'd hero), so it got a little more complex. Complicated
even more due to requiring two copies; ick.
A minor side-effect of this change is that somewhat naughty sounding
"The leprechaun quickly snatches some gold from between your rear regions!"
won't occur anymore. :-}
A bug report complained that Izchak is identifiable when the hero is
hallucinating. That's true but it wasn't particular to him; all shop
transactions were giving accurate shk name regardless of hallucination.
This is a quick fix that avoids changing shk message handling: pick some
shk name at random each time one is used. I didn't intend for it to also
force Izchak to use the general chat response instead of his set of special
messages, but that ends up happening due to randomized name not matching
his, so you really can't recognize him when hallucinating anymore.
The almost never seen names now have a chance to come into play....
Forwarded from the newsgroup by Michael: giving a count before '.' to
rest many turns wouldn't be interrupted by having levitation end (despite
autopickup taking place at the time, which is what the thread is about but
not all that relevant to this particular issue). Stopping counted activity
is easy, so that's all I've done. Stopping a timed occupation would be a
lot harder due to message sequencing; I'm not going to attempt it.
Remove several duplicate includes I discovered while reconciling the
vms Makefile. All of these are already being brought in via hack.h so don't
need to be explicitly included after it.
I couldn't find the original depend.awk (which started out on vms) and
didn't feel like attempting to recreate it, so did this the old fashioned
way (grep,&c of src/*.c). I think that all of the various Makefiles need
one or more of these changes. Adding context.h to the hack.h dependencies
and emin.h to monst.{o|obj} are the most significant ones.
nethack.rankin