Most of the time, rloc() is used for teleporting monsters and it's not a
big deal if they can't find somewhere to go. In a few cases, it is. I
went through all the callsites and made calls to rloc() not cause
impossible()s if they don't need to.
Fixes a bug/suite of bugs reported by ais523.
I'll push a formatting guide at some point. There may still be
outstanding changes, but please feel free to resolve those as you arrive
a them.
To the best of my knowledge, there is no changes to the actual code
content, but the formatter does have the occasional bug. If you run into
an issue, please fix it!
Instead of just "while helpless", the death reason will tell
more explicitly why the player was helpless. For example:
"while frozen by a monster's gaze"
From a bug report, dropping a lit
(burning) potion of oil while levitating can produce an explosion which can
destroy inventory. If in the process of dropping multiple items, the ones
after the oil might be gone, resulting in use of stale pointers and possibly
triggering an "extract_nobj: object lost" panic or even a crash. While
testing my fix, I discovered that being killed by an exploding potion of oil
could produce an "object_is_local" panic if bones are saved (and reproduced
with unmodified 3.4.3).
A post-3.4.3 change made the contents of thrown (or dropped while
levitating) containers subject to breakage, but it had sequence issues.
When something was thrown from outside a shop (or from its doorway or
entry spot) and arrived inside, the shopkeeper was taking possession too
soon, charging the hero for any broken contents, and then going ballistic
(summoning kops and attacking) because the hero was outside the shop while
owing money. We need to break contents before shk claims ownership, which
turned out to be trickier than it sounds since it has to occur after any
item-hits-floor message if such feedback is given.
Also, clear the container's contents-known flag when contents break.
Conceivably it should stay set when there is only one item, since hearing
something break could only be that item, but this resets container->cknown
unconditionally if anything inside breaks.
The ceiling on the Plane of Water is always "water above", not "sky"
when inside air bubbles and "water's surface" when outside. Also, support
throwing things upwards on the planes of air and water and when underwater
instead of silently dropping the missile in such cases.
This is mainly groundwork for a tangential bit of a forthcoming
levitation fix.
Something I've had in mind for a long time and finally gotten around
to implementing: when you fill in the last pit or hole of a sokoban level,
it's considered to be completed so luck penalties for unsokobanish things
(breaking a boulder, dropping everything and squeezing onto a boulder's
spot, reading a scroll of earth) stop being assessed and most Sokoban-
specific movement restrictions (against pushing boulders diagonally,
squeezing diagonally between boulders, floating over a pit or hole without
falling in, digging of new holes by monsters) are lifted. Teleporting,
level teleporting, and phasing through walls are still prohibited when in
the sokoban branch of the dungeon. (Keeping the non-phasing one in place
prevents taking a shortcut to the final prize in order to bypass the
treasure zoo monsters.)
This adds level.flags.sokoban_rules, defines Sokoban macro to access
it, and replaces most In_sokoban(&u.uz) tests to check it instead. It
gets set when a sokoban level is pre-mapped at the end of level creation,
and if it is set then whenever a trap is deleted, the flag gets cleared
if there are no more pits or holes present on the level.
This might fix the following buglist entry
|Teleporting while using tiles may place you one tile beyond the edge of
|the display screen, and place the crosshair on empty space.
Various bits of code, including teleport, are assigning directly to
u.ux,u.uy instead of calling u_on_newpos(). It wouldn't be an issue for
small tiles where the whole map fits on the screen, but it probably is for
bigger ones where clipping is in operation. Using u_on_newpos() adjusts
the clipped map right away but changing u.ux,u.uy directly won't do so
until control returns to moveloop() and it eventually calls cliparound().
Usually the hero's position only changes by one column and/or row, hence
stays within the clipping margin, but that's not the case for teleport
nor for hurtling (throwing recoil while levitating, &c).
Perhaps all the places that assign u.ux,uy should call u_on_newpos()
instead? Most--all?--of them aren't updating u.usteed->mx,my, but I
guess that monster's coordinates don't matter since it isn't placed on
the map.
I've been sitting on this for a long time (29 months?); it got more
elaborate for a while, then got stripped back to something fairly simple.
The original description was once accidentally attached to an unrelated
patch; it was more detailed than this one....
This makes it harder for non-fighter types to throw or shoot
multishot volleys of missiles, and gives a couple of minor new bonues to
try to get a little more variety than the current situation of everyone
(with possible exception of arrow shooting by rangers) just using stacks
of daggers for ranged attacks. Since daggers are so plentiful that's
probably just wishful thinking.
Rename ``kickobj'' to ``kickedobj'' so that the tense matches that
of ``thrownobj''. Also, move their declarations to decl.h and their
definitions to decl.c since usage has spread from dokick.c/dothrow.c to
various files and is about to expand to another one.
Noticed while testing the "<obj> is no longer poisoned" fix; killing
an engulfer via "the poison was deadly..." led to an "obj not free" panic.
It was due to post-3.4.3 changes, so no fixes entry.
Allow potions thrown straight down while hero is mounted to target
steed instead of always hitting the floor. There's already a fixes35.0
entry for potions hitting worn saddle instead of the creature wearing it,
but that only happened when thrown at a nearby saddled monster, not when
the hero was stuck mounted on a steed with cursed saddle.
Eight separate "the <obj> glows <color>" messages were too many...
(four for dipping an item in holy/unholy water, four more for throwing
either of those potions at a saddled monster). Replace the repetitive
code, leaving just two such messages. Setting of bknown flag for the
dipped object is the only intentional change here. That used to be done
unconditionally but now requires that the hero see the glow color.
Throwing an object while engulfed and then quitting triggers a panic
when the end-of-game code tries to clean up the thrown object. Throwing
code wasn't reflecting the fact that adding the missile to the engulfer's
inventory already handles the thrown object. 3.4.3 wasn't affected; it
didn't bother trying to clean up `thrownobj' in done().
From the newsgroup: when a monster throws a potion at the hero and
it hits a long worm's tail, you'd get "The bottle|flask|&c crashes on the
long worm's _head_ and breaks into shards." The relevant code changes
"head" to "body" when appropriate, but monster throwing wasn't setting up
`notonhead' so that alteration only kicked in for player throwing.
Some post-3.4.3 code in done() cleans up thrownobj and kickobj to
plug a potential memory leak (unnoticeable one since the game is over),
but they have to be free objects rather than on any list. toss_up() was
leaving thrownobj defined after putting the thrown object on the floor,
leading to "obj not free" panic from dealloc_obj() if threw you an object
upward and it dealt fatal damage when it fell back down. (For non-fatal
damage, toss_up()'s caller cleaned things up later.)
From a bug report, 2005: applying a
polearm towards a monster ignores the `confirm' option. It's a wielded
weapon attack but is handled internally as a throw since it's also a
ranged attack. The report included a small patch for use_pole() but I'm
calling the regular attack confirmation routine instead.
Also, move the penalty for samurai attacking peaceful monsters into
the same routine that handles knight attacking defenseless monsters so
that they're more consistent.
From a 7.5 year old news posting (with a reply by Kevin Hugo speaking
on behalf of slash'em...): when a monster "nimbly jumps to evade" hero's
kick, it can pass through walls and grid bugs can jump off their grid.
Likewise when a joust or staggering blow knocks a monster back, it could
move grid bugs diagonally. This fixes both cases.
Offhand I can't think of any other non-standard movement situations
which might need similar handling, but it wouldn't surprise me if there
are some. Leashed movement is close but I don't think maybe_mnexto helps.
splatter_burning_oil() is called when a lit potion of oil gets
broken, and it can dish out fatal damage to the hero. An earlier fix
to prevent a light-source panic (thrown item is not on any of the object
lists) during bones creation didn't address leaving that lit potion
intact if it was on the floor (which can happen if the breakage is caused
by striking or force bolt rather than its being thrown or kicked). Use
the existing obj->in_use mechanism as a more general fix, after teaching
bones code that it applies to other things besides the hero's inventory.
A change a couple of weeks ago to have player's chosen ammo be auto-
quivered when using the 'f' command while quiver is empty was excluding
objects with quantity 1. That was on the basis that it was in the process
of being thrown so there was no point in putting it into the quiver slot
first. But if it was a boomerang, or Mjollnir under suitable conditions,
there was a chance for it to be available for another throw, so there is
a point to quivering it. Also, player can hit ESC at the direction prompt
and end up not throwing it after all. So, put even quantity 1 items into
the quiver when 'f' command is used with empty quiver.
There was a suggestion in the newsgroup that if you use the 'f'
command when your quiver is empty, that whatever missile you supply to the
"what do you want to throw?" prompt be automatically put into the quiver.
This implements that, and separates most of the common code from dothrow()
and dofire() into a separate routine. A post-3.4.3 change to dothrow() to
require hands for throwing wasn't propagated to dofire(). With the common
routine, they're much less likely to get out of sync like that.
This is going into the branch as well as the trunk because the hands
checking mismatch was added there too.
From a bug report, walk_path() was
favoring orthogonal steps at beginning of the path and diagonal ones at
end, when intermixing diagonal and orthoganal produced a more accurate
representation of the real path. Only mattered for long distance jumps
3x2 or 3x1 steps away; hurtling always moves in a straight line and short
(2x1 knight) jumps aren't affected by the patch supplied with the report.
From a bug report, kicking unpaid
food in a shop at a tameable monster resulting in taming the monster
without charging for the used-up food. This forces kicked objects that
are owned by shops to be put on the shop bill and flagged as unpaid, which
is normally reserved for carried items but makes kicked ones behave like
thrown ones. (If they land inside the shop without breaking, they're
removed from the bill.) So kicking food to make a pet now results in the
item being moved from the shop's unpaid bill to its used-up bill, same as
for thrown food. Although the latter kept billing consistent, it lacked
shop billing feedback; this fixes that too.
Wielding a bow while kicking arrows gave a shooting bonus. Also,
From a bug report: applying a
polearm to hit at range never caused a pudding to split because the attack
gets treated as throwing. Likewise, confuse monster effect (hands glowing
red) didn't kick in for applied polearms.
From the newsgroup: slash'em lychanthrope character could throw
while in wolf form. That came straight from nethack; any animal capable
of manipulating an object--possibly with its mouth--could throw things.
Now hands are required. This doesn't require free hands, although it
probably should; it's kind of tough to imagine making a competent throw
while your hands are stuck to a cursed two-handed weapon.
Make all stackable weapons capable of multi-shot volleys when thrown.
Affects knives, spears & javelins, and boomerangs; requires advanced skill
assignment (skilled: 1-2 missiles per throw, expert: 1-3 missiles) or
role-specific bonus (ranger class's general +1 bonus is the only one that
applies to any of these weapon types). For monsters, prince-caste get 1-3
missiles and lord-caste get 1-2, as before, with fake player monsters now
also getting 1-2; those counts apply to all stackable weapons regardless
of whether the species or role ordinarily uses whatever is being thrown.
Related changes: monks now get a role-based +1 count for shuriken,
throwing 1-2 instead of just one (they're only allowed to achieve basic
skill so won't reach any higher volley count). Monster monks and ninjas
get that too; ninjas now get the same for darts and they're guaranteed
weapons in starting inventory. Also, fake player rogues now sometimes
get orcish daggers instead of short sword, providing a decent chance to
occasionally have Grimtooth be randomly generated on the Astral level.
Potentially controversial: wizards can still become expert in dagger
skill and receive the to-hit and damage bonuses for that when throwing as
well as when wielding, but the number of missiles for them has now been
reduced to 1-2 (in other words, going from skilled to expert no longer
improves the max count for the volley amount for wizard role). They're
supposed to be spellcasters; being able to throw up to three +7 daggers
at a pop was a big temptation for resorting to brute force, particularly
since they'll already want highest dagger skill for wielding Magicbane.
To do: throwing multiple boomerangs either needs to behave as if
they're all in flight before the first returns, or else the volley needs
to be cut short if one comes back and isn't successfully caught. The
latter is a lot easier to do but the former fits better with what multi-
shot volley is supposed to represent. Another alternative is to change
them to no longer be stackable, then this sequencing issue goes away.
To do too: make worm teeth and crysknives become stackable like the
other knife-skill weapons.
From a bug report:
crossbow shot range shouldn't depend upon strength. Make it fire for a
distance of BOLT_LIM regardless of whether if would have gone shorter or
longer by using the normal ranged calucations. However, strength is
necessary to load crossbows, so make characters with low strength be less
capable of launching multi-shot volleys.
Some code I recently added was misusing count_unpaid() and would
traverse some or all of inventory instead of just container's contents
when looking for unpaid items. Add mew routine `is_unpaid(obj)' to do
what I was intending to do with count_unpaid().
[I accidentally left this out of the previous commit.]
Throwing didn't handle a container owned by the hero which contained
items owned by the shopkeeper. I'm still not quite sure what's going on
there, but throwing the container out of the shop didn't give any feedback
but did add to shop charges which don't show up in ``I x'' (but do get
revealed by ``$'' or ``I $''). Now there's some shop feedback for the
throw and the contents show up for ``I x''.
More explicit control over the behavior of spoteffects() is probably
the way to go in the long run, but this much simpler fix handles the case
at hand. I'm not sure what `thrownobj' was intended to be used for in the
first place, but it came in handy here. (It was being left as a dangling
pointer when thitmonst() reports that the missile has been used up; that's
fixed now.)
Fix the reported problem of lookhere/autopickup not seeing the missile
which just killed the engulfing monster whose death caused the hero to be
put back onto the map and so look/pickup upon arrival. Normally the missile
gets placed after damage has been dealt and the throw has finished. This
overrides that so that the missile is put into the engulfer's inventory as
it is being killed (which will then put that inventory onto the floor prior
to expelling the hero on top of same). If the monster happens to get
life-saved it just ends up collecting the thrown-from-inside object a little
sooner than usual.
This wouldn't correctly handle the same case for a kicked object, if
that were possible. But it isn't possible to kick objects while engulfed,
so that's moot. Other calls to thitmonst() and hmon() don't appear to have
any objects in transit so shouldn't need any comparable fix (I hope...).
<Someone> wrote:
>>comments:
>>When you commit suicide with a potion of oil (lit), sometimes nethack
>>reports an `obj_is_local' error just after disclosing all the game
>>variables. This has been found in-game (don't ask) and reproduced in
>>wizard mode and in-game (start-scumming).
>
> 0) a neutral human wizard (the scrolls/spellbooks burning, potions boiling ;))
> 1) wish up 3 potions of oil (so that the 2 remaining will definitely kill you)
> 2) a'pply one of them
> 3) stand 1 square away from a wall, like "| @"
> 4) throw the lit potion into the wall (`h' in this case)
> 5) answer `yes' on all prompts.
The thrown potion of oil, which was extracted from any chain
during the throw, still had its timers attached when the call to
splatter_burning_oil() was made. If that killed the hero, a
panic would result during bones file creation (saving timers)
because (obj->where == OBJ_FREE) on the potion.
Remove the timer prior to splattering the oil inside.
The recent fix for "breaking glass wand in tool shop" looked suspect,
adding a call to costly_alteration after an existing call to stolen_value.
Either one or the other ought to suffice. (For items on the floor,
costly_alteration() calls stolen_value(); for items in inventory, or just
released from inventory and not placed on floor yet, costly_alteration()
adds a usage fee to the shop bill but doesn't annoy the shopkeeper into
adding surcharges to prices or summoning the kops if already hostile.)
In 3.4.3, stolen_value() wasn't smart enough to charge for an out-of-
shk's-field item (like a wand in a tool shop) taken from a shop container,
and that's the problem the user was reporting. But the post-3.4.3 code was
changed to handle that by checking billable() instead of saleable(); this
bug should have been gone. Unfortunately, billable() treats items already
on the bill as not interesting--from the perspective of adding things to
the bill--so the change accidentally resulted in stolen_value() no longer
handling objects which are marked unpaid, triggering the same symptom for
a different reason. (Other events besides the breakage of thrown objects
suffered from the bug's new incarnation since various places deliberately
call stolen_value() for unpaid objects.) This updates stolen_value() and
stolen_container() to account for the behavior of billable(). And a few
calls to subfrombill() go away since stolen_value() now takes care of that.
<email deleted> wrote:
> - when in a hardware store, I put a glass wand out of a sack (the glass wand
> will cost you 266 zorkmids) and threw it in the shop => shattered into a
> thousand pieces BUT if I try to pay, I do not owe the shopkeeper anything !!!
> If I break a potion with a /oS, I have to pay !
This patch by <email deleted> was released
when 3.4.1 was current and has been incorporated into slash'em. It is
extremely useful while using ranged weapons. When both autopickup and
pickup_thrown are enabled, walking across previously thrown objects will
pick them up even if they don't match the current pickup_types list.
[See cvs log for patchlevel.h for longer description.]
move oattached and oname and other things that vary
the size of the obj structure into a separate
non-adjacent oextra structure, similar to what has
already been done for mextra. The obj structure
itself becomes a fixed size.
New macros:
#define ONAME(o) ((o)->oextra->oname)
#define OMID(o) ((o)->oextra->omid)
#define OMONST(o) ((o)->oextra->omonst)
#define OLONG(o) ((o)->oextra->olong)
#define OMAILCMD(o) ((o)->oextra->omailcmd)
#define has_oname(o) ((o)->oextra && ONAME(o))
#define has_omid(o) ((o)->oextra && OMID(o))
#define has_omonst(o) ((o)->oextra && OMONST(o))
#define has_olong(o) ((o)->oextra && OLONG(o))
#define has_omailcmd(o) ((o)->oextra && OMAILCMD(o))
changed macros:
has_name(mon) becomes has_mname(mon) to correspond.
The CVS repository was tagged with
NETHACK_PRE_OEXTRA
before commiting these, and
tagged with
NETHACK_POST_OEXTRA
immediately after. The diff
between those two tags is this oextra patch.
The associated mail daemon changes to use an oextra
structure instead of a hidden command located in the
name after the terminating NUL, have not been tried
or tested.
<Someone> reported that thitu() was adding d20 damage for silver object
hitting silver-hating hero even though all the callers were using dmgval()
which also does that, resulting in doubled silver bonus/penalty. This
fixes that (including for boomerangs thrown by player, which weren't using
dmgval(), to handle a hyptothetical silver boomerang). While testing it,
I noticed that there was no "the silver sears your flesh" message when a
monster hit you with a wielded silver weapon, so this fixes that too.
(How did we miss that? And how did <Someone>? :-)
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 couple of items pointed out by <Someone>: the killer reason
when hit by mis-return of thrown Mjollnir would vary depending upon whether
it was fully identified, unlike several other death-by-missile cases which
force the object to be described as if fully ID'd. Also, the killer reason
when death is caused by kicking an object would give way too much detail
about the object if it was ID'd. Fix both by switching to killer_xname().
Now "killed by a war hammer named Mjollnir" becomes "killed by Mjollnir"
(same as when already ID'd), and "killed by kicking 5 cursed poisoned -1
orcish arrows" becomes "killed by kicking orcish arrows" whether ID'd or not.
[Trunk only] question? Should being hit by returning Mjollnir really
be receiving half-physical-damage reduction when hero has that attribute?
It ignores the fact that Mjollnir is also dishing out lightning damage.
Are other artifact hits ignoring such things too?
