Be prepared for life-saving to contradict "<mon> falls to pieces".
Purely hypothetically at present (with no plans to change) since
golems don't benefit from amulets of life-saving.
ignitable() was excluding magic lamp and then every place that
used it did so as 'ignitable(obj) || obj->otyp == MAGIC_LAMP'
so just include magic lamp.
I noticed that while hunting for an explanation for report #K2734
where returning to a previously visited level triggered the
warning "begin_burn: unexpected eggs". I've decided that the
zombie apocalypse is probably the cause. It inserted a new type
of timer in the list of such but it didn't bump EDITLEVEL to
invalidate save and bones files which relied on indices into the
old list. I'm not sure whether we should bump that now.
... on the floor, in monster inventory, and in hero's inventory.
Items in your inventory being ignited produce a message even if you're
blind - you can see the lit-state by viewing inventory anyway, so just
give player the message.
(via xNetHack)
Track sokoban cheating (taking actions that incur a luck penalty).
The pull request only reported the number of times (possibly zero)
that the player broke nethack's sokoban rules when reporting the
"you obtained the Sokoban prize" achievement, which is when the
count is most meaningful, but this implements it as a full-fledged
conduct instead. This way the #conduct command can be used after
"creative nethacking" to check immediately whether an action has
violated the Sokoban rules so a player willing to put in a bit of
effort can eventually learn which actions have a negative impact.
The new conduct is only shown during games where the character has
entered the Sokoban branch, but once that has happened it gets shown
no matter the location at the time of #conduct or end of game.
Most of this wasn't in the pull request: expanding the Guidebook to
give more information about sokoban and its conduct.
Bump EDITLEVEL to invalidate to-be-3.7 save files because u.uconduct
has been extended.
Fixes#355
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.
Fixes#340
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.
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:
melt_ice -> minliquid -> mondead -> m_detach -> relobj -> mdrop_obj
-> flooreffects -> water_damage -> erode_obj
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().
Instead of having the demon lair levels unconditionally no-teleport,
grant demon lords and princes the ability to suppress teleportation
in Gehennom on the level they are on.
Setting or clearing u.ustuck now requires that context.botl be set,
so make a new routine to take care of both instead of manipulating
that pointer directly.
teleds() is used for more than just teleportations, the teleportation message
was also given when mounting a steed.
Trying out a new bit flags method parameter design pattern.
Use trapname() in several more places. I wasn't systematic about it.
trapname() could generate a random value of 0 and attempt to use
"real trap #0" but 0 is NO_TRAP. So it ended up with "water" from
the preceding block of entries in defsyms[]. Treat 0 as an extra
chance for the actual trap instead of an hallucinatory one.
Add a couple more hallucinatory traps. "Roach Motel" is trademarked
but like Spam and Band-Aid, general usage has trampled over it. I
included "(tm)" anyway. Also, sometimes generate "<role> trap" or
"<rank> trap" on the fly. Why should tourists get all the fun?
Some new code was using 3.4.3 era formatting (operators at end of
first half of a continued line rather than at start of second half).
Also a few cases of 'g.' prefix making lines be too wide. I imagine
there will be a lot more of these over time.
This adds a boolean option, autounlock, defaulting to true. When this is
set to TRUE, messages stating that some door or container is locked are
automatically followed by a prompt asking if you would like to unlock
it, if you are carrying an unlocking tool (key, lock pick, or credit
card).
Architecturally, this extends the pick_lock function to take three
additional arguments (door coordinates or a box on the ground you are
autounlocking).
The code that selects an unlocking tool will always look first for a
skeleton key, then a lock pick, then a credit card. Since curses, rust,
and other attributes don't really have an effect on the viability of the
unlocking device, it didn't seem to warrant making a more complex
function for that.
Add hallucinatory trap names
This adds many funny, realistic, and nonsensical traps to the game, to
be shown when the player is hallucinating.
Architecturally, the biggest change is merging the what_trap macro and
the "defsyms[trap_to_defsym(ttyp)].explanation" pattern into a single
function "trapname", which returns the name of the trap, handling the
hallucination case. There is also a second parameter used for overriding
hallucination in the occasional cases where the actual trap name should
always be returned.
In addition, the what_trap and random_trap macros are now obsolete and
not used anywhere, so they are removed.
reinstate anti-rng abuse bit on hallucination
updates to hallucinatory trap names and fixes37.0 entry
Poly'd hero hiding on the ceiling was told "you can't go down here"
if using '>' at a spot that didn't have down stairs, trap door, hole,
or pit. Let '>' bring a ceiling hider out of hiding; lurker above
resumes flying, piercer falls to floor or whatever is underneath it.
Fix some issues noticed when experimenting with ceiling hiders.
They're all blind (at least without the monks' Eyes) and some of
the behavior while blind seemed to be incorrect (though some that
I thought was wrong turned out to be ok; feel_newsym() won't update
the map if the hero can't reach the floor). Fixing that made me
notice that some terrain side-effects (being underwater or stuck in
lava) weren't getting disabled when the underlying terrain wasn't
the corresponding type anymore.
When you ride your steed into a polymorph trap and it changes into a
creature that can still wear the saddle, the message is
|You have to adjust youself in the saddle on <foo>.
which sounds as if the game is telling the player that he or she needs
to do something. Simplify it to
|You adjust yourself in the saddle on <foo>.
Submitted for 3.7.0; all but one also apply to 3.6.3.
I rewrote the curses terminal-too-small message instead of just
fixing the spelling of "minumum".
With 3.7+ aspirations of improving savefile interoperability between 32-bit
and 64-bit builds, as well as between platforms, it is better to not have
the underlying struct/array content be conditional.
This splits off some of the MAIL code into MAIL_STRUCTURES code. In theory,
since MAIL_STRUCTURES is unconditionally included, the macro could
just go away and leave that code unconditional, but this commit doesn't
go that far.
Flag existing occurrences of "You hear" as "Deaf-aware" so
that a grep for that string in the future doesn't need to
trigger further investigation of those.
In launch_obj, the code first got the trap, then called ohitmon
(which can delete the trap by doing mondied -> fill_pit ->
flooreffects -> deltrap), then after that used the trap variable.
Zapping wand of opening or spell of knock at self while trapped:
"You are released from pit."
ought to be
"You are released from the pit."
Likewise for most of the other held-in-place situations.
Also, when released like that vision wasn't being recalculated right
away to update line of sight to reach beyond the edge of the pit.
