Introduce a new set of functions to manage delayed killers in the trunk, used
in addressing the various reports of delayed killer confusion. Since existing
delayed killers are related to player properties, the delayed killers are
keyed by uprop indexes. I did this to avoid adding yet another set of
similar identifiers.
- the new delayed_killer() is used for stoning, sliming, sickness, and
delayed self-genocide while polymorphed. Some other timed events don't
use it (and didn't use the old delayed_killer variable) because they
use a fixed message when the timeout occurs.
- A new data structure, struct kinfo, is used to track both delayed and
immediate killers. This encapsulates all the info involved with
identifying a killer. The structure contains a buffer, which subsumes the
old killer_buf and several other buffers that didn't/couldn't use killer_buf.
- the killer list is saved and restored as part of the game state.
- the special case of usick_cause was removed and a delayed killer list
entry is now used in its place
- common code dealing with (un)sliming is moved to a new make_slimed function
- attempted to update all make dependencies for new end.c -> lev.h
dependency, sorry if I messed any up
+ Separate the two uses of flags.soundok.
+ Player-settable option is now called "acoustics".
+ Deafness is now handled as a full-fledged attribute.
+ Check for deafness in You_hear(), rather than caller.
+ Check for deafness in caller, rather than verbalize(),
because gods can speak to characters in spite of deafness.
+ Since changes are being made to prop.h, reorder it to the
same order as youprop.h and enlightenment.
There are still some extraneous checks and missing checks
for deafness, which will be followed up in a future patch.
Because of the size of this patch and its savefile incompatibilities,
it is only being applied to the trunk code. Portions of this patch
were written by Michael Allison.
Fix the reported bug of problems after casting stone-to-flesh spell
on self while wielding a statue. Pointers for worn items weren't kept in
sync and various potential symptoms could occur (most easily visible one
being that ')' falsely reported the no longer existing statue as still
wielded; report stated that one crash was observed). This bug predates
3.4.2 and was probably present ever since stone-to-flesh got introduced.
It makes sense that if you cannot normally move to a location containing a
boulder, dismounting there should be avoided if possible. It seems
that it should be possible to land there if there's no other choice.
Perhaps doing so should result in damage, but that's not in this patch.
<Someone> pointed out the inappropriate appearance of the 3.4.2 message when
fog clouds have you engulfed if you happen to be polymorphed into an aquatic
creature. It does seem that a fog cloud should not cause added damage to
amphibious creatures, which includes breathless (but non-flaming) monsters.
I also thought another message was more appropriate for flaming creatures
(see on_fire()), and added a special case for that.
gulpum was missing symmetric code and I added it there too.
This change adds a new flaming() macro and uses it in several places
where the list of flaming monsters was tested. on_fire() didn't list
salamanders as already being on fire, but should have. A couple other
cases were not updated to include flaming sphere.
While wearing the Eyes of the Overworld, one could use a hook or pole thru
walls. The bug report thought they should work past a boulder, but I
disagree, given a pole or hook's rigid nature, and did not special case that.
couldsee() is not affected by the Eyes, so use that after checking cansee().
Incorporate various killer message grammar fixes suggested by <Someone>.
Mostly these deal with using the proper killer_format and prefix ("the" or
no "the") for unique and type_is_pname monsters, or death to to eating
their corpses.
One case is handled by a general fix to name_to_mon to allow it to deal
with "Croesus' corpse".
The pre-3.4.1 topten behavior for "starved to death" messages is also restored.
Some changes for standard C platforms, to avoid declaring errno explictly.
Such platforms should declare errno in errno.h, which is already included
in the files in question.
The choice was to avoid one of the two sellobj() calls in in_container.
Since I liked the message ordering "put gold into... credit" better than
"credit... put gold into", the code now avoids the 1st sellobj call for coins.
Pat Rankin wrote:
> collect them all into some new struct and
> save that separately rather than jamming more non-option stuff
> into struct flags.
This patch:
- collects all context/tracking related fields from flags
into a new structure called "context."
It also adds the following to the new structure:
- stethoscope turn support
- victual support
- tin support
This is an initial round of SAFERHANGUP hangup changes. It introduces
SAFERHANGUP, provides the core framework, and enables it for UNIX.
Window-port changes are provided for win/tty, win/X11 and win/gnome. Qt
changes should be forthcoming after having Warwick look at them.
window.doc is updated so windowport maintainers have an clue what needs to
be done to support SAFERHANGUP.
This patch introduces a change to yname() and Yname2() that avoids the
possessive "your" for the hero's normal, fully identified artifacts.
Quest artifacts still get the possessive, as do all other objects and all
objects not in the hero's possession. shk_your()/Shk_Your() are used in
many places with a specific, generalized name for the object, so I didn't
introduce the artifact behavior there, although I did change them to append
a space, which simplified some other code. Through added use of yname(),
there may be some places that used to just say "corpse" that will now be more
descriptive via yname()'s use of cxname(). I'm sure <Someone> will point
out any such places that are too onerous, although nothing obviously is.
I took the opportunity to inspect many uses of "your" and even Your(). Two
new functions are also introduced, yobjnam() and Yobjnam2(), which work
like aobjnam() and yname() combined, because I found that many uses of
aobjnam() were preceeded by "your" and I couldn't generally provide the
desired behavior for artifacts (or future artifacts) without a combined
function. In some cases, this change allowed better sharing of code.
rust_dmg() still takes a string as input which is sometimes initialized
from xname() and often prepends "your" to it. Currently, this isn't a
problem since there currently are no normal, armor artifacts. If/when any
are introduced, rust_dmg() will need to be addressed.
The patch is for the trunk only. A lot of research was required and I
didn't feel the upside was there for repeating it in the 3.4.3 branch.
<Someone> wrote:
>> You're equally unlikely to be wishing for spellbooks by colour,
>> but I note that 'grey' for 'gray' only works for dragonscale and
>> stones, not the spellbook description.
>>
> I've just noticed that the fix for this only works for 'grey
> spellbook', not 'grey spell book'; 'spell book' works for wishing
> in other contexts, so it probably ought to here :-)
> Would it be possible to make autodig also dig downward
> when I press '>' while wielding an pick-axe? When digging for gold,
> after casting detect objects, this would be convenient for getting
> to buried gold and gems.
> [<Someone>]
> When I enter a desacrated temple, sometimes an enormous ghost
> appears next to me:
> You have an eerie feeling... An enormous ghost appears next to
> you!
> You are frightened to death, and unable to move.
> You regain your composure. When I don't have telepathy, and don a
> blindfold first, I get the same messages:
> You are now wearing a blindfold. You can't see any more.
> You have an eerie feeling... An enormous ghost appears next to
> you!
> You are frightened to death, and unable to move.
> You regain your composure. Why does the ghost scare me if I
> cannot even see it? How do I notice it appear?
> [<Someone>]
A while back, I delayed applying this patch after a discussion about
quivering coins, because I didn't want to change the behavior of GOLDOBJ
vs non-GOLDOBJ games. I'm tired of seeing this diff in my tree, and I
recall there was some sentiment that I should have checked it in, so I'm
adding the feature in the trunk.
<email deleted> wrote:
> If more monsters fall through a trap door than can fit on the
> level below, when you go down the stairs, you get the following
> message:
> "Program in disorder - perhaps you'd better #quit.
> rloc(): couldn't relocate monster"
> This message seems to appear once for every monster-too-many that
> fell through the hole. I originally found this while
> intentionally completely filling a level with black puddings
> (there was a trap door I didn't know about). I also confirmed it
> in a wiz-mode test using gremlins and water.
[confirmed: moveloop -> deferred_goto -> goto_level ->
losedogs -> mon_arrive -> rloc -> impossible]
This patch:
- causes rloc() to return TRUE if successful,
or FALSE if it wasn't.
- adds code to mon_arrive() in dog.c to deal with
the failed rloc()
- allows the x,y parameters to mkcorpstat() to
be 0,0 in order to trigger random placement of the
corpse on the level
- if you define DEBUG_MIGRATING_MONS when you build cmd.c
then you'll have a debug-mode command #migratemons to
store the number of random monsters that you specify
on the migrating monsters chain.
Quoting the buglist: "If shk.c does get modified, I'd
like to see a call to rouse_shk() added at the start of rob_shop().
If the shk wakes up for buying and selling, he ought to wake up for
robbery--even when it's covered by the customer's credit--too."
A recent report noted that if you are invisible, teleport into a shop,
steal something, teleport out, and then return, the shopkeeper will become
pacified. This is because the pacification code occurred even if the
shopkeeper already knew your name, as long as the "Welcome" message had not
yet occurred. Implement <Someone>'s proposed fix: Before pacifying, either
the visitct must be zero (as per old code) or the customer name must
already be known. And, of course, the customer name must differ from the
current setting. This skips the pacification code in those situations
where the shopkeeper learned your name but was not happy about it (which is
what visitct > 0 implies, at least initially).
This also deals with an older bug report where you attack a shopkeeper
while outside the shop and then later enter the shop while the shopkeeper
is in it. hot_pursuit() sets the customer name, and the new check avoids
pacifying the shopkeeper for the same reason as noted above.
Described in the newsgroup a while back and recently reported: if
you had reflection and were invisible and had esp and were blind, Medusa
would turn herself to stone by looking at you. When you're invisible,
she shouldn't be able to see your source of reflection so shouldn't be
affected by the gaze; that's how things work when you aren't blind but
the relevant code was being skipped when you are.
Now esp is irrelevant for this and she'll see her reflected gaze
only when she can see you, regardless of whether you see it happen.
remove_rooms() was trying to be clever and truncate the maximum room bounds
in partially overlapping rooms. In the process, it would truncate the
bounds of L shaped rooms incorrectly, leaving some locations outside the
bounds with the roomno field set. Since the maximum bounds really do not
have to actually match the largest extent of the room in the case of
irregular rooms, it was easiest to just remove the code that was performing
the incorrect truncation. Due to the way remove_room() is coded, this
could result in shopkeeper messages (or, less likely, priest messages,
although that has not been reported yet) occuring for locations to the
right (or the upper/lower right corner) of the MAP on the Bustling Town level.
> NetHack feedback form submitted by
> <email deleted>
> on Tuesday, September 9, 2003 at 06:41:34
> Hi, Just thought I'd point out a sort of inappropriate word
> choice or typo that I came across in Juiblex's Swamp. I got this
> message, after pushing a boulder into the swamp: There is a large
> splash as the boulder falls into the moat. Obviously it's a swamp
> and not a moat so that sounds a bit wrong. It says the same sort
> of thing when I #dip a scroll in the swamp as well.
<Someone> submitted the following bug report:
> An object and a pit are occupying the same square. I try to kick
> the object out of the square, but "You can't kick something
> that's in a pit!"
>
> I step into the square and escape the pit, but I can pick up the
> object, so maybe it's not in the pit after all.
>
This patch does *not* address this part of the bug report:
> If it's in the pit and it's a cockatrice corpse, should I die
> from landing on it when I fall into the pit?
Bones loading was only checking to see if a
monster was marked extinct, it wasn't adding
up the born count of a species in the current
game with the number of that species on the
bones level being loaded. That made it possible
to exceed the correct number of nazgul and
erinys via bones.
This adds a common routine called propagate()
that makemon() and restmonchn(ghostly) share,
for incrementing the born count and checking for
extinction, etc.
When a bones level is loaded, restmonchn()
will flag an illegal monster (duplicated unique,
or too many of a species) by setting the
individual monster's mhpmax to the cookie
value DEFUNCT_MONSTER. Before getbones() finishes
loading the bones level, it will purge those
monsters from the chain.
Although the overlay stuff is destined to be
removed someday, this patch just makes the
use of STATIC_DCL, STATIC_OVL consistent
in the trunk.
[As a side pointless experiment, I was able
to build a working 8086 port of 3.4.2 after
this change that worked correctly in limited
testing right up until it came time to enter
Ft. Ludios., where it couldn't allocated the
required amount of memory.]
<Someone> forwarded from rgrn that a monster using Stormbringer would
lose hp when hitting the player. The sign of the "gain" was reversed due
to subtracting the difference in the wrong order.
- Guidebook typo
- wizard mode prompt
[...]
> 2/3) In Guidebook* the lines subkeyval (Win32 tty NetHackonly).
> May be used to alter the value of should read subkeyval (Win32
> tty NetHack only). May be used to alter the value of
>
> 3/3) I miss a hint for the new wizmode feature levelteleport by
> menu. Neither wizhelp nor the dialog tell you about it. Maybe if
> (++trycnt == 2) Strcat(qbuf, " [type a number or ?]"); in
> teleport.c:589 could provide a hint.
>
> <Someone>
Prevent succubi from being fully restored via cycles of petrifying
and reviving. It wasn't just a matter of saving traits; cancellation is
one of the monster traits which is explicitly reset when a monster gets
revived. I think that probably makes sense, but this will override it
for succubi and incubi to prevent abuse; if they were cancelled at time
of petrification they'll remain cancelled when reanimated. Likewise for
nymphs; even though the abuse facter isn't present, the cancel effect is
pretty similar for them so keep revivals similar too.
This saves monster traits for every monster that gets turned into a
statue. Unlike with corpses there's no stacking involved to make players
notice that each has become unique, so all such statues might as well all
reanimate just like they were instead of as new replacment monsters.
Make a sleeping or paralyzed shopkeeper wake up if you drop something
he's interested in buying (covers the recently reported case where dropping
gold failed to add credit, but picking it back up increased shop dept) or
if you use the 'p'ay command while owing money. Sleeping shopkeeper is not
affected if you drop something he doesn't care about, or use 'p'ay when
there is no debt, or pick up shop goods (latter case is handled normally--
you'll owe money for the item even though the shk remains asleep).
This makes shopping become a little easier--you aren't stuck waiting
for the shopkeeper to wake up if you actually want to pay for something--
in the rare case where the shopkeeper has been put to sleep, but it's an
awful lot simpler than any other reasonable way I could think of to deal
with the [lack of] credit problem.
This makes the snoring message handling moot--it no longer exists.
(It wasn't very reasonable to begin with, because the program can't tell
whether mon->mfrozen is for timed sleep or timed paralysis so avoided
giving that message for temporary sleep. There ought to be two separate
counters; probing is another case where vague messages are given because
the program can't tell the reason why a monster can't move.)
