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.
Stop pretending that long and int are the same size when picking status
highlight rule for gold or time or experience-points.
Also, K&R compilation might lack <limits.h>, so let XXXconf.h define the
necessary macro(s) (currently just LONG_MAX) so that it can be skipped.
I watched the fuzzer run for a bit and noticed that Str and most other
characteristics were steadily dropping until they hit 3 and not being
recovered, so I gave the defenseless hero a chance to benefit from
blessed restore ability occasionally. It hasn't helped much. Str and
Con both still drop to 3. [If I had to guess, I'd go with side-effect
of polymorphing, but not an intended one.]
Report suggested that if hero is turning into green slime, genociding
green slime should cure it. I went another direction: if life-saved
while dying due to turning into green slime, you survive polymorphed
into green slime form. If green slimes have been genocided (probably
after becoming infected with slime or hero wouldn't have faced any
slimes to cause infection, but that could be from eating a glob of
green slime created prior to genocide, or from #wizintrinsic), you'll
immediately die again, this time from genocide.
If hero was carrying Schroedinger's Box at end of game, disclosing
inventory converted it into an ordinary box. That interferred with
subsequent disclosure when writing DUMPLOG, which saw an empty box
if inventory had been shown or the special box with newly-determined
contents if not. I tried a couple of ways to fix it and decided
that redoing it was better in the long run.
Schroedinger's box is still flagged with box->spe = 1, but instead
of having that affect the box's weight, now there is always a cat
corpse in the box. When opened, that will already be in place for
a dead cat or be discarded for a live one, but the weight will be
standard for container+contents and when box->cknown is set it will
always be "containing 1 item" (which might turn out to be a monster).
Some temporary code fixes up old save/bones files to stay compatible.
TODO: food detection used to skip Schroedinger's Box; now it will
always find a corpse, so some fixup like the ridiculous probing code
is needed.
Replace an old instance of direct manipulation of an intrinsic.
If life-saving occurs 1 turn before sickness will kill the hero,
the sickness if cured. But it was leaving delated_killer for SICK
allocated. Harmless but a bug none the less.
When #wizinstrinsic was expanded to be able to set any timed attribute,
some that need more than just a timeout counter were left inconsistent.
1) Timed Flying wasn't blocked by levitation, and existing flight
wasn't becoming blocked by timed levitation. Also, eventual flight
timeout wasn't updating the status line, so false 'Fly' condition
remained shown until a status update happened for some other reason.
2) Setting timer for Warn_of_mon didn't set up any type of monster to
warn about so wouldn't do anything. This sets that to grid bug
unless already set due to polymorph form or artifact that warns.
The end.c portion is just a bit of formatting.
Add code to run a fuzz tester, simulating (more-or-less) random
keyboard mashing. There's no option to turn it on, you need to
set iflags.debug_fuzzer on via a debugger or something along
those lines.
Life-saving was setting u.uswldtim to 0, presumably intending that
to stop the hero from being digested, but it actually resulted in
being totally digested on the swallower's next turn if the death
being short-circuited wasn't digestion. Change life-saving to make
swallower or grabber release the hero instead of tinkering with
u.uswldtim. In addition to rescuing the hero from digestion, it
prevents an eel which has just drowned the hero (who has survived
drowning via life-saving) from pulling him/her back into the water
on its next turn. It will need to make another successful grab to
do that now.
While testing, I noticed that if I was polymorphed and wearing an
amulet of unchanging, life-saving didn't restore my HP-as-a-monster
and due to the recent change to force that to 0 when the hero dies,
I died again immediately after my life was saved. So this bug was
latent in the past and became noticeable in the last couple of days.
Report was for being fried by angry deity. There are lots of deaths
that don't involve subtracting HP until it hits 0 or less; I haven't
bothered tracking down which ones don't set u.uhp to 0 before they
call done().
No effect on life-saving or declining to die except for HP:0 being
visible on the status line during their messages.
mons[].difficulty takes over for monstr[]
Invoking "makedefs -m" gives a deprecation message; it is also included
in the (now mostly empty) monstr.c.
Ports should now remove "makedefs -m" from their build procedures but this
commit does not include that change.
Make being trapped in/on/over floor block Levitation and Flying, the
way that being inside solid rock already does, and the way levitating
blocks flight.
Blocked levitation still provides enhanced carrying capacity since
magic is attempting to make the hero's body be bouyant. I think that
that is appropriate but am not completely convinced.
One thing that almost certainly needs fixing is digging a hole when
trapped in the floor or tethered to a buried iron ball, where the
first part of digactualhole() releases the hero from being trapped.
If being released re-enables blocked levitation, the further stages
of digging might not make sense in some circumstances.
I recently realized that being held by a grabbing monster is similar
to being trapped so should also interfere with levitation and flying.
Nothing here attempts to address that.
Save files change, but in a compatible fashion unless trapped at the
time of saving. If someone saves while trapped prior to this patch,
then applies it and restores, the game will behave as if the patch
wasn't in place--until escape from trap is achieved. (Not verified.)
Bug report #H7156 listed three items, all relating to perm_invent:
1) it shouldn't persist across save/restore since restore might be
on a system which doesn't have enough room to display it (report
actually complained that config file setting was ignored when
restoring old games, which is an expected side-effect for options
that persist across save/restore);
2) permanent inventory wasn't updated when using scroll of charging;
3) attempts to update permanent inventory during restore could lead
to crash if it tries to access shop cost for unpaid items.
Items (2) and (3) have already been fixed. This fixes (1).
Replace 'flags.perm_invent' with a dummy flag, preserving save files
while removing it from flags. Add 'iflags.perm_invent' to hold the
value of the perm_invent option.
The win32 files that are updated here haven't been tested. Whichever
branch contains the curses interface needs to be updated; ditto for
any other pending/potential interfaces which support perm_invent.
Fixes#124
Fix github pull request #124 which was also reported directly (but not
through the contact form so #Hxxx number). Using ^I or #wizidentify
displays inventory with everything ID'd for that command only and adds
a menu entry "_ - use '^I' to identify" that can be chosen to make
those ID's persistent. Picking underscore would work but picking the
alternate '^I' wouldn't work if the platform had unsigned characters
for plain 'char'. Switch the return value from magic number -1 to
magic number ^I which isn't a valid inventory letter and isn't subject
to sign conversion. Casting -1 to '(char) -1' would have worked too
despite some confusion expressed in discussion of the pull request.
If ^I has been bound to some other command and #wizidentify hasn't
been bound to any keystroke, temporary ID didn't disclose any extra
information (ie, acted like ordinary inventory display) and the extra
menu entry to make temporary ID become persistent wasn't available.
This fixes that too.
H7205 - full-pack identify might skip items if perm_invent is on
because updating the inventory window might reorder 'invent'
while the identify code is in the midst of traversing it;
H7120 - pickup that doesn't pick anything up can change the glyph
shown on the map because the pile might be reordered such
that a different item is on top;
H5216 - performing a sortloot operation on a pile and then switching
back to sortloot:none doesn't restore pile's original order.
The 'revamp' that changed the contributed sortloot feature to switch
to simpler usage (object list itself was sorted rather than having a
parallel array that needed to be constructed, sorted, traversed, and
discarded) turns out to have too many problems. This reverts to a
hybrid solution that constructs an array for traversal, leaving the
linked list in its original order, but hides most of the details of
that from sortloot() callers. The 'revamp' benefit of being able to
use normal list traversal is lost, as is the potential to skip
sorting when the list turns out to already be in the desired order.
This could stand to have a lot more testing than it's had so far.
Noticed while investigating the report about sortloot interacting
with persistent inventory window when identifying all of invent and
possibly skipping some items. [This doesn't fix that.]
End of game disclosure was using makeknown() on inventory. It is a
jacket around discover_object() which passes the flag to exercise
Wisdom. That's useless at end of game [now; conceivably wrong if
disclosure of characteristics exercise ever got added], so call
discover_object() directly to suppress exercise of Wisdom.
discover_object() was also calling update_inventory() for every item
being discovered. That's not useful when looping through inventory
at end of game.
When ascending or escaping from the dungeon, adjacent pets are moved
onto the 'mydogs' list so that they can be included in the score and
mentioned as being with hero in the final messages. But keepdogs()
was caled to do that before the known portion of the map was drawn
in the dumplog file, so adjacent pets were missing. Defer that until
after the map has been dumped so that pets will still be present.
Report was for tty, but X11 exhibited the same behavior. With the
perm_invent option enabled, when the permanent inventory window is
displayed, it would be empty if not carrying anything. For tty, that
meant a naked "(end) " selection prompt. Put a separator line of "Not
carrying anything" into the menu so that it won't be completely empty.
The selection prompt is still present but it is attached to something.
(The behavior is different from !perm_invent, where you get that same
text via pline without any menu at all.)
I saw dumplog text in a newsgroup posting and the only way I could
recognize what version generated it was that "You entered the dungeon
N turns ago" included the missing-until-recently final period. So,
put nethack's one-line version information as the very first dumplog
text and follow it with the dumped game's start and end date+time.
(That information is useful to know in its own right, but also should
prevent the build date+time shown with the version from confusing
anybody about when the dump was written.)
Along the way, I noticed that the 'counting' phase for artifact_score
was being repeated for '#if DUMPLOG' even though it doesn't generate
output. That had a side-effect of adding points for artifacts twice
(applicable when final score was for an ascension or dungeon escape).
Use the same terminology ("creatures" rather than "monsters") for
the two "no <foo> {have been, were} vanquished" messages as for the
"disclose vanquished <foo>" prompt and its "M <foo> vanquished"
summary.
The dumplog data was including a final tombstone unconditionally,
which looked awfully strange for characters who didn't die. Make
it conditional, like actual end-of-game tombstone. (One difference
though: dumplog has a tombstone for hero who died from genocide,
end-of-game does not. I think the latter should display one even
though no grave gets generated.) [Potential for future enhancement:
add some alternate ascii art in place of tombstone for survivors.]
The list of genocided and/or extincted species was never shown
since caller passed 'a' to list_genocided() and it expected 'y'.
Also, once shown, the list entries were lacking indentation that
other sections of the dump generally have.
Both vanquished monsters and genocided/extinct monsters included
a blank line separator even when there was no feedback, making a
noticeable gap in the dumplog text. Have them report "no creatures
vanquished" and "no species genocided", when applicable, so that
their separator lines always have something to separate.
When dumping, omit a couple of blank lines each from vanquished
creatures list, genocided species list, and tombstone so the
relevant sections of the dump are more compact.
Use a simple ring buffer instead of a flat array that needed to have
49 pointers shifted down a slot every time a pline message was issued.
'saved_plines[saved_pline_index]' is the oldest message in the buffer
and the next slot to use when adding a new one.
For "the poison was deadly" against hero, hit points were set to -1
(which gets displayed as 0 when shown) but the status lines weren't
being updated, so stale positive HP value was visible during final
disclosure.
Some reformatting of the recently added pet ranged attack code.
The redundant--but different--multishot volley code has been replaced
so that there are only two versions (hero and monster) instead of
three (hero and monster vs hero and pet vs other monster). The monst
version was out of date relative to post-3.4.3 changes to the hero one.
The pet version was way out of date and had some bugs: wielding an
elven bow gave a +1 multishot increment to volley count for fast weapon
even when throwing something rather than shooting arrows, wielding any
weapon which had at least +2 enchantment gave 1/3 enchantment bonus to
volley count when throwing instead of shooting shoot ammo, and a pet
which got killed in the midst of a multishot volley--perhaps by a gas
spore explosion or some other passive counterattack--would keep on
shooting/throwing until the volley count was exhausted.
Pet use of ranged weapons is not ready for prime-time. Pets don't
hang on to missiles or launchers+ammo, they just drop them if there is
no target immediately available.
