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.
When merging one stack into another and they have different obj->o_id
price adjustments, keep the o_id of whichever one commands the higher
shop price.
I misread part of the original code and the revision introduced a bug
based on that. obj->o_id price variations are used for all types of
non-IDed items, not just non-glass gems.
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.)
It was possible to have the guaranteed luckstone at Mines' End become
merged with a random one and lose its specialness for achievement
tracking. Mark it 'nomerge' when created and clear that if/when the
achievement is recorded.
Fix another inconsistency with containers in shops: prices shown when
looking inside. Apply had them (because shop goods in containers are
flagged as 'unpaid' when hero carries the container), and loot did not
(because they aren't flagged that way).
stolen_value() treated hero-owned container holding shop-owned goods
as free for the taking.
The fix I'm working on which led to discovering this first added
stolen_value() then eventually stopped using it so I don't have an
example of where it is giving the wrong result.
get_cost_of_item() was giving different information from shop #chat
when dealing with containers owned by hero containing objects owned
by the shop. And when it was legitimately reporting a price of 0,
doname_with_price() wasn't reporting 'no charge' for items inside a
shop that were owned by hero or that shopkeeper didn't care about.
Extend the shop price reveal to far-look, but only when hero and item
being examined are inside the same shop.
Symset:Blank sets all the map symbols (except STRANGE_OBJECT) to
<space>. The status lines for !STATUS_HILITES force status to use '$'
instead of ' ' for the prefix before ":1234" for gold, but the status
lines for STATUS_HILITES did not. tty ended up with ":1234" for gold.
win32 and curses both ignore the prefix and construct their own, but
since win32 uses the map symbol for that it must also be ending up
with ":1234" (I assume; I haven't seen it). curses is forcing '$' for
the prefix, even on the rogue level.
This attempts to fix win32 without be able to test the result. I've
left curses alone.
Watching the fuzzer, I saw hero's strength plummet to 3 again and not
rise above 5 after that. It turns out to be due to life-saving, which
was fixing severe hunger but was not restoring the point of strength
that's lost when you go from hungry to weak.
I'm not sure whether this was caused by 3.6.1's commit
024e9e1225 or already behaved that way.
Another fuzzer bit: the monk I was watching was bitten by a wererat
early on and was still inflicted with lycanthropy when he reached
level 19. (I've no idea how his level got to be so high; it jumped
from 14 to 19 while I wasn't paying attention.) Extend the earlier
hack for drinking a blessed potion of restore ability to recover lost
characteristcs to sometimes drink a potion of holy water instead.
The rationale is that since the player character resists conflict,
fake players should too.
[I'm not sure that I buy that. Player character is always the one
*causing* conflict and it doesn't affect self. But this is simple
as long as no other resistance checks are against attack-by-ring.]
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.
Fixes#155
When drowning, you need to be unencumbered in order to crawl out of
water. When not drowing, you don't, but put a limit on how much can
be carried. If polymorphed into a swimming creature, allow stressed
or less; otherwise (magical breathing), burdened or less. (Doesn't
apply on the Plane of Water since there's no climb from water to land
involved.)
'Detect' is used for observing a vampire shape change without being
able to see the vampire. The problem here is that it changed from
bat form to fog cloud form in order to pass under a closed door,
and the message was being delivered when it was already at the door
location instead of before the move from a visible spot to that door.
I'm not happy with this fix, but any other alternative I considered
seemed to be worse. Having the shape change use up the monster's
move is probably a better way to go. Then on its next move it will
be in the right form to make a normal flow-under-door move.
Code appears to intend that riding for 100 turns be treated like a
successful weapon hit as far as skill training goes, but it was
actually requiring 101 turns each time. It's conceivable that that
was intentional, but unlikely.
Reported seven years ago, when ice melts underneath a monster, it
hovers there until its next move, then falls in and drowns. Dunk it
immediately, and give hero credit/blame if it happens during the
hero's turn (so presumably the melting was caused by the hero).
Also, let monster with teleport capability who gets dunked teleport
away from the water before getting wet, the way hero does.
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.
When testing the change to the Eyes of the Overworld wording and asking
for information about inventory item
k - a pair of lenses named The Eyes of the Overworld
I got "I don't have any information on those things". Not because that
item wasn't identified, but because the lookup was for "pair of lenses"
(finding nothing) and then for "The Eyes of the Overworld" (and not
finding it due to "The" which is stripped from the first attempt but
wasn't from the second nor present in the data.base key).
The phrasing of the data.base entry for the Eyes of the Overworld
reads as if it is continuing some passage in a reference book, but
that comes off strange when using '/' to see it. Rephrase it.
data.base could stand to have an entry for 'lenses'....
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.
Another one from nearly 7 years ago. Hero kicked embedded gold out
of a wall while following the guard away from the vault and got
"The guard calms down and picks up the gold."
and player thought it was odd because the guard was peaceful. It is
odd, but guards have an agitation state (0..7) when peaceful and it
is always non-zero when this event occurs. Suppress the "calms down"
part unless the agitation is close to making the guard turn hostile.
[Agitation is set to 5 after that event, so it isn't very calming.]
Also, the guard was picking up gold from underneath the hero while
two steps away. Move him adjacent (although it doesn't knock other
monsters out of the way if there's no room) prior to the message,
then back again after. That's how if works for gold that's not at
the guard's location and not at the hero's location, although that
case does knock another monster out of the way if one is on the gold.
Fixes#169
Monsters should not be afraid of stepping on the vibrating square
since it's only a trap for display purposes. [Perhaps they should
deliberately avoid it if the hero hasn't seen it yet, but I didn't
implement that.]
"You see a strange vibration beneath <mon's> <parts>." was strange
when <parts> was a wolf's "rear paws" or horse's "rear hooves"--was
the vibration magically skipping the front ones? And it sounded
naughty when it was a snake's "rear regions". If the creature has no
limbs or is floating or flying, just say "beneath <mon>"; otherwise,
if the part is "rear <something>", omit "rear ".
The message was weird in another way. Caller removes the monster
from it's old location and places it on the new one, calls newsym()
for the old location to show lack of monster, but then calls mintrap()
before newsym() for monster's new location (the trap's location). If
pline messages cause buffered map output to be flushed, the monster
will be missing during the time the messages are delivered. I fixed
that for vibrating square [seetrap()->newsym() before pline() rather
than after] but it should probably be fixed in the caller instead.
Windows build was actually only using a single function
in there, so just add a similar function to sys/winnt/winnt.c
and eliminate the need for including sys/share/pcsys.c in
the build.
Another 6.5 year old report. This one from Steven Melenchuk told
how to reproduce C343-23 which is still open on our 'known bugs'
page. (I've no idea whether the original bug report came through
the contact page, and if so, what its assigned number was.)
I didn't try to solve this one, I just confirmed that it could be
reproduced and took the fix from grunthack at github. He didn't
menion a fix at the time but implemented one before abandoing his
variant. (Others kept it going afterwards; fix was during his time.)
The overflow occurred when the guard couldn't figure out where to
move to next and just repeatedly 'moved' to his current location
until the maximum number of fake corridor spots was used up. The
fix detects not knowing where to go next and explicitly choosing a
new destination.
Original problem could be reproduced by teleporting into the vault,
digging out a wall and two spaces of stone in a straight line, then
going back into the vault to wait for a guard. When he shows up:
answer, drop gold, follow. If the guard's path walks through both
dug spaces, he will stop waiting for the hero. But hero is in
between the guard and the gap in the vault wall and can't advance;
guard has reached a persistent corridor so doesn't know where to go
next. Have hero wait for 125-ish more turns and then game panicks.
The code was 3.4.3 vintage so needed thorough reformatting, but not
any actual changes (unless I've overlooked something).
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.
Static analysis notices that
if (physical_damage)
tmp = Maybe_Half_Phys(tmp);
will never pass the test because all code paths leading to it set
'physical_damage' to False. Instead of getting rid of it, add a fake
case that leaves that True.
Another item from static analysis. If an internal error ever caused
the "bad do_look buffer" warning from checkfile(), open file 'data'
would not be closed. (The bug in checkfile()'s caller which prompted
that check was fixed long go.)
An alternate fix would be to move the input buffer check to before
the file is opened, but verifying the file first seems worthwhile.
From Jessie's old static analysis report. 'prezero' was used in 3.4.3
when processing a count for 'multi', but count handling is now done in
a separate routine and 'prezero' in parse() never changes value, so
get rid of it.
Fix a few typos, reword a couple of entries describing the bug rather
than its fix to use past tense, move a couple of entries to be adjacent
to closely related entries (there's a lot of scope for more of that...)
and remove a bunch of trailing spaces.
[fixes36.2 starts with a header line but the tags on it aren't being
substituted.]
Another bug from seven years ago, sent directly to devteam so no #H
number. Report stated that throwing recoil could move a levitating
hero diagonally through a shop's doorway to exit it. If the thrown
item was unpaid, it remained unpaid after landing on shop's floor
and was an unlisted item on shop's bill. Moving diagonally out the
door seems to have been fixed, but the same effect still occurred
if you were far enough from the door to have the shopkeeper vacate
his door-blocking spot and throwing recoil took hero to that spot.
The thrown unpaid item remained unpaid, and walking out the door was
treated as shop robbery.
I don't know why we have two different functions which do exactly
the same thing (checking whether an item is unpaid or is a container
that holds at least one unpaid item), but switch the #H2504 fix to
use 'the other one' and reverse one of the changes made when using
the inventory one.
I thought that the earlier fix for #H2504 was too easy for anything
shop related. It didn't deal sensibly with containers owned by hero
but holding unpaid shop goods.
