The 'O' handling for bouldersym was updating the display value for
boulder even if the value had been rejected, and if it still had the
default of '\0', the map would end up with <NUL> characters. (When
examined via '//' or ';', those matched dummy monster class #0 and
led to the impossible "Alphabet soup: 'an("")'" that was suppressed
yesterday.)
Attempting to set bouldersym to ^@ or \0 would also be rejected as
duplicating a monster symbol. That is now accepted and used to reset
the boulder symbol to default. However, other control characters are
also accepted--not due to this patch, they already are, and from a
config file in addition to via 'O'--so bouldersym can still disrupt
the map. But that's no different from putting control characters
into a symbol set or setting them from config file via S_foo:^C.
Fixes#170
Monsters never throw athames or scalpels but some fake player monsters
on the Astral Plane are given those. Since they're stackable the
quantity usually gets boosted but there's no point in having more than
one if they won't be thrown.
This could have been fixed by letting monsters throw those two items,
but I prevented the quantity from being boosted instead.
Player came across a stack of 2 gray stones in a shop and kicked one.
That one ended up with a different (in his case, lower) price once it
was separate. This behavior only applies to non-glass gems which add
a price variation derived from internal ID (obj->o_id) number. Make
splitting stacks always yield the same price per item in the new stack
as was being charged in the old stack by choosing a similar o_id. Do
it for all splits (that can vary price by ID, so just non-glass gems),
not just ones performed inside shops.
He picked up the lower priced one and dropped it back on the original
higher priced one; the combined stack took on the lower price. That
will no longer happen if they come from splitting a stack, but this
fix doesn't address merging with different prices when they start out
as separate stacks. (Unpaid items won't merge in inventory if prices
are different, but shop-owned items will merge on floor.)
Dropping an existing fragile item while levitating will usually
break it. Getting a new wished-for fragile item and dropping it
because of fumbling or overfull inventory never would.
Some callers of hold_another_object() held on to its return value,
others discarded that. That return value was unsafe if the item
was dropped and fell down a hole (or broke [after this change]).
Return Null if we can't be sure of the value, and make sure all
callers are prepared to deal with Null.
Seven year old suggestion was to have a killer bee eat royal jelly if
there was no queen around, then after a short delay it would become a
queen. This does that, with "no queen around" being "no queen bee on
current dungeon level" and the transformation happening immediately
with the "short delay" taking place after.
Pet killer bees will target nearby royal jelly if there's no queen,
hostile killer bees will only eat it if they happen to walk on the
same spot as one. Both types accept either tame or hostile queen bee
as an existing queen.
Killer bees eating royal jelly will drop dead if queen bees have been
genocided, and aren't smart enough to avoid the instinct to eat such
if/when that happens to be the situation.
Another one from 6.5 years ago, identifying a type of gem should give
a new price for any unpaid gems of that type and adjust shopping bill
accordingly. Report was for rubbing with touchstone and learning
worthless glass with price not changing until the learned 'gem' was
dropped. Fix works for that and also other forms of identification
(and for amnesia, raising prices of forgotten gems); no dropping is
required for the price to change.
Theoretically could apply to any type of item, but prices of gems are
by far the most sensitive to whether or not they're identified.
The Unix Makefile.{src,utl} use the compiler name 'gcc' by default on
OSX, and that invokes clang which defines __GNUC__ to deal with gcc
extensions. But when invoked via the Xcode IDE, it evidently uses its
own name instead, and wasn't defining __GNUC__. tradstdc.h started
down the road of duplicating gcc features; switch to pretending to be
gcc instead.
Casting to (void) to discard a function return value doesn't satisfy
gcc's -Wunused-result (which we aren't enabling but is apparently
being activated for particular functions by glibc header files). Turn
it into a no-op to suppress three dozen warnings from Travis builds.
