From a bug report, it was possible to get
|You hit the with all your might. You stop digging.
if a boulder went away--in his case, it was picked up by a giant--while
you were occupied trying to break it with a pick-axe. The code explicitly
used "" to fill in the message when dig_target had an unexpected value.
This just avoids giving the message in a case like this. Possibly
extra stop_occupation() calls should be done instead, but I didn't want
to try to figure out how many would be needed (monster picks up object,
monster zaps wand of striking, others?).
The intersection of a couple of recent patches: noticed when
updating movement as a grid bug, and accentuated when fixing the attempt
to move down while levitating. If you can't reach the floor due to
levitation, don't show '>' in the list of likely candidate directions for
the prompt when digging. It was always included so that the list could
never be empty, but it's a poor suggestion to the player when levitating.
Use '<' instead in that situation; also a poor suggestion, but silly
rather than unintentional. :-)
This only affects the bracketted part of the "In what direction?"
prompt, not the actual digging (and player can pick any direction whether
it's shown in the prompt or not, so the digging code is already prepared
to handle attempts to dig up as well as down anyway).
From a bug report, attempting to move
diagonally when poly'd into grid bug form doesn't give any useful
feedback in the general case, and in the specific case of using 'u' to
try to move northeast with vi-style keys, it performs #untrap instead.
Diagonal directions were being classified as non-movement when in grid
bug form, so the feedback was usually just "unknown command". But 'u'
is bound to untrap as a a convenience to players who use num_pad-style
movement keys. (Move commands don't actually reach the assigned key
part of command handling, so for forms other than grid bug, !num_pad 'u'
moves NE despite the untrap function given to that key.)
Split the diagonal handling out from movement command recognition.
It now gives "you can't get there from here..." if player tries to move
diagonally as a grid bug. For direction prompts, it now gives "you can't
orient yourself that direction" instead of popping up the command assist
display. (In the prompt string showing likely candidate directions for
digging, diagonal handling for grid bugs is academic because they aren't
strong enough to wield pick-axes.)
Using F prefix when trying to move into a wall or closed door yielded
"you attack thin air". Like the recently fixed F-vs-boulder case, give
more appropriate feedback. Also like F-vs-boulder, initiate digging if
wielding a pick-axe. (Also handles axes versus trees and closed doors).
One thing which isn't handled but possibly should be: F vs closed
door when not wielding a pick or other axe might attempt to force the door.
(Right now it gives "you harmlessly attack the door".)
Reported two months ago by <email deleted>,
having a water elemental become trapped in a bear trap seems pretty
strange. Fixed by marking water elementals as M1_UNSOLID (like air and
fire elementals), which has a side-effect of making them immune to webs
as well. Tweaked some unused digging code which checks unsolid(), added
unsolid() to the types allowed to bar through iron bars, and brought the
check for whether a monster is willing to enter a bear trap location up
to date. That code also needed an update to reflect the change made to
anti-magic traps last year. Lastly, there was another report which
suggested that being hit by a bear trap should dish out some damage
(along with a suggestion that wand of opening should work to escape such
traps, which has already been done). This makes bear trap do 2d4 damage
(on entry, not when trying to pull out after becoming stuck).
Remove some more code that forced pointers into a long int, and
vice versa where information could be lost (P64 platforms such as
WIN64 have a 64 bit pointer size, but a 32 bit long size.)
This 2nd part deals with timeout functions switching
some arguments from type genericptr_t to 'anything'.
Like part 1, this needs to increment EDITLEVEL in patchlevel.h.
The latest Micrsoft compilers complain when a function is
assigned to a function pointer, and the function's argument
list does not match the prototype precisely.
It was evem complaining about the difference between this:
int x()
{
[...]
}
and a prototype of
int x(void);
when assigning that function's address to a function pointer.
This quiets those warnings, without suppressing the mismatch
check altogether for more serious mismatches.
Axes can't dig through the floor, but attempting to dig down with one
shouldn't just "scratch the floor" if there is an armed land mine present.
Have it set off a land mine or bear trap, in addition to the possibility
of chopping your way out of being stuck in a bear trap (a recent change).
<Someone> suggested that digging down on a land mine with a pick-axe ought
to set if off. I agree; this implements that and also for bear traps. In
the bear trap case, if you dig down once trapped, you will destroy that
trap explicitly rather than replace it with a pit, so it's now possible to
escape from one without leaving another trap in your wake. Once the bear
trap is gone, further digging there will make a pit as usual. While stuck
in one, digging down poses a modest risk of harming yourself.
|You now wield a pick-axe.
|You start digging downward. A bear trap closes on your foot!
|You start digging downward. You destroy the bear trap with your pick-axe.
|You continue digging downward. You dig a pit in the floor.
|You start digging downward. You dig a hole through the floor.
|You fall through...
[It seems a bit strange that finishing a pit discards all digging context,
so that resuming within the pit in order to make a hole "starts" digging
rather than "continues" it.]
Digging down with a wand or spell will disarm these two types of traps
and then leave the corresponding object (which may or may not fall through
the resulting hole, like any other object there). Digging to the side via
magic while trapped in a pit will also disarm such traps when it encounters
them. (When not in a pit, a digging beam which simply passes over an armed
bear trap or land mine won't have any effect on the trap.) Digging to the
side via tool behaves somewhat oddly ("no room for the rubble"?) and will
probably need some tweaking before eventual release; at present it doesn't
reach adjacent traps so didn't need any land mine or bear trap handling.
I put the fixes entry in the new features section.
This one turned out to be more effort than I had
originally anticipated.
We had a bug report requesting that zapping a wand of digging
laterally while in a pit should dig beside you. That seemed
like a reasonable enough request, but this ended up with
the following results:
- needed to check where this should not be permitted, or at
least where there should be special-case code because there is
something such as furniture on the surface above the dig
point.
- now tracks conjoined pits through new fields in the trap
structure, hence the pathlevel increment. The array of
8 boolean values represents each of the 8 directions
around a pit.
- Previously, pits could be adjacent to each other as two
individual pits, in which case moving between them
results in a fall as you went into the next pit. That
behavior is preserved.
- Pits created either by zapping a wand of digging
laterally while in a pit, or by "clearing debris"
between two adjacent pits via a pick-axe, sets the
conjoined fields for those two pits. You cannot
create a brand new adjacent pit via pick-axe, only
with the wand.
- The hero can pass between conjoined pits without
falling.
- dighole() was hijacked for adjacent pit digging,
so the ability to pass coordinates to it and
its downstream functions was added (dig_up_grave()
for example). dighole() does pretty much everything
appropriately for this adjacent digging, more so
than calling digactualhole() directly.
- moving into a conjoined pit that has spikes still
does damage, but less so that "falling" into the
spiked pit, and you "step on" the spikes rather
than falling into them.
- Not done: should pits with the conjoined fields
set be referred to as 'trenches' rather than pits
in messages and identifications?
I'm pretty sure this check at_u should be included since x,y
can be passed to digactualhole(). The lack of any related
bug reports suggest that at_u is currently always
true for any code that calls digactualhole().
Note: The CVS repository was tagged with NETHACK_PRE_MEXTRA
prior to application of this patch to allow easy withdrawal if necessary.
Adds a new mextra structure type that has a set
of pointers to various types of monster structures
including:
mname, egd, epri, eshk, emin, edog
Replaces the mextra bits in the monst structure
with a single pointer called mtmp->mextra of type
(struct mextra *).
The pointer can be null if there are no additional
structures attached. The mextra structure is not
adjacent to the monst structure.
Reduces the in-memory footprint of the monst that
has no other structures attached, at the cost
of adding 6 extra long ints per monster to
the save file
The new mextra structure has the mextra fields
independent of each other, not overlapping as was
the case with previous NetHack versions.
This patch doesn't do anything to capitalize on
that difference however.
Consolidates vault.h, epri.h, eshk.h, emin.h and edog.h
into mextra.h
Adds a macro for checking for whether a monster has
a name:
has_name(monst)
This fixes the magic trap panic
expels() -> spoteffects() -> dotrap() ->
domagictrap() -> tamedog()
because the monst no longer varies in size so no
replacement is required.
Extend the capabilities of corpse_xname() so that various callers can
be simplified. It can how handle an article prefix, effectively turning it
into corpse_doname() (not quite; still need doname() to see a count when
quantity is more than one, or to see bless/curse state). It can also handle
inclusion of adjectives like "partly eaten" or "bite-covered". For unique
monsters those come out in the form
the Chromatic Dragon's partly eaten corpse
instead of the old
partly eaten Chromatic Dragon corpse
[so wishing probably needs to be taught about potentially finding a monster
name before assorted adjectives such as blessed; also, name_to_mon() needs
to learn how to cope with the possessive suffix].
A sizeable chunk of this patch deals with consolidating some of the
redundant "petrified by a cockatrice corpse" handling. It may be possible
to consolidate all remaining instances together since they're quite similar,
but I didn't think about that until just now and I want to get this patch
over with.
A post-3.4.3 change dealing with reaching into pits resulted in "you
sit on the air" if you used the #sit command after escaping a pit trap.
Change can_reach_floor() so that caller explicitly controls whether being
on the brink of a pit is a condition that prevents reaching the floor.
This also splits a fairly common message about not being able to reach the
floor into a separate routine.
There is still oddness here: if you're polymorphed into a flyer,
#sit yields "you sit down" followed by "you fly over a pit" (latter occurs
when escaping trap activation). A ceiling hider behaves similarly, but
the second message is "you escape a pit" and doesn't sound quite as silly.
Perhaps #sit should pass TOOKPLUNGE to dotrap(), or maybe there's some
better way to handle this?
<Someone> reported that when levitating and blind, he was getting
"You float over the hole" without it showing up on the map. Easiest way
to reproduce: zap a wand of digging downwards while levitating blind,
move off the spot and back over it.
Make sure that all traps created by the player are mapped. For other
traps, it was about 50:50 whether the trap triggering message yields enough
information to warrant forcibly mapping the trap when blind.
There was already code to ensure that if a hidden monster moved, it would
no longer be hidden. However, if the monster is asleep or whatever under
a rotting corpse, when the corpse rotted away, the monster would not
immediately become detected. Add a check to the rot code before the newsym.
Change pit behavior to always mark a non-flying poly'd player as trapped in
a pit, even when Passes_walls is set. This allows players polymorphed into
xorns to descend into pits and pick things up. In this case, any attempt
to move out of the pit now takes a turn but always succeeds. Also fixed
a related bug (w/o ID) that a player could become trapped as if in a pit
when leaving xorn form because u.utrap wasn't checked, and simplified the
code since the extra Passes_walls checks are no longer needed. Also
updated code in sit.c that duplicated uteetering_at_seen_pit.
<Someone> wrote:
> You start bashing monsters with your 2 cockatrice corpses.
> You hit the foo with the cockatrice corpse (note singular).
> The foo is slowing down. The foo turns to stone.
> Also: Your cockatrice corpses rots away.
It appears that vtense() has a problem recognizing "corpses"
as plural. This doesn't fix that, it just switches to using
otense() in this particular case.
- [fixed in trunk] Alchemical explosion
- [fixed in trunk] Artifacts' blasting
- [fixed in trunk] Boiling/freezing potions
- [fixed in trunk] Chest/door/tin traps
- [fixed in trunk] Falling rocks/boulders (trap, digging, scroll of earth)
- [fixed in trunk] Mixing water and acid
- [fixed in trunk] Thrown potion (acid)
This is my last patch on this today.
- [fixed in trunk] iron-ball-pulling yourself out of a bear trap
- [fixed in trunk] Hitting your foot with a bullwhip
- [fixed in trunk] Hooking yourself with a grappling hook
- [fixed in trunk] Being thwacked by an iron ball chained to you
- [fixed in trunk] A crystal ball exploding on being applied
- [fixed in trunk] Hitting yourself with your pick-axe
- [fixed in trunk] Molten lava (entering or being splashed)
- [fixed in trunk] Getting squished in a pit under a boulder
- [fixed in trunk] Kicking something that makes you go "Ouch!"
20000922 Water should flow into pits from broken WoD, or DoE.
This addresses the Wand of Digging part, but does not
do anything about Drum of Earthquake.
+ Separate the two uses of flags.soundok.
+ Player-settable option is now called "acoustics".
+ Deafness is now handled as a full-fledged attribute.
+ Check for deafness in You_hear(), rather than caller.
+ Check for deafness in caller, rather than verbalize(),
because gods can speak to characters in spite of deafness.
+ Since changes are being made to prop.h, reorder it to the
same order as youprop.h and enlightenment.
There are still some extraneous checks and missing checks
for deafness, which will be followed up in a future patch.
Because of the size of this patch and its savefile incompatibilities,
it is only being applied to the trunk code. Portions of this patch
were written by Michael Allison.
Pat Rankin wrote:
> collect them all into some new struct and
> save that separately rather than jamming more non-option stuff
> into struct flags.
This patch:
- collects all context/tracking related fields from flags
into a new structure called "context."
It also adds the following to the new structure:
- stethoscope turn support
- victual support
- tin support
This patch introduces a change to yname() and Yname2() that avoids the
possessive "your" for the hero's normal, fully identified artifacts.
Quest artifacts still get the possessive, as do all other objects and all
objects not in the hero's possession. shk_your()/Shk_Your() are used in
many places with a specific, generalized name for the object, so I didn't
introduce the artifact behavior there, although I did change them to append
a space, which simplified some other code. Through added use of yname(),
there may be some places that used to just say "corpse" that will now be more
descriptive via yname()'s use of cxname(). I'm sure <Someone> will point
out any such places that are too onerous, although nothing obviously is.
I took the opportunity to inspect many uses of "your" and even Your(). Two
new functions are also introduced, yobjnam() and Yobjnam2(), which work
like aobjnam() and yname() combined, because I found that many uses of
aobjnam() were preceeded by "your" and I couldn't generally provide the
desired behavior for artifacts (or future artifacts) without a combined
function. In some cases, this change allowed better sharing of code.
rust_dmg() still takes a string as input which is sometimes initialized
from xname() and often prepends "your" to it. Currently, this isn't a
problem since there currently are no normal, armor artifacts. If/when any
are introduced, rust_dmg() will need to be addressed.
The patch is for the trunk only. A lot of research was required and I
didn't feel the upside was there for repeating it in the 3.4.3 branch.
<email deleted> wrote:
> If more monsters fall through a trap door than can fit on the
> level below, when you go down the stairs, you get the following
> message:
> "Program in disorder - perhaps you'd better #quit.
> rloc(): couldn't relocate monster"
> This message seems to appear once for every monster-too-many that
> fell through the hole. I originally found this while
> intentionally completely filling a level with black puddings
> (there was a trap door I didn't know about). I also confirmed it
> in a wiz-mode test using gremlins and water.
[confirmed: moveloop -> deferred_goto -> goto_level ->
losedogs -> mon_arrive -> rloc -> impossible]
This patch:
- causes rloc() to return TRUE if successful,
or FALSE if it wasn't.
- adds code to mon_arrive() in dog.c to deal with
the failed rloc()
- allows the x,y parameters to mkcorpstat() to
be 0,0 in order to trigger random placement of the
corpse on the level
- if you define DEBUG_MIGRATING_MONS when you build cmd.c
then you'll have a debug-mode command #migratemons to
store the number of random monsters that you specify
on the migrating monsters chain.
Digging a pit in the location where you're stuck should always free you.
This would not occur if you used a wand of digging to do the digging,
especially if you did so while levitating.
Digging a pit while a xorn set the trap time, but falling into a pit did
not. While lookin at this, it occurred to me that the same inconsistency
might occur while polymorhing from/to a xorn, and there was.
> Receiving Excalibur from a fountain while blind doesn't update the
> display (i.e. the missing fountain) immediately.
Various other topology changes had the same problem. The display
was only being updated if the hero was invisible on the assumption that
it wouldn't matter otherwise, but a blind character who moved off the
affected location would still have the old map info (fountain, trap, &c)
shown--until he walked back onto that spot or searched next to it or
regained sight--even though the player is told about the map change as
it happens.
Prevent burying a ball from ending your punishment.
When you bury the ball, internally NetHack Punishment
ceases, but a new trap type of TT_BURIEDBALL immediately
kicks in (acting similar to TT_INFLOOR in some ways).
You can eventually work the ball free (or teleport, etc.),
but that will just return you back to normal Punishment.
Prevent #rub from wielding an item that is already being worn
(which should narrow things down to the various types of eyewear;
other tools and weapons that go through wield_tool() can't be worn).
Fix up the wield_tool message spacing in the process.
This moves wield_tool() from apply.c to wield.c. Some plural
handling for messages is included; it is feasible to try to #rub a
"pair of lenses" or a stack of N candles.
Building with an old version of gcc with various warnings enabled
generated a lot of noise. Most of it was due to not guarding string
literals with `const', but there were a couple of actual problems too.
> Zapping a wand of digging at trees in ranger's quest gives a message
> "rock glows then fades".
There was code to handle this, but it didn't work due to the
definition of IS_TREE making checks for STONE be sensitive to code
ordering (STONE was checked first in this case).
#define IS_TREE(typ) ((typ) == TREE || \
(level.flags.arboreal && (typ) == STONE))
Why is it defined this way? Shouldn't STONE simply be converted
into TREE when arboreal levels get created?
Reported to the list. Player breaks a wand of digging causing the
shopkeeper to fall. This didn't clear unpaid items. For now, this can
only occur due to player action, so added a call to make_angry_shk to
handle this situation.
- Breaking wand of digging dug through rock which should be undiggable.
Checks assumed pits would never show up in solid rock.
- Breaking wand of digging near shop walls wouldn't anger the shopkeeper
Checks assumed pits would never show up in walls, also, added a special
case to pay_for_damage to handle the case where you're falling thru and
can't be asked to pay.
- Shop walls wouldn't be restored if there are pits in the way.
Checks assumed pits would never show up in walls.
- If there was a hole outside the shop, you could kick stuff out of the
door into the hole without shopkeeper noticing. Added the missing check.
<Someone> wrote:
> Linux, Redhat 7.1 nethack 3.4.0
>
>Please see attached patch file.
>
>I'm attempting to move more stuff into the "read-only" area, in
>preparation for a port to another OS.
- In various places, cutting down a tree would result in a corridor symbol
showing up, although trees are generally found in room-like areas. Added
the missing checks.
- Trees were diggable except on mazelike levels. Added the missing check.
- In a cavernous town like minetn-6, digging a wall would result in a
corridor symbol being displayed instead of a doorway. This looked strange,
especially in the town. Added a check for this, making use of the new
meaning of in_town(); non-town parts of this level still do CORR
replacement as expected.
I saw no secret doors in any of the towns, but in 340 (fixed in 341),
guards would patrol the entire level, so they might complain about secret
doors elsewhere. Fix the check for future use. Also, I noticed trees, eg
on minetn-6, weren't checked at all. Now they are.
for now at least, until there is more time to look into it.
<email deleted>
> Yet more nitpicking about potions of oil being lit by sparks from axed
> statues, I'm afraid.
>
> Konosja's potions of oil catch light!
> "That will cost you 66 zorkmids (Yendorian Fuel Tax)."
> "That's in addition to the cost of Konosja's potions of oil themselves, of
> course."
> You snuff the lit potion.
>
> a) why is the Fuel Tax on (in this case) six potions the same as on one?
>
> b) if you a)pply-light a potion, it's just "in addition to the cost of
> the potion". Is Yname2() the right name-function for catch_lit() to
> be using? It's odd for Konosja to be talking about herself in the
> third person.
>
> c) Grammar on the snuffing message is wrong for multiple potions.
Pat forwarded a message from the newsgroup in March that the town guards
enforce rules even outside the town proper. Fix: On room-based town levels,
check if the location is in a room containing subrooms (roomno will often
have a subroom id instead). On the other levels (e.g. minetn-5), there are
no subrooms, so the whole level is fair game. Currently, this is valid.
If fancier towns are added in the future, more flags or use of regions may
be required to tell where the town border actually is. These checks are done
in a new in_town function.
<Someone> writes:
I can accept that losing gold into a fountain recharges it to make it
possible to find a gem in it in future (however weird that is). What
_does_ seem wrong is that receiving a warning about a Minetown
fountain prevents finding gems and gold there.
