It was silly how some clearly mechanical traps didn't consider
flight or levitation when to trigger. Do those checks in dotrap/mintrap
making hero and monster trap triggering match more closely.
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.
For testing mhurtle, which is used for jousting or
bare-handed combat.
Improve mhurtle_step to handle bumping into another monster,
and when the monster gets killed or stuck in a trap.
If the first monster the hero kills is killed by the hero's first hit
with a wielded weapon, report the hit first and kill second instead of
the other way around. Not as hard to manage as I feared, but bound to
be more fragile than the simpler handling that produced the odd order.
Also while testing it I knocked something into a polymorph trap and it
changed form without any feedback. Give foo-changes-into-bar message
if the hero is moving and can see it happening. It isn't needed with
a monster moves deliberately into a polymorph trap but probably would
be useful when that's is unintentional.
The "<hero> enters the dungeon" log message had a trailing period but
other log messages don't have sentence punctuation, so take that off.
When a thrown item lands in a pool of water, it immediately
rusts - but don't give that message unless the hero is at the same
location and also under the water. My reasoning: hero can't see items
under water, and by the time the item rusts, it's in the water.
The wall of water goaded me into updating waterbody_name(). It's
mostly the same, aside from being moved from mkmaze.c to pager.c and
adding "{wall of|limitless} water" instead of plain "water" for WATER
terrain. I'm not very happy with "limitless" for the Plane of Water
because limits imposed by air bubbles are all over the place. "Wall
of water" might work ok for that level.
Water on Medusa's level is now described as "shallow sea" rather than
lame "water". The two unusual pools on the Samurai home level are
described as "pond" rather than previous "water" which replaced 3.6's
ridiculous "moat". When lava is hallucinated, it is described as
"molten <substance>" (yielding silly things like "molten yoghurt"),
rather than just "<substance>" to distinguish it from hallucinated
water. 'autodescribe' doesn't use waterbody_name() though.
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.
Implement the suggestion that falling rock traps and rolling boulder
traps be harmless to xorns. I've extended that to all missiles made
of stone (rocks, gems, boulders, a handful of other things that will
only matter if poly'd hero throws in '<' direction or is hit by stuff
scattered by an explosion).
I excluded ghosts because they would become even harder to kill and
the missile handling would need extra checks to test for blessed objs.
If you want to declare a pointer which the address pointed to is constant,
you should declare it as like `static const char *const var = "...";`.
This commit supplies missing `const` and prevents some programming
error in the future.
When a flying hero deliberately "swoops" through a trap door or hole,
consider the movement down to the next level to be controlled flight
rather than falling, preventing the sort of inadvertent touching of a
carried cockatrice corpse that happens when falling between levels.
Always give a message when creating a detected monster
during gameplay (as opposed to during level creation).
To prevent the message, use the MM_NOMSG flag for makemon.
Most places already handled their own messaging, but there
were some, such as bag of tricks, create monster magic
and random monsters created during gameplay that didn't.
Elbereth was fading when offscreen monsters stepped into
pits or holes dug elsewhere on the level. This was happening
because monsters falling into traps set by you were calling
setmangry() as if you had just attacked them. The behavior
made it unsafe to use Elbereth if you've dug down anywhere
else on the level, making it a bit harder to get archeologists
off the ground.
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.
Replace some
(foo &&
bar)
that had crept back into the code with
(foo
&& bar)
to match the reformatting which took place before 3.6.0. There are a
couple of lines ending in '||' still present but they look intentional.
isaac64.c has some trailing '|' bit operators that could/should be
moved to the start of the next line but I didn't touch that file.
While in the affected files, I tried to shorten most overly wide lines
(the right margin is supposed to at column 78 and there are quite a
few lines which are 79 characters long, but I left most of those
rather than introduce new line splits). Also replace a handful of
tabs with spaces. I was a little surprised not find any trailing
spaces (in the dozen or so files being updated). I didn't look for
trailing arithmetic or '?'/':' operators which aught to be moved to
the start of the next line.
Keep track of the highest value that u.uhpmax and u.uenmax have
attained, in new u.uhppeak and u.uenpeak. They aren't used for
anything yet. u.mhmax (max HP while polymorphed) isn't interesting
enough to track.
Not save and bones compatible so increments EDITLEVEL.
Reported by Vivit-R, the chance of freeing a monster from being
trapped in a web was very small and failure resulted in creation of
a new web at the hero's spot, eventually making it impossible to
attempt to #untrap the monster (if hero escaped the new web and moved
to another spot adjacent to trapped monster, eventually surrounding
it with webs). [That's actually misleading. Escaping the new web
but staying at the same spot lets the player try again; repeat as
needed.... But chance of failure still seemed way too high.]
This reduces the chance of failure from 29/30 to 6/7 and makes the
chance of spreading the web after failure be 1/3 instead of 100%. It
also supplies missing feedback about the monster still being trapped
if the attempt to make a new web fails.
Closes#608
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 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.
|..X..
|.X}X.
|..X..
When testing the odd Samuari moats, I discovered that you could
easily walk diagonally between any two of the solid stone pillars
and fall into the water but you would always drown because it's a
no-teleport level and the crawl routine wouldn't let you back out
via that same diagonal.
The crawl routine is also being used by travel for the last step--a
post 3.6 change--so there was an unnecessary restriction on diagonal
movement there too.
Revisited this feature, and the chance of a spider spinning a web
depends now on the number of webs already present on the level.
For a giant spider to spin a web in the middle of a room with no
supports, the limit of existing webs is 4, next to one support 9,
next to two supports 14, and so on. Cave spider limits are much lower.
Revive some code from 5 or so years ago that's been sitting in a
defunct local git branch. There are a couple of references to
figurines having gender; the old, unfinished code did already have
support for that, the current code doesn't. It probably won't take
much effort to add it in but I want to get this first part out of
the way.
Replace some of the
pmname(mon->data, Mgender[mon]) calls with simpler
mon_pmname(mon) and some
pmname(&mons[statue->corpsenm],
(statue->spe & CORPSTAT_GENDER) == ... ? ... : ...) with simpler
obj_pmname(obj). There are other instances of them which haven't
been changed but could be.
Dead monsters that had traits saved with the corpse would revive as
the same gender, but ordinary corpses revived with random gender so
could be different from before they got killed.
Since corpses of monsters lacked gender, those for monsters with
gender-specific names were described by the neuter name.
This is a fairly big change for a fairly minor problem and needs a
lot more testing.
Fixes#531
... and make them actually deal damage based on the energy
it would've drained, if you have Antimagic.
Also prevent them appearing too early in the dungeon.
Allow drain energy attacks (and anti-magic traps) drain more
than your level of energy.
Make eating magical monsters such as wizards and shamans give
the same tiny buzz bonus as eating a newt.
If monsters see you resist something, generally elemental or magical
attack, or if they see you reflect an attack, they learn that and
will adjust their attack accordingly.
Originally from SporkHack, but this version comes via EvilHack with
some minor changes.
Don't include "Click!" in the feedback when a rolling boulder
trap is triggered if the hero is deaf. Some feedback based on
being able to see a monster be hit by a rolling boulder should
also be reported if the location can be seen and an invisible
monster can be sensed there. Change "you hear rumbling in the
distance" to "you hear rumbling nearby" when unseen activity is
close. If the boulder itself is visible when it starts to roll,
report seeing that instead of hearing rumbling.
Fixes#490
We used to have the contents of chests and large boxes be immune to
water damage, oilskin sacks immune unless the sack was cursed, other
containers be vulnerable. Some reddit discussion about ice boxes in
unnethack indicates that they are treated like oilskin sacks, which
makes sense. This adds that to nethack and also makes chests and
large boxes behave similarly. So it's now: nothing is immune even
when cursed (except statues); oilskin sacks, ice boxes, and other
boxes are immune to water damage unless cursed; all other containers
vulnerable even when not cursed.
|
| Old New
|immune all statues, statues
| the time chests, large boxes
|
|immune when BU, oilskin sacks oilskin sacks,
| vulnerable if C ice boxes,
| chests, large boxes
|
|vulnerable ordinary sacks, ordinary sacks,
| all the time bags of holding, bags of holding
| ice boxes
|
I suspect that the old ice box classification might have been an
accident caused by the Is_box() predicate yielding False for it.
The changes won't make much difference to actual play. Chests and
large boxes are rarely carried and never start out cursed, ice boxes
even more so, and sacks/bags haven't been changed. However, players
might intentionally curse a container to keep strong pets from
picking it up, or be carrying a box because they haven't found a bag
yet and then muck about with fountains or thrones and get it cursed.
