Add minor detail to recently added map description in doc/window.txt:
origin is in upper left and positive y goes downward, so not typical
Cartesian x,y coordinate plane.
Issue reported by vultur-cadens: one of the checks for whether a
shade would be harmed by an attack was erroneously inside a block
of code that only executed when you could see the attack. Basic
physical damage wasn't affected but some monster (or poly'd hero)
damage types that shouldn't affect shades didn't when seen but did
when unseen.
Could also get "attack passes harmlessly through the shade" when
an unseen attack for physical damage hit and failed to deal damage.
fixes#907
Pull request from entrez: rename update_mon_intrinsics() to
update_mon_extrinsics() since it deals with properties conferred
by equipment in use rather than internal capabilities.
fixes#908
Pull request from entrez: explicitly throwing 1 out of stack of more
than 1 and then having the throw be rejected by tageting yourself did
not recombine the split, resulting in stacks of 1 and N-1 that both
had the same inventory letter. Undo the split if throwing fails.
A similar fix was made for gold a year and a half ago by commit
c3ccd93a88.
fixes#904
Pull request by Theyflower: carrying a loadstone prevents big
monsters from hitting their target for knockback effect, same as
wielding Giantslayer.
The PR code needed fixing (unintended switch from 'otmp' to 'obj')
so I didn't use the commeit. The PR code also required that the
loadstone be blessed which sounds nethackish but would mean that
nobody would ever notice. Allow carrying any loadstone to prevent
being knocked back. It will still be a rare accident or uncommon
tactical decision. (It doesn't happen if the target is flying or
levitating because those checks deliberately come first.)
supersedes #906closes#906
A giant mummy starts out with a mummy wrapping but couldn't wear it.
Allow humanoids who are bigger than human size (including poly'd hero
when applicable) to wear such cloaks. They won't do so if they are
invisible and the cloak would let hero start seeing them.
cansee(), couldsee(), and templit() are macros which are described
as boolean and used as if boolean, but they've been using bit
masking to return integer values greater than 1. That works since
C treats any non-zero as True but doesn't match boolean intent.
Something that FIQ once pointed out: the fact that map column 0 is
not shown wasn't explicitly described anywhere. Add a paragraph for
NHW_MAP to doc/window.txt and describe it there.
Some routines return ECMD_TIME|ECMD_CANCEL (for instance when 'a'pply
wields an item and player cancels the attempt to use it) so change
drop_menu() to test that properly. I don't think drop() ever returns
that combined mask value but be prepared to handle time passage if it
ever does.
When not carrying any contained gold, or the only contained gold is
inside container(s) whose contents aren't known, ^X writes one line
about the hero's "wallet". When known contained gold is present, it
writes two lines for gold, first one about wallet with the second
one about contained gold being a continuation of the first. Move
the conjunction that combines them from the start of the second line
to the end of the first.
So change
|Your wallet contains M zorkmids,
|and you have N more contained in your pack.
to
|Your wallet contains M zorkmids, and
|you have N more contained in your pack.
and
|Your wallet is empty,
|but you have N zorkmids contained in your pack.
to
|Your wallet is empty, but
|you have N zorkmids contained in your pack.
It evens out the line lengths a little bit and starting the second
line with uncapitalized "you" seems slightly less jarring than with
"and" or "but".
Reported by entrez: using ^A instead of #retravel after interrupted
travel can pick wrong location if cursor was previously positioned
with movement commands rather than feature targeting because it
won't be starting from the original spot. Also, ^A after ';' will
just redescribe whatever was examined previously instead of having
the player pick a new spot.
This suppresses cursor positioning from the do-again queue so that
repeating travel or quick-look or other command that needs player
to choose a position will repeat the command but then need to have
a position chosen. For interrupted #travel, the cursor will already
be placed on the previous destination so that's relatively painless,
but also allows a different destination to be chosen.
It adds iflags.remember_getpos that callers of getpos() could set to
be able to restore the old behavior but none do so far.
Fixes#905
Issue reported by vultur-cadens: Elbereth used to be effective in
inhibiting monster movement when an object was present on the same
spot, but since 3.6.0 it isn't. It only functions that way when the
hero--or hero's displaced image--is present these days. So special
levels that have been using engraved Elbereth to try to protect
objects from monsters haven't been providing any useful protection.
This makes Elbereth that's engraved during level creation work like
it used to in 3.4.3 and earlier: when there's at least one object
on the engraving's spot, monsters who are affected by Elbereth will
be affected. [I'm fairly sure that that behavior started out
unintentionally, as a side-effect of an optimization to only check
for scroll of scare monster when there was at least one item present
which is a necessary condition for such a scroll.]
Old-style Elbereth includes Elbereth chosen as a random engraving
during level creation in addition to engravings specified in special
level definitions. Engravings by the player don't have the required
attribute and player-engraved Elbereth behaves in the 3.6 way.
This ought to be replaced by something more general. Perhaps a new
engraving type not usable by the player?
Fixes#900
Fix most of the things pointed out by #wizmondiff.
Weakening of placeholder 'elf' is due to recent removal of M2_STRONG
for it as part of the "orc strongmonst" changes.
I assume that the discrepancies for multiple quest leaders came about
as part of the change that allows killing the leader as an alternate
way to gain access to the lower levels of the quest, but didn't check.
I don't know what's up with 'piranha' but just changed it to match
generated value.
'{freezing,flaming,shocking} sphere' still show up as discrepancies
with hardcoded (mons[].difficulty) value higher than generated value.
They got harder when their explosion was beefed up, so the formula to
calculate difficulty ought to be updated to account for that.
Shorten the name of the recently added debug command that validates
monster difficulty values. 'wizcheckmdifficulty' was 19 characters
long, the next longest is 14 ('wiztelekinesis'). The extra width
messed up the Qt interface's extended command selection dialog when
wizard mode commands are included. It sizes the button for every
command to fit the longest name; the increase in size from 14 to 19
made the button grid become too big for the screen.
Add monsters' base difficulty level to the #wizmondiff output.
Add #wizmondiff and #wizdispmacros to 'wizhelp'.
Force windowtype to be the first option written to new RC file since
its value can affect how other options are processed. (Only saved if
comes from existing RC file, not command line.) doset() lists a few
compound options before the rest too. Combine the two sets of want-
to-be-first and move the handling for that to optlist.h where the only
cost is that the options are no longer in alphabetical order.
I hadn't ever used #saveoptions before and when I checked to see
whether the autounlock:none changes were being handled properly, I
discovered that options set via 'm O' weren't being handled at all.
This includes some miscellaneous reformatting of things noticed
while tracking down the problem.
Add a stack of 2 tins of spinach near the leader on the monk quest
start level and another stack of 2 blessed tins of spinach at a
random spot on the monk quest locate level, to compensate for the
inability to gain strength from giant corpses if they adhere to
vegan or vegetarian conduct. paxed supplied the 'tinplace' magic.
4 tins of spinach aren't nearly enough to get to 18/100, but by
uncursing the first pair, if necessary, and waiting until strength
is at least 18, they can be eaten to add 4..40 (average 22) points
of exceptional strength. (Players choosing either of those conducts
for other roles or foodless for any role are on their own as far as
boosting Str goes, same as before.)
The special level loader needed to be modified to handle tins of
spinach. It now accepts "spinach" as a fake monster type for an
object of type "tin". Also added support for empty tins since it
involved the same code, and use of fake monster type "empty" with
object type "egg" to be able to create generic (unhatchable) eggs.
(Wishing for "egg" produces those by default but it also accepts
explicit "empty egg" by coincidence.)
Handle alternate values for hero poly'd into a 'strongmonst' form
more thoroughly by propagating max values other than 18/100 to the
attribute manipulation routines.
ATTRMAX(A_STR), which used to be a relatively simple expression, now
contains a function call.
Along the way, change the races[] terminator's value for 'mnum' from
0 (giant ant) to NON_PM.
When strength loss is so big as to cause HP damage, but reduce
strength if the damage causes hero to revert to normal form. There's
no point in adjusting strength before rehumanization and not fair to
do so afterward.
Also, validate strength and its intended adjustment before doing
anything else. (Just paranoia; there's no reason to suspect that any
bad data ever gets passed in.)
Try again to make losestr() do what's intended. If it would take
strength below 3, it takes away HP and max HP instead. If hero is
poly'd, those come from the hero-as-monst values. If hero was
poly'd but isn't any more, hero-as-monst died and rehumanized as
previous self; leave max HP alone. If hero wasn't poly'd, take
HP and max HP from their usual values, but don't take max HP below
the threshold of minimum max HP (experience level times 1). The old
check for max HP going below minimum can't happen anymore, unless
hero was below that threshold already (which shouldn't happen; if it
does somehow, don't punish hero further).
If this still isn't right, I'll throw up my hands and my lunch.
Refine pull request #802 by entrez. Applying damage within a loop
could potentially damage the hero multiple times, maybe using up
an amulet of life saving and then killing hero anyway, or causing
rehumanization and taking further HP from normal form, or both,
causing rehumanization and then using up amulet of life saving.
Accumulate the damage in the loop and then apply it as a unit.
Issue reported by vultur-cadens: Elbereth used to be effective in
inhibiting monster movement when an object was present on the same
spot, but since 3.6.0 it isn't. It only functions that way when the
hero--or hero's displaced image--is present these days. So special
levels that have been using engraved Elbereth to try to protect
objects from monsters haven't been providing any useful protection.
This makes Elbereth that's engraved during level creation work like
it used to in 3.4.3 and earlier: when there's at least one object
on the engraving's spot, monsters who are affected by Elbereth will
be affected. [I'm fairly sure that that behavior started out
unintentionally, as a side-effect of an optimization to only check
for scroll of scare monster when there was at least one item present
which is a necessary condition for such a scroll.]
Old-style Elbereth includes Elbereth chosen as a random engraving
during level creation in addition to engravings specified in special
level definitions. Engravings by the player don't have the required
attribute and player-engraved Elbereth behaves in the 3.6 way.
This ought to be replaced by something more general. Perhaps a new
engraving type not usable by the player?
Fixes#900
Fix most of the things pointed out by #wizmondiff.
Weakening of placeholder 'elf' is due to recent removal of M2_STRONG
for it as part of the "orc strongmonst" changes.
I assume that the discrepancies for multiple quest leaders came about
as part of the change that allows killing the leader as an alternate
way to gain access to the lower levels of the quest, but didn't check.
I don't know what's up with 'piranha' but just changed it to match
generated value.
'{freezing,flaming,shocking} sphere' still show up as discrepancies
with hardcoded (mons[].difficulty) value higher than generated value.
They got harder when their explosion was beefed up, so the formula to
calculate difficulty ought to be updated to account for that.
Shorten the name of the recently added debug command that validates
monster difficulty values. 'wizcheckmdifficulty' was 19 characters
long, the next longest is 14 ('wiztelekinesis'). The extra width
messed up the Qt interface's extended command selection dialog when
wizard mode commands are included. It sizes the button for every
command to fit the longest name; the increase in size from 14 to 19
made the button grid become too big for the screen.
Add monsters' base difficulty level to the #wizmondiff output.
Add #wizmondiff and #wizdispmacros to 'wizhelp'.
Force windowtype to be the first option written to new RC file since
its value can affect how other options are processed. (Only saved if
comes from existing RC file, not command line.) doset() lists a few
compound options before the rest too. Combine the two sets of want-
to-be-first and move the handling for that to optlist.h where the only
cost is that the options are no longer in alphabetical order.
I hadn't ever used #saveoptions before and when I checked to see
whether the autounlock:none changes were being handled properly, I
discovered that options set via 'm O' weren't being handled at all.
This includes some miscellaneous reformatting of things noticed
while tracking down the problem.
Pull request from entrez: simply the 'O' submenu for autounlock by
removing choice 'none'. Fix error reporting for bad autounlock value
from run-time config file or NETHACKOPTIONS.
Fixes#897
Add a stack of 2 tins of spinach near the leader on the monk quest
start level and another stack of 2 blessed tins of spinach at a
random spot on the monk quest locate level, to compensate for the
inability to gain strength from giant corpses if they adhere to
vegan or vegetarian conduct. paxed supplied the 'tinplace' magic.
4 tins of spinach aren't nearly enough to get to 18/100, but by
uncursing the first pair, if necessary, and waiting until strength
is at least 18, they can be eaten to add 4..40 (average 22) points
of exceptional strength. (Players choosing either of those conducts
for other roles or foodless for any role are on their own as far as
boosting Str goes, same as before.)
The special level loader needed to be modified to handle tins of
spinach. It now accepts "spinach" as a fake monster type for an
object of type "tin". Also added support for empty tins since it
involved the same code, and use of fake monster type "empty" with
object type "egg" to be able to create generic (unhatchable) eggs.
(Wishing for "egg" produces those by default but it also accepts
explicit "empty egg" by coincidence.)
Handle alternate values for hero poly'd into a 'strongmonst' form
more thoroughly by propagating max values other than 18/100 to the
attribute manipulation routines.
ATTRMAX(A_STR), which used to be a relatively simple expression, now
contains a function call.
Along the way, change the races[] terminator's value for 'mnum' from
0 (giant ant) to NON_PM.
When strength loss is so big as to cause HP damage, but reduce
strength if the damage causes hero to revert to normal form. There's
no point in adjusting strength before rehumanization and not fair to
do so afterward.
Also, validate strength and its intended adjustment before doing
anything else. (Just paranoia; there's no reason to suspect that any
bad data ever gets passed in.)
Try again to make losestr() do what's intended. If it would take
strength below 3, it takes away HP and max HP instead. If hero is
poly'd, those come from the hero-as-monst values. If hero was
poly'd but isn't any more, hero-as-monst died and rehumanized as
previous self; leave max HP alone. If hero wasn't poly'd, take
HP and max HP from their usual values, but don't take max HP below
the threshold of minimum max HP (experience level times 1). The old
check for max HP going below minimum can't happen anymore, unless
hero was below that threshold already (which shouldn't happen; if it
does somehow, don't punish hero further).
If this still isn't right, I'll throw up my hands and my lunch.
Refine pull request #802 by entrez. Applying damage within a loop
could potentially damage the hero multiple times, maybe using up
an amulet of life saving and then killing hero anyway, or causing
rehumanization and taking further HP from normal form, or both,
causing rehumanization and then using up amulet of life saving.
Accumulate the damage in the loop and then apply it as a unit.
Pull request from copperwater: if a theme room produced a room with
one door that effectively opened on a 'hallway' leading to the core
of that room, it would be considered to be eligible to become a shop.
But if the only spot available for the shopkeeper to move away from
the spot in front of the door was another spot in the hallway, there
would be no possibility to get out of the way, either to let someone
in, or if the hero arrived by teleport or trap, to let hero out.
| --
| ---..[rest
|##+12..of the
| ---..room]
| --
Shopkeeper would move back and forth between 1 and 2, always blocking
access between the door and the rest of the room.
Currently no rooms get generated with that shape. I haven't tried to
force one in order to verify the fix.
Fixes#888
Pul request from entrez: in some circumstances a monster holding the
hero can move away and continue holding. Check for that sooner and
release hero is warranted.
Fixes#893
Pull request from entrez, with several commits: monster spell 'weaken'
didn't handle poly'd hero correctly, possibly continuing in poly'd
form with negative hit points. Make losing strength (which takes away
HP if Str would drop below 3) take care of applying damage too so that
several callers don't need to do that.
Fixes#892
Pull request from entrez: poly'd hero who digests a creature has a
change to gain an intrinsic from it. I put the fixes entry in the
New Features section.
I was a bit concerned that g.afternmv might be cleared during the
turns the hero is busy digesting, leaving a stale value for
g.corpsenm_digested, but I don't think that that can happen.
Fixes#883
Issue reported by eakaye: for a 'hugs' attack to succeed, the
monster must have at least three attacks and the two preceding the
hug attack need to both hit. Guardian nagas had three attacks but
the first was melee 'bite' and the second was ranged 'spit'. Those
are mutually exclusive, so they would never both hit and nagas never
grabbed their prey.
Make the spit attack be first, the bite attack be second, insert a
touch attack for 0 damage third, and make the hug be fourth. Also,
change their hug damage type from 'phys' to 'wrap'. The first and
2nd+3rd+4th are still mutually exclusive.
The resulting message feedback left something to be desired and has
been tweaked.
The difficulty-level formula used by deprecated 'makedefs -m' now
generates 17 rather than 16 for guardian naga so I changed revised
monster to match. They are definitely more difficult now that their
constriction attack has a chance to hit.
Fixes#894
Reported directly to devteam, mounted hero whose steed got hit
for knockback effect triggered impossible "no monster to remove".
In addition to fixing that, this makes a knockback attempt at a
hero who is stuck to a cursed saddle knock the hero and steed back
instead of knocking the hero out of the saddle.
mhurtle_step() should be able to use u.ux0,u.uy0 to update the
hero's old location after moving the hero in order to move the
steed, but the value was different from what was expected and the
map showed stale steed symbol when I used that. I'm not sure what
is going on there; saving u.ux,u.uy before moving the hero worked
as intended so I didn't pursue it.
More tty-specific hangup handling. There's still doubt about the
origiinal testing, but not about testing after "post bitrot repair",
if there was any. That wasn't useful because the new code was
accidentally suppressed by testing a misspelled macro. when deciding
whether to include it.
Pull request from entrez: the conditional hangup handling in
wintty.c hasn't been getting used because the HANGUPHANDLING macro
from the core was misspelled as HANGUP_HANDLING.
The old testing was probably invalid since it was most likely done
with the same misspelled #if. I haven't done any new testing so
since this should be considered potentially buggy.
Fixes#891
Issue reported by eakaye: the alternate hobbit chat message is a
complaint about dungeon conditions, given if its current HP is 10
or more less than its maximum HP. But since hobbits are level 1,
they will almost never have 10 HP so won't be alive to chat when
at max minus 10.
Keep the old behavior if maximum happens to be more than 10, but
give alternate feedback when less than max if max is 10 or less.
Fixes#890
I was trying to reproduce the reported "no monster to remove" warning
from remove_monster() when a mounted hero was knocked off jabberwocky
steed but so far haven't been able to.
While trying, I came across a more minor bug. The hero got knocked
off a flying steed and got feedback of "you fly off" rather than
"you fall off". Flying capability came from the steed and dismount
feedback is aware of that but calls u_locomotion() which isn't. This
commit fixes that.
This adds some groundwork (DISMOUNT_KNOCKED) for better dismount
control. With a map fragment of
|....
|.Du.
|....
I got knocked off my steed by the attacking dragon and ended up with
|..@.
|.Du.
|....
It would be better to prefer spot 1, then the 2s, then 3s, then 4s
(not sure about farther spots if none of those are available)
|.432
|.D@1
|.432
when forced to dismount by knockback. This does _not_ implement that.
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.
Reported by eakaye: orcish hero has maximum strength of 18/50 but
hero poly'd into an orc was given 18/100 strength. Also, a comment
from vultur-cadens pointed out that orcish heroes start with poison
resistance while monster orcs lack it.
Even though the boost to 18/100 is only temporary until the poly
times out, make orcs a special case where strongmonst from poly'ing
into them only gives 18/50 strength instead of 18/100. Adopt the
suggestion that Uruk-hai be an exception and continue to give hero
poly'd into them 18/100.
If any gnome becomes strongmonst (currently none are), treat them
as 18/50 too. Elvenking and elf-lord are strongmonst; treat their
forms as plain 18 though, matching the limit of elf heroes. Lesser
monster elves aren't strongmost.
While in there, add another special case so that hero poly'd into a
giant gets 19 strength. Monster giants are still plain strongmonst
so might warrant some sort of adjustment.
Give orcs poison resistance, but eating their corpses doesn't provide
an opportunity to confer it. Note goblins and hobgoblins still don't
have the resistance (to distinguish them from orcs a bit).
Take away strongmonst from orc shamans and give it to orc mummies.
Human mummies should have it too (at least according to movies) but
I didn't alter them becuase they're already pretty dangerous at the
point they start occurring. Take away strongmonst from plain 'elf'
placeholder.
New: when hero polymorphs into a form that lacks the strongmonst
attribute, take away any exceptional strength (drop 18/01 through
18/100 down to 18; as mentioned above, the drop is only temporary).
There's no attempt to set the maximum even lower for wimpy forms.
Fixes#679
Suggested by entrez: when you search while engulfed the feedback asks
whether you're looking for the exit, but the joke about the exit isn't
funny when repeated over and over which happens if the player waits to
be expelled by using 's','s',... rather than '.','.',....
[sic] should be "engraving in frost mentions dust"
Writing on ice with fingers is described as writing in frost, but if
you overwrite an existing engraving rather than add to it the game
said you wiped out the engraving in the dust (immediately followed
by writing in the frost).
Not mentioned in the report: finishing a multi-turn engraving on
ice had the same problem.
Pull request from entrez: X11's get-extended-command widget
allocated 1 extra byte for a couple of end-or-array terminators
and then wrote more than 1 byte to them when initializing its list
of extended commands.
Fixes#884
A change to the curses interface from three years ago to make sure
that round-off didn't make the horizontal and vertical clipped map
indicators appear to not be clipped was using ROWNO for both instead
of COLNO for the horizontal one. For modest clipping the mistake
was unnoticeable; I don't know whether that remained true for more
extreme clipping.
[Not fixed: the curses scrollbar stuff ignores the fact that map
column 0 is unused.]
Make the prompt for single genocide be more precise
from: What monster do you want to genocide?
_to_: What type of monster do you want to genocide?
and the re-prompt for it be slightly more verbose
from: What... [type the name of a monster]
_to_: What... [enter the name of a type of monster]
Also, make the already verbose re-prompt for class genocide even
more verbose
from: What class... [type the symbol representing a class]
_to_: What class... [type the symbol or name representing a class]
Possibly should have changed 'type' to 'enter' on the last one to
keep them consistent but I left that as-is.
Pull request from entrez: genocide prompt has a short explanation
appended. Skip that on first try, and on all tries if 'cmd_assist'
option is Off.
For class genocide, don't retry an unlimited number of times if
player supplies an empty response. Any empty response will now
count toward the 5 chances available to supply a valid choice, as
it does with single genocide.
Fixes#882
Pull request from chasonr: if the curses interface did a full screen
update while the game was ending, it could attempt to refresh windows
that had already been removed.
For #if PDCURSES, raw_print() could attempt to write to the message
window after it had been removed.
[Why is raw_print() using the message window at all? Isn't the main
point of it to bypass that?]
Fixes#881
Pull request from entrez: fix an off by one error in the allowed
range of subroom indices.
I've never understood subrooms and am accepting this fix on faith.
Fixes#859
Pull request from vultur-cadens: don't change unID'd gem prices
when source changes insert some new object before them or the game
gets rebuilt with different featues enabled such as MAIL.
This is more about keeping the spoiler table in the wiki accurate
than anything to do with game play. It definitely gives players
who use spoilers an advantage over ones who don't, but does so in
such an insignificant aspect of play that it likely doesn't matter.
I'm fairly sure that the remark that keeping the prices the same
is what the original implementor intended is not correct. I don't
recall who implemented this and the commit log for the first cvs
repository is long gone so it's moot.
Fixes#733
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
Refine commit 4885653014.
> I'm not sure whether gcc 3 is really the right test for whether the
> returns_nonnull attribute setting is available.
The gcc.gnu.org website only goes back to 5.1, and searching the
documentation of that version for returns_nonnull finds it. I used
ftp to get gcc-core-3.0.0 and gcc-core-4.0.0 and their doc files don't
mention this attribute. It might have been added for some later 4.x
but that really doesn't matter for nethack's purposes.
Use __GNUC__ >= 5 instead of __GNUC__ >= 3 when testing whether
__attribute__(returns_nonnull) is available.
The menu to interactively set the windowborders option for curses
uses 'a'..'e' for choosing 0..4. Accept '0'..'4' (via unseen group
accellerator) too.
If environment had TTYINV=4 (perm_invent shows worn/wielded only),
disclosing inventory at end of game only showed worn and wielded
items instead of full inventory. Didn't matter whether perm_invent
is On or which interface is in use or whether game was built with
TTY_PERM_INVENT enabled.
This is an alternate way to deal with pull request #876, where
splitting a stack that has a name assigned updated perm_invent when
cloning the name and ran into trouble with shop billing when trying
to format for persistent inventory display.
The PR#876 fix has been left in place but wouldn't have been needed
if this had gone in first.
Reported by paxed 8 years ago: if a bones file contains a
doppelganger imitating a unique monster, when it gets loaded
that monster ends up being marked as having been created. The
doppelganger itself will shapechange to other forms, but the
unique monster won't be created when it should be because it has
become extinct.
Report involved creating a statue of a unique monster which
yields a doppelganger in that monster's shape, then using stone
to flesh to animate the statue, dying before it changes to some
other shape, and having bones be saved.
Pull request from copperwater: don't give "flash of light" feedback
when activating a level teleporter because it's too much like one of
the outcomes of a magic trap.
This doesn't use the suggested commit. Getting the "you feel
disoriented" feedback before being asked for destination level (when
having teleport control) seemed contradictory. This gives different
feedback and does so after the actual teleport.
Supersedes #850
and since nhcopier doesn't seem to understand "supersede"
Closes#850
Mark alloc()--also dupstr() and re_alloc()--for gcc and clang as
always returning non-Null. This should silence some of the static
analysis complaints.
Almost all the monster and object naming functions (anything that
returns an mbuf or an obuf) should be marked this way too but I'll
leave that for somebody else to deal with.
I didn't attempt to mark alloc() with the 'malloc' attribute because
macro definitions could end up causing trouble. Specifying its
deallocator would probably be useful but is at even bigger risk of
macro interference.
I'm not sure whether gcc 3 is really the right test for whether the
returns_nonnull attribute setting is available.
Year old issue from copperwater: 'open' directed at a non-door told
player that there isn't a door and took no time unless character was
blind and learned what type of terrain it is, applying a key gave
the same message but used a turn and didn't update map to reflect any
terrain discovery.
Attempting to open an adjacent door or applying a key to one while in
a pit had a similar issue: they produced the same "you can't reach
it from here" but had different time vs no-time outcome.
There may be other actions in the same situation.
Closes#581
Pull request from copperwater: the random traps specified by the
special level definitions of the tourist locate and goal levels could
be placed inside the shops present on those levels.
Fixes#848
Use the level passed in instead of the hero's location when checking
the dungeon branch.
It probably doesn't make any difference, but use the argument that's
already being provided.
Add a comment to the effect that engraving with Fire Brand doesn't
cause it to become dull.
[I'm not sure that is the behavior we really want. It seems like an
unintended side-effect of changing Fire Brand's engrave type to BURN.]
Someone asked whether the 'magr' argument to artifact_hit() can be
Null or not since the code sometimes checks whether it is Null and
other times uses it unconditonally. The answer is "it depends."
Can't reply to asker due to forced anonymity when the contact form
was submitted.
Pull request from argrath nearly a year ago: an 'if' and corresponding
'else' have the same code so there's no point in testing for if/else.
I'm still not convinced that simply removing the if/else is the right
fix here but nothing else is going on. I've put part of the removed
code back inside '#if 0' in case it needs to be resurrected someday.
Closes#628
Pull request from entrez: the check for whether a pet in desperate
straits will eat a corpse that will cause it to polymorph used bad
logic. The suspect code was added post-3.6.
Fixes#879
Pull request from entrez: the change to remove digestion damage
from trappers and lurkers above didn't handle engulfing by poly'd
hero adequately.
Fixes#858
Pull requet from entrez: give better feedback than "it" when hero
observes a corpse reviving into a monster that can't be seen.
Tweak reviving from a container which was coded as if the container
was optional. That can lead to confusion when someone reads the
code so make the situation more explicit.
Fixes#871
Pull requet from vultur-cadens: use space instead of hyphen in
enlightenment and end-of-game feedback.
All the other resistances already use space. The inappropriate
hyphen in "disintegration-resistance" seems to have been present
since enlightenment was added (in 3.0; back then the relevant code
was in cmd.c; current insight.c didn't exist until 3.6).
Fixes#877
when splitting a stack of named, shop-owned objects
Pull request from entrez: when perm_invent is on, splitting an unpaid
stack would issue impossible "unpaid_cost: object wasn't on any bill"
while cloning the new stack's name from the old stack.
Fixes#876
Change the handling for windowing system specific files so that
when building for more than one set, each gets compiled as a set
instead of some being interspersed among rival window systems.
Put differently, handle tile.o specially so that there's no need
for the hints to sort the WINOBJ list in order to avoid tile.o
duplication.
So the order of compilation is
common source files
unix-specific files
tty files
curses files
X11 files
Qt files
tile.c (if applicable), version.c, date.c
Previously, some of the X11 files were scattered around among the
others because of the spelling of their file names.
Only matters if you're watching the progress of a build.
This reverts commit 94945a719a.
It was too intrusive and can be handled by the 'onefile' script
by compiling isaac64.c before any source file that includes hack.h.
Issue reported by k2: tipping a wand of cancellation, bag of
holding, or bag of tricks from a non-magic container into a bag of
holding causes the bag of holding to explode but it wasn't dealing
out explosion damage nor being logged for livelog/chronicle the way
putting the item directly into a bag of holding is handled.
This fixes the described issues but bones handling leaves a lot to
be desired.
Fixes#875
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
Format a horn of plenty whose charge count is unknown but is known to
be empty as "empty horn of plenty" like is done for real containers.
This was too easy; I must have missed something....
Require a free hand when tipping a container into another container.
Presumeably you need to open the destination container and possibly
keep holding it open.
If you try to tip a carried container into an unknown bag of tricks,
apply the bag (once) instead of performing the tip. (To 'open' the
destination as above.) Possibly slightly confusing if bag is empty.
When tipping a container, always ask for the destination instead of
doing that only when carrying other containers. Confirming floor
as destination can be annoying but having to do that sometimes and
skipping that sometimes is aggravating because it is error prone.
And floor is preselected so can be chosen with space or return.
(I wanted to change the selector letter for floor from '-' to '.'
and then keep '-' as an unseen group accelerator, but the latter
doesn't work for PICK_ONE so I've left '-' as-is.)
Don't display "monsters appear" after tipping a bag of tricks.
Monster creation gives feedback these days. (Comparable to recent
"summon nasties" fix.)
For tipping purposes, a horn of plenty is treated like a container.
But using one as the source container in a container-to-container tip
wasn't supported. Implement that.
Also, #tip was offering carried bags of tricks as candidate containers
to tip some other carried container into. Only do that for ones which
aren't known to be bags of tricks (so when type not discovered yet, or
specific bag not seen yet due to blindness).
PatR