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.)
There were routines that were passed the
object name as an argument. Before the oextra
patch, ONAME() always returned a valid pointer
to a location within the obj struct. The oextra
patch worked around those cases by
using a temporary variable that was either set
to ONAME (if the obj passed the has_oname() test),
or to "" (pointer to an empty string) if no name was
present.
Since that might be a common thing to do, provide
the safe_oname() routine that you can use as a
function parameter without having to worry about
about whether ONAME(obj) is valid, and without
the need for the temporary variable.
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.
<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.
<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>? :-)
Move some internals-related code out of port-specific main so that
it isn't duplicated a bunch of times. One minor side-effect of this
change is that if you auto-pickup something at the very start of a game,
it will happen after any full moon/new moon/Friday 13th message rather
than before. There's a second change for some: the shared main() used
by several of the micro ports had a small difference in game play--if you
saved a game while on an engraving, it would automatically be read when
you resume--that will now occur for everybody [Elbereth weenies rejoice!].
pcmain() was also calling update_inventory() at start of play. That's
unnecessary for new games, where inventory initialization triggers a call
to it for each item added to your pack; but I wasn't sure about restored
games, so everybody gets it there now.
The Mac and BeOS ports evidently haven't been touched it some time;
they still referenced flags.move which got replaced by context.move quite
a while back. The Windows GUI code has a declaration for mswin_moveloop()
which appears to be non-existant, but I left it alone. I assume that the
Qt interface uses the existing main() routines; at least I couldn't find
any start of game code specific to it. vmsmain's revised main() is the
only one which has been tested.
Something I encountered while playing slash'em a while back, but
relevant to nethack: "Its orcish spears shatter from the force of your
blow!". I was using a two-handed weapon (at skilled or expert level) to
fight an invisible monster which was wielding a stack of multiple spears
(slash'em gives them out in groups of 3 for monsters' starting inventory).
After killing it, I found 2 orcish spears along with an invisible corpse
of somebody-or-other the Kobold King. The message suggested that the
whole spear stack had been destroyed (and the weapon shattering code in
hmon_hitmon() clearly expects that to be the case), but only one of them
had actually gotten used up.
I can't recall whether "shatter" was actually given as singular or
plural at the time; nethack handles that aspect correctly. Only object
destruction needed tweaking.
<email deleted> wrote:
> Eating gold in a vault (or polymorphing a pile of gold into 1 gold piece)
> doesn't anger the guard.
This addresses the eating part of that report, but the hero
has to get caught doing it.
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?
From a bug report: when creating a
level, anthole rooms can be generated even when no ants are left, unlike
beehives which get suppressed once killer bees are gone. Also, if some
ants are available but the type chosen for the current level isn't (in his
case, soldier ants had been genocided), the anthole was filled will random
monsters instead of picking another type of ant. This fixes both issues.
Random monsters will only occur if the last type of ant gets used up while
filling an anthole that was started when some ants were available, same as
how monster generation for beehives and barracks works.
<email deleted> wrote:
> * Doors absorb the blast of a broken wand of striking. What's more, the message
> reads "The door absorbs your bolt!" rather than "blast".
passes wand type to explode() as a negative value for the case
where the wand type isn't mapped to an AD_* explosion type.
Then explode() converts it to a positive and passes it to zap_over_floor().
Implement the following suggestion by <email deleted>
- Reading a scroll of light while confused should
create a hostile yellow light (black light if cursed).
It only creates the light monster effect 1 out of 5 times.
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.
Make a not-very-robust fix for the report from <email deleted> about
being told a scoll disappears as you read it, then for the case of cursed
remove curse being told that the scroll disintegrates. He missed similar
case for scroll of fire erupting into flames after it had disappeared.
This suppresses the "disappears" part of the scroll reading message for
those two cases, but won't be very reliable if other scroll messages
referring to the scroll itself get introduced in the future. [Several
paths through scroll of fire won't report that it burns, and now it doesn't
give the disappears message any more. I don't think that's worth worrying
about; the scroll leaving inventory after burning up is implicit.]
Also cut down on redundant feedback for several scrolls (genocide,
charging, identify, stinking cloud) that start off by informing the player
what they are. That's only needed when the the player doesn't already
know the type of scroll. I've always felt it silly to be told that I've
"found a scroll of genocide" when I'm intentionally reading a known scroll
of genocide. All these types of scroll give a subsequent prompt which
makes them recongizable if you somehow manage to choose the wrong object
when picking the one to read.
Lastly, make spell of identify behave like ordinary uncursed scroll of
identify by default instead of ususally ID'ing multiple items. Now you'll
need to be skilled or better in divination spells skill in order to get the
blessed scroll effect out of it. And give some feedback if the spell is
cast when not carrying any inventory; it was just silently moving on to the
user's next command in that case.
This fixes the monnam() family of functions so that hallucinated
personal names, such as Barney, won't be prefixed by "the". It uses the
same hack as is used for shopkeeper names: single character prefix on
names which warrant some handling other than the default. rndmonnam()
strips that off, so unmodified callers (which is almost all of them...)
retain the same behavior has before.
There are several capitalized names that I have no idea whether need
to be treated as personal names:
Evil Iggy - name, or type of monster named after someone?
Totoro - no clue
Invid - ditto
Vorlon - just guessing that it's a species rather than an individual.
I couldn't remember whether Godzilla was baby Godzilla's mother or father,
so I went with female there. So far, no callers of rndmonnam() care about
gender so it doesn't make any difference. Because of that, I didn't look
though the non-capitalized names to see whether any should be all male or
all female and need one of the other prefix codes.
I've added "were-rabbit" from the Wallace & Gromit movie. The recent
ads for its DVD release reminded me that I was going to add that back when
the movie first came out. I haven't seen it but the creature name fits.
I also fixed Smokey Bear. Smokey the Bear is a common misspelling;
I thought we had fixed that ages ago, back when people still had some clue
as to who in the world he was.
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.
Reveal more tin details at end of game disclosure.
b - an uncursed carrot
c - an uncursed tin of broiled kobold meat
d - an uncursed tin of stir fried fox meat
e - 4 uncursed tripe rations
f - 4 uncursed food rations
g - an uncursed cream pie
n - 4 uncursed tins of spinach
o - 3 uncursed tins of pureed newt meat
p - an uncursed homemade tin of fox meat
Note that in the case of homemade and rotten
it sounded better to have the term before the
word tin, rather than after:
homemade tins of newt meat
rather than:
tins of homemade newt meat
The wishing code should probably be
changed to reflect this so people can wish for
a "homemade tin of newt". As it stands, they must
wish for a "tin of homemade newt" which differs
from the final display. That is not included.
Add new_mname/free_mname functions to make monster name handling be
more like the other extended data and to hide mextra details a bit more.
Add some casts where int and unsigned are being intermixed. Simplify
christen_monst(); it ought to be changed to have type `void' but I wanted
to avoid modifying another ten or so files.
<Someone> noticed the leftover zeromextra, this removes it.
Using memset() on a possibly failed mextra allocation was inapprorpriate,
so replace the newmextra() macro with a function.
Prevent a crash in christen_monst() if mextra was not initialized.
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.
From a bug report, amorphous creatures can fit underneath
closed doors but could still be considered too big to fit through diagonal
gaps. Let them and several other shapeless or flexibly shaped critters
squeeze through provided that they pass the not-carrying-too-much check.
Have killer_xname() handle corpses properly and also avoid having it
use user-supplied fruit names as per <Someone>'s suggestion. Also make
a start at eliminating the umpteen inconsitent checks for whether a monster
type (like "Oracle") ought to be prefixed by "the ".
I used a stub which looped over all object types, all artifacts, and
corpses of all monster types to print the output of killer_xname() for each
one; its prefix choice among {[no article], a, an, the} looked right.
From a bug report: sleeping pet could
be shown as "eating" by stethoscope. Fixing that is a one-liner since all
(or should be all; sleeping gas trap wasn't utilizing it) cases of monster
being forced into sleep go through one routine. That wasn't the situation
for paralysis, but now it is. Paralyzed pets won't continue eating either.
Add support requested by a user for number_pad:3 to use a phone-style
keypad layout where 1,2,3 are on the top row and 7,8,9 on the bottom,
opposite of the adding machine layout adopted by computer keyboards. Also
number_pad:4 combines that with the number_pad:2 hack to give different
behavior for the 5 key (also meta-5 and meta-0). And number_pad:-1 is a
rather absurd way to support German keyboards which have y and z keys
swapped, avoiding the need to add a new option for that. With it, z moves
upper-left and y zaps wands, with corresponding swap of the upper case,
control, and meta variations of those two letters. (There is a "German
keyboard patch" for this floating around the net, but it implements a
compile time configuration setting which results in hard-coded behavior
for those keys. This implementation lets it be toggled on or off at will.)
There's more here, intended to ultimately simplify rhack() quite a
bit. Most of that isn't finished yet. However, the part that is done
should produce same run-time behavior as before. I hope....
iflags.num_pad and iflags.num_pad_mode should now be viewed as opaque
items used for communicating dynamically updated option settings to the
core only. Ports and/or interfaces which feel inclined to peek at them
should switch to Cmd.num_pad,&c instead. (I've made that switch for a
couple of places which would have stopped compiling due to sdir and ndir
going away, and for vms+tty where I could directly test the change(s),
possibly plus one or two places which got heldover over from my earlier
attempt that did try to update all of them. Ports which haven't made the
change yet ought to continue to work as-is though.)
Eventually ports/interfaces which implement alternate ways to invoke
commands (pull down menus or extra keyboard buttons or whatever) should be
able to scan Cmd.commands[] to figure out which input characters trigger
which nethack functions. The ones that currently use hardcoded key lists
will probably need to migrate before any dynamic key binding functionality
gets implemented. (Which may never happen; it's definitely not on my own
to-do list.) Cmd.serialno is intended to be the way for them figure out
when the commands have been changed (which right now only happens when 'O'
is used to alter the number_pad setting); perhaps a new interface callback
would be better suited for communicating this.
It may be necessary to rearrange header inclusion so that func_tab.h
gets included before flag.h (and/or struct cmd gets moved from the latter
to the former--but then func_tab.h would be needed in a bunch of places
which don't currently use it) to support some pre-ANSI compilers. And the
command initialization might need to be moved to somewhere earlier than
init_options() at some point if port/interface initialization starts caring
about it.
The fix to prevent naming an unknown gray stone "the Heart of Ahriman"
from revealing whether the object was a luckstone was inadequate to prevent
using the same trick with "the Mitre of Holiness" to determine if an unknown
helmet was a helm of brilliance. (I don't know whether whoever figured out
the first one has realized the second yet; no one had mentioned it in the
newsgroup the last time I looked.) To get this right we need to check for
objects sharing the same set of shuffled descriptions in addition to testing
whether they have identical descriptions. Doing that meant reorganizing how
object shuffling is done, but it produces the same behavior as before.
Let monsters use lock picks and credit cards in addition to keys for
opening doors. And the earlier code to have pets hang on to a key didn't
work as intended. It worked fine if the key was the only object carried,
but the monsters' item dropping code didn't give any special handling to
keys so they'd be dropped too if the pet carried another droppable item.
This eliminates second set of checks for handling some items specially--
dropping now uses the same routine as is used when pet movement decides
whether there's anything to drop.
Also, a couple more door message tweaks. "You see a door open" seems
strange when you watch your pet do the opening. Previously fixed for the
"unlock and open" case, this does the same for opening already unlocked
doors and for giants smashing down doors--it now gives a more specific
message when you see a monster perform the action.
Possible change in play balance: pets capable of picking up the
rogue's Master Key of Thievery or tourist's Platinum Yendorian Express
Card will keep one of them. So a player might accidentally lose one by
leaving it on the floor in a pet's path, or more significantly, the Card
will yield a means of giving magic resistance to a monster who can't wear
a cloak or dragon scales. It's neutral and the most interesting high-end
pets are lawful (hence won't pick it up), so that probably won't have much
impact.
From a bug report, the probing/stethoscope code assumed that all Angels
(the specific monster type, not the whole 'A' class) used the epri extension
to hold alignment, but that's not true for randomly generated ones. So
monster status feedback gave erroneous results, and it would vary based on
pet behavior if the random Angel had been tamed. Also, touch_artifact()
didn't know about special alignment handling for Angels and aligned priests
so always used their default alignment.
There are other problems with Angels--such as whether they should even
be allowed to be generated randomly in the first place--that this doesn't
attempt to address. The patch for that was starting to sprawl all over the
place so I pulled this simpler bit out for a first cut. Probing now shows
the Wizard of Yendor as unaligned instead of lumping him in with chaotics.
Another Makefile update needed: pline.[c,o] no longer needs epri.h.
Fix a couple of problems From a bug report. Eating a Rider corpse is fatal, but eating a live Rider's
brain was not--now it will be, both for monster mind flayers and for player
poly'd into one. Also, there was no check for cannibalism when poly'd hero
eats brains--now there is. Not mentioned in the report: eating Medusa's
brains will now be fatal just like eating her corpse. And pet mind flayers
who eat the hero's brains will gain some nutrition like they do when eating
monster brains.
Creating a common eat_brains() routine turned out to be something of
a mistake; there is only a tiny amount of overlap among the u-vs-m, m-vs-u,
and m-vs-m cases.
Makefiles need a dependency update to add edog.h for eat.c.
Noticed when incorporating the "vampire dancing" patch: losing a level
while polymorphed would subtract from your normal hit points but didn't
affect your monster hit points. Now they'll lose d8 from max and current,
similar to the amount they increase when gaining a level.
This also addresses an issue from the newsgroup a few weeks back:
someone mentioned an assumption that Stormbringer drained an amount other
than d8 for monsters who use some other formula for their hit points. It
wasn't true, but now it will be (approximately). Most monsters with unusual
hit points aren't subject to level drain, so it shouldn't have much impact.
Fix the problem pointed out by <email deleted>
where polymorphing into a new man at level 1 could be used to approximately
double or triple your hit points and spell power. With means to drain
level back down to 1 and with amulets of life saving to survive those times
you lose levels instead of gain, you could do this repeatedly and end up
with HP and Pw values in the millions.
This uses the earlier patch that records the HP and Pw increments from
level gains. Now when polymorphing into a new man, level based HP and Pw
are removed from the current values, remainder get multiplied by 80%, 90%,
100%, or 110% (average 95%, so tend to drop slightly), then a brand new set
of level gain increments (reflecting new man's Con and Wis) are added in.
Code for calculating spell energy is moved from pluslvl() and u_init()
into new routine newpw(). It and newhp() take over responsibility for
remembering the level based increments from pluslvl() which didn't deal
with the initial amount (stored in slot [0]; earlier patch didn't need it).
Make it easier for a low level character with ordinary Max HP to get
the healing result from a successful prayer. Mid level characters are the
same as before: will be healed if at 1/7 (or worse) of max. High level
characters, or anyone with Max HP really high for their level, will need
to wait until current HP is lower before being able to obtain that result.
This mainly affects spoilers; the actual impact for any player who doesn't
know the old formula is fairly small. The exception is for "protection
racketeers" who manage to build up a high HP without gaining any levels;
a level 1 character will only get healed when at HP 5 or less, regardless
of what percentage of max their current hit points are.
Under the old system you could get healed at 6 HP if you had 42, at
7 HP out of 49, and so forth. Now you'll need to be at least level 2 to
get healed at 6 HP out of 30 or more, at least level 3 for 7-9 out of 35-45.
"Normal" max is capped at 15 times level and anyone above normal is treated
as if their max was that lesser normal value. Levels 1 to 5 use a new
threshold of current HP being 1/5 (or worse) of max, levels 6-13 use 1/6,
14-21 retain old 1/7 threshold, 22-29 now use 1/8, and level 30 uses 1/9.
The somewhat odd level break points are based on where rank titles change.
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.
From a bug report. <Someone> as slashem-Bugs-883643 on 1/24/2004. To avoid
using the possibly invalid object pointer after calling bhit(), changed as
suggested to add another level of indirection allowing bhit to null the
object pointer before returning. Callers that are affected update their
object pointers after bhit returns.
Make petrification initiation or termination go through a new routine,
make_stoned(), instead of manipulating its countdown timer and delayed
killer directly. No change in behavior.
There's no reason in terms of bug risk or game play or saved data why
this shouldn't be done in the branch too, but so much of the surrounding
context has already diverged between trunk and branch that it's trunk only.
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?
> clear stale prompt
[...]
> Can someone who understands the relevant windowing code fix ^R in getpos()?
I still don't understand why it wasn't working as expected, but moving
the existing cursor positioning after flush_screen() instead of before now
makes ^R work ok during getpos(). It doesn't restore the top line text so
isn't a transparent redraw but it now displays a prompt string there instead.
Likewise after typing '?' for help so that it should be move evident that
nethack is still waiting for you to move the cursor somewhere.
Also add support for ^L in numpad mode. I almost never use that and
didn't think of it the first time around.
This uses Michael's suggestion for keeping the display up to date when
removing a djinni or water demon in advance of granting a wish (so that it
won't be present in a bones file if the wish is fatal--problem with earlier
fix was that player could notice monster was already gone while responding
to the wish prompt). It's not quite as straightforward as I was hoping for
and would get a lot messier if it needed to cope with Warning & Warn_of_mon.
Pointed out by <Someone>: engraving with a cursed wand should pose a
risk of having it explode just like zapping does. [At the moment when one
explodes, any existing engraving doesn't get changed.] Suggested by someone
(<Someone>?) some time back: explosion due to recharging could be consolidated
with explosion due to zapping cursed wands. And noted by <Someone> in the
newsgroup: '+' in an engraving--perhaps written by someone trying to leave
bones file notes--should have a chance of being partially rubbed out to '-'.
Implement the suggestion that Fire Brand avoids damage from rust traps
by boiling away the water. Rather than making this be trap-specific, it
applies to all types of erosion which go through erode_obj(). That includes
hitting rust monsters but not dipping into potions or fountains, nor falling
into moats. And it doesn't provide 100% protection, just a high chance of
avoiding rust damage. Also, Frost Brand gets similar protection by freezing.
The message handling needed some rewriting for the branch version.
That compiles ok but hasn't been tested. It would have been simpler just to
move Yobjnam2() over even if nothing else was changed to use it yet....
<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.
[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.
Fix a buglist entry: fracturing a boulder or statue owned by a shop
was ignored by the shopkeeper. The existing vague fixes entry of "some
shop thefts weren't charged" covers this.
Suppress "Mr" or "Ms" title for shopkeepers when they're going by a
first name rather than a surname. The bug report was for Izchak, but it
would have happened with the two last resort names (which I've never seen
in actual use) and for the "hippie names" used in post-3.4.x health food
shops. I have not attempted to specify gender for those, just flagged
them as first names. This prepends a prefix character to the name string
(see comment in shknam.c) to specify gender and/or first name vs surname.
Revert mostly to <Someone>'s original approach for keeping track of whether
a container being applied or looted had been destroyed by the operation.
askchain() now knows not to attempt to re-merge an item that has been
destroyed (a theorhetical action since no stackable items can trigger a
magic bag explosion) like the earlier change to menu_loot(). Also have
use_container() clean up after itself so that current_container never has
an old pointer value left around.
A user recently complained that he started an activity such as
searching and specified a repeat count, right after getting--and not
realizing the significance of--the first message in the countdown
sequence for turning into stone. He suggested that subsequent messages
interrupt multi-turn activity so that the player has a chance to do
something to prevent imminent death. This implements that, with the
added wrinkle that it won't interrupt if the activity is something that
might save the character's life: attempting to eat a tin that is either
sure to help (if ID'd as food that cures stoning) or a desparate gamble
(if unID'd). Some hooks for similar behavior for other conditions like
turning into slime are included, although no tins can help for anything
other than petrification so far.
Shouldn't fatal illness have an end-is-near countdown too?
