From a bug report, the fallback selection criteria
(used when everything is extinct?) in rndmonnum() was excluding hell-only
monsters when outside of Gehennom, but failed to exclude never-in-hell ones
when inside. [Some of the never-in-hell monsters are Angels, but the rest
are all cold based creatures. That must date to when fire resistance was
required for the hero, which is no longer the case. Should those cold
monsters retain their never-in-hell setting?]
This also fixes a latent copy/paste bug in the unused mons[] definition
of Cerberus (it was the only unique monster which failed to specify G_NOGEN).
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 problem in the earlier rev was tracked to cleanup_burn(),
where arg was holding a (genericptr_t) timer id, and
passed directly to del_light_source() as is.]
P64 (Win64) has a 64 bit pointer size, but a 32 bit long size.
Remove some code that forced pointers into a long int, and
vice versa where information could be lost.
This part deals with light source functions and their
arguments mostly, and switches some arguments
from type genericptr_t to 'anything'.
Hide pointer formatting in alloc.c by eliminating the need for callers
to know how big a buffer is required. I generally prefer the caller to
pass in its own buffer for this sort of thing, but in this case the usage
is almost entirely for debugging so using static buffers results in less
clutter in the rest of the code.
Bug in #tip handling for horn of plenty. Emptying one while levitating
would trigger an "obj not free" panic by flooreffects() due to following
hitfloor() with redundant/inappropriate dropy().
<Someone> reported that he applied an unID'd bag and it became
discovered as a bag of tricks even though a spellbook appeared on the floor
next to him rather than having a monster show up (the monster was a mimic).
Suppress the bag discovery unless you can see or sense a monster appear.
(This doesn't really achieve much for most players, who'll recognize the
bag because they know that only one type of container doesn't prompt to
take things out and/or put things in, but I think it does make sense.)
While mucking with bag of tricks I decided that to be consistent with
the behavior of other containers, the #tip command should release all the
monsters in the bag instead of just one.
And after doing that, I realized that horn of plenty ought to behave
much the same, so #tip will operate on it now. However, it won't be listed
as a likely candidate in the "which item?" prompt unless/until it has been
discovered. (Attempting to empty any other type of horn yields "nothing
happens", same as for a horn of plenty with no charges left.) Emptying a
horn of plenty in a shop can be extremely verbose, but I don't think that
qualifies as a bug and don't currently have any plans to alter it.
Provide a common routine that always does the right
thing with respect to timers and weight when altering
obj->corpsenm, and use it throughout the code.
The revised newmail() wouldn't compile (Strncpy doesn't exist, `buf'
was an array of pointers rather than of char). Simplify it substantially,
and adjust the one caller (vms) that relied on the old convoluted bit.
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.
Cut down on the excessive verbosity generated when entering a temple.
The first time you enter a particular temple (or more accurately, the
temple attended by a particular priest), you still get the three message
sequence
The <priest of foo> intones:
Pilgrim, you enter a sacred place!
You have a strange forbidding feeling...
or
You experience a strange sense of peace.
except that the last one doesn't say "strange" any more. On subsequent
visits to the same temple, you usually won't get the first introductory
message any more, often won't get the second entry one, and sometimes
won't even get the final one, depending upon how much time has elapsed
since the previous entry. The old verbosity could really be infuriating
when attempting to lug corpses to the altar before they spoil. Even
though the messages don't affect the passage of time, it always felt as
if they were slowing you down. And even when you weren't in any hurry,
it required at least one and often 2 or even 3 responses to --More--
depending upon the length of the deity's name and whether some other
message was also delivered on the same turn (fairly common in minetown).
Saving and restoring, or leaving the level and returning, resets
the priest's memory of when the messages were last given, so the next
entry after that behaves similar to the very first. This was initially
intended for cleanup prior to saving bones data, but it seemed reasonable
to have it apply to the current game too. Unattended temples now also
have a 25% chance of not giving any message when entering. That one is
random rather than based on the passage of time since last entry; there's
no priest available to track the latter data.
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.
Remove several duplicate includes I discovered while reconciling the
vms Makefile. All of these are already being brought in via hack.h so don't
need to be explicitly included after it.
From a bug report: cancelling objects
in a shop doorway or one step inside would cause the shopkeeper to brand you
a thief. The relevant code is trying to handle the case where you're inside
one shop and zap a wand or spell from there into another one; it didn't cope
with being in the neutral area of a single shop.
From a bug report. Pushing one
boulder from a location which had more than one would open up line of sight
at that spot as if all boulders there were gone.
My previous fix (trap.c) prevented the panic, but didn't actually stop
gold possessed by a reanimated statue from doubling. That problem was due
to how the monster info was saved rather than to how it was restored.
The previous fixes entry applies.
For cancellation I accidentally used terrain type WATER when I meant
object type POT_WATER, so being charged for cancelling holy or unholy water
wasn't working. When I first put in COST_UNHOLY the name made some sense
based on its usage, but after later adding COST_UNBLSS it didn't any more;
change it to COST_UNCURS.
A shopkeeper's complaint that you're uncursing or unblessing his wares
(only applies to water) now sets bknown flag since you know that the object
has become uncursed. I hadn't realized that confused remove curse only
affects uncursed objects; this greatly simplifies extra code I added there
for costly_alteration().
[No fixes entry needed.]
[This ought to be suitable for the branch version too but I'm not going to
spend the effort to migrate it there.]
Recently From a bug report, reducing
the value of a shop object via cursed enchantment was ignored by shopkeeper.
This replaces the existing costly_cancel() routine with costly_alteration()
which performs a similar task: bill for any item whose value has been made
less. The hero owns the resulting object but must pay for the original one
before being allowed to leave the shop.
This covers the majority of cases where bill_dummy_object() was already
being used: cancelling a charged or enchanted item, casting drain life at
same, diluting potions or blanking scrolls or books by dipping them into a
potion of water, dulling a weapon by engraving with it, eating unpaid food
or opening unpaid tins, applying a cream pie to hit yourself with it in the
face, applying a wand to break it, burning something by dipping it into lit
potion of oil, and clearing potions by dipping a unicorn horn into them.
The shop billing behavior for those actions hasn't been changed, just
consolidated into one place which delivers a common message for them.
This also covers many cases which weren't being handled: stripping
wand or magic tool charges via cursed scroll of charging, reducing a charged
ring's enchantment via same, reducing weapon or armor enchantment via cursed
scroll of enchant weapon or armor, stripping an item's rustproofing via
confused enchantment, making a crysknife revert to a worm tooth, unblessing
potions of holy water or uncursing potions of unholy water. (That last one
won't be billed if it's the result of prayer rather scroll, spell, or #dip.)
And this tries to handle the reverse situation more thoroughly too:
many actions which improve the value of an unpaid item now also cause the
shop bill to be updated to reflect its new higher price. Aside from the
basic enchanting and charging magic, it covers converting dragon scales into
dragon scale mail and worm tooth into crysknife. Some things which might be
expected to inflate shop prices, like rustproofing or increasing the number
of charges in a wand, don't actually affect the price. And there are bound
to be cases where the price is affected but I've overlooked.
Various actions (potion dilution, igniting candles or oil, dulling a
weapon by engraving) on an unpaid object can modify it in such a way that
a shopkeeper will force the hero to buy it. bill_dummy_object() is used
to make a copy for the shop bill; play continues with the modified item
now owned by the player. bill_dummy_object() was setting the no_charge
flag unconditionally on the modified object but the flag shouldn't be set
for items in inventory. It was possible to drop the object and sell it,
pick it back up for free due to that flag setting, then drop it and sell
it again. One easy way to reproduce is to zap yourself with a wand of
cancellation while carrying unpaid positively enchanted armor or weapon.
The no_charge flag gets cleared when you pick something up off the
floor or take it out of a container, so this sell-it-again case would only
repeat once. Selling a dropped item ought to clear the flag, but my head
is still spinning after looking at the shop code to see about implementing
that. This fix just prevents bill_dummy_object() from mis-setting the
flag in the first place; sellobj() still can't fix it up after the fact.
[Attention: This patch increments EDITLEVEL in patchlevel.h, rendering all
previous save and bones files obsolete.]
Here's the first cut at the two recommended flags lknown and cknown.
I've attempted to stay close to Pat's recommendations:
"Containers ought to have two new flags: lknown for lock status known,
and cknown for contents known (ie, `secret'). Formatted box and chest
descriptions should include locked/unlocked/broken when that is known
and empty/nonempty (or something like "holds N items") when contents
are known. The contents indicator would also apply to nonlockable
containers."
I probably overlooked a place where a flag should be adjusted, but this
should give us a good starting point.
I wasn't sure what to do with the case of the auditory feedback for
magical locking "Click" and "Clunk". The question that came to my mind
was: Should those reveal the locked or unlocked status of a box?
I suppose if you knew the type of wand you were zapping or the spell
you were casting, you could argue that they should.
In the end, I opted for setting lknown right off the zap/cast effect
for anyone playing a Wizard role, and not setting it for anyone else,
thus advancing class differentiation a little bit too.
I haven't checked the cknown results under all flags.menu_style options
at this point, only MENU_FULL.
<Someone> wrote:
> "You kill the invisible storm giant. The boulder fills a pit."
> [...] why did I find the corpse *lying on* and not *buried in* the
> former pit?
Ensure that the corpse ends up buried in that case.
- store the variety of tin at tin creation time
rather than at tin-opening time (as a negative
value in spe just as homemade was; spinach
is still spe 1)
Allow wishing for a particular variety of tin
from the tin variety list:
"deep fried", "boiled","broiled","candied"
"dried", "french fried", "homemade"
"pickled", "pureed", "rotten", "sauteed"
"smoked", "soup made from", "stir fried",
"szechuan"
Example: "tin of soup made from orc"
non-debug player could randomly fail on the
variety specification 1 in 4 times
Allow migrated objects to break on arrival. Added code to obj_delivery to
cause this, along with a flag to keep breakage from occurring. The new
flag isn't used yet, because all the current object migration involve
objects that were moving/dropping. To help make this change, rloco now
returns whether the object was placed or not, so caller can know if an obj
pointer is still valid or not.
Making the breakage messages for MIGR_NEAR_PLAYER objects show up after the
new level is displayed required some effort (rather than while the old level
was still displayed, which was confusing), due to the needs of goto_level.
- obj_delivery now has 2 passes, one for before player arrives, another after,
allowing the two cases to be treated differently
- goto_level calls obj_delivery twice (run_timers is not called twice,
since the run required before the level is displayed will have already run
any timers on migrating object)
- kill_genocided_monsters now kills eggs on the migrating_objs list too
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
<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.
Previously, if mksobj() was called with the 1st argument
having a value of CORPSE, and a second argument (init)
set to FALSE, the corpse would never get a timer attached.
A while back, I noticed that there was a custom use of the obj->recharged
flag in mkobj.c for tracking corpses on ice. It's much more obvious for
those of us that don't have the entire source base memorized to follow the
usual convention of adding a #define to obj.h. That's what this change does.
While an object is being thrown, it isn't on any list. This means that
killing a shopkeeper with an unpaid object wouldn't be able to clear the
unpaid bit. By the time the object lands, the shopkeeper is gone, and then
it's too late. Added a new global to track a thrown object, set it and later
clear it in throwit(), also clear it as needed in dealloc_obj(), and check
it in setpaid(). It should be possible to use this global to avoid losing
thrown objects during hangup saves as well. But that can wait.
The complaint states:
It still won't let you unwield a cursed secondary weapon while
two-weaponing, even though you can drop such a weapon without problem.
You aren't supposed to be able to two-weapon
with a cursed alternate weapon at all. It appears that there are some
checks to prevent twoweaponing if uswapwep is cursed when you try.
This patch ensures that two-weaping stops if uswapwep gets cursed
while two-weaponing. I think this means the 'A' command will never
encounter the situation now in the complaint now.
The rules in wield.c state
The secondary weapon (uswapwep):
1. Is filled by the x command, which swaps this slot
with the main weapon. If the "pushweapon" option is set,
the w command will also store the old weapon in the
secondary slot.
2. Can be field with anything that will fit in the main weapon
slot; that is, any type of item.
3. Is usually NOT considered to be carried in the hands.
That would force too many checks among the main weapon,
second weapon, shield, gloves, and rings; and it would
further be complicated by bimanual weapons. A special
exception is made for two-weapon combat.
4. Is used as the second weapon for two-weapon combat, and as
a convenience to swap with the main weapon.
5. Never conveys intrinsics.
6. Cursed items never weld (see number 3 for reasons), but they also
prevent two-weapon combat.
Instead of adding a new artifact.h to pray.c, remove the existing
ones from attrib.c, invent.c, and mkobj.c. This also updates the Unix
and VMS editions of Makefile.src; having stale dependencies in those
for other ports could cause unnecessary recompilation but can't break
anything in this case.
Curse and bless status has no meaning for gold. Likewise
for erosion and other object flags controlling whether an item is
considered to be fully identified.
Fix some inconsistencies in armor handling. The 'T' command
wouldn't let you take off a suit or shirt if you were wielding a
cursed two-handed weapon, which makes sense; however, the 'A'
command neglected to impose the same restriction. Also, the 'W'
command had some code intended to prevent you from donning a suit
or shirt while wielding such a cursed weapon, but it didn't work.
This patch fixes the 'A' command's checks for whether an
item can be removed and it makes the 'T' and 'R' commands use the
same code as 'A' instead of maintaining multiple sets of checks.
It also fixes the trivial 'W' problem and attempts to prevent the
sequence of 1) get interrupted while removing a set of equipment
including suit and/or shirt; 2) wield a cursed two-handed weapon
or have already wielded one become cursed; 3) resume removing
armor via 'A' but I haven't tried to trigger that situation to
confirm the bug or this fix.
- candles, et al, light via catch_lit
- non-weapons can be damaged
- only flammable items can be damaged, previously SILVER objects, for example,
would get a message, but add_erosion_words wouldn't display a damage word
- can't track burnt food, put this in the "seems" case too
- PLASTIC items are is_flammable, which is appropriate for all current uses
- paper gets destroyed (special artifacts excepted by earlier check)
- a cursed potion now spills even if not dipping weapons
- charge for damaging unpaid objects this way
- still very hard to destroy PYEC this way
Duuuh. Of course adding objects already changed the editlevel.
Anyway, here's the fix I was working on. It only matters in a very obscure
situation. (Also, the quest leader still speaks no matter what he's
polymorphed into.)
