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.
Back in April, <Someone> reported to the list that when you are
polymorphed into a mimic and #monster, and return to human form while still
mimicing, your appearance does not change. This was due to a change
between 3.4.0 and 3.4.1 that caused all mimicing to go thru one case and
the code to change appearance was actually never executed.
Digging a pit while a xorn set the trap time, but falling into a pit did
not. While lookin at this, it occurred to me that the same inconsistency
might occur while polymorhing from/to a xorn, and there was.
Due to limitations in some interface's display capabilities, don't let
polymorphed players web over stairs or ladders. As a side effect, this
side-steps missing checks for webs when going up or down stairs and ladders.
> Receiving Excalibur from a fountain while blind doesn't update the
> display (i.e. the missing fountain) immediately.
Various other topology changes had the same problem. The display
was only being updated if the hero was invisible on the assumption that
it wouldn't matter otherwise, but a blind character who moved off the
affected location would still have the old map info (fountain, trap, &c)
shown--until he walked back onto that spot or searched next to it or
regained sight--even though the player is told about the map change as
it happens.
Below is the result of your feedback form. It was submitted by
<email deleted> on Tuesday, March 11, 2003 at 07:48:17
---------------------------------------------------------------------------
mailversion: 1.17
nhversion: 3.4.1
nhfrom: Our 3.4.1 source release, unmodified
hardware: i686 arch.
software: Debian woody, gcc 2.95.4
comments: When polymorphing to eg. horned devil, and wearing a helmet,
I get "Your pierce through your elven leather helm.". Likely
there is a broken variable there.
Prevent burying a ball from ending your punishment.
When you bury the ball, internally NetHack Punishment
ceases, but a new trap type of TT_BURIEDBALL immediately
kicks in (acting similar to TT_INFLOOR in some ways).
You can eventually work the ball free (or teleport, etc.),
but that will just return you back to normal Punishment.
Building with an old version of gcc with various warnings enabled
generated a lot of noise. Most of it was due to not guarding string
literals with `const', but there were a couple of actual problems too.
Some recent newsgroup discussion claiming that a pet ki-rin was
wearing a helmet (I think poster was hallucinating) caused me to look
at some of the hat handling code. There were a couple of noticeable
problems and one latent one in code added for 3.4.1. Polymorphing
into a minotaur pushes hard helmets off hero's head, but nothing
prevented you from putting one right back on. Helmet wearing monsters
who polymorphed into minotaurs weren't affected at all. And message
handling always assumed multiple horns even though we have some singled
horned monsters, but since all those have no hands they can't wear any
armor and that potential pluralization issue wasn't noticeable.
<Someone> wrote: "Also, hobbits can't wear armour,
at least, you can't wear armour when polymorphed into a hobbit, even
though hobbits do tend to be carrying elven mithril-coats.
It's tempting to suggest adding an explicit exception in
sliparm() for elven mithril just to keep the Tolkienness."
- added a general routine for adding race-based /object
combination exceptions.
- hobbits can wear elven mithril-coats
<Someone> reported several incorrect death messages
1) "petrified by deliberately gazing at Medusa's hideous countenance" is
too long and won't fit on the tombstone. I reworded it, which also better
reflects that Medusa's gaze is really an active attack.
2) "killed by war hammer named Mjollnir" for partly identified Mjollnir now
says "killed by a war hammer named Mjollnir".
3) "using a magical horn on himself" was missing the "killed by" prefix
4) there were supposedly cases the the a/an article was missing after being
killed by a monster. I didn't see where this was occuring (eg AoLS resets
killer_format before it returns), but now done_in_by always resets
killer_format, which should address any such cases.
Polymorphing into creature with horns such as a minotaur,
will cause your helmet to fall off if it is made of a hard material.
Only minotaurs pass the has_horns() test in include/mondata.h
because the complaint specifically referred to them, but that
should perhaps be reviewed at some point by someone who is
certain which creatures have horns growing from their
head (some demons?)
Fix the problem [reported in the newsgroup and forwarded by <Someone>]
of blessed potions of gain level having the possibility of reducing
your experience points if you were already level 30. The random XP
value that averages "half way to next level" could be less than your
current experience if you had gotten to level 30 via such a blessed
potion or had drunk at least one of same since reaching that level.
This didn't really make any difference to game play since you weren't
losing any levels, HP, mana, or score, but it was visible to users who
enable the `showexp' option.
As per <Someone>:
> I had a game today where I was polymorphed (by a sink) into a mimic, and
> #monster-ed (hid). The symbol on the map for me was ]. Then, I polymorphed
> again, this time into a kobold lord -- but the symbol remained ]. This
> seems wrong.
Handle this similar to the polyman code.
When potions of full healing got added, they included the
ability to restore lost experience levels when blessed ones are
quaffed. This patch throttles them so that when multiple levels
have been lost, drinking multiple potions can only restore half
of those levels. Also, it prevents them from fixing any level
loss which occurs if you polymorph into a "new man" (or woman
or dwarf, &c, where you can gain or lose up to 2 levels).
This also makes the "golden glow" prayer result be at least
as good as blessed full healing by restoring a lost level instead
of giving 5 extra hit points when you have any recoverable lost
levels pending.
And tangentially related: gaining a level while polymorphed
now gives your current monster form an extra hit die in addition
to the latent boost your normal human/whatever form gets.
Files patched:
src/exper.c, polyself.c, potion.c, pray.c
