fix #H1816 - polearm/grapnel/whip fixes (trunk only)

     From a bug report, applying a polearm to make a
short-range ranged attack didn't scuff any engraving you were standing on,
unlike ordinary melee and throwing/shooting attacks.  Grappling hooks had
the same omission.  Fixing it led to several other minor bugs.  Attempting
to target an unseen monster's spot with polearm or grapnel would yield some
permutation of "wait, there's something there" but draw the 'I' glyph at
the wrong spot.  It used <u.ux+u.dx,u.uy+u.dy> instead of the actual target,
so put the 'I' one step in front of your most recent move (or throw or zap
or whatever last set u.dx and u.dy).  Giving ESC when prompted for target
spot failed to use up a turn even when the polearm or grappling hook had
just been auto-wielded for use.  Neither use_pole() nor use_grapple() set
`notonhead' for hmon() (called via thitmonst() in their cases; this was
academic since plain physical damage attacks don't actually care about it).
[The bad 'I' placement was a post-3.4.3 bug.]

     Applying a bullwhip to attack an adjacent monster didn't have any of
those issues but did have the possibility of targetting off the edge of
the map when standing at that edge while confused or stunned.

     Applying a polearm to target an 'I' would yield "nothing happens" if
the unseen monster wasn't there anymore, and it didn't bother to remove
that 'I' from the map.  After changing it to do so, the phrasing no longer
made any sense.  This led to a slightly bigger change than I intended:
since statues are now shown as gray monsters (does that work for tiles?)
instead of as chunks of stone, they are likely to be intentional targets
sometimes, so polearm attacks now handle them differently from other
non-monster locations.  [I hope that other attack forms don't need
similar handling.  Melee certainly doesn't, since walking onto the spot
is enough to distinguish statues from monsters.  Having the missile pass
right through a statue's location probably suffices for ranged attacks.]

mimics as doors on rogue level

     From a bug report.5 years ago? and again today:
mimics appear on the rogue level even though they're lowercase letter
monsters.  <Someone> notes that during level generation, mimics pretending to
be closed doors are sometimes substituted for trapped actual doors.  That
should be avoided on the rogue level both because its doorways are always
empty (enforced after the fact in extralev.c code rather than in the door
making code) and because mimics aren't uppercase letter monsters (so
should only ever appear there if they've travelled from another level).

small mimic grabbing bug (trunk only)

     Noticed while testing the patch for monster ranged attacks when hero
is hidden.  Using #monster while in small mimic form would hide you, as
intended, but the first monster (or last monster?) who hit you hand-to-hand
would be grabbed ("It gets stuck on you.").  Unlike large and giant mimics,
small ones lack such a grab attack so when you eventually returned to
normal form, u.ustuck would remain set and you would end up being stuck
to an arbitrary monster instead of releasing it from your grasp.

fix #1812 - ranged targetting of hidden hero (trunk only)

     From a bug report, a hero who had
eaten a mimic corpse and was stuck mimicking gold was hit by an approaching
dragon's breath attack.  Make monsters usually fail to notice that you're
lined up for their ranged attack when/if you're hidden from them.

digging prompt: > vs < (trunk only)

     The intersection of a couple of recent patches:  noticed when
updating movement as a grid bug, and accentuated when fixing the attempt
to move down while levitating.  If you can't reach the floor due to
levitation, don't show '>' in the list of likely candidate directions for
the prompt when digging.  It was always included so that the list could
never be empty, but it's a poor suggestion to the player when levitating.
Use '<' instead in that situation; also a poor suggestion, but silly
rather than unintentional.  :-)

     This only affects the bracketted part of the "In what direction?"
prompt, not the actual digging (and player can pick any direction whether
it's shown in the prompt or not, so the digging code is already prepared
to handle attempts to dig up as well as down anyway).

yet more monpolycontrol (trunk only)

     Factor out a few lines of common code instead of duplicating them.

monpolycontrol typo (trunk only)

object save/restore (trunk only)

     Make the same simplification to save and restore of obj->oextra as
was done yesterday for monst->mextra:  no need for a set of all 0 sizes
when the whole thing is null.  Bumps EDITLEVEL again.

fix #H1803 - levitating at floor level...

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

mimic statues & 2009 startup banner (trunk only)

     A mimic posing as a statue was displayed as a tengu statue (and
recognizeable as such now that statues are displayed as the corresponding
monster rather than rock-class back tick), but the lookat code described
it as a giant ant statue (since there was no obj->corpsenm available to
indicate the monster type, it defaulted to 0).  This adds monst->mextra
field `mcorpsenm' so that mimics have a place to remember what sort of
statue or corpse they are mimicking.  And it picks a random monster type
when they take such forms so that the old tengu hack becomes irrelevant.

     newmextra() and newoextra() initialized pointers via memset(...,0)
which is not portable; switch to explicit assignments.  The wizard mode
code to display memory used for monsters and objects added in amounts
for the miscellaneous things pointed to by monst->mextra and obj->oextra
structs but didn't include memory for those structs themselves; add it.
Simplify monster save/restore slightly; there's no need for extra zeroes
to represent monst->mextra->X sizes when monst->mextra is null.

     Update the startup banner for 2009.  I should have done this with a
separate patch but I'm taking a shortcut.  :-]

probing shapechangers and mimics (trunk only)

     Mentioned in the newsgroup recently:  stethoscope didn't reveal
when a monster was actually a chameleon, even though that's the sort of
inside information you might expect.  This adds "shapechanger" to the
other miscellaneous attributes shown.  I initially had "(a chameleon)" or
"(a vampire lord)" but decided that that was too specific, particularly
for the latter where you might expect/hope that the vampire bat next to
you is just an ordinary vampire rather than a lord.

     I had a pet eat a mimic corpse and take on the shape of a pyramidal
amulet.  Probing described it as "mimicing a pyramidal".  Many of the
names and descriptions in objects[] are only partial, so aren't suitable
for supplying feedback like this (and "mimicking" was misspelled...).
Switch to simple_typename(), although in the case of undiscovered amulet
it yields just "an amulet" rather than "a pyramidal amulet".  This also
extends probing feedback for mimicry to include all monsters mimicking
something, not just those who are in the midst of eating.  [That's
post-3.4.3 code and is only applicable for wands of probing.  Using a
stethoscope or hitting with Magicbane will unhide a mimic before giving
extra info about it.]

grid bugs vs diagonal movement (trunk only)

     From a bug report, attempting to move
diagonally when poly'd into grid bug form doesn't give any useful
feedback in the general case, and in the specific case of using 'u' to
try to move northeast with vi-style keys, it performs #untrap instead.
Diagonal directions were being classified as non-movement when in grid
bug form, so the feedback was usually just "unknown command".  But 'u'
is bound to untrap as a a convenience to players who use num_pad-style
movement keys.  (Move commands don't actually reach the assigned key
part of command handling, so for forms other than grid bug, !num_pad 'u'
moves NE despite the untrap function given to that key.)

     Split the diagonal handling out from movement command recognition.
It now gives "you can't get there from here..." if player tries to move
diagonally as a grid bug.  For direction prompts, it now gives "you can't
orient yourself that direction" instead of popping up the command assist
display.  (In the prompt string showing likely candidate directions for
digging, diagonal handling for grid bugs is academic because they aren't
strong enough to wield pick-axes.)

monpolycontrol tweak (trunk only)

I) When testing the shopkeeper polymorph fix a couple of days ago, I
tried to pick a form without a head (which is now rejected for shk) by
specifying "trapper" via #monpolycontrol.  It worked, in the sense that
the shopkeeper didn't take that form, but it also retried with "lurker
above".  After trapper was rejected, it matched "trapper or lurker above"
for monster class and picked at random from that class (and in this case,
the second try was rejected for being headless too).  The code I added
(a couple of years ago?) to prevent picking invalid forms for vampire
shapeshifting was a bit sloppy with its retry attempts.

II) I also noticed that monpolycontrol would let you pick forms that
newcham subsequently rejected, like placeholder monster "giant", so that
select_newcham_form got called again, resulting in a new prompt from
monpolycontrol to choose a form without seeing any explanation why the
first try was ignored.  Now you'll get the same "it can't become that"
feedback and immediate reprompt as for an invalid monster, instead of
returning newcham a form that it won't accept.

III) The change in shopkeeper polymorph was rejecting forms without hands.
That was way too restrictive; the notake() filter is sufficient.

     This is all modification of post-3.4.3 stuff, so no fixes entry.
[Not 100% true.  newcham() doesn't explicitly reject humans anymore,
relying on polyok() test instead.  Kops are the only humans who pass it.
If they're not supposed too, they need M2_NOPOLY in their definition.]

fix #H1798 - limbless shopkeepers shouldn't take possessions (trunk only)

     From a bug report, a shopkeeper who's been
polymorphed into a limbless creature shouldn't be able to come take your
possessions when you die since you can't pick up items when in that shape.
Rather than add new special case handling for shopkeepers, prevent them
from taking on shapes that render them unable to behave like shopkeepers
so that they can continue to catch thrown pick-axes and assorted other
things that would otherwise need a lot of extra checking introduced.
Ditto for temple priests, vault guards, and quest leaders.  Restriction
also applies to wizard mode use of #monpolycontrol, the only place where
players can actually notice this.

     It could--perhaps should--restrict them even further, forcing forms
that retain speech capability, but I didn't go that far.

Sunsword redux (trunk only)

     This started out as a one line change.  After I saw someone in the
newsgroup mention that Sunsword's light was inferior to that of a lamp,
I decided to make it work better (than in 3.4.3, that is, becoming the
same brightness as a lamp) when blessed and worse when cursed (useless to
hero but still visible if wielded by a monster).  But then it needed to
change light radius when its curse/bless state changed, and it needed
message feedback when doing so, and that got kind of complicated.  I
wouldn't have bothered if I'd known what I was getting into, but I don't
want to throw it away now that I've done all this work....

     Sunsword now gives a light radius of 3 when blessed (same as a lit
lamp), radius of 2 when uncursed (same as a lit candle and as it has been
providing since added in 3.4.0), and a radius of 1 when cursed (nearly
but not completely useless, as mentioned above).  Also, it now "shines"
rather than "glows" since we usually use the latter for temporary effects.

blessing/cursing via potion (trunk only)

     Allow potions thrown straight down while hero is mounted to target
steed instead of always hitting the floor.  There's already a fixes35.0
entry for potions hitting worn saddle instead of the creature wearing it,
but that only happened when thrown at a nearby saddled monster, not when
the hero was stuck mounted on a steed with cursed saddle.

     Eight separate "the <obj> glows <color>" messages were too many...
(four for dipping an item in holy/unholy water, four more for throwing
either of those potions at a saddled monster).  Replace the repetitive
code, leaving just two such messages.  Setting of bknown flag for the
dipped object is the only intentional change here.  That used to be done
unconditionally but now requires that the hero see the glow color.

fatal explosion feedback (trunk only)

From the newsgroup:
    As you read the scroll, it disappears.
    The scroll erupts in a tower of flame!
    Your spellbook of force bolt catches fire and burns!
    [...]
    Your potion of paralysis boils and explodes!
    Something seems to be holding you.
    Do you want your possessions idenified?
This character survived the burning and boiling objects then succumbed
to the initial flame explosion.

     A fatal explosion calls done() without any explanation.  Or rather,
it dated to the time where it would immediately follow "the scroll erupts
in flame" (or "you are caught in <some kind of> explosion") without the
chance for intervening messages.  Then when item destruction was moved
sooner (for bones file purposes), message sequencing was left dangling.
This patch adds a new "it was fatal" message in front of done().

Fix a few build issues seen by various compilers
 that I have on my system but haven't used for a while
(a couple of warnings and a couple of errors)

exerchk fix (trunk only)

     Post-3.4.3 problem noticed by Michael:  some code which was supposed
to be inside the end of a loop got placed in front of the wrong closing
brace, ending up beyond that loop.  As a result, decay of old attribute
exercise wasn't working as intended, and out of bounds array modification
was occurring (clobbering u.abon.a[0], which probably messed up resetting
strength when taking off rings of gain strength which were worn during an
exercise check).

lifesaved steed (trunk only)

     From the newsgroup:  hero's steed can become untame if killed while
it is wearing an amulet of life saving, leaving the hero still mounted
and resulting in repeated "placing steed onto map?" warnings when the
steed tries to move.  Force the hero to be thrown off the mount in that
situation.

fix #H1755 - feedback for clerical summoning when blind (trunk only)

     From a bug report, the feedback
you get when a monster summons insects or snakes is the same when blind
as when you can see.  A comment in the code stated as much, but fixing
it is relatively straightforward.  (Or not; there are actually a lot of
cases to be handled; this covers enough of them, I hope.)

fix #H1733 - fainting doesn't behave like falling (trunk only)

     Suggested by <Someone> <email deleted>, fainting from lack
of food while wielding a cockatrice corpse should fall on that corpse
and be fatal, like triggering a pit or moving down stairs while too
heavily encumbered.  I put the fixes entry in the new features section
even though it probably qualifies as a bug.

fix #H1745 - enlightenment about number of times killed

     From a bug report, code that always
produced plural feedback (used only for values of N greater than 3) was
unnecessarily handling plural vs singular.  No change in game behavior;
just one less function call in the code.

fix #H1749 - kick that misses didn't reveal concealed mimic

     From a bug report, getting "your
clumsy kick does no damage" when attempting to kick the location of a
concealed mimic or hidden monster didn't bring the target out of hiding.

[part of] #H1743 - sleeping victim of theft (trunk only)

     Mentioned by <email deleted> in his report about
sound anomalies, it was possible for a sleeping hero to "gladly start
removing armor" when attacked by a nymph or succubus.  The code
explicitly wakes up the hero if he has fainted from lack of food because
"can't charm without waking you" (according to the existing comment),
but it didn't handle other forms of sleep and paralysis.  You could get
 |You fall asleep.
 |The wood nymph charms you.  You gladly start removing your armor.
 |The combat awakens you.
Now in the same situation you'll get
 |You fall asleep.
 |You wake up.
 |The wood nymph charms you.  You gladly start removing your armor.

hand slip when naming objects (trunk only)

     From a bug report, the text change applied
when you try to give an artifact's name to am item of that artifact's type
would choose a letter from 'a' through 'y' when replacing the randomly
selected target letter.  Rather than fixing the off by one bug which
prevented 'z' from being chosen, this switches to the existing routine
used for mangling engravings.  (Unfortunately the fix is not as simple as
first expected, because wipeout_text() doesn't guarantee to change text
which has spaces in it and all the quest artifact names have those.)

monsters eating green slime corpses (trunk only)

     From a bug report, pets able to eat
acidic and poisonous corpses (black naga was the case cited) would eat
green slime corpses without turning into green slime, unlike the hero.
This prevents such monsters from eating green slime unless they're
starving, implements transformation into green slime for the case where
it does get eaten, and prevents non-pet gelatinous cubes from devouring
such corpses.  meatobj() is reorganized to hopefully become clearer, and
it removes the assumption that the object eater is a g.cube in case we
ever adopt slash'em's "tasmanian devil" monster.

     Monsters with digestion attacks who swallow green slime monsters
are turned into green slime, but ones who swallow hero poly'd into green
slime are not.  This doesn't address that.

'[' vs embedded dragon scales (trunk only)

     When dragon scales or dragon scale mail becomes embedded in poly'd
hero's skin, the '[' command would report "you are not wearing any armor"
but the '*' command showed "a set of <color> dragon scales (embedded in
your skin)".  The '[' feedback is more accurate but the '*' feedback is
probably more useful.  This changes '[' to be more specific when lack of
worn armor is accompanied by embedded dragon scales/scale mail.

     I put the fixes entry in the new features section since the old
behavior wasn't a bug.

more breaking wands (trunk only)

     If breaking a wand of polymorph uses up any floor objects, give a
"you feel shuddering vibrations" message like happens when zapping.

breaking wands (trunk only)

     From a bug report, polymorph of self due to
breaking a wand also polymorphed various items that were dropped in the
process, unlike the case of zapping polymorph at monsters which excludes
dropped items from being poly'd.  This polymorphs the pile at the hero's
feet before polymorphing the hero.  I first tried to handle it using
obj->bypass like with monsters, but that didn't work.  Post-3.4.3, the
bypass handling is also used for polyself (by retouch_equipment()) and
it was getting reset at an inconvenient time.

     He also complained that he failed to get "you feel shuddering
vibrations" when some polymorphed objects got destroyed.  That message
is issued by weffects() which do_break_wand() doesn't call.  It ought to
be fixed, but this patch doesn't address it.

     Lastly, add code to prevent objects guarded against polymorph via
obj->bypass from getting used up when creating polypile golems.

comment tidbit (trunk only)

     Noticed when fixing branch code.

misplaced C variable declaration in current code

options.c
..\src\options.c(4072) : error C2275: 'boolean' :
illegal use of this type as an expression
        c:\personal\nhdev\350\test\include\global.h(56) :
see declaration of 'boolean'
..\src\options.c(4072) : error C2146: syntax error :
missing ';' before identifier 'found'
..\src\options.c(4072) : error C2065: 'found' : undeclared identifier
..\src\options.c(4072) : error C2065: 'numeric' : undeclared identifier
..\src\options.c(4077) : error C2065: 'found' : undeclared identifier
..\src\options.c(4088) : error C2065: 'numeric' : undeclared identifier
..\src\options.c(4090) : error C2065: 'found' : undeclared identifier
..\src\options.c(4090) : error C2065: 'numeric' : undeclared identifier

fix #1727 - offering Rider corpses (trunk only)

     The report that killing a Rider on an altar allowed you to sacrifice
its corpse was a wizard mode-only phenomenon in 3.4.3 (because you needed
to use an altar at some location other than the Astral Plane, hence also
needed to use ^G to get the Rider there), so not really a bug.  But a
post-3.4.3 change has made it possible to offer corpses from the floor on
the astral level, unintentionally making it possible to sacrifice Rider
corpses.  This makdes #offer check specifically for them and trigger their
revival if the attempt is made, same as done by pickup.

loose objects at game end

     Some post-3.4.3 code to clean up thrown or kicked objects which were
in transit at the end of a game didn't work correctly for kicked objects,
leading to an "obj not free" panic if you kicked an object at some point
and didn't kick anything else before the game was over.  Unlike thrownobj,
kickobj wasn't being cleared after use.

monsters putting on shirts

     From the newsgroup:  code intended to prevent a monster who's wearing
a suit from putting on a shirt didn't work due to faulty logic.

Dr.Who graphiti (trunk only)

     Add an entry to the set of randomly placed engravings.  The revival
of Doctor Who, which seems to be referred to as Series 1 through Series 4
ignoring umpteen years of earlier versions, showed graphiti of "BAD WOLF"
intermittently throughout season two and brought it back for the finale
of season four.  As far as I noticed, it was always written in all caps.

makesingular vs compound phrases (trunk only)

     When testing singularizing of fruit names I noticed that "bunches of
grapes" became "bunche of grapes".  makesingular() had a comment about
not recognizing "es" and suggesting that recursion could solve it.  But
makeplural() already handled things like that without resorting to
recursion, and it also recognized more compounds than just "foo of bar"
and "*man-at-arms" (such as "pie a la mode" and "soup du jour").  This
moves the compound phrase recognition into a separate routine so that
both makesingular() and makeplural() will handle the same stuff, and it
modifies makesingular() to do as well as makeplural() when processing the
front half of compound phrases (the "foo" part in "foo of bar").

     Also, a minor plurization tweak:  algae was recognized as already
plural but larvae and several similar words weren't.

force fruit name to be singular (trunk only)

     Inventory formatting for a single slime mold object would be strange
if the user entered a plural word or phrase for fruit name.  Forcing the
user-specified value to be singular as it's being set up as current fruit
avoids that.  [Something like <Someone>'s "bunch of grapes" is unaffected;
it's already singular and correctly handled as such by makesingular().]
This may have a side-effect of limiting the creativity of some players
who try to trick others via bones files gimickery, but I think the extra
consistency in object naming during ordinary play is worth it.

     According to the cvs log info, this issue was actually mentioned in
a patch I made ("fix M203...") in October, 2005.  I have no recollection
of that at all....

more fruitadd() (trunk only)

     Each time save and restore is performed, the ffruit list gets
reversed.  Since additions can be made when it is in backwards order or
in original order depending upon whether an odd or even number of save/
restore cycles have taken place, the numeric sequence of its entries is
ultimately arbitrary.  So there's no point using extra code to force new
ones to be added at the end of the list; just put them at the beginning.

current_fruit (trunk only)

     I almost abandoned this when Michael beat me to it, but besides
handling the fruit rename bug it also moves `current_fruit' into the
context structure to eliminate separate save/restore for that.

change of fruit name

From a bug report:
The following steps do not yield the expected fruit:
  1) start nethack in explore mode (with a wand of wishing)
  2) change fruit name to "tomato"
  3) save/restore
  4) change fruit name back to "slime mold"
  5) save/restore
  6) wish for a fruit; you get a tomato
  7) check options; fruit name is set to "slime mold"

If you specified a fruit name that already existed in the list,
fruitadd() always set current_fruit to the fruit with
the highest fid encountered in the list to that point, instead
of the fid of the matching entry.

some updates to make nethack.6 less dated.

first divine gift artifact (trunk only)

     From the newsgroup:  if no co-aligned artifacts are available when
attempting to give the first divine gift for an offered corpse, nothing
would be given.  Since the gift counter stayed at 0, subsequent attempts
to select one would still treat it as first gift and always fail again.

     The first divine gift from offering corpses must match the hero's
alignment; after that, nonaligned artifacts (Frost Brand, Giant Slayer, &c)
are added to the pool of choices for further divine gifts.  It's pretty
easy for a chaotic character to use up the co-aligned artifacts before
getting any divine gift.  There aren't many chaotic ones and some are
inelgible due to being race-specific items.  Wishing for Stormbringer--or
loading a bones file which contains it--and creating Sting and Orcrist
via naming will do the trick for an elven hero.

     This patch expands the pool of candidates to include nonaligned
artifacts during first gift selection if no co-aligned ones are available.

first conditionalized docs (TRUNK ONLY)
plus various related missing bits and tids

regenerate mdgrep.h (TRUNK ONLY)
now that this should have the right version numbers in it, save the new file

mdgrep.pl tids (TRUNK ONLY)
aka "try again before the wireless drains my laptop battery"

makedefs --grep prep, misc cleanup (TRUNK ONLY)
use makedefs --grep in Makefile.doc
call make clean in doc from make clean in top
add commented out rule to produce mdgrep.h from mdgrep.pl
macosx1.5: don't chown/chgrp for single-user install
unixmain.c: work around C90 warning for Mac-specific code, fix last fix
makedefs.c: temporarily disallow blank after control introducer until docs
 catch up
mdgrep.pl: add ALLDOCS, clean up generated file's header

followup (trunk only)
Finally found a flag combination that will complain about declarations mixed in
with other code: -ansi -pedantic.
Clean up the violations of that I just introduced and add that flag to the
Mac 10.5 hints file.  (Note that there is one warning left in unixmain.c -
it's in Mac-specific code.)

SHELLERS for SYSCF, MacOS 10.5 hints file (trunk only)
Add SHELLERS - people allowed to use ! command with same syntax as WIZARDS.
Add new hints file for 10.5, since the rules and commands for groups changed
(new commands introduced in 10.4, old ones removed in 10.5; creating a new
user under 10.4 gave you a matching group, in 10.5 it doesn't).  Also move
shared build into roughly right place in file system when being installed
for root - don't use ~root.
Makefile.top - don't remove ./-p unless it exists (that's always annoyed me).
fix error invoking macosx.sh

restful sleep bit (trunk only)

     A change yesterday made putting on an amulet of restful sleep avoid
clobbering the timeout from having already eaten one, only replace it if
the new timeout is shorter.  This does the inverse; when eating one, if
you're already sleepy from also wearing that type of amulet, only replace
the timeout if new one is shorter.  And don't clobber the other intrinsic
bits with FROMOUTSIDE, just add it to whatever ones might already be set.
Neither should have any observable effect on game play, so no fixes entry.

fix #H1662 - temporary vs permanent sleepiness (trunk only)

     From a bug report, wearing
(or removing) an amulet of restful sleep was overriding permanent
sleepiness which had been obtained previously via eating another amulet.
The setting of timeout clobbered the non-timeout bits for that intrinsic.

     This also adds the timeout counter for sleepiness to enlightenment
feedback in wizard mode.  Unrelated:  rephrase enlightenment feedback for
adornment to more accurately describe what that does.

makedefs build on non-C99 compilers follow up

Pat Rankin wrote:
>      That patch looks incorrect.  `CONSUME' increments argv,
> so now a different value is being passed to the function when
> initializing that variable than was passed before.

makedefs build on non-C99 compilers

..\util\makedefs.c(426) : error C2143: syntax error : missing ';' before 'type'
..\util\makedefs.c(427) : error C2065: 'p' : undeclared identifier
..\util\makedefs.c(428) : error C2065: 'p' : undeclared identifier

initial sling skill

     From a bug report, archeologists were
inadvertently starting out at basic skill level in sling because of their
carried touchstone, which is flagged as being sling ammo.

lex sync (trunk only)

     Propagate recent util/*_comp.l changes to sys/share/*_lex.c.

mdgrep.pl tid
Use the right name for the output file in all places.
Thanks Pat.

more warning cleanup, makedefs grep bits (trunk only)
drop -Wcast-qual
warning cleanup (lev_comp)
comment bits
makedefs grep cleanup: drop magic constant, add --grep-define, --grep-undef,
 #ifdef out code not needed yet, update mdgrep.h, mdgrep.pl

more warning cleanup (trunk only)
More warning bits that never got committed.
More appropriate compiler flags for warning checks (macosx only for the moment).
The changes in dgn*[lc] just rename line_number to nh_line_number to avoid a
clash, so no need to regenerate the lex output.

macosx hints file consolidation (trunk only)
get macosx down to one hints file (default tty, single user) for
 tty, x11, qt and single or multiple users
preliminary bits that might allow a macosx qt build

add MAXPLAYERS to SYSCF (trunk only)
Add MAXPLAYERS to SYSCF config file; deprecate (but continue to support)
 MAX_NR_OF_PLAYERS in nethack.sh since it is trivially overridden in many
 (all?) cases and isn't useful for ports that don't use nethack.sh.

makefile bit for makedefs grep (trunk only)
add dependency for mdgrep.h

makedefs conditional grep (trunk only)
This code (except for some of the argument parsing changes) is not used yet.
mdgrep.pl generates mdgrep.h; like the lex and yacc files we ship mdgrep.h
 pre-generated; there is no need for perl on end-user/end-compiler systems.
 (In fact mdgrep.h is so simple mdgrep.pl is probably overkill.)
mdgrep.h creates an array reflecting the compiler options in effect
The changes to makedefs break the Mac OS9 compile; if necessary the fix is
 simple and documented (but I think that port is permanently dead).
With that port out of the way, makedefs can be allowed to take real options;
 none of the current options have been changed.  Instead, a second sub-main
 routine has been added to handle options starting with two hyphens and all
 the new options start with two hyphens:
--input specifies the input file (- is stdin)
--output specifies the output file (- is stdout)
--grep causes the input file to be filtered into the output file
--grep-showvars dumps the info from the array in mdgrep.h
--grep-trace turns on tracing of the grep filtering
Docs for the filtering language are in the source.

tweak probing while swallowed (trunk only)

     Follow up to the patch that adds a fake inventory entry for the
swallowed hero when probing an engulfer.  Make the header for the hero
be plural to match those of object classes, and prefix the hero entry
itself with a/an to reflect its count of 1.
| Swallowed Creature              ->  Swallowed Creatures
| > - elven ranger called wizard  ->  > - an elven ranger called wizard

probing while swallowed (trunk only)

     Reported recently by <Someone>:  probing feedback while engulfed
shouldn't claim that the monster is not carrying anything when the hero
is inside of it.  The simple case where it's not carrying anything else
was a trivial one line change; handling inventory plus hero was trickier
and I wouldn't have bothered if I'd realized what it was going to take.
But it's done now; trivial case
        The purple worm is not carrying anything besides you.
and harder case
        The purple worm's possessions:
        Weapons
        a - an uncursed dagger
        Swallowed Creature
        > - human archeologist called wizard

post-3.4.3 obj not free panic

     Throwing an object while engulfed and then quitting triggers a panic
when the end-of-game code tries to clean up the thrown object.  Throwing
code wasn't reflecting the fact that adding the missile to the engulfer's
inventory already handles the thrown object.  3.4.3 wasn't affected; it
didn't bother trying to clean up `thrownobj' in done().

build error message tid
Don't call impossible() if there are no window types  - we just core after
being told to #quit when it's too early to do so.

aborting key/pick usage (trunk only)

     From the newsgroup:  applying a key and then using ESC at direction
choosing prompt was using up a move even though hero didn't do anything.

wand engraving bit (trunk only)

     Readability tweak; use `WAND_BACKFIRE_CHANCE'.  This code for giving
cursed wand a chance to explode when engraving is in the branch too, but
the macro wasn't added there.

display/map glitch in C quest temple

     From a bug report:  in the irregularly
shaped temple on the C quest home level (the room where the leader is
located), the lit south wall contained a dark spot where a secret door
is located.  It stayed blank until you got right next to it rather than
just until you got to a good angle facing it.  (Magic mapping hides the
problem by showing that spot as a wall instead of leaving it as unseen;
you have to walk or teleport to that room in order to see the problem.)
The code that lights walls and doors which border lit rooms neglected
temporary walls produced by secret doors.

vitamin deficiency (trunk only)

     Implement something <Someone> suggested a long time ago:  eating a
disenchanter corpse has a chance to remove an intrinsic.  Uses the same
routine as nighttime gremlin attacks, which chooses an intrinsic randomly
and attempts to remove it, so has no effect if it chooses one the hero
lacks.  This can be used to remove "aggravate monster" but is much more
likely to target something the player wants to keep.  [By the way, a lot
of potential candidates are missing:  sleep, shock, and disintegration
resistance and teleport control come immediately to mind.]

     Also, it has been bugging me that you can get both strength and
fire/cold/shock resistance from the same fire/frost/storm giant corpse.
The code prevents mind flayer corpses from conferring both intelligence
and telepathy, so strength handling was inconsistent (even though it
predated mind flayers...).  This causes strength boosting to be treated
as an extra candidate when selecting an intrinsic to confer, so you'll
either get strength or resistance (which might be a no-op) but not both
from those giants.  And it special cases the other giants to have the
same 50% chance for boosting strength, even though the alternative in
their case is to do nothing instead of trying to confer something else.
Lastly, it now gives a message when you succeed in gaining strength.

fix #M57 - alchemical potion explosion fails to wake monsters

     From a bug report,
the message when dipping one stack of potions into another triggers an
explosion says "BOOM" yet nearby sleeping monsters remained undisturbed.

eel hiding behavior (trunk only)

     From a bug report:  an exposed eel in an isolated
pool--swamp rooms sometimes produce those--would never re-hide no matter
how long you left its vicinity.  Re-hiding is part of post-move handling
and an eel with no adjacent water to move into would never reach that bit
of code since it didn't move anywhere.  The code used to re-hide monsters
when you return to a previous level was ignoring eels altogether.  Give
unhidden eels a chance to hide earlier during monster movement and also
when the hero returns to their level.

     Also a really minor bit to slow down hit point loss of eels out of
water.  I don't think anybody reverse genocides krakens to get experience
any more since they don't provide a big bonus when they're out of water,
so this change won't have much of an affect.

show source of bits of makefiles (trunk only)
Mark the generated makefiles as generated and mark the source of each section
to aid debugging.

more lint (trunk only)

     The one `anything any' that was triggering a warning was shadowing
another `anything any' in the same function; no need to rename it, just
remove the unnecessary declaration.  Also, mark the couple of arrays with
initializers that I'd noticed as static instead of letting them default
to auto.  The abil_to_spfx()::abil2spfx[] one might need to be redone in
code as a switch if some compilers/linkers have trouble initializing it.

Window type not recognized tid (trunk only)
Fix the grammar error that results when a binary with one window system
compiled in is explicitly told to use another.

warnings cleanup (trunk only)
This covers the warning cleanup bits no one objected to.

Placeholder for Amiga large disks (untested)
placeholder so we don't lose large disk fix, but I can't test it

identify_pack (trunk only)

     Three years ago <email deleted> reported that
stepping off the end of inventory via typing space to go to the next menu
page wasted his identify scroll.  He suggested that some people might do
that because they don't know how to back up in a multi-page menu.  I
pointed out the Guidebook section that describes < and ^ to go back one
page or back to start and left things at that.  However, traditional mode
reprompts if you step through all of inventory without choosing something,
so this changes identify-via-menu to do likewise.  You can dismiss the
menu with ESC to really avoid choosing anything.

     This also makes identification of N items when you're carrying N or
fewer unID'd things behave the same as identify all:  identify everything
without any prompting.

more ^X (trunk only)

     The characteristics display checked for cursed rings of sustain
ability but neglected to check for uncursed ones locked in place by
cursed gloves or weapon.  And the half-hearted attempt to check for
future items conferring Fixed_abil couldn't handle an uncursed thing
covered by something cursed either, so just get rid of it.

^X refinement (trunk only)

     Use sentences for the characteristics (instead of "Strength = 15") to
match the rest of the enlightenment display.  When showing ATTRMAX, phrase
as "limit" rather than "maximum" since magical ajdustments can exceed max.
And be more selective about which alternate attribute numbers to show:
 Your strength is 14 (current; base:13).  => +1 ring of gain strength
 Your strength is 13 (current; peak:14).  => lost a point to poison or abuse
 Your strength is 14 (current; base:13, peak:14).  => combo of both of those
 Your strength is 14 (current; limit=18/50).  => you're a gnome
instead of always showing all of base & peak & limit when any of the three
are interesting.  During play, a limit which is different from normal human
(18 or 18/100) is considered to be interesting; for end of game disclosure,
it's interesting iff the final value hasn't reached maximum, regardless of
what that max is.

imitation spelling (trunk only)

     I'm not a contender to win any spelling bees.  (Mimicker does't
seem to even be a real word; I'm not sure if it ought to end in "or"
instead of "er".  But changing it to "mime" would be too weird.)

done_in_by shapechanger (trunk only)

     Augment killer reason when slain by a shapechanged creature:
"killed by a foo" becomes "killed by a chameleon immitating a foo" or
"killed by a vampire in foo form" or "killed by the Wizard of Yendor
disguised as a foo" (after double-trouble, when the clone starts out
mimicking something).

     I put the fixes entry in the new features section.

#monpolycontrol of unseen monsters and of vampires (trunk only)

     I was testing something with #monpolycontrol enabled and got a
series of "Change it into what kind of monster? [type the name]" prompts
when I went to a new level.  It was asking about monsters that were being
created (in this case, multiple vampires for top level of Vlad's Tower)
and naturally I couldn't see them since the level wasn't finished yet.
This switches to noit_mon_nam() to at least be informed about the type
of creature you're being asked to specify a shape for, and adds the map
coordinates so that it doesn't appear to be reprompting for the same
monster over and over when multiple similar ones are being created.

     In the process I discovered that #monpolycontrol would let you give
any type of monster for the shape of vampires.  Unlike chameleons, they
don't change into arbitrary shapes so that was inappropriate.  [And
trying to test the fix for this is what led to the previous ^G patch.]

wizard mode ^G of shapechangers (trunk only)

     A while back there was a change in how the initial shape for a
shapechanging monster gets chosen during monster creation, and a side-
effect of that lets/makes you choose the shape when #monpolycontrol is
enabled.  But ^G was overriding your choice by forcing the shapechanger
to start out looking like the type of monster that you specified (to ^G,
not to subsequent #monpolycontrol prompting), hence always in its natural
shape.  The intent for ^G was that if asked for a unique monster but got
a doppelganger instead, it would initially look like the requested unique
monster.  Post-3.4.3 code, so no fixes entry needed.

exercise/abuse while polyd (trunk only)

     Three years ago <Someone> reported that even though exercise of
attributes other than wisdom is suppressed while the hero is polymorphed,
attribute gains or losses due to pre-existing exercise can still take
place in that situation.  Since it's an entirely different set of attrs
which will be replaced upon rehumanizing, there's not much point.  (The
same is actually true for wisdom, but I didn't change how exercise works
for it.)  Adopt his one-liner fix:  old exercise won't cause attribute
changes while polymorphed; it will silently fade as it does when its
magnitude is insufficient to trigger a change.

     While checking that out, I noticed that exerchk() was using `/= 2'
to fade out old exercise/abuse.  That will produce platform-dependent
results for negative values (ie, for the abuse case) since C's integer
division doesn't specify whether to truncate towards zero or towards
negative infinity.  In particular, -1 / 2 could yield -1 rather than 0
as the code expected.  (Its impact on play was negligible though.)

     This reduces the code for displaying the messages which accompany
attribute gain/loss.  A few were repharsed in order to simplify that.

build fix (trunk only)

     The recent SYSCF patch introduced a build problem even though I
haven't attempt to use that new stuff yet.  My compiler complained that
`out' in build_english_list() was used without being initialized, which
in turn caused make to quit.  The compiler was right; only the words==1
case actually set up the output buffer.  Once that buffer was fixed, the
routine to copy a single word was overwriting it on each call instead of
building up via appending as intended.

     I changed the 3 or more case to yield "A, B, or C" like Keni wrote
in his description rather than the "A, B or C" which was being produced.
I'm pretty sure that both forms are considered acceptible; I've always
used the first one with an extra comma in front of and/or.

more SYSCF and related bits - cleanup and features
infrastructure for "system options" - things currently specified at build
 time that should be changeable at install time or run time but not really
 under user control
generalize contact info so it can be localized and it doesn't have to be
 an email address
move recently introduced WIZARDS into sysopt
drop bogus OPTIONS=wizards possibility
new function build_english_list() to comma-ize and add 'or' from a whitespace separated list: A.  A or B.  A, B, or C.
syscf file now handles: WIZARDS SUPPORT RECOVER
 SUPPORT specifies local support information
 RECOVER will eventually supply port-specific and/or localized info on how
  to run recover (or get it run for you).
Note: in sys/msdos I changed sys.o (generated from pcsys.c) to pcsys.o
Note: sys/msdos/Makefile.GCC has 2 rules for sys.o (now pcsys.o)

ring discovery (trunk only)

     Picking up and putting on a +1 ring of protection while blind
resulted in having a "+1 ring (on {left|right} hand)" in inventory and
having ring of protection show up in the discoveries list.  The problem
is the same as the one for wands which has been previously addressed
(but not 100% fixed...):  when using an item whose effect is observable,
the item's type became discovered based upon that observation even if the
item itself had never been seen.

     The code for removing ring of protection lacked its break statement
and fell into the case for removing ring of protection from shapechangers,
but didn't cause any noticeable problem.

blindfolds and more (trunk only)

1) the change yesterday to mark inventory as seen when recovering from
   blindness neglected to handle blindfold removal;
2) fix grammar when using 'R' or 'a' to try to remove cursed lenses
   (now "they are cursed" instead of "it is cursed");
3) attempting to put on a wielded or quivered blindfold, amulet, or ring
   and failing because of already wearing one (or two in the case of
   rings, where cursed gloves and ESC at "which ring-finger?" prompt got
   similar result) unwielded/unquivered item rather than leave it as is.

inventory after regaining sight typo (trunk only)

     Out of date diff last time.

inventory display after regaining sight (trunk only)

     I suspect--but have no way to test--that there is a subtle difference
in game play between perm_invent and !perm_invent involving object merging
or other activity that depends on whether or not object->dknown is set.
For objects pickup up while blind, where object->dknown is left as is,
the perm_invent config would have such items marked as seen sooner (since
there are umpteen places that call update_inventory() which will end up
setting the seen bit while formatting objects).  Non-perm_invent wouldn't
have that done until the user examines invent (or asks to see a list of
objects at the "which object?" prompt for various commands).  This patch
effectively examines inventory whenever blindness ends, so both modes get
dknown set as soon as possible.  And if we ever add an "effect known" flag
for unseen objects which are used while blind, this would be a suitable
place to perform deferred object discovery.

initoptions warning following its split (trunk only)

..\src\options.c(565) : warning C4101: 'opts' : unreferenced local variable
The code in initoptions_init() that uses opts seems to now be isolated to
UNIX and VMS.

H1406: jellyfish have no head
I did some research, and technically, a jellyfish does indeed have no head
(and, technically, no brain, just a "nerve net").  The part on top is a
"bell" used for buoyancy, not a head.

linux warning bits (trunk only)
a few syntactical tweaks to silence warnings from gcc on linux
for code that was only updated in the trunk

'T' failure feedback; suit_simple_name() (trunk only)

     The post-3.4.3 ring removal bug also applied to suit when wearing a
cloak and shirt when wearing a suit or cloak or both, although it would
never give "you have nothing else to take off" because the covering item
was always present as a likely candidate.  The ring fix also fixed armor.
When testing that fix, I saw "you can't take that off" for trying to take
off a suit while wearing a cloak.  That isn't new or a bug, but it seemed
awfully terse so I've changed it to give "you can't take that off without
taking off your cloak first".  (Likewise, "cloak", "suit", or "cloak and
suit" as appropriate when trying to take off a shirt.)

     This adds new routine `suit_simple_name()', comparable to 3.4.3's
cloak_simple_name() and post-3.4.3 helm_simple_name().  No doubt there
are other places besides "without taking off your X first" that could
make use of it but I haven't attempted to track them down.  The "you are
already wearing _some armor_" one doesn't quite fit.  It would need to
adjust "some" to "a"/"an" at times ("some mail" or "some dragon scales"
vs "a suit" or "a jacket").

'R' behavior for rings (trunk only)

     A bug in some post-3.4.3 code made attempting to remove a worn ring
when wearing two skip inventory the selection and give "you don't have
anything else to remove" if you were wearing gloves and weren't wearing
an amulet or blindfold.  The intent was that rings wouldn't be included
as likely candidates in the list of inventory letters to choose from if
you were wearing cursed gloves, but had a copy+paste mistake in the
argument controlling whether to consider the gloves curse state and was
in the wrong section of getobj()'s "ugly hacks".  Also, it makes more
sense to require that the player know that those gloves are cursed, so
inaccessibe_equipment() got changed too.  [Not knowing that the gloves
are cursed leaves rings listed as candidates; picking a ring will get
removal failure feedback later and mark the gloves as known cursed then.]

buried ball enhancement (trunk only)

     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.

moving while trapped (trunk only)

     Pull the u.trap portion of domove() into a separate routine.  The
only significant change is to the wording of a couple of TT_BURIEDBALL
messages.  Like with enlightenment, say "you are <steed> are chained to
a buried ball" instead of "<steed> is chained to a buried ball" if you
try to move while mounted and punished and attached ball has been buried.
Unlike floor trap activation, punishment doesn't directly affect steed.

enlightenment tweak (trunk only)

     Yesterday's changes made it possible to use ^X to recognize an
unknown ring as one of sustain ability by checking whether wearing the
ring blocks display of base/peak/maximum characteristics when those are
considered to be interesting.  This limits that to cases where the ring
is cursed, so using ^X to figure out the type will leave an undesireable
ring stuck on your finger.  (Both before and after are unnoticeable in
wizard mode, where items which block access to base strength, dex, &c
are overridden by magical disclosure.)

fix #1586 - stale alignment record after changing alignment type (trunk only)

     From a bug report, putting on a helm of opposite
alignment wipes out divine protection (regardless of which god originally
bestored it) but leaves piety level towards the old god in place for the
new one.  Reset alignment record to 0 when changing alignment type.  Yes,
that means that the helm can now be used to clear a negative alignment,
which I think is in keeping with having subtle positive uses for bad items.

     Permanent alignment change did try to tweak alignment record, but
I'm not sure that it worked as intended.  Lawfuls changing away from law
got a bonus for their new alignment, neutrals retained their old record,
and chaotics changing away from chaos took a penalty to their record, all
without regard to what the new alignment became.  The magnitude of the
bonus or penalty was half the record limit (which gradually increases with
turn count) so could be very big, but I don't think it made much sense.
Reset alignment record to 0 for permanent conversion same as for temporary
conversion.  It's simpler and reflects the fact that you haven't yet done
anything to bolster or weaken your new alignment.