Remove callers' responsibility to deal with possible hero death when
calling losestr. This is less fragile and error-prone than leaving it
in the caller's hands, but it means that death from the monster spell
'weaken target' no longer goes through done_in_by, and the death reason
is no longer "killed by <monster name>".
Killer format isn't a boolean, since it has 3 possible values
(KILLED_BY_AN, KILLED_BY, NO_KILLER_PREFIX). It shouldn't make any
difference behind the scenes, but it's confusing to use 'boolean' for
it.
...could leave hero in creature form with negative u.mh
losestr can subtract HP, but doesn't directly kill its target. The
caller is responsible for possibly killing the hero if losestr reduces
her HP to 0 or lower; most callers do this by combining losestr with a
losehp call, which can kill off the hero if necessary.
MGC_WEAKEN_YOU calls done_in_by if u.uhp < 1 after losestr, but didn't
handle the Upolyd u.mh case, so could leave a polymorphed hero with
negative health. Add a rehumanize call in that case.
This could also be done by changing losestr to call losehp itself for
the HP loss it deals out, but this would interfere with
cast_wizard_spell's use of done_in_by to generate the death reason:
either all strength loss is described one way ("terminal frailty" or
something -- not great) or else losestr must be passed a death reason
and is described a different way than other attack spells (because it
wouldn't go through done_in_by).
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
Monster purple worms can now gain intrinsics from swallowing foes whole,
so maybe the hero should be able to do so too. Intrinsics aren't
granted immediately upon swallowing (that would probably have been
easier), but only once a corpse is created and then entirely digested.
I'm not sure if this is too powerful and was being avoided deliberately
for that reason, since it includes potential level gain from wraith
corpses in addition to other intrinsics. That's consistent with monster
purple worms but may be a bit too much in the hands of the hero, though
it is limited by needing the corpse creation roll to succeed.
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
../win/curses/cursmain.c: In function 'curses_init_nhwindows':
../win/curses/cursmain.c:157:17: warning: unused variable 'pdc_font' [-Wunused-variable]
157 | static char pdc_font[BUFSZ] = "";
| ^~~~~~~~
../win/curses/cursmain.c: At top level:
../win/curses/cursmain.c:157:17: warning: 'pdc_font' defined but not used [-Wunused-variable]
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.
An Xcode update has started causing the same problem that was experienced on
Linux with newer compiler or glibc a while back.
˜
In file included from monst.c:6:
In file included from ../include/config.h:670:
In file included from ../include/integer.h:54:
In file included from /Applications/Xcode_14.0.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/14.0.0/include/stdint.h:52:
In file included from /Applications/Xcode_14.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdint.h:52:
In file included from /Applications/Xcode_14.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:32:
/Applications/Xcode_14.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:302:39: error: too few arguments provided to function-like macro invocation
^
1 error generated.
make[1]: *** [monst.o] Error 1
Please enter the commit message for your changes. Lines starting
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
The SIGHUP handling for the TTY windowport added in 594cb5f was wrapped
in '#ifdef HANGUP_HANDLING', but the actual define is 'HANGUPHANDLING'
without the underscore.
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
