[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.)
