When a failed #untrap attempt while mounted caused hero to be moved
onto the trap, it neglected to set the steed's coordinates to match.
If 'sanity_check' was On, that would trigger warnings about steed's
anomalous position. Eventually a normal move would put steed's
coordinates back in sync with the hero's.
The pull request code set u.usteed->{mx,my} directly. I've used
u_on_newpos() instead. I also replaced some direct manipulations of
u.{ux,uy} with u_on_newpos() so that if clipping is in effect it will
be updated.
This reverses all of c67f1dd71044b7d0ec98a6e4645b1c20915467f0
except for the fixes37.0 entry and does a better job in a cleaner
fashion. If Sting is going to start glowing and "you materialize
on a different level" is pending, give the materialize message
before the glowing message. Otherwise handle both stop-glowing
and/or you-materialize in the normal fashion.
When level teleporting, Sting/Orcrish/Grimtooth would start or stop
glowing based on occupants of the new level before "you materialize
on another level". That wasn't necessarily incorrect for the glow
stopping but was clearly wrong for it starting. This fix uses a flag
as a hack to avoid finding and changing all the calls to docrt() and
see_monsters(). It ought to be fixed properly....
while 'mention_decor' is enabled. When stepping onto different
terrain and one or more objects remained on the new spot after
autopickup, describe_decor() was issuing its new-terrain message
right before look_here()'s similar under-the-objects message. If
autopickup grabbed everything or there weren't any objects to begin
with, look_here() doesn't issue any dfeature (terrain) message.
describe_decor() isn't smart enought to know whether that is going
to happen. Give look_here() a new flag argument so that its caller
can ask for the dfeature message to be skipped for the case where a
similar message has already been given.
One monster hitting another with an artifact within the hero's view
gave "<Mon1> swings his <Artifact> at <Mon2>." followed either by
"<Mon1> misses <Mon2>." _or_ the two messages "<Mon1> hits <Mon2>."
and "The <Artifact> hits <Mon2>." Defer the <Mon1> hits <Mon2> one
when Mon1 is using an artifact and only deliver it if there is no
artifact hit message.
copperwater [Mon, 6 Nov 2017 16:01:15 +0000 (11:01 -0500)]
Candle light radius is now square root, not logarithmic
After some discussion with Alex Smith, it seems like a good change for
both gameplay and realism that candles' light radius should decay
quadratically instead of exponentially. Now a light radius of 4 from
candles can be accomplished by burning 9 candles, and players who find a
lot of candles might even be able to get up to 5 (16 candles) or 6 (25
candles).
The main impetus for this change is that with the existing formula, the
more candles -> more light mechanic was more or less useless outside of
wizard mode, because you needed 49 candles to do better than a lamp.
Extended achievement and conduct fields for xlogfile
Introducing two new xlogfile fields "achieveX" and "conductX" which encode
achievements and conducts as a series of comma-separated strings which are
more easily parseable and also somewhat interpretable independent from knowing
the source code.
Example for a player that died shortly after picking up the luckstone from the
gnomisch mines:
achieveX=entered_the_gnomish_mines,entered_mine_town,entered_a_shop,entered_a_temple,obtained_the_luckstone_from_the_mines
conductX=polyless,polyselfless,wishless,artiwishless,genocideless
Change obj->oextra->omid from a usually-Null pointer field in
oextra to a simple 'unsigned' that doesn't need any allocation
beyond obj->oextra itself. Value 0 means that it is not in use;
it is used to hold a monst.m_id and those are always non-zero.
Delete unused obj->oextra->olong. 'olong' used to be the last
field in struct obj, put there to force alignment of anything
which followed it back when obj structures were over-allocated to
append extra information. It had a comment about being used for
temporary gold but whatever that was, temporary gold was gone long
before obj->oextra got introduced.
Bump EDITLEVEL since this invalidates existing 3.7 save files.
Add some prototypes and add a new include to a couple of files that
use config.h instead of hack.h. So sys/unix/Makefile.src has been
changed slightly.
Issue was for dropping glob of green slime while swallowed by a
purple worm but also applied to pet eating habits. Green slime
corpse doesn't exist any more; check for glob instead.
Applying a bullwhip down while levitating or riding gives a chance
to pick up items from the unreachable floor. Doing so over water
yields "you wrap your bullwhip around <item> on the water" when
that item is actually on the bottom. Same for lava. Don't fetch
items from beneath the surface. Also, for the lava case subject
the whip to fire damage.
This has actually broken the seal on a can of worms. Every item
at a water location sinks to the bottom even if it should float.
I'm not opening that can....
Fix "objects[0] class #1 not in order!" panic. The new check to
make sure that the elements of objects[] were in ascending order
by object class uses a plain 'char' index so -1 to indicate 'no
previous value' didn't work on a system using unsigned chars.
Verfied by temporarily adding '-funsigned-char' to CFLAGS before
and after the revision. Before: panic, after: no panic.
I added -Wmissing-prototypes to my CFLAGS and got a bunch of warnings.
This fixes the core ones (there are more for X11 that I haven't looked
at yet). While fixing these, I discovered a few option processing
issues: the non-Amiga 'altmeta' should be settable while the game is
in progress (not sure about the Amiga variation so left that as-is),
'altmeta' and 'menucolor' are booleans so shouldn't have had optfn_XXX
functions; 'MACgraphics' and 'subkeyvalue' were conditionally defined
differently in options.c than in optlist.h.
Allow nurses heal attack when wielding a non-weapon/weaptool
This matches the nurses' hitting behavior with their chatting messages.
Chatting to them suggested that the heal attack would happen but the check in
mhitu.c was just for wielding anything.
This opens up the possibility of a YAFM in MS_NURSE when wielding something
that allos the heal attack to proceed. But I couldn't come up with a good
one.
Allow crystal ball to search for furniture (stairs and ladders,
altar, throne, sink, fountain) as well as for a class or objects
or of monsters or all traps. Giving any of '<','>','_','\','#',
or '{' will find all of those rather than just the individual type
specified. Because of the default character conflict, '_' can no
longer be used to find chains; looking for altars is more useful.
The chance of getting the cursed effect due to failing a saving
throw against intelligence when the ball isn't actually cursed has
been reduced. If it is the hero's own quest artifact, it will
happen if rnd(8) is greater than Int, so Int of 8 or more will
never yield that effect. Otherwise if it is blessed, rnd(16) is
used so 16 or better Int means it can't act like it is cursed.
When uncursed and not hero's quest artifact, the old rnd(20) > Int
test is still used.
Crystal balls now start with 3..7 charges rather than 1..5, and
blessed charging sets the amount to 7 charges rather than 6 and
also blesses the ball. Recharing with uncursed scroll of charging
is slightly better (adds 1..2 charges instead of always just 1,
caps the amount at 7 rather than 5) and uncurses the ball. Cursed
scroll strips off all charges even if the ball is blessed and also
curses the ball so is harsher than before.
Crystal balls now cancel to -1 instead of 0, like wands, and using
one effect will destroy it, like zapping cancelled wands.
Also a minor tweak to the initial charges for can of grease (5..25
instead of 1..25) and horn of plenty and bag of tricks (both now
3..20 instead of 1..20).
Have 'makedefs -m' output default mons[].difficulty values in the
stub 'monstr.c' that still gets generated for that option. It
would be better to allow specifying which monsters are of interest
but I didn't want to get bogged down by interface issues.
I needed it for mons[PM_ELF].difficulty after changing that monster's
level, so it still has a purpose. Code is from 3.4.3, reformatted
manually.
Remove an obsolete comment about soldiers since they haven't been
contiguous for over 15 years as the 'ants in barracks' bug report
revealed.
Do some reformatting, mostly for attacks among the '@' class.
Only one actual change: reduce the level for 'elf' (placeholder
for zombie and mummy corpses) from 10 to 0 (and corresponding
difficulty from 12 to 2). I don't think that level is ever used
anywhere and the one for humans is already zero. Having it be
higher than Elvenking's level was absurd.
'@' section should either be completely reordered to obey 'rule #2'
or nurse should be moved back to where it once was (in front of
shopkeeper). I haven't done either but only because I couldn't
which of the two should be done.
Monster detection skipped dead monsters during fmon traversal but
found semi-dead guard parked at <0,0> waiting to remove temporary
vault corridor. If that happened to be the only monster found then
the feedback was incorrect (a blank map showing no found monsters
instead of a strange feeling). Object detection found semi-dead
guard's inventory and might report incorrectly too although the
chance of that being the only objects found on the level is a lot
less than it being the only monster.
fix issue #325 - wishing for "garlic" doesn't work
Wishing allowed "royal jelly" to match "lump of royal jelly" as a
special case, but not "wolfsbane" to match "sprig of wolfsbane" or
"tricks" to match "bag of tricks". Handle that sort of match in a
more general way.
While in there, add a minor glob bit: instead of giving a random
corpse (because monster is flagged as no-corpse) if someone wishes
for "gray ooze corpse" give "glob of gray ooze".
After 05403182ebc542da4bacd716cef408a27372c1ad (I think, possibly the
change to objnam.c which followed that one) from a couple of days ago,
wishing for a monster name dereferenced a Null pointer and crashed.
"were{rat,jackal,wolf}" each occur twice in mons[], once for the
beast form and second time among '@' for the human form. Wishing
for werecreature corpse or tin always matches the first entry so
yields the beast form, but all their beast forms are flagged as
no-corpse so the wish would fallback to a corpse with random monster
type. Wishing for werecreature figurine worked but always produced
one that created its beast form if/when activated.
This fix allows specifying "human werecreature" to match the second
entry. It's optional for corpse and tin; the wish code will now
switch to that implicitly if it gets a no-corpse were-form for
those. It has to be specified explicitly to get a figurine that
will activate as the human form. It works for ^G too.
name_to_mon() has a bunch of alternate monster names, such as
"gray-elf" to match "grey-elf" and "ki rin" to match "ki-rin". Those
worked as intended when they occurred at the end of a wish, but only
worked in the middle if their length was the same or one character
less than the canonical name in mons[].mname.
djinni figurine -> h - a figurine of a djinni
genie figurine -> i - a figurine of a djinni
figurine of mumak -> j - a figurine of a mumak
mumak figurine -> k - a figurine of a mumak
figurine of mumakil -> l - a figurine of a mumak
mumakil figurine -> nothing fitting that description exists
(The one-less case worked because its following space ended up being
implicitly removed when skipping ahead by the length of mons[].mname;
subsequent explicit removal didn't find a space so was a no-op.)
The bases[] array allows finding the index of the first object in
a particular class. Extend it so that bases[class + 1] - 1 is a
reliable way to find the last object in any class. The array had
to be extended by one so that the last class has a [class+1] entry
available, and object initialization now makes sure that classes
within objects[] are in ascending order so that [class+1] always
holds a higher index than [class].
Water locations on Medusa's level didn't show steam clouds. It
wasn't because the location was a moat rather than a pool, it was
because the moat location was unlit (and in line of sight) and
tested pool locations were lit. Poison gas clouds explicitly
override the lit/unlit issue but other region types weren't.
Pasi Kallinen [Sat, 18 Apr 2020 13:51:35 +0000 (16:51 +0300)]
Fix segfault on teleport while punished due to flooreffects
... deleting the ball & chain, but keeping a boulder in the pit.
Noticed a segfault when fuzzing, teleport while punished caused
a segfault via fill_pit -> flooreffects -> bury_objs -> unpunish,
and then the next line in teleds tried to look up uchain.
Guard against that particular case.
Fix the case of boulder being in a pit, triggered by you being in
a pit and a giant throwing a boulder on top of you.
This adds a superset of the code from github pull request #328
to create a short-lived cloud of steam when fire hits a pool or
fountain. The original code required C99; this doesn't. It also
allowed vapor clouds on the Plane of Water where they don't work
sanely becaure regions don't understand air bubble movement and/or
vice versa. This inhibits the clouds there [the same ought to be
done for scrolls of stinking cloud]. It also left as-is the code
that reported when fountains got used up even though conceptually
the steam should interfere with being able to see that. This adds
a glyph-check hack to augment cansee() so that fountains that boil
away entirely are hidden at the time.
Regions that block line of slight should be calling block_point()
when created and unblock_point() when removed but a naive attempt
to introduce that didn't work as expected so I'm giving up on.
Screen erasure leaves the map set to spaces. If S_unexplored is
something other than <space>, tty wasn't drawing with S_unexplored
after a menu or long message line got erased following temporary
overwrite of part of the map.
This seems to work but is not the correct way to do things.
clear_screen(), cl_eos(), and cl_end() should all be taught to
flag the map as needing to be refreshed after they erase part of it.
tty_clear_nhwindow(WIN_BASE) is also lacking since it erases the
message line, full map, and status lines but leaves their internal
windows with stale data about what is shown instead of marking them
blank.
Pasi Kallinen [Thu, 16 Apr 2020 18:01:24 +0000 (21:01 +0300)]
Dehardcode the monk minetown food shop conversion
Instead of trying to figure out in core whether to change a minetown
food shop to health food shop for monks, just figure it out in the
minetown level creation script.
Make a mimic that picks special VEGETARIAN_CLASS look like food
instead of a random object. Also, at least a couple of Minetown
variants are classified as mazes so had a 50% chance of not even
making that choice and look like a statue instead. Override maze
when 'in_town()' yields True.
When a food shop gets converted into a health food shop (minetown
when playing as a monk), the shop type and underlying room type
weren't changed to match.
This started with fixing a warning suggesting parentheses when
mixing || and &&, then started sprawling. The getpos help for x/X
was misleading. It said that using x or X would move cursor to the
next unexplored location but it actually moves the cursor to next
explored location that's adjacent to an unexplored one.
Pasi Kallinen [Wed, 15 Apr 2020 08:02:33 +0000 (11:02 +0300)]
Mimic in a health food store could cause a panic
Health food stores use a special "vegetarian class" of items,
which mkobj doesn't understand. Just make the mimic use a random
item class in that case.
copperwater [Mon, 28 May 2018 23:36:23 +0000 (19:36 -0400)]
Change logic for immobilized displacement, fixing a bug
The bug was that you could easily displace peaceful sleeping monsters.
The source of this was that there was no check for sleeping in the
attack() function that checks for immobilization.
As well as adding the sleeping check, this logic is modified so that it
makes more sense: if a monster is immobilized at all (sleeping, frozen,
or mcanmove = 0) it always "doesn't seem to move!" You can't randomly
displace it anyway 1/6 of the time.
Sessile monsters who are otherwise not immobilized don't move 5/6 of the
time, but can be displaced with the other 1/6.
copperwater [Tue, 20 Mar 2018 16:17:38 +0000 (12:17 -0400)]
Pet displacement improvements
Pets can no longer be displaced out of a trap, because that was
inconsistent with peaceful monsters refusing to be displaced out of a
trap. The untaming-via-displacement-out-of-trap code is removed.
Pets also now have a better survival instinct: they follow the code for
peaceful displacement into a bad position, and refuse to swap places.
This means it's no longer possible to accidentally kill a pet by
levitating/walking over water and displacing it.
copperwater [Mon, 12 Mar 2018 02:20:32 +0000 (22:20 -0400)]
Fix: rn2(0) when trying to displace peaceful out of trap
A side effect of making is_safepet() count peacefuls. Now checks
directly for a trapped, peaceful monster and says "they can't move out
of the trap"; this is inconsistent with pet behavior, and pet behavior
should probably be changed to be in line with it (ie they can't be
displaced out of a trap at all.)
Also refactor the code here a bit: a bunch of different if statements
have the exact same resetting code and steed resetting code in them.
Change this to a boolean flag and put the resetting code in one place
checked by that flag.
copperwater [Sat, 24 Feb 2018 04:02:29 +0000 (23:02 -0500)]
More peaceful monsters that can't be displaced: priests, Oracle
Shouldn't be able to displace priests since that could theoretically
eventually force them out of their temple, which would probably cause
problems. The Oracle doesn't usually move anyway, but seems like she
should "not want to swap places" in any circumstance.
copperwater [Fri, 8 Dec 2017 04:26:17 +0000 (23:26 -0500)]
Player can now displace peaceful monsters
Changes domove() code to allow displacing peaceful monsters.
Specifically, is_safepet() now returns true if the monster is peaceful.
Peacefuls are slightly pickier than pets about whether they consent to
being displaced: they will not displace if a goodpos() check fails for
the displaced space, or if there is a trap on the displaced space, or if
they are your quest leader. is_safepet should probably be renamed to
something else.
In the process of doing this, some other changes were made: the code now
checks whether the player and monster should be swapping places at all
first (previously it ran some code for displacing pets out of traps
first, which was a little weird if the displacement didn't actually
happen.)
In the original commit for this, I needed to guard the spoteffects()
call made in domove with a clause testing whether the player actually
moved; it was previously possible to fail to displace a monster and then
re-trigger a trap on the space you were still standing on. However, the
devteam has apparently put in an if (u.umoved) clause in the same place
and serving the same purpose.
Pasi Kallinen [Wed, 15 Apr 2020 04:15:37 +0000 (07:15 +0300)]
Fix "x" and "a" when choosing map location
Recent(ish) change to split unexplored glyphs from solid wall glyphs
resulted in getloc commands to choose unexplored and interesting
locations not work correctly.
Allow specifying a montype on figurines in lua files
This was already allowed for the other montype-compatible objects like
statues, corpses, eggs and tins. I don't see a reason why figurines
shouldn't be part of this group; perhaps it was an oversight.
Move demon summoning and were creature summoning out of mattacku()
to a separate routine. Should be no change in behavior.
Also, redo several comments that came after what they applied to
rather than before, and reorder the file-scope prototypes to be in
the same order as the corresponding functions.
When rest and search refuse to operate because a hostile monster is
adjacent, include a reminder of how to force them to operate. Every
time if 'cmdassist' is On, or just once until after some subsequent
try actually does something.
This new rest and search behavior probably needs to be optional and
default to the old behavior. It isn't uncommon to deliberately rest
while adjacent to a hostile monster if also adjacent to a peaceful
one and trying to wait for Stun or Confusion to time out, or maybe
search while next to such a monster hoping to find a secret door to
run away through. A count prefix won't work and needing an extra
keystroke each time is going to be an annoyance.
When polymorphed into a nymph and melee hit steals items from the
target, the same-gender charm message vs opposite-gender seduce
message is being chosen by hero's base gender rather than nymphs
always being female. The seduce message used dynamic pronouns for
the target monster but the charm message used hardcoded She and her
for female nymph attacking female target. I'm not sure why hero's
base gender is used so left that alone; this changes charm message
to use dynamic pronouns that correctly match the target monster.
Pasi Kallinen [Mon, 13 Apr 2020 18:49:16 +0000 (21:49 +0300)]
Scatter bag of holding contents instead of deleting them
Losing all of your items in one go is really frustrating.
If you blow up your bag of holding, make the contents scatter around
instead of outright deleting them. This will destroy fragile objects.
Pasi Kallinen [Mon, 13 Apr 2020 16:59:03 +0000 (19:59 +0300)]
Allow matching any wall map terrain in lua scripts
When matching a terrain, allow using a "w" placeholder that matches
any solid wall:
For example:
local s = selection.match([[w.w]]);
would match all floor locations with a wall to the left and right of it.
The walls can be solid stone, horizontal, vertical, etc.
This applies to selection.match(), selection.filter_mapchar(), and
des.replace_terrain()
Pasi Kallinen [Sun, 12 Apr 2020 14:21:23 +0000 (17:21 +0300)]
Prevent searching or waiting next to a hostile
Generally speaking there's no reason to wait or search next to
a hostile monster, so let's just prevent those actions. You can
still do those commands by prefixing them with the 'm' prefix.
Instead of just picking up wands of undead turning when one or more
corpses are in hero's inventory, have monsters also pick those up if
hero has a cockatrice corpse in a carried container. And instead of
only zapping such wands (as defensive measure) when hero is wielding
a cockatrice corpse, also zap them (as offensive measure) if hero is
carrying any corpse in open inventory.
Testing a forthcoming extension of monsters using wands of undead
turning revealed a couple of pre-existing bugs. Previously only
noticeable if hero zaps self or breaks a wand of undead turning so
unlikely to have happened much.
"Your <mon> corpse comes alive" was given even if it was revived
as an undead. Also, it was "your <mon> corpse" instead of "one of
your <mon> corpses" even when one from a stack was involved. If
done by hero to self that message follows "one of your <mon>
corpses glows iridescently" so the comes alive message was ok but
verbose. Change that to "it comes alive" or "it reanimates" when
following the glow message.
when hero is wielding a cockatrice corpse. Wands of undead turning
aren't generated as starting equipment but they will now be picked
up if come across while the hero is carrying any corpse, and used
in preference to any other item when carried and non-empty and hero
is wielding a petrifier's corpse.
m_lined_up() was declared 'boolean' but returned 0, 1, or 2.
The 1 case isn't actually used any more. I changed it to 'int'
rather than 2 to TRUE; it could just as easily be the other way
'round.
Avoid giving "you are back on the bottom" nearly every step when
moving around underwater.
Avoid "you are back on floor" followed by "you trip over <object>"
when fumbling in case that fumbling was due to being on ice when
taking the step to floor. Done for all fumbling rather than just
one-turn fumbling instigated by ice.
When moving from ice or water to ground, show "you are back on floor"
before listing objects at that spot instead of after.
I think there was at least one more thing but have lost track. At
any rate, 'mention_rate' potentially has a new set of bugs.
"You materialize at another location," was delivered while the
previous location still controlled line of sight. Very noticeable
if you started from underwater and landed on the surface in an area
which hadn't been mapped yet.
The fix to try to avoid messages about out-of-view objects taking
erosion damage made water_damage_chain() vulnerable to dereferencing
a null pointer, leading to a crash if you create a pool via wizard
mode wishing.
Eating a tin of one of the Riders and being life-saved or declining
to die would crash when trying to revive a non-existent corpse. An
old comment stated that since such tins were impossible it could
assume that it was dealing with a corpse, but wishing for tins of
the Riders is possible in wizard mode.
They can't be passed along to normal mode via bones because they're
changed to empty tins as bones are saved. So there doesn't seem to
be much point in allowing wizard mode wishing to create them, but
I've left that as is.
I got "The chain mail rusts." seemingly out of the blue, then when
moving around the corner of the building on Valk home level I saw a
spot of remembered ice be redrawn as water. Before that I checked
for any mapped objects (via ';' 'o' 'o' ... so I didn't overlook
anything; there were only a couple of objects shown on the map and
none of them were piles) and didn't see any remembered chail mail or
anything at all on that ice spot, so I'm assuming that it was carried
by a monster. I may be leaving out some steps in the call chain here:
erode_obj() uses bhitpos for visibility check of eroding objects not
carried by the hero or by a monster, with a comment expressing doubt
about doing that. It wouldn't have yielded the right answer for the
possible call chain here unless it got set by some monster activity.
I had been zapping a wand just before and bhitpos would have been set
to a coordinate I could see at the time, fooling erode_obj()'s check
if the value was stale.
Anyway, this only addresses objects eroded from flooreffects(),
water_damage_chain(), and fire_damage_chain(). There are lots of
other indirect calls to erode_obj().