From the newsgroup: someone using <Someone>'s level-flip patch
(to transpose special levels left-to-right or top-to-bottom or both in
order to get more variety from them) ended up in solid rock. When
climbing the stairs up from the Valley to the Castle, goto_level() was
hardcoded to find a spot in the extreme lower right corner. If the level
is turned upside down, solid rock from an unused row at the top edge of
the map ends up at the bottom, and the placement code could put the hero
there. That code only checked for walls and monsters being in the way,
not rock. Also, if the level is flipped side-to-side than hero ends up
in same area as the upstairs rather than on opposite side of the Castle.
This switches to the same teleport-region code used for other level
changes which don't arrive on stairs; such regions get flipped along with
map by that patch (I hope). Even though no such fix is currently needed
for unmodified nethack, this change gets rid of the special case Castle
placement code entirely, simplifying both goto_level() and u_on_sstairs()
in the process.
The Castle's existing from-below region covers the rightmost half-
dozen or so columns across all rows, so offers a bigger landing zone than
just the bottom corner. That could be tweaked within castle.des but I
don't think it needs to be.
From a bug report, being stuck in the
floor or in lava and trying to move downwards while levitating gave "you
are floating high above the floor/lava" which contradicts being stuck.
Now you'll get "you are trapped in the floor/lava" in that situation.
I thought about letting it fall through to the chance to autodig with
wielded pick, but decided to go with just the alternate message. (Being
tethered to a buried iron ball still lets you "float high above the floor",
so this doesn't check for being trapped that way.)
Make being tethered to a buried iron ball be a bit more interesting
than just being stuck in the floor. You can now move within a shortened
chain radius (1 step from the ball's burial location rather than normal 2
that applies when it's on the floor). This has only been modestly tested,
and the message gets to be annoying if you move around a bit while monster
attack and object pickup/drop messages are being delivered. There ought
to be some better way to override Norep.
This would work nicer if the chain was actually visible at the ball's
location instead of becoming implicit at the time of burial. But I don't
want to try to figure out all the ramifications of having an object on
the floor which can't be moved--perhaps uchain handling already suffices,
but I suspect that there's a can of worms waiting to have its lid opened.
From a four year old news posting: hero was levitating via #invoke
on the Heart of Ahriman, then dropping that artifact yielded:
You drop a gray stone named The Heart of Ahriman.
You float gently to the floor.
A gray stone named The Heart of Ahriman hits the floor.
That might be strictly correct, assuming that both hero and stone fall at
the same speed; if the stone was dropped from perhaps waist height then
the hero's feet would touch first. But it looks strange, like a cartoon
where something hangs in midair until someone notices that it should fall.
Removing the artifact from inventory causes the #invoke property to
toggle off. Unfortunately it has to be done here before the object can
be placed at its destination. Modifying message order seemed unviable;
this fix fiddles with the Levitation property in order to defer hero's
descent until after object handling is finished. Now same setup gives:
You drop a gray stone named The Heart of Ahriman.
A gray stone named The Heart of Ahriman hits the floor.
You float gently to the floor.
You see here a gray stone named The Heart of Ahriman.
This is probably on <Someone>'s bug list, but I don't remember where
that lives. I found a copy of an old news message by him which pointed
out that gem probabilities are set for a given dungeon level at the time
it is being created, but they don't get reset when an existing level is
revisited. So giants' inventory creation and any monsters' death drops
generate gems using values from the level most recently made rather than
from their/hero's current location. That can lead to high level gems in
the main dungeon after entering the mines.
Clean up the code at the end of goto_level(). The only change in
behavior, aside from eliminating a couple of wizard mode quirks, is that
if a hangup save occurs while staring at the quest entry message, it will
be flagged as seen and not show up again if you leave and return to the
quest after restore. (For wizard mode, you'll no longer find the Wizard
waiting if you use the level teleport menu to jump directly to the Astral
Plane from outside the endgame, and level teleporting away from astral
level to one of the elemental planes then returning won't make more fake
players or another guardian angel.)
Simplify the insertion into and removal from of gold in inventory for
the !GOLDOBJ configuration. If GOLDOBJ ever becomes unconditional this
will be superfluous, but in the mean time it unclutters the container and
drop code. Also, tweak a recent getobj() hack so that its purpose might
be a bit clearer.
Some miscellaneous changes preparatory to enhancing the container
interface. This also fixes a minor inconsistency in object manipulation:
askchain() wouldn't let you split a stack of welded weapons but getobj()
would, so you couldn't get rid of part of the stack using 'D' or #loot,
but you could with 'd' (and post-3.4.3, with #adjust). Now getobj() will
behave like askchain(); if you have 3 cursed daggers welded to your hand,
you won't be able to drop 1 or 2 of them anymore.
Make worm teeth and crysknives be stackable. Positively enchanting
a stack of multiple worm teeth produces a single crysknife, negatively
enchanting a stack of multiple crysknives produces a single worm tooth.
A dropped stack of N fixed crysknives has 90% of remaining N crysknives,
10% of becoming a stack of N worm teeth, rather than produce an average
of 0.9*N crysknives and 0.1*N worm teeth. (The code which handles that
transformation operates on loose objects so cannot handle stack splitting
because it wouldn't have any idea of what to do with extra objects.)
Terminate multi-shot volley throwing of boomerangs if one comes back
and isn't caught. The sequence throw-catch-throw-catch is odd, but would
take a substantial amount of code and effort to be changed to the more
intuitive (for rapid volley throwing) throw-throw-catch-catch. Even if
feasible, doing that for underused boomerangs would be a waste of effort.
If a Rider's corpse revival timer ends with failure (presumeably
because the level has become entirely filled with monsters), give it a big
chance to try again in a few turns instead of always rotting the corpse
away. Also, if there is another monster standing on the corpse when it's
due to revive, try to bump that monster out of the way to let the Rider
revive in place instead of having it be diverted to some other location.
Eliminate a couple of minor redundancies; no change in game play.
dropy() - only check about selling object if there is a shop on the level.
pick_obj() - leave it to addinv() clear object's no_charge bit.
From the newsgroup: it was possible to saddle, mount, and ride on a
sleeping jabberwork without it ever waking up. Movement was checking for
timed sleep (!mon->mcanmove, set when mon->mfrozen contains a timer count
for either sleep or paralysis) but not indefinite sleep (mon->msleeping).
This moves the checking into its own routine which handles both types.
And it gives monsters a chance to wake up when they get saddled or mounted.
- Instead of checking for the Rogue level, check which
graphics are engaged (PRIMARY or ROGUESET) in the
SYMHANDLING() macro.
- track which graphics are active through 'currentgraphics'.
- Instead of symset and roguesymset and symhandling and roguehandling
variables, have symset and symhandling be arrays of two, with the
following indexes:
PRIMARY
ROGUESET
That reduced the amount of repeated code.
(Not to be confused with the 'symset' and 'roguesymset' config file options
both of which still exist)
- the symbol routines were adjusted to pass
the index , rather than 'rogueflag' and coding to roguesymset etc.
Other than fixing bugs that are encountered, this is probably
the last of the symbol stuff, with the exception of
making the symset and roguesymset config file options
accept the keyword value "default".
When the hero arrives on a level and a monster at his destination can't
be relocated to make room for him, goto_level() would place the hero on top
of the monster. From a bug report, who said that the
game panicked (without providing specifics, at least so far). I wasn't able
to reproduce a panic but get a pair of impossible warnings and can confirm
that there is a monster on the same spot as the hero, which could easily
lead to strangeness depending upon what actions the monster attempts to
perform. This fix causes a non-relocateable monster in that situation to
be moved to the migrating monsters list for later arrival back on that same
level. That's inconsistant with the migrating monster arrival routine,
which kills off any monster it can't place; I'm not sure which action is
more reasonable, deferred arrival or outright removal.
There are three or four dozen ``(void) rloc(mon)'' calls which don't
do anything special when rloc fails to move the monster. Those need to be
reviewed and the ones where it's making a space for some other monster have
to do something about failure. (Failed teleport attempts can simply leave
the monster in place, so most of those calls won't need any extra handling.)
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.
Fix the bug From a bug report.alt.org server, where killing a monster by closing the
castle drawbridge resulted in a panic after the dead monster's possessions
were dropped into the moat and a potion of acid exploded in the process.
water_damage() deleted the object but had no way to tell flooreffects()
that it was gone, so flooreffects() couldn't tell its own caller not to
place and stack the object. After that, a chunk of freed memory became
part of the floor objects chain and eventually triggered a panic which
tried to make a save file but whose reason didn't get logged properly.
Add Hojita Discordia's Dungeon Map overview as
conditional code for experimentation and testing.
Everything is guarded by
#ifdef DUNGEON_OVERVIEW
#endif
The notes that accompanied the original patch follow.
Dungeon Map Overview Patch for Nethack 3.4.3
Version 3
=============================================================================
Changelist:
v3: Changed #level to #annotate to avoid #levelchange collision. Fixed
handling of elemental planes and astral plane (oops). Changed
formatting to be slightly closer to print_dungeon()'s. Should be
"final" version for 3.4.3.
v2: Added tracking of trees. Changed ctrl-m command to ctrl-o. Portals
displayed as "sealed" instead of "closed".
v1: First release.
(Note: all versions are mutually save compatible.)
=============================================================================
This patch creates a dungeon map overview that is recorded as the player
explores the dungeon. I was tired of returning to a game a few days later
and having no idea what the dungeon looked like. Trying to name pieces
of armor with shorthand didn't work so well as an intermediate solution
either, especially around nymphs.
It can be assumed that this map is in the mind of the hero and thus
can't be stolen, can be read when blind, or when buried, or when the hero
doesn't have any hands, or eyes, or hands free, or...etc. On the other hand,
this implies that the hero doesn't remember all of the details ("a fountain",
"some fountains", "many fountains") and that the map is subject to amnesia
when applicable.
This overview tracks fountains, altars, stores, temples, sinks, thrones,
trees, and dungeon branches. It attempts to not spoil the player nor
reveal more information than the hero knows. For this reason, it only
tracks dungeon features found in the guidebook and dungeon branches.
This patch breaks save file compatibility. Sorry.
Added commands
=============================================================================
#overview (ctrl-o, if not in wizard mode) - displays overview
#annotate (ctrl-n, if using numpad) - names current level
Example Output From #overview
=============================================================================
The Dungeons of Doom: levels 1 to level 15
Level 1:
A fountain
Level 3: (My stash.)
An altar, some fountains
Stairs down to The Gnomish Mines
Level 7:
Many fountains
Level 8:
Stairs up to Sokoban, level 7
Level 15:
A general store
Sealed portal to The Quest
The Gnomish Mines: levels 4 to level 7
Level 7: <- You are here
Many stores, some fountains, a temple
More Details
=============================================================================
The overview shows only levels that have anything interesting to display and
doesn't show branches that don't have any interesting levels.
To avoid the map revealing more information than the hero knows, the overview
only displays things that the hero has seen or touched. (If the hero
blinds herself, levitates above a known fountain, and obliterates it with a
wand of digging, the overview will still say that there is a fountain.)
This is done, sadly, by adding 6 bits to the rm struct to track the last
known dungeon type. On the other hand, this change could potentially allow
a window port to do something like drawing an item and a fountain on the same
square.
Things That Could Be Better And Maybe Some Feedback Would Help
=============================================================================
"<- You Are Here" is pretty goofy
-...but an indicator of some sort is nice.
=============================================================================
Many thanks to all the kind folks on r.g.r.n. who had very good feedback
about this patch, in particular L (for the trees), <Someone> Papaganou (for the
#annotate suggestion and some formatting feedback), and <Someone> (for the suggestion
of just overriding ctrl-o instead of using the very broken ctrl-m.)
=============================================================================
20060311. Hojita Discordia. (My usenet email is bogus. Sorry.)
Responding with '?' to the "what level?" prompt when using ^V in
wizard mode brings up a menu of special level destinations that lets you
move across dungeon branches. But getting in and out of Fort Ludios
didn't work, and jumping to the endgame forced you to arrive on the Plane
of Earth. Now Fort Ludios will not be selectable in the menu until after
the portal ordinarily used to reach it has been created (so you'll need a
level between Bigroom and Medusa with a vault on it to be created before
you can bypass the magic portal and jump directly to the Fort), and you
can go directly to any of the elemental planes, including Astral, without
stopping at Earth first (the Wizard will be there to greet you, whichever
level you pick). Also, this limits the menu to endgame entries once you
are in the endgame. (Previously, picking a non-endgame level would yield
"you can't get there from here"; you can still get that, if you really
want to see it for some reason, by giving a destination level number
outside the range of -1 to -5 instead of using the menu.)
I hadn't realized that this feature has been around since 3.4.2 until
I couldn't find any new feature entry for in the current fixes file....
Something I noticed during a level change in slash'em:
You hear the sounds of civilization. You fly down the stairs.
The first message ought to follow the second. Our only arrival messages
that are handled via the special level loader occur in the endgame where
travel is by magic portal, and the transit message given for portals is
for entering one rather than exiting at the far side, so this sequencing
problem can't currently be noticed in nethack. But sooner or later there
will be levels reachable by stairs and having entry messages, or there'll
be some feedback added when magic portal transport finishes, and then we'd
get bitten by this.
Tested by adding an arrival message to each of the bigroom variants.
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.
From a bug report: #M30: 3.4.2 bugs and ideas); describe
flyers (poly'd hero or riding flying steed) as flying when they use ladders
or jump down holes. This also gives feedback when using the stairs in the
ordinary up or down case, where no message was previously given.
When you first attempt to walk down the stairs from the Valley of the
Dead to the second level of the Gehennom branch, the game prompts you about
whether you really want to proceed. But if wasn't keeping track of whether
you had previously level teleported past that point (which is possible when
starting from the Valley rather than from higher up), so would still issue
that once-only prompt if you used the stairs later. Mark the prompt as if
it has already given whenever you reach a Gehennom level beyond the Valley.
I think being asleep or unconscious ought to override vision the way
that being blinded does, but that's a more ambitious change than I care to
tackle. This replaces You("see ...") with You_see("..."), comparable to
You_hear(). It catches the reported door case and several variations of
light sources burning out while on the floor rather than in inventory, but
it probably misses some other cases. zap_over_floor() in particular is
highly suspect.
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?
[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.
<Someone> reported that if you polymorph into a flying monster while in a
pit, you must take u.utrap turns to first climb out before you can fly. Of
course, once you're out, you can swoop down into the pit to pick things up
w/o delay. Rather that have you automatically fly out (e.g. like quaffing
a potion of levitation), I thought it was better to take a turn to fly out,
so that's what I've implemented.
The code to deal with exiting a pit is moved to a new climb_pit function
and the "up" command now lets you climb from a pit too (something I've
found non-intuitive in the past).
Finally, I noticed that non-moving monsters could still go up/down even
though they couldn't move around. Added non-moving checks in doup/dodown.
Reported last December by <email deleted>. Using
a wand or spell of undead turning inside a shop used up corpses without
checking whether they were owned by the shop. Although the report didn't
mention it, using stone-to-flesh on statues had the same problem.
I'm not completely satisfied by some aspects of this code, but if I
don't commit what I've got now I probably never would. My original notes
are lost; I thought that there were some additional fixes present, but
looking at these diffs I don't see anything else significant enough to
warrant mention in the fixes file.
As From a bug report, if you couldn't see a rolling boulder
fall into a pit, you only heard the sound if you were blind.
Also fixes the article used in the message.
Attempting to go > while blind and floating over unknown stairs/ladder
would refer to the stairs in the "high above" message (however, the
stairs/ladder remained unidentified on the map). Change this case so
it only refers to stairs/ladder if that's what the hero remembers on the map.
"You push the boulder into the pool" should be "Your steed pushes
the boulder into the pool" if done while riding since that's how other
boulder pushing messages are handled.
Fix the reported problem of bad inventory management if the user
specified a count (with traditional menu style) when attempting to drop
part of a stack of cursed loadstones. After the "you can't drop that"
message, it tried to undo the stack split, but splitobj was changed
sometime back and the undo hack wasn't adjusted to account for the fact
that it needed to merge with the previous object instead of the next one.
The result was that it would incorrectly increment the count of the next
item instead of the original loadstone, or crash in canletgo() if the
split off stone was the last item in the list.
This prevents cursed loadstones from being split (via getobj()'s
count handling) in the first place, so there's nothing to undo later.
It still uses a similar kludge so that the "can't drop that" message can
be adjusted, but it's now a simpler kludge and I hope a more robust one.
Use a new flush_screen(-1) call to toggle 3rd screen update in goto_level.
This keeps the 3rd screen state unchanged, no matter what happens at higher
levels, ensures the map window cursor stays on the hero, ensures the
hero's showrace colors remains bright white, and so on.
It is not physical damage if:
1. it already qualifies for some other special type of damage
for which a special resistance already exists in the game
including: cold, fire, shock, and acid. Note that fire is
extended to include all forms of burning, even boiling water
since that is already dealt with by fire resistance, and in
most or all cases is caused by fire.
2. it doesn't leave a mark. Marks include destruction of, or
damage to, an internal organ (including the brain),
lacerations, bruises, crushed body parts, bleeding.
Current exceptions to the rule (already existing):
- holy water burning chaotic ("it burns like acid") is physical damage.
- unholy water burning lawful is physical damage.
- [fixed in trunk] Jumping/Newton's-Thirding into something solid
- [fixed in trunk] Being hit by Mjollnir on the return
- [fixed in trunk] Contaminated or boiling water from a sink
- [fixed in trunk] Falling on a sink while levitating
- [fixed in trunk, fire only] Any passive attack
- [fixed in trunk] Zapping yourself with a wand, horn or spell
- [fixed in trunk] Burning (un)holy water
- [fixed in trunk] Thrown potion (bottle)
- [fixed in trunk] Bumping head on ceiling by cursed levitation
- [fixed in trunk] Exploding rings and wands (under all circumstances)
- [fixed in trunk] Stinking cloud damage
- [fixed in trunk] Sitting in a spiked pit, in lava
- [fixed in trunk] Exploding spellbooks
- [fixed in trunk] Falling off or failing to mount a steed
- [fixed in trunk] Falling into a (spiked) pit
- [fixed in trunk] Land mine explosion
- [fixed in trunk] Fire traps
- [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!"
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
> Not all objects say "Splash!" when they fall in the
> water. When levitating/flying and dropping things they
> don't, but when polymorphing and forced to drop items
> they do. [<email deleted>]
when floating over the water, things dropped always
make some sort of sound. Also fix up some messages
when Underwater that previously said things like
"feel what is lying on the water" by adjusting
surface() in that situation to return "bottom."
While looking into this, I noticed that if you
are polymorphed into a Flyer and you then polymorph
back into your normal form, you don't end up in
the water until you move, so this attempts to
correct that too.
Introduce a new set of functions to manage delayed killers in the trunk, used
in addressing the various reports of delayed killer confusion. Since existing
delayed killers are related to player properties, the delayed killers are
keyed by uprop indexes. I did this to avoid adding yet another set of
similar identifiers.
- the new delayed_killer() is used for stoning, sliming, sickness, and
delayed self-genocide while polymorphed. Some other timed events don't
use it (and didn't use the old delayed_killer variable) because they
use a fixed message when the timeout occurs.
- A new data structure, struct kinfo, is used to track both delayed and
immediate killers. This encapsulates all the info involved with
identifying a killer. The structure contains a buffer, which subsumes the
old killer_buf and several other buffers that didn't/couldn't use killer_buf.
- the killer list is saved and restored as part of the game state.
- the special case of usick_cause was removed and a delayed killer list
entry is now used in its place
- common code dealing with (un)sliming is moved to a new make_slimed function
- attempted to update all make dependencies for new end.c -> lev.h
dependency, sorry if I messed any up
+ 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.
