- add a themeroom with random buried zombifying corpses
- disturbing buried zombies makes them revive much faster
- lua des.object() now returns the object it created
The prior behavior was an ugly kludge that treated rumors as
only-eligible-to-appear-from-fortune-cookies if they contained the
string "fortune" or "pity". This commit gets rid of that system and
introduces a system where each rumor can be specified as such by
prefixing it with "[cookie]".
In order to avoid changing existing behavior, I have applied the
[cookie] prefix to all the rumors which were affected under the old
rules. However, several rumors seem like they were misclassified under
the old rules, and I am in favor of changing them as follows:
Should be made cookie-only (they only really make sense in context of
eating a fortune cookie):
- "Ouch. I hate when that happens."
- "PLEASE ignore previous rumor."
- "Suddenly, the dungeon will collapse..."
- "Unfortunately, this message was left intentionally blank."
Should be made non-cookie-only (they make sense if they appear as
engravings, Oracle messages, or artifact whispers):
- "They say that a gypsy could tell your fortune for a price."
- "They say that fortune cookies are food for thought."
Every other case I'm aware of where a visible monster that the hero can
see turns invisible has some associated message, but not when zapping it
with the wand of make invisible and lacking see invisible. This adds a
message "[monster] vanishes!" in this case, which is the same as the
most common message one gets for zapping a monster with teleportation,
by design to keep the wand's identity ambiguous.
Technically, prior to this commit, there was a leak of information if
one zapped a wand that made a monster disappear: the identity of the
want could be determined immediately by the presence or absence of a
vanishing message. Practically, though, it was easy to check if there
was a new invisible monster in the same spot or not.
Also, zapping teleportation at a monster and having it land somewhere
visible to the hero now has attention explicitly drawn to it with a
message (in prior versions it didn't, so it could potentially be a
different monster appearing by some other means), so I additionally made
the wand of teleportation automatically identify itself when the hero
sees the monster appear as a result of their zap.
Reverse part of commit 4021a63bcf
"wand/spell/breath killer reason" so that wand of magic missile
zapped by a monster isn't ambiguous about who is responsible.
Setting protection from shape changers via wizintrinsics
caused a sanity error on the next turn, if any monsters affected
by it were in changed shaped on the level.
Call rescham after setting the timeout, so the monsters will
immediately revert to their own form.
Making the zeroing out of memory used by an object that is about to
be freed unconditional, and do the same for monsters. Should never
matter aside from an undetectable amount of extra overhead.
If standing at the location of a closed door while having Passes_walls
ability, attemping to open that door with 'o' reported "you don't find
anything here to loot".
Using 'o' to loot for direction ./>/< is intentional but it ignored
the possibility of there also being a closed door present. When the
latter applies, only switch from open to loot for direction '>' so
that '.' (and '<') will open the door. Doesn't matter for creatures
that can ooze under a closed door--trying to use 'o' gets rejected for
them because they lack hands.
Also allow hero in Passes_walls form to use 'c' when at open door spot.
(For creatures that ooze under doors, 'c' is rejected just like 'o'.)
Unrelated: fix a typo in a recently added comment.
While fuzzing, the game got stuck here trying to generate
a random stoneable monster for a Medusa level statue.
I didn't investigate deeper why it failed to find a matching
monster type.
Fix the duplicate feedback given when landing on one or more items
after teleporting out of lava.
This also avoids "you find yourself back on solid water" if you are
able to survive at a water location and safe_teleds() puts you on one.
relocate surface(), ceiling(), and avoid_ceiling() to dungeon.c
adjacent to has_ceiling() etc.
astral and fire, like airlevel and waterlevel return FALSE
for has_ceiling()
if a caller does happen to call ceiling() on fire level,
return "flames above"
if a caller does happen to call ceiling() on quest level,
return a more-generic "expanse above", instead of the
word "ceiling"
add "stairs" return to surface()
remove recent update to engrave.c to special-case "stairs"
since surface() will return that now
Consolidate a couple of makemon() calls. I thought that this would
end up being clearer but it isn't actually much of an improvement.
Should be no change in behavior.
The overly simplistic fix to prevent pets from picking up objects
while they were busy eating had unwanted side-effects, making them
seem to be paralyzed in some situations such as #chat. Reverse the
recent change done in commit 754e9333f5
("fix pet picking something up while eating") and handle it in the
pet pick-up code instead.
Refine the fix #K3888 by moving multiple instances of the check for
cancel_don() from destroy_arm() to one instance in wornarm_destroyed().
Should be no change in behavior.
Report was for spell-casting monster using the destroy armor spell on
hero's levitation boots while hero was floating over lava. The boots
became unworn but still in inventory, hero dropped into lava, the
boots happened to be an inventory item which got burned up, then the
call stack unwound back to the destroy armor routine which tried to
finish by deleting them but they were already gone by then. Could
also happen for black dragon breath, hero reading scroll of destroy
armor, or overenchanting the boots with scroll of enchant armor, so
not so unlikely that nobody would be expected to notice.
Initially I couldn't reproduce the object lost panic. It only happens
if the memory used by the boots is cleared or clobbered during first
time it's freed, otherwise second free doesn't notice any problem.
The 'wornarm_destroyed()' portion of this commit is sufficient to fix
this. The other bits are things I tried before figuring out how to
reproduce it, plus zeroing out any object passed to dealloc_obj().
Defining des.object({ id="large box", locked=false })
was the same as random locked state. Make it actually mean unlocked,
and not defining locked at all means random.
To get the Magic Mirror of Merlin to speak, you could apply it in
any direction (or wield it). To get the Master Key of Thievery to
speak, you had to apply it toward an adjacent doorway or down while
on a container (or wield it). Make the key behave like the mirror.
When a genetic engineer polymorphs someone it normally teleports away.
Also set mspec_used so that it can't polymorph someone [else] on its
next turn, it case of a no-teleport level or it happens to randomly
land adjacent to the target.
Previously the fuzzer usually stayed in the Dungeons of Doom,
only very rarely going to other dungeon branches. Now, it will
randomly choose a dungeon branch and a level in that branch
to level teleport to.
Special level creation could make levels with boulders on top
of lava or water; this was caused by mazewalk populating the maze
before the rest of the level was created.
Add a post-level-creation map cleanup routine, where boulders
and traps on liquid terrain are removed.
If asked to create an Angel when MM_EMIN isn't specified, makemon()
will either create an ordinary monster of type Angel without any
emin extension or add emin and create a minion affiliated with the
god for randomly chosen alignment. Figurines didn't specify emin
so could result in either type, but wishing for them offered no
opportunity to specify alignment for the second type.
Change figurine activation to force the first type: an ordinary
monster of type Angel, not affiliated with any particular deity.
Add "again" to the hit message when an attack sequence has
consecutive attacks of same type and they hit. A {bite, claw, claw}
sequence won't give that for first claw attack regardless of whether
the bite hits but will give it for the second claw attack when both
of the claw attacks hit.
The message sequence
|The fire ant bites! The fire ant bites! You're on fire!
or |The fire ant bites! The fire ant bites! You avoid harm.
when the first bite was for physical damage and the second was
for fire damage seemed a little confusing.
This changes that to be
|The fire ant bites! The fire ant bites again! You're on fire!
or |The fire ant bites! The fire ant bites again! You avoid harm.
It still isn't crystal clear that both bites are from a single
attack and that the second bite is for different type of damage
but I think it's an improvement.
Many damage handling routines were calling mhitm_mgc_atk_negated()
in advance so that the result could be used for u-vs-m and m-vs-u,
and m-vs-m variations of an attack. But the monster versus you case
called hitmsg() to deliver a "<mon> <bites, claws, &c> you" message
after that. When the negation checking routine recently began
issuing messages for some types of damage, they would be delivered
before that hit message when your armor/jewelry negated its damage.
|You avoid harm. [when MC is about to block the shock]
|The grid bug bites. [bite for electric damage]
or
|The fire ant bites. [for physical damage]
|You avoid harm. [when MC is about to block the fire]
|The fire ant bites. [second bite for fire damage]
This fixes the sequencing issue at cost of making the code become
even more complicated. It will probably require further refinement.
Be more consistent with the engulf attack feedback by creatures who
fold themselves around the victim (trapper, lurker above) rather than
swallow or directly engulf.
Replace an instance of a non-literal format string and the warnings
manipulation it needed with a literal one.
Adjust the message given when an attack knocks its target back. Say
|<defender> is knocked backward by <attacker>
if target will actually move or
|<defender> is knocked back by <attacker>
if there's something preventing the move. Most players probably won't
even notice the difference. (Possibly "rocked back" would be better
when not changing location but this hasn't gone that far.)
Also make the knock back distance be 1 step 2/3 of the time or 2 steps
1/3 instead of 50:50 chance for 1 or 2 steps.
I happened to notice when looking at a ttyrec that farlooking
with automatic description would blink the cursor on hero for
one frame, and then back on the farlooked map location.
Using #retravel when no destination was set up just silenty finished,
effectively a no-op. Could happen for the first travel attempt on
the current dungeon level, or after most recent #travel successfully
reached and cleared its destination.
Using #retravel when already at previously set but unreached--via
travel--destination, or explicitly picking your own spot as travel
destination using #travel, actually traveled from your current spot
to the same spot. Usually nothing interesting occurred and you got
no feedback. However, if you happened to be stuck in a trap at that
spot you tried to walk out of it and got trap feedback about that.
(Then probably right back into the trap if you succeeded in escaping
it. I didn't try to test that.)
