While not a path exactly, the dumplog file isn't placed somewhere
fixed so being able to see where it is placed could be useful.
This cascaded a bit during testing. Fix one of the warnings from
hardfought (fqn_prefix_names[]). And a few more that came up with
SYSCF disabled (panictrace_gdb, two unused variables if files.c).
For ^X and final disclosure, report external issues that affect game
play: midnight, other night, new or full moon, and Friday the 13th.
The 'new feature' entry in the fixes file rambles a bit but if it
heads off even one spurious bug report, it'll have been worth it.
savebones() sets all the fruit indices negative, then resets to the
normal positive value for each fruit it actually writes into the bones
file. But if 'perm_invent' is enabled and something triggers an
update_inventory() while bones saving is in progress, object formatting
for the inventory display won't be able to find any fruits, resulting
in impossible "Bad fruit #N". Fix is to turn off 'perm_invent' when
the game ends, so it won't be On when bones are written. Disclosure
uses a popup for inventory so persistent window is obsolete by then
anyway.
[I don't know what is triggering update_inventory() while savebones()
is executing. Also, I don't see where the fruits whose index stayed
negative--because there aren't any on level being saved--get purged.
Maybe when those bones are loaded by another game?]
Carried containers could have their contents-known state and/or
lock-known state changed without persistent inventory window being
updated to show the new information.
This also changes the behavior when player has hero zap self with
wand of locking or wizard lock spell. If it doesn't trigger a
holding trap then the effect will hit inventory, similar to how
opening/knock operates (releasing hero from holding trap or hiting
inventory when that doesn't happen).
Fixes#196
If you didn't die from turning into green slime but then died because
green slimes had been genocided, the message given assumed that you
had just seen "OK, you don't die" from answering No to "Really die?".
Its wording didn't make sense if the reason you didn't die was an
amulet of life-saving. Give a different message for that case.
Also, if you survive turning into slime (via either method) and either
green slimes are still around or you answer No to "Really die?" when
they've been genocided, give a message after "You survived that attempt
on your life" pointing out that you have done so in green slime form.
Useful since prior to 3.6.2 you would have reverted to original form--
despite the Slimed countdown saying you had turned into green slime.
If you died while Punished but with attached ball and chain temporarily
off the map (changing levels and when swallowed are the cases I looked
at; there may be others), the ball and chain objects would not appear
in bones (for the falling-down-stairs case; bones are never saved if
hero dies while swallowed) and they weren't being freed. Put them
back on the map so that they'll be included in bones and also freed as
part of normal map cleanup.
This caused a problem if the attached ball had state OBJ_FREE due to
being thrown rather than being temporarily off the map. 'thrownobj'
was being deallocated without first cancelling punishment, so uball
object was freed via thrownobj pointer but stale uball pointer still
referenced it. Unpunishing would introduce sequencing issues because
that would need to be after attribute disclosure. So instead of
deallocating thrown or kicked object, put it/them (can't actually have
both at the same time) back on the map. This has a side-effect of
saving thrown Mjollnir in bones if it kills hero when failing to be
caught upon return. (I thought that that had been fixed ages ago?)
Preserve temporary fake object's previous dknown value by storing it
as a flag value within the m_ap_type field of the posing monster, and
recalling it when it is needed.
This is intended to help eliminate observable differences in price display
between real objects and mimics posing as objects.
98% of this is just switching the code to utilize macro M_AP_TYPE(mon)
everywhere to ensure that the flag bits are stripped off when needed.
The curses interface wouldn't build with HILITE_STATUS disabled. I
started adapting it to handle genl_status_update() but that was taking
too much effort with each niggling detail leading to another. This
goes the opposite direction: forcing the old STATUS_VIA_WINDOWPORT
behavior without having that #define available. That dragged along a
bunch of unexpected changes too.
When the 'time' option is on and context.botl isn't already set,
call a simpler status update routine that ignores all other fields.
When that flag is already set, full status update takes care of time
along with the other fields.
Expected to reduce bottom lines processing time but not screen I/O.
Only lightly tested.
Back in December, a change was made to suppress status when u.uhp == -1.
But if the hero died with exactly that amount, the status display would
be blanked out during end of game disclosure. Force u.uhp to be 0 when
dying. That was already happening if death occurred while hero still
had positive HP, but not when damage took him/her to negative.
Do late message suppression in a different fashion. Also, there are
more messages than shk taking hero's possessions and guard taking
hero's gold that need to be suppressed if regular message delivery
is no longer possible: "do not pass Go", "you arise from the grave
as a foo", "the corridor disappears", "you are encased in the rock".
Those last two are from vault handling but take place in a convoluted
manner: paygd -> mongone -> grddead -> clear_fcorr.
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).
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.
