Nearly same code was in two places - the only difference was
how g.context.run == 1 was handled. Previously, if you were
blind, and knew about the water or lava, you still ran into it.
Now, we always avoid the dunking if running/rushing.
Instead of returning monster's mtrapped-state, return specific
trap return values.
Add one extra trap return value, for when a monster was
moved by the trap.
In the name of accessibility: Prevent moving into dangerous liquids.
Now with themed rooms, water and lava are more common, and it's
unreasonable to expect blind players to check every step for those.
With paranoid:swim, just prevent normal walking into those liquids,
unless you prefix the movement with 'm', or if the liquid would not
harm you.
Doesn't completely prevent an accidental dunking - for example
if the hero is impaired or couldn't see the liquid.
This comes from xNetHack by copperwater <aosdict@gmail.com>
with some changes to the code.
Log game events, such as entering a new dungeon level, breaking
a conduct, or killing a unique monster, in a new "Major events"
chronicle. The entries record the turn when the event happened.
The log can be viewed with #chronicle -command, and the entries
also show up in the end-of-game dump, if that is available.
This feature is on by default, but can be disabled by
defining NO_CHRONICLE compile-time option.
This also contains "live logging", writing the events as they
happen into a single livelog-file. This is mostly useful for
public servers. The livelog is off by default, and must be
compiled in with LIVELOG, and then turned on in sysconf.
Mostly this a version of livelogging from the Hardfought server,
with some changes.
The "water" terrain (as used on the Plane of Water) behaved
strangely outside the plane. Make it behave a bit more consistently,
although it's still not really usable elsewhere.
The rationale here being it's a solid wall of water.
Firstly, disable levitation and flying (which was already done
when moving into the water on the Plane of Water), and moving into
it refers to it as a "wall of water" to make it clear it's a solid
block of water.
Bumping into an unseen wall reported "a wall" instead of "solid stone",
even though you could not know it was a wall when looking at it.
Use the same method when looking at glyphs on the map instead of
the map location type.
Fixes#318
Instead of returning 0 or 1, we'll now use ECMD_OK or ECMD_TURN.
These have the same meaning as the hardcoded numbers; ECMD_TURN
means the command uses a turn.
In future, could add eg. a flag denoting "user cancelled command"
or "command failed", and should clear eg. the cmdq.
Mostly this was simply replacing return values with the defines
in the extended commands, so hopefully I didn't break anything.
Follow up on some old groundwork. For tty, if the core has designated
a message as 'urgent', override any message suppression taking place
because of ESC typed at the --More-- prompt. Right now, "You die"
messages, feedback about having something stolen, feedback for
"amorous demon" interaction (mainly in case of armor removal), and
exploding a bag of holding are treated as urgent.
The "You die" case is already handled by a hack in top-line handling;
I left that in place so the conversion of 3 or 4 pline("You die.*")
to custompline(URGENT_MESSAGE, "You die.*") was redundant. There
are probably various non-You_die messages which precede done() which
should be marked urgent too.
Other interfaces might want to do something similar. And we ought to
implement MSGTYPE=force or MSGTYPE=urgent to allow players to indicate
other messages that they want have to override suppression. But I'm
not intending to work on either of those. I mainly wanted to force
the magic bag explosion message to be shown since a sequence of "You
put <foo> into <bag>." messages is a likely candidate for --More--ESC.
Teleporting a monster only updated the map. Give a message
so blind players can get the same information.
Making a monster invisible gives the same message, if you
cannot detect invisible.
Several other places where monsters teleported themselves
now also give the same message.
The pull request by argrath changes weight_cap() to never return a
value less than 1 because try_lift() divides by that return value
and a 0 would trigger a crash. The code involved is used when
attempting to pull a monster out of a pit via #untrap.
I'm fairly sure that weight_cap() can never produce a value that's
less than 1 already, but have put in a variation of the PR's fix.
I've also implemented a different fix that removes the division
from try_lift(). The original code seems to have gone out of its
way to avoid calculating inv_weight() twice, but doing the latter
(for the once in a hundred games where it might happen) greatly
simplifies things by removing details of carrying capacity.
Fixes#621
Reported by G7Nation; attacking walls and such with a polearm just
gave lackluster "you miss; nobody's there" feedback.
Make applying a polearm at some non-monster locations give feedback
similar to using 'F'orcefight with melee weapons. Was
|You miss; there is no one there to hit.
now
|You uselessly attack the closed door.
Also, extend the supported locations to include dungeon furniture.
Was
|You attack thin air. ('F')
now
|You harmlessly attack the throne. ('F')
|You uselessly attack the throne. ('a')
This doesn't address #613: attempting to hit non-visible locations
with an applied polearm.
Closes#614
Reported by entrez, wielding something fragile (potion of acid
perhaps), and using F to smash it against iron bars called breaktest()
directly, then a second time indirectly through hero_breaks() via
hit_bars(). There is a random chance to resist breaking (99% for
artifacts, 1% for other items) so breaktest() might say that something
will break on the first call and that it will not break on the second
call, or vice versa. That could remove uwep from inventory then leave
it in limbo without destroying it, or destroy uwep without removing it
from inventory first triggering impossible "obfree: deleting worn obj".
Reported directly to devteam by entrez via email:
>
> I noticed some potential issues with (melting) ice:
>
> * Digging down into ice, or setting a land mine on the ice and
> triggering it, doesn't remove the melt_ice timeout, so it can result
> in a sequence like dig down -> pit fills with water -> freeze water
> -> freezing water tries to set melt_ice timeout -> duplicate timeout
> impossible. Or if you don't freeze the water again, melt_ice will
> run on a non-ice surface, which might at least produce strange
> messages.
>
> * Setting a land mine on ice: melting ice doesn't do anything with
> the trap, so there is still a land mine which you can trigger by
> flying over the water (the land mine's trigger is also still
> described as being 'in a pile of soil', despite being underwater at
> this point). Similar thing happens with bear traps.
>
> * Not really related to _melting_ ice, but an exploding land mine
> doesn't reset the typ from ICE to FLOOR (like normal digging does),
> so it will result in a square with a pit that is also an ice square,
> where the ice can melt under the pit and produce a combination
> pit/moat. If you then freeze the moat, the pit reappears on top of
> the ice.
If the hero can move to a boulder's location via m<dir>, allow travel
to do so too. You will always stop on the boulder spot rather than
keep going toward the destination because of change in visibility at
a boulder spot.
Giants should be able to see over boulders, and doing that for poly'd
hero would probably be straightforward, but when not poly'd, seeing a
giant beyond a boulder and vice versa seems like it would be a can of
giant-sized worms.
A couple of other miscellaneous changes are mixed in with this.
https://github.com/NetHack/NetHack/pull/573 by entrez
Pull request comment states:
"Moving into a position containing a warning symbol with m-<direction> to
'safely' move would still attack as though the 'm' prefix was not
specified. Ensure warning symbols are counted as 'detected' monsters
for this purpose, to avoid falling through to do_attack()."
Closes#573
Revise the m<dir>-toward-boulder handling to let a hero who would be
able to squeese into the boulder's spot if it was blocked from being
pushed to do the squeeze without any pushing.
Unlike the previous changes, this might have an impact on play. It
allows squeezing under then stepping past an unblocked boulder that's
in a corridor in order to be able to push it back the other direction
where maybe there's more room to maneuver it out of the way.
Allow a hero polymorphed into a giant to move to a boulder's spot
via m<dir> no-pickup move, instead of having to push it until the
way is blocked by something and then having push failure move hero
to the spot.
Also change m<dir> when not a giant to no longer push the boulder.
No time will elapse when not moving unless hero who didn't know
that there was a boulder there learns that one is. Since no actual
push attempt gets performed, player doesn't learn whether there is
anything beyond the boulder that inhibits it from being pushed.
When you push a pile of boulders, describe the second and remainder
as "the next boulder" rather than just "the boulder". Matters most
when pushing into water or lava and you keep on pushing when the
first one or more sink into the pool or plug it, but also matters
for an ordinary push where the top-most one moves successfully and
then blocks the continuation attempt to push the second one. It was
somewhat confusing when all the messages said "the boulder" whether
they were referring to the same boulder or different ones.
Multiple pushes on the same move has always been a bit odd, but this
doesn't change that, just the feedback it generates.
