Place libnh targets in $(TARGETPFX)

Fix build failing for libnh when using TARGETPFX

Compiling with WANT_LIBNH=1 and TARGETPFX=(...) failed because ioctl.o
could not be found.

This is because the targets are specified with the $(TARGETPFX) but the
libnh targets consumed these targets without the $(TARGETPFX).

remove duplicate novel titles

For novel title lookups, have the variant spelling substitutions use
the entries from array of titles instead of explicit strings which
duplicate those.

some reformatting

Replace some
  (foo &&
   bar)
that had crept back into the code with
  (foo
   && bar)
to match the reformatting which took place before 3.6.0.  There are a
couple of lines ending in '||' still present but they look intentional.
isaac64.c has some trailing '|' bit operators that could/should be
moved to the start of the next line but I didn't touch that file.

While in the affected files, I tried to shorten most overly wide lines
(the right margin is supposed to at column 78 and there are quite a
few lines which are 79 characters long, but I left most of those
rather than introduce new line splits).  Also replace a handful of
tabs with spaces.  I was a little surprised not find any trailing
spaces (in the dozen or so files being updated).  I didn't look for
trailing arithmetic or '?'/':' operators which aught to be moved to
the start of the next line.

document obj->owornmask

ship_object() and obj_delivery() use obj->owornmask for something
other than tracking what slot(s) an object is worn in.

insufficient spell power feedback

If attempting to cast a spell without having enough power, you get
 |You don't have enough energy to cast that spell.
Recently that was augmented to
 |You don't have enough energy to cast that spell yet.
if your current power is at maximum and not enough.  Augment again to
 |You don't have enough energy to cast that spell anymore.
if current power is at maximum and that maximum is less than the peak
value it once had and that peak value would have been enough.

glob update

Initialize glob weight sooner in mksobj() and have weight() skip the
fix up it had been doing when it was passed a glob with weight 0.
This allows shrink_glob() to be simplified slightly in the situation
where a glob inside a container shrinks away to nothing.

weight(glob) with glob->owt==0 now yields 0 instead of 20.  That was
only needed for 'obj->owt=weight(obj)' during object creation and
the new earlier weight init makes the 0 to 20 fixup obsolete.  In
turn, that allows a glob which has shrunk to 0 while in a container
to not have to be removed before updating the container's weight.

pickup.c bits

This started out as just some minor reformatting but ended up including
a couple of new comments and a revision in how the use_container()
decides whether it is feasible to put something into the container.
Behavior isn't changing.

attrcurse() on 'see invisible'

If hero has intrinsic see-invisible and a gremlin steals that, the
map wasn't being updated to hide invisible monsters (until the next
iteration of moveloop() after other monsters finished current turn).

Accessibility: give a message when teleporting a monster

Teleporting a monster only updated the map. Give a message
so blind players can get the same information.
Making a monster invisible gives the same message, if you
cannot detect invisible.
Several other places where monsters teleported themselves
now also give the same message.

endless shrink_glob...

A shrink_glob timer keeps running for a glob on the migrating objects
list so shink_glob() needs to be aware of that.

shrink_glob bug when when glob is totally gone

When a wielded glob shrank away to nothing, an impossible warning:
"obfree: deleting worn obj" would be issued.

If a glob is quivered or wielded or set up as swap weapon when it
shrinks away to nothing, clear the relevant weapon slot before
destroying the glob.

Won't happen for monsters since they never wield globs.  Also won't
happen for migrating objects (which overload obj->owornmask) because
they have to have arrived somewhere in order to have their shrink
timer execute.

formatting bit

wizard mode polyself to "priest"

When polymorphing while already polymorphed, picking your own role
will rehumanize (wizard mode only; restores old characteristics and
experience level, unlike becoming a new man which can change those
and even be fatal if level drops below 1).  But it didn't work if
you were a priest or priestess because name_to_mon() yields aligned
cleric monster rather than cleric role.

shape change while strangling

Polymorphing into a vulnerable form while wearing an amulet of
strangulation says "your amulet still constricts your neck" if your
previous form was also vulnerable or "your amulet beings constricting
your neck" if previous form wasn't vulnerable.  But a change nearly
6 years ago to have the status line be updated to say "Strangling"
during the message--instead of next status update after it--caused
the "still constricts" variation to always be given even when the
"begins constricting" was appropriate.

long worm growth again

The previous change could have resulted in a long worm losing HP when
gaining a segment (if it had gained levels while at the peak amount
for the previous number of segments).  I think this is finally right.

long worm growth

I think this is what was originally intended.

misuse of hero_glyph

It isn't just the hero's normal glyph, it gets adjusted when poly'd.
So the way I tried to use it didn't work as intended.  Explicitly
check Upolyd separately so that hero_glyph won't be affected by tat
and only returns the player monster or race monster value.

showrace again...

I'm fairly sure that the 'showrace' and PC rogue cases are covered
correctly now despite the approximation in deciding whether the
specified glyph represents the hero.  However, I'm not sure how the
accessibility handling ought to work when the hero is not in normal
form.  Right now it kicks in if the glyph is any monster, so the
hero is visible as a monster (whether normal or poly'd or on steed).
It does not kick it when mimicking an object (after eating a mimic
corpse or being poly'd into a mimic and then hiding) or furniture
(only if poly'd into mimic) because execution won't make it into the
is_you block in that situation.  Same situation applies to setting
the MG_HERO flag bit, but that doesn't seem to be used anywhere.

remove a couple of tabs

rogue symset issues following expanded glyphs

Contributed by entrez

Also, remove the iflags.use_color test from the many if-statements
in reset_glyphmap(), and test and/or override it once before
the assignment to gmap->color.

tracking peak maximum HP and energy

Keep track of the highest value that u.uhpmax and u.uenmax have
attained, in new u.uhppeak and u.uenpeak.  They aren't used for
anything yet.  u.mhmax (max HP while polymorphed) isn't interesting
enough to track.

Not save and bones compatible so increments EDITLEVEL.

showrace followup

Previous patch made sure that the color tweaks were really at the
hero's location, but not whether it was actually drawing the hero
there.

I'm taking the suggestion about fixing pet_override on faith....

commit ccb10489aee5f2af752177b0f8451790140292e2
Author: PatR <rankin@nethack.org>
Date:   Fri Dec 3 18:35:12 2021 -0800

    showrace when hero can't see self

    This supersedes pull request #644 by entrez, "Fix: expanded-glyphs
    hero color regression".  The code to change color for the hero in
    special circumstances (for 'showrace' and for some PC rogue stuff)
    was relying on the hero's map coordinates rather than verifying
    that the hero was shown at that spot.  When the hero is invisible
    and lacks see invisible, he isn't shown.  But the color of whatever
    could be seen beneath him was incorrectly having its color changed
    (to HI_DOMESTIC for showrace or to YELLOW for PC rogue).

    Closes #644

get Xcode build working

tested with visual studio 17.0.2

bullwhip inconsistencies

Reported by entrez:  applying a bullwhip towards a medium or small
peaceful monster used to be an attack but that stopped working when
'safepet' was extended to peacefuls in order for the hero to be able
to swap places which those.  Also, side-effects were different when
hero applied the whip from within a pit compared to when not in one.

This allows the hero trapped in a pit to try to snag furniture or a
boulder even when a small or medium is present, and escaping that
pit if successful.  (It still snags big monsters in preference to
furniture/boulder at their location.)  When no such non-monster
target is available, it attacks the monster if hostile or peaceful
but not when tame.  When revealing a previously unseen monster it
prevents snagging that monster's wielded weapon because hero couldn't
possibly target the weapon in that situation.

This makes other changes, mostly dealing with finding and exposing
concealed monsters, which may introduce some new bugs.

Since I was already in the right place, implement snagging an item
off the floor while flying.  It isn't necessary since a flyer can
pick things up off the floor directly, but there isn't any pressing
reason to disallow it.  Supersedes the commit in pull request #632
by RojjaCebolla.

Closes #632

feedback for spell cast failure due to energy

If the hero is at full energy but still lacks enough to cast a chosen
spell, say "you don't have enough energy yet" instead of just "you
don't have enough energy."

fixes entry for pull request #642 - shk name vs it

3.6.1 changed a bunch of messages in shk.c to give the actual shk
name even when a the shopkeeper couldn't be seen, to avoid things
like "You owe It <N zorkmids> for <item>."  But there are various
messages issued outside of shk.c which were overlooked.  Fix those.

Closes #642

Fix: 'you owe It for goods lost'

Some messages about owing a shopkeeper money would use 'it' when blind,
with weird results such as "You owe It 267 zorkmids for goods lost."  It
seems maybe like these were missed in 6591f8b since they were outside of
shk.c/shknam.c.  Bring those messages into alignment with most other
shopkeeper-related messages, which use the shopkeeper's name even if the
hero is blind or can't see them at the moment.

Some of the 'it gets angry' ones don't seem so bad, but similar 'gets
angry' messages in shk.c use Shknam so I changed those as well for
consistency's sake.

yet another shrink_glob fix...

When catching up for lost time spent on another level, globs inside
containers that shrank away to nothing didn't need to have those
containers' weight explicitly adjusted because obj_extract_self()
does that, so yesterday I removed the unneeded container_weight()
call.  However, ones that shrank only partially did need to have
their containers' weights adjusted and that wasn't being done.
The weight would be brought up to date within 25 or so turns when
the contained glob's next shrink_glob event took place.  Until then
attempting to pick up the container by hero or monster, or to pick
up something else by a monster already carrying it, could have been
impacted by the weight discrepancy.

miscellaneous tweaks

Simplify a glob handling bit in a recent shrink_glob change used when
catching for lost time upon returning to a level.

Revise a clumsily worded fixes entry.

Fix a comment typo in makedefs that's been there for a bunch of years
now.  It's been within the diff context for several recent patches
and I still hadn't noticed it until just now.

fixes entry for pull request #640 - zoo monsters

Populating some of the types of special rooms can pick monsters that
sometimes come in groups, and getting a group could have some members
spill out of the room (or inhibit other random choices by filling some
spots that haven't been populated yet, preventing subsequent monster
creation there).

The misbehavior isn't new so it seems surprising that no one has ever
previously reported this.

Closes #640

Fix: zoo monsters spawning in hallways

If a random G_[SL]GROUP monster was generated in a zoo, the resulting
group of monsters could spill out into nearby hallways and other
surrounding areas.  Disregard G_GROUP flags when filling a zoo with
monsters to avoid this problem.

CapMons[] entries for hallucinatory monster names

Simplify the handling of capitalized hallucinatory monster names
which should be described as "the Bogon" rather than just "Bogon".
Instead of inserting an ESC character to indicate "this entry
should be freed when done", keep track of how many of the entries
come from mons[] (which always come first and shouldn't be freed)
and just free the rest.  So one instance of inserting an ESC and a
couple of skipping it when present and one of testing for it when
freeing are removed.

Also, the check for bogusmons classification code was testing
whether the name started with a letter (or with '@', an obscure
special case for letter()) rather than for the actual type codes
used in dat/bogusmons.txt.  If '@' becomes used as a classification
code (so far it isn't one) any entries using it could have been
misclassified and would be misspelled because it would stay as the
first character.  And existing entry "/r/tard" was also subject to
misclassification, but since it doesn't start with a capital letter
either with or without leading '/' that had no noticeable effect.
If the leading slash was followed by a capital letter there would
have been a different sort of misspelling with that slash missing
in the copy kept in CapMons[].  I knew all that when I first used
letter() but have decided that it is better to extract 'bogon_types'
from bogusmon() in order for the handling to be more consistent.

rumors again...

The code to provide even distribution for rumors was being successfully
used for engravings, epitaphs, and hallucinatory monster names but not
actually for rumors themselves.  Move it into its own routine and have
both the three miscellaneous things and rumors use that.

My testing has verified that asking for a true rumor can produce the
first and last true rumors and not either of the first or last false
rumors, and vice versa when asking for a false rumor.  Asking for
unspecified true/false can produce all four of those.  Aside from that
verification of correctness (I hope...), I haven't checked that the
distribution when selecting is actually even.

tribute update: Monstrous Regiment and A Hat Full

of Sky

Add a page citation for Monstrous Regiment passage 1 and add four new
passages, bringing its total to 12.

Add two new passages to A Hat Full of Sky, bringing its total to 13.

get_rnd_text() for rumors and other stuff

Solve the uneven distribution situation that has been present for
picking random rumors for a long time and for random engravings,
epitaphs, and hallucinatory monster names since 3.6.0.  This relies
on the previous partial solution where short lines have been padded
to a longer length.  When that length is N and random seek lands in
a long line of length L, retry if the position is in the first L-N
characters.  Put differently, it if takes more than N characters to
reach the next newline, reject that random seek and try again.  This
effectively makes long lines behave as if they had the same length
of N as the short lines have been padded to and when all lines are
the same length, all entries have the same chance to be chosen.

SOUND=foo vs !defined(USER_SOUNDS)

Give a better message than "Unknown config statement" if SOUNDDIR or
SOUND directives are found in the configuration file being loaded by
an executable built without support for USER_SOUNDS.  And just give
it for the first occurrence since when present there will likely be
multiple SOUND instances.

It doesn't attempt to deal with the case where the current interface
does not support sound but USER_SOUNDS is enabled because another
interface in the same executable does.

format issues

Fix a couple of things that prototyping pline() with FORMAT_F(1,2)
pointed out.  The mkobj.c one looks familiar; I thought it had
already been fixed.  Maybe it matches a pull request that hasn't
been incorporated yet.

compile-time format checking

We've had a few pull requests fixing format/argument mismatches
lately.  I did't notice when PRINTF_F(format_index,first_arg_index)
attribute use and the checking gcc and clang do with it got removed,
but that was very useful.  Putting it back triggers a whole bunch
of "format string is not literal" warnings, but that's because
'-Wformat-nonliteral' was explicitly added to the *.2020 hints.
Checking pline/You/&c arguments in the cases where the format is a
literal is more valuable than the complaints for sprintf being fed
a generated format, so reinstate PRINTF_F usage and turn off the
check for non-literal format strings.

nhassert() for vms

Update nhassrt_failure() to handle VMS file names.  Still builds on
OSX but not actually tested for VMS>

unpadding capitalized hallucinatory monster names

Two semi-related patches within the span of less than three days and
I overlooked the overlap.  When the() deals with a capitalized string,
it calls CapitalMon() to check whether the string matches a monster
and if so whether usage should be "the Monster" (Oracle or Olog-hai
for example) or just "Monster" (Medusa).  The first time that gets
called, it collects all capitalized non-the Monsters from both mons[]
and the bogusmon file.  The latter just got changed to pad short
lines, and that works fine for selecting hallucinatory monsters at
random via get_rnd_text(), but non-the Monster collection processes
the bogusmon file directly and wasn't updated to strip the padding.

get_rnd_text() selection distribution

While testing 'the("Capitalized Hallucinatory Monster")' I noticed that
some hallucinatory monsters showed up more often than others.  When
the random engravings, epitaphs, and bogus monsters were converted from
hard-coded arrays to data files accessed by random seek (3.6.0), they
became subject to the same distribution irregularites that rumors suffer
from.  The chance that an entry will be chosen depends upon the chance
that a random seek will hit somewhere in the line which precedes it, so
entries that follow long lines are more likely to be chosen and entries
that follow short lines are less likely.  We improved that for rumors
by having makedefs pad the shortest lines.  Distribution still isn't
uniform but is much better than it was (and could be further improved
with a longer padding length at the cost of making data files bigger so
possibly slower to access; both overall size and access speed mattered
back when floppy discs were supported but are probably irrelevant now).

Start doing the same thing for the newer files:  pad the shortest lines
to increase the chance that seek will find them.  The tradeoff is that
the data files become bigger.  Rumors, engravings, and epitaphs lines
are all at least 60 characters now; bogus monsters are at least 20.
These are the data file sizes I see (in bytes:  old, new; padding for
rumors was already in use so its size hasn't changed):
  bogusmon    4449    7211
  engrave     1326    2894
  epitaph    14159   24075
  rumors     49173   49173

The only place that padding is noticeable in-game is #wizrumorcheck.

suppress warning

The compiler which suggested that 'aname' might be used without
being initialized is wrong, but this should pacify it.

shrinking globs vs shop bill

A shop-owned glob picked up by the hero was added to shop's bill
and if that shrank to nothing it moved from the unpaid portion to
used-up portion as intended.  But once there it retained obj->owt
of 0 and if 'sanity_check' was enabled, that triggered a warning
every move until finally paid for.  Both the 'Ix' list of used-up
items and itemized shop billing revealed a weight of 0 aum if
'wizweight' was enabled.

Keep track of the weight a glob had when it becomes unpaid, then
reset from 0 to that amount if it becomes used-up.  This overloads
the obj->oextra->omid field which is an unsigned int previously
only used for corpses.  Now for globs it is pre-bill obj->owt which
is also unsigned int.  I didn't add new oextra access functions for
it; it is only used in two places and existing omid ones suffice.

artifact fruit

Reported by entrez:  when fruit name is given the name of an artifact
that doesn't use "the" at the start of its name, messages about the
artifact could be altered.  Example was fruit=Excalibur causing usual
 |You are blased by Excalibur's power!
to unintentionally change to
 |You are blased by the Excalibur's power!
because of a false match during special handling for named fruit in
function the().

This fixes that, and also changes basic inventory formatting.  Former
 |f - an Excalibur
will now be
 |f - Excalibur
for a fruit that has been assigned that name.  When sort pack in On,
as it is by default, that will be listed under Comestibles rather than
under Weapons so really shouldn't fool anyone.  And
 |f - 2 Excaliburs
also breaks the illusion.

This formatting change only affects named fruits.  User assigned names
for object types or for individual objects behave the same as before.

add a Harry Potter reference

Add three new hallucinatory monsters:  dementor, flying monkey, and
plaid unicorn.

attempting to polymorph into a unique monster

Noticed while testing revised "the" handling and trying to trigger
"you can't polymorph into [the] Oracle", if the character was human
it would turn into a new man or woman instead of having the unique
form be rejected.

fix pull request #636 - the("Capitalized Monster")

Function the() wasn't supposed to be used for monsters because many
of the ones with capitalized names confuse it, but over time multiple
instances of the(mon_nam()) have crept into the code.  Instead of
ripping those out, modify the() to handle that situation better.

Pull request #636 by entrez dealt with this with one extra line of
code, but could end up scanning all the names in mons[] repeatedly
if the("Capitalized string") gets called a lot.  This uses a similar
one line fix but calls a whole new routine that scans through mons[]
once collecting all the relevant special case names.  As a bonus,
it does the same for hallucinatory monster names which name_to_mon()
couldn't handle.

Fixes #626

more windows keyhandling follow-up

Merge branch 'pr637' into NetHack-3.7

Merge branch 'fix-format-char' of https://github.com/argrath/NetHack into pr637

avoid zero for the windows key handling values

use %d for short

obj->otyp is short, so corresponding format string is %d.

(from Coverity Scan)

fixes entry for #635 - magical breathing w/ gills

Fixes entry for pull request by entrez.  If poly'd hero is wearing
an amulet of magical breathing, avoid gradually losing hit points
while out of water when in aquatic form.  You won't be able to put
on an amulet of magical breathing if already in aquatic form, but
you could have one carry over from being worn in some other form.

Implemented for monsters too but won't have any effect during play
for them because they never use that particular type of amulet.

Closes #635

Magical breathing helps fish survive out of water

The hero in an aquatic polyform loses HP for time spent out of the
water; allow magical breathing to prevent this, just as it allows the
hero in her non-aquatic natural form to breathe underwater.

Also add a similar rule for monster fish-out-of-water HP loss, even
though currently monsters can't use amulets of magical breathing and
there's no non-breathing fish/eel -- just in case this changes at some
point.

fix github issue #608 - #untrap vs web

Reported by Vivit-R, the chance of freeing a monster from being
trapped in a web was very small and failure resulted in creation of
a new web at the hero's spot, eventually making it impossible to
attempt to #untrap the monster (if hero escaped the new web and moved
to another spot adjacent to trapped monster, eventually surrounding
it with webs).  [That's actually misleading.  Escaping the new web
but staying at the same spot lets the player try again; repeat as
needed....  But chance of failure still seemed way too high.]

This reduces the chance of failure from 29/30 to 6/7 and makes the
chance of spreading the web after failure be 1/3 instead of 100%.  It
also supplies missing feedback about the monster still being trapped
if the attempt to make a new web fails.

Closes #608

This is cron-daily v1-Jan-20-2020.  guidebook updated: doc/Guidebook.txt

This is cron-daily v1-Jan-20-2020.  files updated: Files

windows console changes - eliminate *key.dll

Incorporate the functionality of the loadable DLL's (nhraykey.dll,
nhdefkey.dll, and nh340key.dll) into the consoletty.c code and
remove the dll building

Merge branch 'pr633' into NetHack-3.7

Merge branch 'patch-1' of https://github.com/melkersona/NetHack into pr633

shrink_glob nitpicking

For a glob in a container carried by the hero, shrinking away to
nothing would have indirectly updated the container's weight when
obj_extract_self() was called, then the 'old_top_owt' value would
never be different from current topcontnr->owt.  That only matters
for the shrink-but-not-gone case and could only happen for the gone
case so didn't result in anything noticeably wrong.  But fix it to
match the comment about weight not being adjusted yet.

ignore visual studio files in util

cut and paste error

update Install.windows for vs 2022 compiler

Include visual studio 2022 in the list of compilers tested for build
- nmake Makefile.msc tested

vs 2022 is current version as of November 8, 2021

shrink_glob while away from level

If the hero left a level that had globs on the floor or in floor
containers or being carried by monsters and stayed away for a
while, returning to the level only shrunk them by one unit of
weight.  Account for all the time away.  The complexity of this
has steadily grown; I hope its peak has been reached.

shrink_glob feedback

When carrying a glob, possibly inside a container, give shrink
feedback more often (twice in the ~500 turn cycle to shrink from
20aum to 0aum rather than just once).

Update NetHackW.c

Updated some comments that referred to an old file name

weight of gold

I had wizweight On when testing glob changes and noticed
|Slasher drops a gold piece (0 aum).

Coins are supposed to weigh 1/100 of a unit, and the calculation
rounds rather than simply truncates any fraction, but that still
yielded 0 for quantities of 1..49.  Force any non-zero stack of
gold to weigh at least 1 unit.

Also, add a check for attempting to weigh a quantity 0 or less
(of anything, not only for gold) just in case.

proceed further into dochat() when deaf

decaying glob tweaks

Don't hardcode the weight (20) of an unaugmented glob, use
objects[].oc_weight (also 20) instead.

When a glob inside a container has decayed all the way to nothing
(weight 0), take it out before updating the container's weight.
Otherwise weight() would use objects[].oc_weight instead of 0 for
that glob.

decaying globs of {ooze,pudding,slime}

Globs never rotted away but did become tainted after a relatively
short while, which seemed like a contradiction.  Change them to never
be tainted but shrink by 1 unit of weight approximately every 25
turns.  An ordinary glob (one that hasn't combined with any others)
starts out weighing 20 units, so it takes about 500 turns to vanish.
That's roughly twice as long as a corpse takes to rot away.

Shrinking globs give feedback when in hero's invent or in a container
in hero's inventory, but rarely (when going from an exact multiple
of 20 weight units; that is, from integral number of N globs to
N-1 + 19/20, or if weight reduction triggers an encumbrance change).
When a glob goes away completely, there is feedback for those two
circumstances and also for seeing the glob vanish from the floor.

I haven't touched how much nutrition eating a glob confers.  I have
changed formatting of glob names to use "small", "medium", "large",
"very large" instead of "small", [no adjective], "large", &c.  You
still need to have at least five globs coalesced together for the
adjective to become "medium", same amount as before.

I don't think EDITLEVEL needs to be modified but have incremented it
anyway to play things safe.

detect visual studio 2019 16.11.5 after build test

tribute update: Night Watch and The Wee Free Men

Add a page citation to passage #1 of Night Watch, and add five new
passages, briging the total to 12.

Add four new passages to The Wee Free Men, bringing the total to 13.

more imp

visual studio 2022 preview 7

bad cast making sp_lev chameleon light source

Closes #625

Merge branch 'lightsource-mon-ptr' of https://github.com/entrez/NetHack into pr625

Fix: bad cast making sp_lev chameleon light source

Giving new_light_source '(genericptr_t) mtmp' leads to the light
source's id.a_monst being set to 'mtmp->nmon' rather than 'mtmp',
since that's what is stored in the initial byte of the monst struct.
When mtmp->nmon == 0x0 this can cause a segfault in do_light_sources.

tile fix

commit b88e17d04ec2bb37e2c12842e9f4c4a9 changed the order of some
objects but neglected to update the win/share/objects.txt tiles
to match.

In fairness, the error-alerting was broken at the time but has
since been resolved.

warning: for tile 46 (numbered 46) of objects.txt,
found 'lance' while expecting 'angled poleaxe / halberd'
warning: for tile 47 (numbered 47) of objects.txt,
found 'angled poleaxe / halberd' while expecting 'long poleaxe /
bardiche'
warning: for tile 48 (numbered 48) of objects.txt,
found 'long poleaxe / bardiche' while expecting 'pole cleaver / voulge'
warning: for tile 49 (numbered 49) of objects.txt,
found 'pole cleaver / voulge' while expecting 'pole sickle / fauchard'
warning: for tile 50 (numbered 50) of objects.txt,
found 'broad pick / dwarvish mattock' while expecting 'pruning hook /
guisarme'
warning: for tile 51 (numbered 51) of objects.txt,
found 'pole sickle / fauchard' while expecting 'hooked polearm /
bill-guisarme'
warning: for tile 52 (numbered 52) of objects.txt,
found 'pruning hook / guisarme' while expecting 'pronged polearm /
lucern hammer'
warning: for tile 53 (numbered 53) of objects.txt,
found 'hooked polearm / bill-guisarme' while expecting 'beaked polearm /
bec de corbin'
warning: for tile 54 (numbered 54) of objects.txt,
found 'pronged polearm / lucern hammer' while expecting 'broad pick /
dwarvish mattock
warning: for tile 55 (numbered 55) of objects.txt,
found 'beaked polearm / bec de corbin' while expecting 'lance'

fix error checking during tile processing

noticed following a patch last night

"someone"/"something" instead of "it"

I thought there were more places that checked for "it" and substituted
"someone" or "something".  Perhaps there are and I'm just not finding
them now.  Anyway, this extends x_monnam() and adds some_mon_nam() and
Some_Monnam() to do that during monster name formatting instead of
having various bits of code try fix it up after the fact.  The fixups
could be fooled by monsters given the name "it" or "It"; x_monnam()
won't be.

refine "next boulder"

Guard against any other places besides minimal_xname() that set up a
fake object without being aware that for boulders the corpsenm field
should be 0 rather than NON_PM.  If that field is unexpectedly -1,
xname() will format it as ordinary "boulder" rather than producing
special "next boulder".  An explict value of 1 is now required for
the latter.

fix github issue #603 - guarding prize items

Reported by Vivit-R with comments by several others.  The prize item
in one of the closets off the Sokoban treasure zoo is sometimes
missing, most likely picked up by an elf who won't be dissuaded by
the presence of engraved Elbereth or a scroll of scare monster.

This fix prevents monsters from targetting the mines' and sokoban's
prizes for pickup (or for eating).  Once the hero picks either of the
prizes up, they stop being prizes and will be ordinary monster fodder
if dropped/stolen/stashed.

One of the comments by copperwater suggested this approach as a
possible way to fix things.  I had already implemented it from scratch
before noticing that.  It handles the usual monster behavior toward
items, but there could easily be some unusual cases still susceptible
to taking the prize before the hero gets to it.  Those are the breaks.

Fixes #603

more baalz - digging in front of the "eyes"

like the leg hackery, if the baalz level gets flipped during creation
the fixup that modifies the locations in front of the eyes to allow
digging needs to deal with that too.

fixes entry for pull request #598 - baalz level

If the baalz level got transposed during creation, the fixup for
a decorative portion of the map didn't work properly.  Monsters
eligible to be created at pool locations could end up trapped in
a couple of inaccessible locations.

[To be fair, the baalz hackery predates level flipping....]

Closes #598

Fix: baalz_fixup didn't account for level rotation

Because some spots in the fly's 'legs' on the Baalzebub lair level are
specified as pools in the level file, then later converted to walls in a
post-generation fixup routine, monsters can be generated on those spots
and then left walled up and inaccessible, Cask of Amontillado style.
For the love of God, makemon-tresor!

Some code already existed to relocate these monsters after generating
the level, but it depends on misorientated 'leg segments' being fixed up
in a particular way.  That wasn't being triggered because it didn't
account for the possible rotation of the level; as a result, the
monsters in the leg segments wouldn't be relocated, and the leg segments
themselves would continue to have the wrong orientation.

Account for possible level rotation so that the monsters are relocated
properly (and the leg segments are 'fixed').

fix github issue #623 - soldiers and mattocks

Reported by eakaye.  Selection of equipment when creating a soldier
or watchperson can pick a polearm, but random selection among those
had a chance to choose dwarvish mattock which doesn't use polearms
skill and isn't appropriate for a human soldier or watchperson.
Not mentioned, but lance was in the same boat.

Change the selection to only pick something which uses polearms
skill, then make that moot by moving lance and dwarvish mattock out
of the midst of the polearms so that they're no longer candidates
for special case rejection.

A couple of other things which might have had a similar issue were
already ok.  Giving a polearm when creating a troll selects between
a few choices rather than among all the polearms.  And wishing for
"polearm" only considers items which use polearms skill.

While changing objects.h to reorder the two non-polearms, I removed
a bunch of tabs that were present in the scroll definitions.

EDITLEVEL is incremented due to objects[] reordering, so existing
save and bones files will be invalidated.

Fixes #623

commit message for pull request #599 - artifacts

Explicitly un-create a randomly generated artifact if it gets
rejected (too big to include as a treasure drop with a small corpse)
so that it remains eligible for creation later.  And when generating
random contents for a new container, explicitly avoid artifacts
(which were already implicitly avoided).

Closes #599

Formally block artifacts as random box contents

Another (latent) case of an artifact possibly being generated and
immediately deleted: part of the process of a mimic disguising itself as
an item involves generating a random object, then deleting it.  If this
item is a box or sack, it will generate with random contents, which will
be deleted along with the container. If artifacts are allowed as random
box contents, this can silently remove an artifact from being available
in the game.

This is effectively blocked already, since none of the artifacts
eligible for random generation are items from classes marked as valid
box contents (see boxiprobs[] in mkobj.c).  Nonetheless, formally
preventing artifacts from generating as box contents will guarantee this
issue won't crop up if a randomly generated artifact tool, ring, etc, is
added in the future.

Fix: artifacts silently removed from the game

Death drops will generate a random item, which may be an artifact.
After the object is created, some rules are applied to check whether its
size matches the monster that dropped it; if it fails these checks,
the item is deleted.  aosdict recently pointed out that if the death
drop was an artifact, this would permanently remove it from the game.

Use artifact_exist(..., FALSE) in various cases where potential
artifact objects are created, then immediately removed.  This will
prevent artifacts from being removed from play by marking the artifact
as available to create again.

fix #K3474 - "you detect it where <foo> was"

A vampire in bat form was seen via infravision or possibly telepathy,
then when it changed into fog cloud form the feedback was
|You now detect it where the vampire bat was.
The message substitutes "detect" for "see" when the new form can't
be seen and the monster name formatting yields "it" for that case.

Give a vanish message instead since that is effectively what happens.

fix pull request #621 - potential divide by 0

The pull request by argrath changes weight_cap() to never return a
value less than 1 because try_lift() divides by that return value
and a 0 would trigger a crash.  The code involved is used when
attempting to pull a monster out of a pit via #untrap.

I'm fairly sure that weight_cap() can never produce a value that's
less than 1 already, but have put in a variation of the PR's fix.
I've also implemented a different fix that removes the division
from try_lift().  The original code seems to have gone out of its
way to avoid calculating inv_weight() twice, but doing the latter
(for the once in a hundred games where it might happen) greatly
simplifies things by removing details of carrying capacity.

Fixes #621

re-do the wounded legs fix

wounded legs check in insight.c

close #620

more comment accuracy

fix github issue #614 - applying polearm at doors

Reported by G7Nation; attacking walls and such with a polearm just
gave lackluster "you miss; nobody's there" feedback.

Make applying a polearm at some non-monster locations give feedback
similar to using 'F'orcefight with melee weapons.  Was
|You miss; there is no one there to hit.
now
|You uselessly attack the closed door.

Also, extend the supported locations to include dungeon furniture.
Was
|You attack thin air. ('F')
now
|You harmlessly attack the throne. ('F')
|You uselessly attack the throne. ('a')

This doesn't address #613:  attempting to hit non-visible locations
with an applied polearm.

Closes #614