This is a really weird inconsistency. Player orcs are poison resistant,
and certain orcs use poisoned ammunition with abandon, yet none of them
actually resist poison, as can easily be seen by flinging poison darts
or arrows at a horde of hill orcs until one of them is instakilled. Fix
this by making all types of orcish monsters poison resistant.

Bugbears in xNetHack, being a sort of orc, are moved into the o class,
and thus also became poison resistant. I considered them sufficiently
orcish to also make them poison resistant in this commit, though they
remain in the h class for now.

These seem like they would be bulky sorts of shields, so set the bit to
true on them. This doesn't affect any game mechanics.

Feature ported from dNetHack, with slight changes (it wakes monsters,
produces different messages, and doesn't let this particular ray travel
any farther).

The main gameplay implications are probably that it's easier to get into
Orcish Town now (an orc from inside might even blast them out for you)
and that iron-barred closets with prizes inside will be a little more
accessible. Currently iron bars don't play a critical player-containment
role on any other special levels.

If the iron bars are marked nondiggable, they won't be blown up, just
like they can't be dissolved with acid.

For some reason, I thought I remembered implementing a message like "The
iron bars vibrate violently but remain intact" if hit by a force bolt
and the bars are nondiggable, but apparently not, as the code isn't in
xNetHack.

Like in UnNetHack, blessed wands wrest 1/7 of the time, and uncursed
wrest 1/23 of the time. Cursed wands still wrest 1/121 of the time. This
is intended as a minor buff to having a blessed wand, and making it
feasible to wrest uncursed wands without spending fifty or more turns
zapping it to no effect.

Ideally, I would have blessed wands identify that they have 0 charges
when you zap them and nothing happens (and never wrest if you didn't
know it had 0 charges), to prevent an accidental 1/7-probability wrest.
However, there's no way to have the charges be known without also having
the recharge count be known, which doesn't make any sense for the hero
to know. And it's certainly not worth putting in another known flag just
for this.

The only place where I can see this biting someone is that if you zap a
wand of wishing until you get "Nothing happens" without formally
identifying it, there's now a 1/23 chance that you wrest and lose it
instead of a 1/121 chance. However, doing that under the old behavior
could still randomly wrest it, and most spoiled players already know to
formally identify a wand of wishing as soon as they learn what it is.

If the player is trying to kick a sink to get some effect, there's no
real advantage in making them try it 20 times before something happens
if 10 will do. This makes it much more likely for something to happen
when a sink is kicked.

This is another SliceHack feature, but again heavily modified. This gets
rid of the current pointless confused effect of dropping rocks instead
of boulders; earth elementals and dust vortices get created instead.

Unlike SliceHack, there is no possibility of causing an earthquake;
instead, varying the beatitude varies the number of monsters created
instead. Also unlike SliceHack, this doesn't really care about
difficulty and won't go out of its way to guarantee certain numbers of
vortices or elementals; the magic of the scroll is what it is.
Furthermore, the generated monsters aren't forced to be hostile.
(Vortices are always hostile anyway; earth elementals might be peaceful
for neutrals, and if so, good for them.)

This is a widely popular and freqently requested feature. I consider it
to be acceptable since the player is, in the best case, forfeiting a
100% chance of a wish right now for an 80% chance of a wish later.
There's no way for it to be turned into multiple wishes. It can
theoretically be reused to generate multiple oil lamps, but this will
eventually end when a djinni does something other than give a wish, and
the light from a magic lamp is infinite anyway.

This also allows players to spend a wish from something that isn't a
magic lamp on a magic lamp so that they have an infinite light source.

This is a fairly popular suggestion. It does the same thing as other
items identifying themselves when they are used and something
unambiguous happens, and it saves the player having to manually
type-name the wand.

The wand does not get named if there is any ambiguity. Some variants
have done clever things with things in this vein (e.g. if the bugs on
the floor stop moving and you have already identified sleep, they will
auto-identify it as a wand of death for you) but that is not the case
here.

This is needed for the next commit, which needs a way of getting the
string representation of a place on the map. back_to_glyph already did
all the necessary work to get a defsym, but it immediately converted
that into a glyph. So, extract this out into its own function.

Headstones, altars, sinks, ladders, and thrones all provide enough cover
for a monster that can hide under objects, even if there are no objects
there. They behave exactly the same; for instance, a concealable monster
that steps onto a sink will vanish under it and become undetected.

The AI for concealable monsters is tweaked so that in adjacent areas of
concealing terrain such as a large area of scattered objects (a treasure
zoo's gold piles, perhaps), they will pick their spot to move and *then*
decide with their 90% chance not to move, *if* the spot would be moving
out of concealment. Previously this was tested before they actually
looked for new places to move, meaning that a monster able to move from
one concealed spot to another would be pointlessly sluggish.

Minor change to remove the conflict between Mercury and Hermes, who
already exists in the Healer pantheon. Plus, neither Mercury nor Venus
are actually gods of archery (Mars isn't either but being a war god he's
acceptably close), so Apollo and Diana make much more sense.

Spellcasting monsters are highly magical and so it seems reasonable that
you can tap into some of that magic when you eat them. Newts still grant
d3 energy, whereas casters give d(baselevel). The odds of gaining a
point of maximum energy are not changed - still 1/3 of the time and only
when you would have gone over maximum. Also, change the message to a
"moderate" buzz instead of mild when you do gain maximum energy by this
mechanism.

Green slimes possess a unique way to threaten the player, but by the
time they appear, the player is likely to shrug off most of their
sliming attacks due to high magic cancellation from their armor, making
it easy to fix the occasional one that gets through. Giving them an
engulfing attack which always starts the sliming process makes them more
of a threat.

Some edge cases:
- If you are fiery, you will burn through and instakill the slime.
- If you have unchanging, are noncorporeal, are a green slime, or the
  slime engulfing you is cancelled, you still get engulfed, but are
  unaffected.

Small patch that creates a free fortune cookie upon eating a szechuan
tin of something, half of the time.

You don't get a cookie if you choose not to eat it and discard the open
tin (I considered moving the cookie generation to before you smell the
contents, but that would give away that it is szechuan). I did move it
after the cprefx/cpostfx and greasy-finger calls, because when testing
the original code I got "You consume szechuan newt. There is a free
fortune cookie inside! l - a fortune cookie. You feel a mild buzz."
which seems out of order.

If the tin is unpaid, the cookie does not add any extra cost; this is
because the tin containing the cookie was already being sold for its
usual cost. It's not really abusable either, since the cookie sells for
less than the tin does.

Minor fixes for them: their low speed doesn't make much sense
considering other orcs are already speed 9, and they now count as lords
to their kind (no other o monster is really a candidate for this).

* Rings dropped down a sink now have an 80% chance of becoming buried
  under the sink, rather than 20%. This is to make it more attractive to
  try and identify a ring with a sink before waiting to find a
  duplicate, which usually takes a long time.
* All sinks (except those in special levels, because the special level
  code is so weird I have no idea why I couldn't get it to work)
  generate with a ring pre-buried. The "ring looted from sink" flag is
  removed. The special level exception is not too important right now;
  the only sink currently on a special level is in Bazaar Town.
* Kicking a sink that has rings buried under it and getting the "Flupp!"
  effect, or drinking from a sink and getting the ring finding effect,
  will cause one of the buried rings to be spit out, providing a way to
  access them without destroying the sink.

Because this deletes S_LRING, it also deletes a line which handles that
in nhlua.c.

Uncursed light now gives radius 11 light (in line-of-sight, the same as
any other radius effect), and blessed light now illuminates the entire level.

The intention of this change is for the scroll of light not to be useless
like it currently is. With the current light rules, the scroll is
inferior to both the wand of light or the spell of light; hopefully
full-level, non-line-of-sight lighting will have good uses.

This also accounts for lighting up a gremlin's square from anywhere on
the level (suppressing its cry of pain if it's not in sight and angering
it if it was the player's turn).

It is an extremely common complaint that floating eyes' dark blue
coloration is so dark that players don't see them in time and bumble
into them. We can't make players reconfigure their color palettes, but
we can change the eye's color to something that is naturally more
visible.

This was inconsistent; the trap disappeared when the player set it off
but not when a monster did, which enabled players to pursue strategies
like repeatedly displacing a pet onto a polymorph trap while protected
themselves via magic resistance.

However, that's not the primary motivation for this change; the main
reason is so that a crowd of monsters can't all polymorph repeatedly
into too-strong forms. Also so that the player is in general less likely
to run into a polymorph trap in an area that monsters have obviously
passed through.

I don't think anyone actually uses the "feature" where specifying
nothing to wish for generates a random object. Also, it's terribly
unintuitive that hitting Escape (or any key, like the arrow keys, which
begins an escape sequence, or accidentally hitting Enter with the buffer
still empty) resolves the wish, breaks wishless conduct, and gives the
player an item they almost certainly don't want.

Instead, wishing for ESC or "" is interpreted as resolving to a wish for
"nothing", but the game will prompt the player to confirm that they
really meant that.

It's easy enough to test for anyway (by damaging yourself and seeing if
you regenerate a point of HP every turn), so avoid encouraging that
rather silly strategy and make it unambiguous.

Previously this happened half of the time and the other half the player
was moved instead. In the interest of being fair to players who
encounter e.g. a on-the-upstairs difficult bones file, or swarm of
soldier ants, this guarantees that they will be able to escape.

This will also make them hide under furniture, due to an earlier change
that allows that. Giant rats are of course too large to hide under
things.

This came from SliceHack, and it includes a refactor of one of the
leading contenders for "ugliest section of code in NetHack", the switch
statement determining spell hunger reduction. The refactor pulls the
hunger reduction logic into its own function, and provides a macro that
is used to check, essentially, whether you have hungerless casting.

This came about because I wanted to let likes_magic monsters pick up
*any* item with oc_magic, not just amulets, rings, scrolls, potions, and
spellbooks. But since e.g. TOOL_CLASS contains both magical and
nonmagical items, it wouldn't be correct to add that to the list.

This commit does away with the practice of passing a string of object
class characters to mpickstuff, replacing it with a callback that simply
takes an obj* and can do whatever it wants with that. All of the old
behavior is kept, except for the planned gameplay change that the
magical one now tests based off oc_magic rather than oclass.

Interestingly, this means that some magical items can be informally
identified by noticing a monster pick them up that wouldn't normally.
This is a good little detail in my opinion.

This was an annoying quirk of the wishing code. If it couldn't parse
your input 5 times, it would give you a random object you almost
certainly don't want. What exactly is the point of this?

Fix this by allowing the user to enter malformed or unrecognizable input
an indefinite amount of times. They'll get it right eventually, or at
least get prompted to enter "help" for assistance and see their option
of getting out by entering "nothing", if they don't want anything.

Previously this happened, but only 75% of the time. Make this a
certainty instead; this makes it a valid strategy to make yourself
hallucinate when fighting floating eyes.

Inspired by a YANI by Kahran042 for hallucinatory breath weapon names. I
started out just implementing that, but ended up expanding it (since it
doesn't look very good to have "The flesh golem breathes glitter! The
blast of fire misses you. The blast of fire bounces! The blast of fire
hits you! The blast of fire misses the tribble.")

So now, every ray - wands, spells, and breath weapons alike - will be
described as a blast of something ridiculous when you're hallucinating.
(This is suppressed for the occasions where it's writing a possible
death reason; the death will report the real type of ray that killed
you).

This removes most toying with a const char* variable fltxt, replacing it
with calls to a new function flash_str. I first tried just editing
fltxt, but then you get the same blast for every bounce, miss, and hit
of a given ray, and since the original breath uses a different codepath,
they wouldn't be the same. So this rerandomizes the blast for each
message that gets printed for the ray.

An attempt to smooth the rather jarring transition between messages like
"You float gently down to earth. Do you want your possessions
identified?"

The new message doesn't say why you can't reenter the Mazes, only that
you can't. It's probably classified Yendorian information.

There are an lot of things in NetHack that scale on the player's
experience level. This was one of them. But the group size should depend
on the local difficulty of the area, not the player - this makes flavor
sense (why would a level 1 pacifist on dungeon level 23 encounter
smaller hordes of orcs than an appropriately leveled player would?) and
also practical sense (reducing your own level shouldn't be rewarded with
an easier dungeon.)

This also removes a compiler bug hack in m_initgrp that was last
reported at least seventeen years and 6 major GCC versions ago. I doubt
it's causing problems any longer.

Why did the code go out of its way to make sure these maces had a 50%
chance to be cursed? They're priests. They should be able to deal with
curses on their own equipment.

Does not affect the special case of the mace being made +1, +2, or +3.

From UnNetHack. No modification is made to the prerequisites for the
portal - a vault in the main dungeon below level 10, not on a level
where another branch splits off - but it will now not randomly decide to
skip the vault when generating a level and maybe defer to some later
vault.

There are two reasons for this. First, to make Ludios accessible in
practically every game. It will only be inaccessible if no vault
generates on every single level between level 11 and the Castle, which is
a very small chance. Second, because this biases the portal to be placed
rather high up in the dungeon, often before the hero's really ready to
take on Ludios, and it's more interesting to have a branch that is
discovered then deferred and returned to later than a branch that is
discovered then immediately cleared without much effort.