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.
This one is only seven years old. Dropping an unpaid item inside an
engulfer leaves it unpaid and still on bill. If engulfer is killed,
it ends up unpaid when back on the shop's floor.
Treat dropping an unpaid item into engulfer's inventory as stealing
that item. You have to pay for it to leave the shop, and like any
other dying monster's inventory, the shopkeeper will take ownership
if it lands on the shop floor when the engulfer is killed.
The 'theft' doesn't anger the shopkeeper and the cost shows up on 'Ix'
as part of "usage fees/other charges" rather than as an itemized used
up item.
That #H number isn't a typo. This finally fixes--at least improves--
something reported eight years ago. The monster types chosen by
mkclass() could be way off in some circumstances. Cited example was
repeated same-race sacrifice by chaotic hero on dungeon level 20; it
produced about twice as many incubi as succubi even though they're
the same as far as difficulty goes. (No changes in the intervening
years had any discernable effect; that was still reproducible.)
The report also mentioned that ndemon() threw away the result from
mkclass() and retried quite often and suggested that mkclass() be
taught to filter by alignment when caller cared about that.
This seems to even things out, although it also made harder monsters
chosen more often. A test program generated these numbers when
picking a chaotic demon 10000 times (level 1 hero on dungeon level 20,
so not realistic; actually probably level 0 hero since the program
didn't initialize struct u.) Third column is the number of times the
monster type was chosen with the old mkclass(), fourth is same for
the new one.
mkclass() calls 27315 10000
286 succubus 2800 3309
288 incubus 5552 3262
291 marilith 973 780
292 vrock 477 1617
293 hezrou 150 626
294 bone devil 46 247
295 ice devil 2 107
296 nalfeshnee 0 23
297 pit fiend 0 15
298 sandestin 0 4
299 balrog 0 10
Note that vrock has generation frequency 2 and marilith only 1, so
getting twice as many vrocks as mariliths should be expected.
I temporarily changed ndemon() to ask for lawful demons instead of
chaotic ones and got this.
mkclass() calls 15762 10000
287 horned devil 3197 3375
289 erinys 4991 3339
290 barbed devil 1812 3286
I also ran it for dragons with any alignment (so the outcome was
never thrown away; 10000 calls were needed for 10000 picks) instead
of demons of specific alignment and am suspicious of the outcome.
mkclass() calls 10000 10000
140 baby yellow dragon 1124 0
141 gray dragon 1096 1096
142 silver dragon 1073 1099
143 red dragon 1061 1126
144 white dragon 1077 1128
145 orange dragon 1141 1118
146 black dragon 1154 1049
147 blue dragon 1137 1123
148 green dragon 1137 1154
149 yellow dragon 0 1107
There may be a flaw in the test program. Or else old mkclass() was
not very good at picking dragons.
