Unless you kill the monster with one hit, it'll wake up
cranky and make noise - waking up other sleeping monsters.
This was a bit tricky with all the message sequencing; I tested
all the hit/throw/fire/zap combos I could think of, and it took
a while to get things looking right.
Insert the calls to trigger a number of potential soundeffects
into the core.
If no additional soundlib support is integrated into the
build, then the Soundeffect macro (sndprocs.h) expands to nothing:
[#define Soundeffect(seid, vol)
]
If, however, at least one additional soundlib support is integrated
into the build, then the Soundeffect macro gets defined as this
in sndprocs.h:
[#define Soundeffect(seid, vol) \
do { \
if (!Deaf && soundprocs.sound_soundeffect \
&& ((soundprocs.sndcap & SNDCAP_SOUNDEFFECTS) != 0)) \
(*soundprocs.sound_soundeffect)(emptystr, (seid), (vol)); \
} while(0)
]
That macro definition checks for the hero not being Deaf; it checks
to ensure that the active soundlib interface has a non-null
sound_soundeffect() function pointer; and it checks to ensure
that the active soundlib interface has declared that it supports
soundeffects by setting the SNDCAP_SOUNDEFFECTS bit in its sndcap
entry. That just means that the interface routines are prepared to
accept and deal with the calls from the core, whether or not it
actually produces the desired soundeffect.
The previous commit had the up/down test backward. Also the commit
log text described the old behavior incorrectly: zapping down while
hiding-under skipped the top item but zapping up hit the whole pile.
Still not adequately tested.
This should fix the problem of polymorphing or stone-to-fleshing a
pile of multiple boulders and having some underneath ones which get
changed resist and not get changed, producing a pile with one or more
non-boulders above one or more boulders. If that situation arises,
re-stack the pile so that boulders are moved to the top.
This also revises zapping up or down while hiding under something
(if that is even possible; the types of creatures which can hide
under things can't zap wands or cast spells; maybe there are some
exceptions?). Zapping up used to hit only the top item, but zapping
down hit the whole stack. Now up still hits only the top, but down
skips the top and hits the rest.
Caveat: not adquately tested.
If hero zaps self with a wand and the result is fatal, report the
death as "zapped himself with <a wand of sometype>" rather than just
"zapped himself with a wand".
The consolidation of global variables from scattered source
files into decl.c and declared in decl.h was begun in 3.7.0.
Their placement in common files was done for centralized
initialization and potential re-initialization during a
"play again" scenario.
It wasn't really necessary for all of them to be housed in a
single huge structure to meet the "play again" requirement,
and the single huge structure has been a little unwieldy when
it comes to maintenance.
Following this commit, instead of one single extremely large structure
named 'g' to house all of the relocated global variables, they
are distributed into several ga through gz.
To make things easy for the developer, each variable is placed
into the struct corresponding to the starting letter of the variable.
That way, no lookup is required in order to know which struct houses
a particular variable, it is a simple match to the starting letter
for all the centralized global variables.
A global variable named 'amulets', would be found in ga.
ga.amulets
^ ^
A global varable named 'move', would be found in gm.
gm.moves
^ ^
A global variable named 'val_for_n_or_more' would be found in gv.
gv.val_for_n_or_more
^ ^
A global variable named 'youmonst' would be found in gy.
gy.youmonst
^ ^
Instead of using index() macro defined to strchr, use C99 strchr.
Instead of using rindex() macro defined to strrchr, use C99 strrchr.
If you want to try building on a platform that doesn't offer those
two functions, these are available:
define NOT_C99 /* to make some non-C99 code available */
define NEED_INDEX /* to define a macro for index() */
define NEED_RINDX /* to define a macro for rindex() */
Pass the wait-for-response arg when displaying the wishing help text
window. tty, curses, and Qt waited regardless, but X11 honors the
no-wait request. It was showing the text window then letting the
core immediately resume, resulting in reissuing the wish prompt on
top of the help window. Entering a successful wish then dismissed
the prompt but left the help on the screen, possibly obscuring the
map depending on placement.
Pull request #607 by Vivit-R proposed renaming "huge chunk of meat"
to "giant meatball" to better reflect the similarity to meatball.
But an object name that contains a monster name prefix requires extra
work in the wishing code. I considered "huge meatball" which retains
more of the original name but decided to go with "enormous meatball"
becaues it seems more evocative.
Supersedes #607Closes#607
Reported by Umbire:
|You kill SpaceMannSpiff! SpaceMannSpiff puts on a dwarvish cloak.
|SpaceMannSpiff puts on a dwarvish iron helm.
|The seemingly dead SpaceMannSpiff suddenly transforms and rises as
| a Vampire.
This was tough to reproduce but I finally managed it. The issue
text mentions that it was fixed by copperwater in xNetHack with
commit 8c4af50f0aa3e72522f3eb98df039ff25c2a1ea0 to the repository
for that variant. My attempt to cherry-pick that failed--I'm not
even sure whether it should have been expected to work--and some of
the code has been impinged upon by changes, so I ended up applying
the contents of that commit manually.
The commit changes how/when monsters put on new armor rather than
anything directly related to vampires. Circumstances similar to
the example above now yield:
|You kill SpaceMannSpiff!
|The seemingly dead SpaceMannSpiff suddenly transforms and rises as
| a Vampire.
on one turn, then on the next turn the revived vampire produces:
|SpaceMannSpiff puts on a dwarvish cloak.
My test case only had one item of interest; I assume that the second
item of armor gets worn on a subsequent turn rather than at the same
time as the first one.
Fixes#843
The pull request included some changes that were neither accidental nor
unintentional, so only a subset of the changes from pull request #869
submitted by klorpa were manually applied.
behaviour -> behavior
speach -> speech
knowlege -> knowledge
incrments -> increments
stethscope -> stethoscope
staiway -> stairway
arifact -> artifact
extracing -> extracting
The uses of "iff" were left alone.
Close#869
When breaking a wand of sleep, don't print the message "the sleep ray
hits you!" since it produces an area effect/explosion rather than a ray.
For a couple other wands, !ordinary (wand breakage) effects don't
produce a message (I assume because the do_break_wand feedback is
considered sufficient), but I put in an alternative message for the
explosion since I think it's important to inform the player the hero has
fallen asleep.
Change trappers and lurkers above to remove digestion damage. They
fold themselves around rather than swallow the victim. There were
are lot of places that assumed that an engulfer which is an animal
would swallow and digest the victim. In hindsight, it might have
been simpler to take the M1_ANIMAL flag off of trappers and lurkers
above.
This adds a new digests() predicate for creatures with AT_ENGL+AD_DGST
(purple worm) and also enfolds() for AT_ENGL+AD_WRAP (both 't'-class
critters).
There are several minor fixes mixed in with this. I didn't record
them as I went along but the two I remember are
1) if poly'd into a holder and holding on to a monster, the '<' and
'>' commands refursed to work; release the held creature first
and then treat those commands as normal;
2) throwing a non-weapon while engulfed by an ochre jelly reported
"the <item> vanishes into the ochre jelly's /currents/".
This needs a lot more testing. I found and fixed multiple minor
details before my own testing burned out.
Add macros to convert AD_foo, WAN_foo, and SPE_foo to relative values
for passing to BZ_U_foo and BZ_M_foo macros.
Change some return values in monster spellcasting function from
magic numbers to MM_MISS or MM_HIT.
Make buzzmu consider hero resistances - previously the
monster with innate zapping ray (Angels and Asmodeus) would
just keep doing that attack, but they will now just curse if
it saw the hero resist the attack.
Apply the diff from entrez to deal with out of array bounds access by
wand or spell zap when deciding whether to bounce if that zap reached
the extreme edge of the map (not just the edge of the portion of the
map in use by current level).
... unless there's some other form that would override the choice,
such as a worn dragon armor, lycanthropy, or vampirism.
The polymorph will be in effect for 10-24 turns.
One of the drivers of this change was that screen coordinates require a
type that can hold values greater than 127. Parameters to the window
port routines require a large type in order to be able to have values
a fair bit larger than COLNO and ROWNO passed to them, particularly for
their use to the right of the map window.
This splits the uses of xchar into 3 different situations, and adjusts
their type and size:
xchar
|
-----------------------
| | |
coordxy xint16 xint8
coordxy: Actual x or y coordinates for various things (moved to 16-bits).
xint16: Same data size as coordxy, but for non-coordinate use (16-bits).
xint8: There are only a few use cases initially, where it was very
plain to see that the variable could remain as 8-bits, rather
than be bumped to 16-bits. There are probably more such cases
that could be changed after additional review.
Note: This first changed all xchar variables to coordxy. Some were
reviewed and got changed to xint16 or xint8 when it became apparent that
their usage was not for coordinates.
This increments EDITLEVEL in patchlevel.h
release_hold() checked for (Upolyd && sticks(g.youmonst.data)) before
checking for (u.uswallow) and it could set u.ustuck to Null while
u.uswallow remained set to 1. dmove_core() was accessing u.ustuck->mx
and u.ustuck->my after that, resulting in a crash.
This fixes that particular case but there might be others that also
assume sticky poly'd hero should be handled before swallowed hero.
Being swallowed/engulfed needs to be handled first.
Issue #769, reported by k2 and diagnosed by entrez: eating a troll
corpse that revives on the last turn of the meal was using up the
corpse while the revival was in progress (unless the hero couldn't
observe the resulting monster), leading to a panic when trying to
use it up at the end of revival. Brought on by a recent change to
interrupt an occupied hero who can observe a hostile monster being
created nearby.
The fix isn't perfect. If revival fails because there's no place
to put the revived troll, the meal will be interrupted with one bite
left instead of finishing. If that happens, the interruption will
include a "you stop eating" message, just with no explanation why.
The partly eaten--almost completely eaten--corpse will remain.
Closes#769
Switch to using a macro invocation Verbos(n, s) in place of the
flags.verbose checks.
Provide the mechanics for individual suppression of any of the
existing messages that were considered verbose.
Mechanics only - this code update does not provide any means of
setting the suppression bits.
iflags.verbose = 0
is still a master suppression of all the verbose messages.
iflags.verbose = 1
turns on the verbose messages only for those whose suppression
bit is 0 (not set).
The new livelogging of wish results caused a segfault when attempting to
handle the results of a wizard mode terrain wish, since a successful
terrain wish returns a nonzero obj which nonetheless is just a dummy
object. Move the existing check for that further up to skip all the
livelogging stuff entirely, since such wishes will never happen in a
real game and exist purely for debugging purposes.
Extend the log event for a wish to include what was produced. It
would be better to show the item as fully ID'd but then #chronicle
gives away information.
The backslash+newline pairs were inserted for this log message. In
the game and in dumplog those two lines are each one wide line. The
turn numbers shown are actually arbitrary since ^W takes no time.
|Logged events:
| Turn
| 1: wizard the chaotic male orcish Wizard entered the dungeon
| 2: made his first wish - "protection", got "a tattered cape"
| 3: made his first artifact wish - "blessed +2 rustproof magicbane",\
got "an athame named Magicbane"
| 4: wished for "master key of thievery", got "a key named The Master\
Key of Thievery"
Add the patch from entrez to describe the tower of flame effect from
a scroll of fire as "the blast" rather than "your spell" if it reveals
a secret door.
explosion that reveals a secret door
Make the fix to feedback when an exploding potion of oil reveals a
door and then destroys it not affect other zap_over_floor feedback.
This incorporates the followup comment from entrez.
A couple of things I noticed when trying--and failing, so far--to figure
out the revive panic:
1) revive() treated y==0 as out of map bounds (x==0 is out of bounds
but y==0 isn't);
2) get_mon_location() might yield stale coordinates for steed (but
moot since that's only used for mobile lights and no light emitting
monster can wear a saddle; didn't affect light emitting objects
carried or worn by monsters).
When probing a trapped container, report that it is trapped.
Done with a one-line message in the zap code and also in the title
of the contents display if it isn't empty.
For wizard mode wishing, if both "trapped" and "broken" are specified,
produce an untrapped container with a broken lock.
Also for wizard mode wishing, ignore "trapped" if player wishes for
"trapped secret door".
Reported directly to devteam: when a Rider revived, its corpse
didn't get used up.
The change to have delobj() never destroy Rider corpses, like it
won't destroy the Amulet or invocation items, didn't take into
account that they should be destroyed when Riders revive from them.
Add delobj_core() to be able to do that without changing existing
delobj() usage.
I'm surprised hardfought players haven't been all over this one.
A change made 5 or 6 weeks ago that was meant to enhance tracking of
artifact creation had an unintended side-effect of making every object
obtained via wishing have its dknown flag be set. That made them
behave differenly from items picked up off the floor, so revert to the
old behavior.
For timed acid resistance and timed stoning resistance, report
"You {are,were} temporarily {acid,petrification} resistant."
For items being protected by worn equipment, add "by your {armor,&c}"
similar to the existing feeback about you being protected "because
<some-reason>". Wizard mode only.
