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.
The relatively recent change to lev_comp do deal with apparent junk
in some places in its generated data has triggered a bunch of
"cast to 'vA' (aka 'const char *') from smaller integer type 'int'
[-Wint-to-pointer-cast]"
from clang when building with USE_OLDARGS. Probably should have
added a zillion explicit casts to long and 'L' suffix for 0 rather
than trying to handle both int and long. Or maybe just turned off
that particular warning, which must be coming from -Wall or -Wextra.
This modification has no effect for USE_STDARG or USE_VARARGS configs.
We still don't know whether this will be of any help against
disconnected processes that hog the CPU instead of exiting, but I
don't think it imposes significant overhead on ones which aren't
disconnected. Install it before it suffers from more bit rot.
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.
While the fuzzer was running, amidst the continual screen updating I
caught a glimpse of "Cn" and was puzzled about how the hero became
cancelled. I quickly realized it actually meant confused, but I
think "Cf" is a better abbreviation for that. I've also changed "Ha"
to "Hl" for hallucination and "Ri" to "Rd" for riding. The rest is
formatting.
Salvage part of an old patch. Swapping places with any long worm,
even a baby one, always failed with "You stop. Foo is in the way!"
This lets you swap places with tame baby long worms, and adult ones
if they have no tail (which won't happen unless there are more than
32 long worms on the current level--even if a long worm appears to
be only a head, there is normally a hidden tail segment at the same
location).
Although choose_classes_menu() is only used for objects, it is written
to handle monsters too. My change to give <space> special handling
might have broken selecting ghosts if it's ever used for monsters so
fix that.
More on clearing pickup_types so that autopickup reverts to picking up
evertyhing: for menustyle:Full and Partial, add a menu entry for 'all
classes' as an alternative to unselecting every class already set.
Also, Full and Partial had no way to include venom. Now it's a choice
when in wizard mode. There's still no way--other than switching to
Traditional or Combination--during normal play (where venom objects can
exist if they were wished for in wizard mode and then left in bones).
'sz' is the size of the buffer; 'if (count < sz) buf[count++] = c;'
can fill the entire buffer, leaving count==sz, so buf[count] = '\0';
would be out of bounds.
Formatting was way off. Indentation these days should be multiples
of 4 spaces, never tabs.
To use 'O' to clear a value from pickup_types with menustyle Traditional
or Combination, you needed to give a value starting with 'a' (for 'all').
Accept space(s) too, similar to removing an object or monster name.
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.]
A change I included with the vault guard fix was triggering fuzzer
panics about dead monsters on the fmons list. I'm not quite sure why;
I couldn't reproduce it interactively. [Perhaps caused by hero killing
a monster and then getting another move before monsters get their turn,
but trying to do that still didn't trip the dead monster sanity check.]
Suppress that check so that the fuzzer can run amok.
Also, a waiting-to-exit vault guard could move extra times, uselessly
since ''hero hasn't left temporary corridor yet'' is why he's waiting,
if there were any monsters fast enough to get extra moves before the
hero's next turn.
"Placing monster over another?" warning was triggered for vault guard
by an earlier change which made m_detach() stop removing monsters at
<0,*> from level.monsters[][]. So one guard would replace another at
<0,0> for however many guards were created, and memory for all but
the last one would be lost.
This involved a lot of flailing about and the patch includes various
things would could have been discarded. One or two extended monster
sanity checks are included, plus a couple of debugpline()'s for
tracking guard movement.
The fruit name fix a couple of days ago revealed that an() didn't
pick the right article for single letters. If you set named fruit to
"X" and wished for "fruit", you'd have 'k - a X' added to inventory.
This changes an() and also doname() which bypasses an().
struct rm.flags in overloaded for a bunch of rm.typ -dependent things
(doormask, altarmask, throne/fountain/sink looted, a few others) and
wasn't being reset for various cases where rm.typ gets changed.
I've changed a lot, some no doubt unnecessarily, and probably missed
plenty. This compiles but has not been thoroughly tested.
When clairvoyance revealed an underwater object and the player wasn't
being given a chance to browse for some other reason, the map didn't
get refreshed and the object stayed displayed with the water hidden
under it. Force a chance to browse when revealing underwater objects
despite that being intrusive when clairvoyance kicks in while walking
around.
Jumping or teleporting while levitating in xorn form wouldn't toggle
blocking of levitation when moving from open spots to wall/stone and
unblocking of same when moving the opposite way.
This handles those cases but there are no doubt others. The only
other one I checked was when failed #untrap moves hero onto trap.
That case works correctly--at least after this fix is in place.
Noticed while working on it: change of terrain didn't always update
the status line. When levitation became blocked, it still said Lev
and when unblocked, didn't say that. Next status update got status
condition back in sync.
Some code added for 3.6.1 tries to find the longest matching prefix
when comparing a user-supplied with previously set up fruit names.
It does so by temporarily replacing space with NUL then passing that
to makesingular(). After already having named a fruit (resulting in
something to try to compare with), attempting to assign a name
beginning with two or more spaces would yield an impossible "singular
of null?" warning.
After the warning, the name minus its leading spaces got successfully
assigned. I'm not sure why a single leading space didn't trigger it
too, nor where the leading (and trailing, if any) spaces are going
away when the name is assigned.
Fix by removing all leading and trailing spaces from a new fruit name,
and combine consecutive internal spaces to one, before any other
manipulations. (This can result in names that used to work as-is now
being simplified a bit--when consecutive internal spaces have been
given--but that shouldn't be a problem.)
Also, don't complain about "missing parameter for 'fruit:'" if user
hits <return> when prompted for fruit name by 'O'. An empty fruit
name at that stage is just a no-op.
Make the sequence:
be zapped by lightning,
have worn ring of levitation be destroyed,
fall onto fire trap
work better. The fire trap handling will mark everything in inventory
as already processed; anything vulnerable to lightning past the destroyed
ring would not be checked. So delay destroying such a ring until after
all of inventory has been subjected to lightning.
In the 'special options' section at the end of 'O's menu, change the
spelling for the menucolors entry to "menu colors" so that it isn't
spelled exactly the same as the 'menucolors' boolean option. Only
affects what the player sees when reading that menu.
If player uses 'O' to add any menu colors and 'menucolors' boolean is
Off at the time, give a reminder to toggle it to On in order to have
those menu colorings become active. (Adding hilite_status entries has
a similar reminder for 'statushilites' if done while that is 0.)
With options along the line of
OPTIONS=statushilites:4
HILITE_STATUS=gold/always/yellow
gold started out unhighlighted (unhighlit?). I didn't try to figure
out why, just changed things to force a full status update when gold
requires internal changes (different \G encoding or different glyph)
which is something that happens when session first enters moveloop().
Inventory traversal can be disrupted when items being traversed are
able to change inventory. I've lost track of how many times this
sort of thing has been discovered.
Report claimed that boiled potion of polymorph caused transformation
which resulted in dropped weapon and dropped or destroyed worn armor.
That was evidently a guess; potionbreathe() for that potion only
abuses constitution. The traceback showed 'you_were()' was involved.
Boiled potion of unholy water triggers human-to-beast transformation
of hero inflicted with lycanthropy, yielding similar situation.
I didn't notice anything unusual when reproducing this but inventory
was definitely vulnerable. My 'one line' fixes entries are steadily
getting to be more verbose; I may have to go back to 'fix bug'. :-}
When a hero dies due to turning into green slime, actually polymorph
him into a green slime monster before killing him off. That way he'll
show as a green 'P' on the map instead of white '@' during final
disclosure. Also, armor that gets destroyed by polymorphing into that
form will be absent from resulting bones file.
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.
When deciding whether to discard interrupted lock/unlock context while
changing levels, maybe_reset_pick() checks whether xlock.box is being
carried. But it was doing so after the old level had been saved and
memory for non-carried container there had been freed.
That led to a couple of other issues. context.travelcc was using -1
for 'no cached value', but the fields of travelcc have type 'xchar' and
shouldn't be given negative values. 0 should be fine for 'no cache'.
Failed partial restore which occurred after old game's context had been
loaded would begin a new game with old game's stale context. Restoring
goes out of its way to avoid that for 'flags' but didn't for 'context'.
hmon() can destroy the weapon being used, and known_hitum() would
still pass the pointer to the freed object to cutworm(). Remember the
relevant weapon attribute before using and maybe freeing the object,
then pass that attribute instead of the whole weapon. Also pass
'more-likely-to-cut' for axes in addition to blades.
thimonst() behaved similarly, although due to much different code
paths none of the objects that might get to hmon() were then passed to
cutworm(), so it wasn't vulnerable. But pass 'more-likely-to-cut'
for axes instead of for blades when thrown.
Update tty command completion to ignore #shell and #suspend when
they're disabled. (Since they aren't flagged for command completion,
this should be unnoticeable.)
Update X11 extended command selection to not show shell and suspend
in the menu when they're disabled. (Trickier than I expected.)
X11 currently rejects #suspend (at run time, not compile time) but
allows #shell. If it was launched syncronously from a terminal
window, shell escape behaves sanely. Otherwise, that seems like
asking for trouble.
Change the command list to always include #shell and #suspend so that
a user's preferred key bindings can span platforms without worrying
about whether those exist or not. They're still effectively no-ops
when compiled out.
'#?' suppresses them from the list of displayed commands. Interface-
specific extended command handling may want to check new extcmd.flag
value CMD_NOT_AVAILABLE to do the same, but failing to do so shouldn't
pose a problem. They behave sanely if executed when not supported.
Replace recent "(light blue aura)" with
"(flickering light blue)" if there are 1..4 orcs,
"(glimmering light blue)" if 5..12, or
"(gleaming light blue)" if there are 13 or more, and move its place
in the formatted name.
_3.6.1_: Sting (weapon in hand) (glowing light blue)
_recent: Sting (weapon in hand) (light blue aura)
_now___: Sting (weapon in hand, flickering light blue)
The thresholds for intensity may need to be tweaked. The start
message has been changed from "glows" to "flickers/glimmers/gleams"
and is given when the intensity changes (up or down) as well as when
first glowing. Stop message will usually be "stops flickering" but
some form of mass kill (genocide for sure, maybe explosion, probably
not wand zap) might result in stopping directly from higher intensity.
It still "quivers" if hero is blind when there are orcs on the level,
but no name augmentation shows in inventory for that situation;
describing it as "(weapon in hand, quivering)" would be too silly.
Also, the quiver or glow intermediate message if blindness is toggled
while Sting is active only worked for make_blinded(), not for putting
on and taking off a blindfold. Now fixed. I think becoming blind due
to polymorphing into an eyeless form is still not handled, but there
are no eyeless creatures capable of wielding weapons so that can wait.
Polymorphing from eyeless to sighted is handled but moot for Sting.
My sysconf allows shell escape, and the fuzzer seems fond of that.
Suppress '!' and also '^Z', although I didn't notice it execute the
latter. Without this hack, the sequence '!', sub-shell exit, '&'
causes nethack to be killed via SIGTTOU while fiddling with terminal
settings for introff().
Text popups on OSX could be dismissed with <space> or <return> or
<esc> if user's X resources had 'NetHack*autofocus' set to True, but
for the default of False they ignored all keystrokes even if you
clicked inside the popup window to set focus explicitly. Clicking
on the Close Window button of the popup's title bar was the only way
to get the popup to go away. Fix suggested by Pasi.
By creating a spot of lava, filling up the whole level, and creating
a lurker above, I managed to trigger the impossible "Dismount: can't
place former steed on map" that was added earlier today. I also was
told that my god was displeased even though the engulfer's attack was
responsible. This addresses both situations. I can't trigger that
impossible any more, and only voluntary dismount blames the hero if
it's killed because there's nowhere to place it. Hero is still blamed
for any dismount that kills the steed while flying or levitating over
dangerous terrain--hero took steed into jeopardy.
Noticed whlie testing the steed-in-pit fix. The EXTRA_SANITY_CHECKS
for remove_monster() are being tripped if riding hero has steed killed
out from under him because the steed is not on the map. This started
out simple but got a bit complicated. It seems to be sufficient but
I'm not very confident about it.
Being engulfed while mounted gave "placing monster over another?" due
to a change made along with EXTRA_SANITY_CHECKS but not conditional on
it. (The change was to issue a warning about an actual problem which
was previously undiagnosed.) I think bumping the engulfer off the map
in favor of the former steed only worked because some u.uswallow code
eventually used the hero's location to put the engulfer back. I didn't
pursue that to try to figure what really happened, just prevent it.
The DISMOUNT_BONES handling was being executed even if the steed was
dead. DISMOUNT_BONES only happens if the hero is dead. Since I don't
know whether it's possible for dead hero and dead steed to happen at
the same time, move it inside the steed-not-dead block just in case.
Fixes#164
No message was shown when riding a steed into a pit or spiked pit.
Setup for the message was done, but post-3.4.3 insertion of else-if
into the previous if/else/endif cut off its delivery.
Applying a non-wielded cursed pick-axe first wielded it, then dug,
but it didn't report "pick-axe is welded to your hand". (Attempting
to drop it or wield something else did report that, after the fact.)
The same thing happened if you used a pole-arm rather than pick-axe.
Stinking cloud placed near water or poison gas breathed across it
would affect and potentially kill underwater monsters. Most swimmers
are on the surface and should be affected, but eels and other fish
shouldn't be.
This also changes minliquid() to not treat flying and levitating as
ways to survive water when on the Plane of Water.
I think goodpos() needs to be taught about that Plane (where many ways
of existing at a water location don't apply). This doesn't do that.
There was a spurious seli-colon after an if's test, making a boundary
check be ineffective. When looking at that, I noticed that the 'O'
command's display of the current value for mouse_support ("0=off" and
so forth) was relying on implicit concatenation of adjacent string
literals, which would break K&R compilation. Do that concatenation
the old fashioned way....
While testing (after temporarily adding WC_MOUSE_SUPPORT to tty's
window_procs), I also noticed that wording used by config_error_add
looked strange when it was in response to giving a bad value via 'O'
command. Suppress its "config_error_add: " prefix is that situation.
Fix lev_comp's variable argument usage by changing it to make
add_opvars() expect an int rather than a long when given the "i"
indicator, and add "l" for really passing a long. The ints are
conveted to longs when setting up the interpreter. I think I changed
just about all the integer opvars to int, although there is one use
of "l" in lev_main.c just to make sure it works. There could be
arguments that really do need to be 'long'; if so, the add_opvars()
calls for them will have to have its indicator string updated and
possibly add or remove some casts.
There's a lot of reformatting included but it's not consistent about
tab replacement. Some of the changes are due to renaming long-named
'variable_definitions' to 'vardefs' to shorten a bunch of lines.
Updated sys/share/*_yacc.c will be checked in separately. The ones
currently in the repository won't work with patched lev_main.c due to
that renamed variable.
Fixes#163Fixes#153
Encumbrance calculations for taking things out of a bag of holding
where subject to rounding issues due to integer division. This may
improve things, although I think taking out a partial stack might not
be much better than before.
I simplified the contributed code, then decided that it wasn't an
improvement. In the process of switching back and forth I may have
introduced bugs which weren't present originally.
Fixes#161
Report states that scattering objects might leave a 'pile' glyph when
no longer appropriate. I didn't try to reproduce that, just took it
on faith. The fix tried to be too efficient and might have missed
fixing the display if breaks() or ohitmon() destroyed the objects
being scattered and left 'total' at 0.
During level change, when a monster from mydogs (monsters accompaying
hero, usually pets) couldn't be placed because the level was full, it
was set to migrate to that level (in order to get another chance to
arrive if hero left and returned). The code sequence
mon_arrive()-> mnexto()-> m_into_limbo()-> migrate_to_level()-> relmon()
tried to remove the monster from the map, but it wasn't necessarily on
the map (depending upon whether it couldn't arrive at all, or arrived
at the hero's spot and couldn't be moved out of the hero's way). The
EXTRA_SANITY_CHECKS for remove_monster() issued impossible "no monster
to remove". relmon() now checks whether monster is already off the map.
While investigating that, I discovered that pets set to re-migrate
to the same level to try again on hero's next visit didn't work at all.
migrating_mons gets processed after mydogs so moving something from
the latter to the former after arrival failure just resulted in
immediate second failure when the more general list was handled during
the hero's current arrival. And failure to arrive from migrating_mons
would kill the monster instead of scheduling another attempt.
The sanest fix for that turned out to be to have all monsters who
can't arrive be put back on the migrating_mons list to try again upon
hero's next visit. Pets still fail twice but are no longer discarded
during the second time, and now do arrive when hero leaves and comes
back provided he or she has opened up some space before leaving. If
there's still no space on the next visit, monsters who can't arrive
then are scheduled to try again on the visit after that.
Recent fix for invalid corpses becomes moot. Monsters aren't killed
during arrival failure so there are no resulting corpses to deal with.
Attempting to untrap an adjacent location failed if you had escaped a
pit, claiming that you couldn't reach. You can't reach the bottom of
the pit if you're not in it, but you should be able to reach adjacent
spots normally.
Prevent food detection--scroll or crystal ball--from noticing the cat
corpse inside SchroedingersBox since its presence is tentative and
resolving its status during detection is a huge can of worms (live cat
placement on map from inside locked box, parallel resolution required
for monster detection/warning/telepathy that would render the box
fairly useless since it would probably end up getting resolved by ESP
before hero gains access).
Prevent cat corpse in the Box from being added to shop bill if unpaid
Box is picked up. That prevents it from being listed as a bought item
if the player buys the box (instead of being described as unknown
contents; an older, more general bug which still hasn't been fixed).
As far as I'm aware, off the revised handling of Schroedingers Cat is
finished.
A copyright header inserted last spring uses the wrong format for a
DCL comment and triggers a couple of warnings about invalid commands.
Some linker hackery added a long time ago draws complaints from the
linker on IA64. This was noticed during the release cycle for 3.6.0
but then went unaddressed.
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.
Migrating monster attempting to arrive on a level which is already
full of monsters gets killed off. It was leaving a corpse without
regard for whether it was a type of of monster which should never
leave corpses.
I'd prefer that it be put back on the migrating_mons list rather
than be killed off, but this just suppresses impossible corpses.
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 paying for shop door or wall damage, if the entire amount was
covered by shop credit then impossible "zero payment in money2mon"
would occur as the shop code tried to transfer 0 zorkmids from hero
to shopkeeper after using credit to pay.
Clean up quite a bit of minor things found with simple grep patterns:
operator at end of continued line instead of beginning of continuation
(and a few comments which produced false matches, so that they won't
do so next time), trailing spaces (only one or two of those), tabs (a
dozen or so of those), several casts which didn't have a space between
the type and the expression (I wasn't systematic about finding these).
I think the only code change was in the function for the help command.
If bogusmon, engrave, epitaph, oralces, or rumors won't open, assume
it's because the file is missing so don't have impossible() tack on
"saving and restoring might fix this" when telling the player.
(Missing rumors or oracles previously only used pline() rather than
impossible() so this hadn't been an issue for them. Now it would be.)
Apparently I exited emacs without saving and the revised vmsbuild.com
ended up as a backup file that 'git nhadd' wouldn't see. This was
supposed to be included in the patch committed several hours ago....
New-ish files 'engrave', 'epitaph', and 'bogusmon' added for 3.6.0
were not handled by playground setup. NetHack runs without them so
limited testing didn't notice.
Add 'makedefs -s' to build them and include them in installed files.
Also, remove 'makedefs -m' and obsolete monstr.c.
I was experimenting with some potential changes to menu searching but
have not been satisfied with the result. However, this bit of code
consolidation is worthwhile regardless of that.
Some of the items in NetHack.ad were separated from others by "!"
comment line rather than plain blank line and that tended to make it
look like the two items were directly related. For the ones which
aren't, remove '!'.
I also expanded some comments and reordered a couple of resources,
moving 'slow' closer to top and advanced 'translations' farther down.
Vampires tend to take vampire bat form and stay that way, unless/until
there's a closed door they want to pass in which case they change to
fog cloud form. Those shifted forms are weak, so pet vampires tend
not to attack other monsters, and if they don't take damage, they
won't change to vampire form. So, when comparing relative strength of
self and foe while deciding whether to attack another monster, treat
their own strength in weak form as if in vampire form, making them be
more aggressive.
Hostile vampires shouldn't need any comparable change. They don't use
relative strengths when deciding whether to attack something.
Fixes#159
The nurse monster definition is flagged to be able to convery poison
resistance when a corpse or tin is eaten, but the post-corpse code
for nurse healed HP and cured blindness then skipped the intrinsic
handling.
Use the make_foo() intrinsic set/reset routines instead of trying
to manipulate the intrinsics directly. Previous patch left Dex
down by 1 if stoning caused wounded legs to be fixed, and left
delayed killer allocated if stoning cured sliming or vice versa.
I tried 'pick all' in the #wizintrinsics' menu and after 30 turns,
died with "poisoned by a poisoned, while vomiting". Food poisioning
and/or terminal illness beat the other fatal conditions to the coup
de gras. However, the final stage of vomiting sets Sick to 0 cure
food poisoning and ends up clobbering the killer reason if Sick is
due to terminal illness. It's feasible for that to happen without
using #wizintrinsic, so this fixes that, and also a few other
combinations that seemed contradictory:
1) limbs turn to stone during Stoned countdown now cures wounded legs;
2) turn to stone (a couple of turns later) cures vomiting and sliming;
3) turning to slime during Slimed countdown cures stoning.
Salvaged from an old, unfinished patch. When checking whether the
hero is trapped by walls and solid rock, adjacent boulders are
evaluated on whether they can be pushed out of the way. Extend that
evaluation: (1) two boulders on a spot are pushable if there is a
pool beyond that spot, and (2) boulders can't be pushed diagonally
in Sokoban.
and over the hero. 3.6.0's clairvoyance tried to show things in
a non-standard sequence, which was intentional but had unintended
side-effects like the disappearing monsters complained about in the
report. To make it work as intended would have required --More--
whenever it kicked in, which is much too intrusive when it happens
every N turns rather than when explicitly casting the spell.
Redo it substantially, and give preference to monsters over objects,
objects over traps, and traps over underlying terrain like normal
vision-based display does. It now detects all monsters within its
bounding box but shows ones which aren't directly in view as
"unseen monster" unless via spell cast at skilled or expert, or at
basic when also having intrinsic clairvoyance.
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.
Fixes#156
githib issue #156 complains that "The Excalibur falls down the stairs,"
is using poor grammar despite the fact that the usual drop message is
"You drop the +0 Excalibur." I agree. Change it to be "Excalibur
falls down the stairs." (Drop message remains unchanged.)
While looking at that, I noticed that when knocking other items down
stairs, text was being appended to the formatted object name. It was
probably safe due to the space reserved for inserting a prefix while
formatting an object's name, which becomes available for a suffix
after that name has been copied into otransit_msg()'s local buffer,
but using a separate buffer is safer.
Attempting to mount a long worm tail could yield
\#ride -> mount_steed() -> test_move() -> worm_cross() ->
impossible("worm_cross checking for non-adjacent location").
New: call to panic() in impossible() used arbitrary string as a
format so was vulnerable to percent signs in that string. (This
potentially serious problem is not limited to USE_OLDARGS.)
Old: revised message string for impossible ("save/restore might fix
this" instead of "perhaps you'd better quit") passed wrong number of
arguments to pline() when using the clumsy VA_PASSx() mechanism (was
missing arg 0 for the fixed-arg format argument).
Old: varargs config_error_add() in files.c wouldn't compile for
USE_OLDARGS. Evidently no one has been impacted by that but this
fixes it anyway. (Two problems: prototype used FDECL() when it
should have been using VDECL(), and calls to config_error_add() in
the same file would need the VA_PASSx() stuff to force presence of
all optional args. I moved it instead of adding the latter.)
Enlightenment feedback for "nudist" was added 3.5 years ago. Ever
since, ^X has been reporting "you are not wearing any armor" when
wearing a shield without any other armor.
Since Valkyrie starts in that situation, it's very surprising that no
one ever noticed 'til now (or did notice and didn't bother to report).
Followup to 'fix #148' patch: looting a container with menustyle:Full
wasn't offering a chance to remove everything in one go. That was due
to an error I introuduced 2.5 years ago with commit
529dad8ef1 when I changed how the flags
passed to query_category() were being set up. It accidentally switched
'A' from take-out to put-in but the only code to handle 'A' at that
time would take everything out (from container to inventory).
Prior to that, removing everything worked as intended and putting in
everything wasn't supported. Now 'A - autoselect all' is a viable
choice for both in and out.
Fixes#154
With menustyle:Full, picking 'A - autoselect all' when putting items
into a container ran code for taking things out and there wasn't any
corresponding code for putting things in.
Add some put-in-everything code. Taking things out doesn't offer
'A - autoselect all' as a choice so the code mentioned above may now
be dead. Taking everything out seems like something that's much more
likely to be desired than putting everything in.
Hopefully this will be the last one. Change from a text window to
a menu so that it is possible to scroll backwards (without needing
scrollbars) via '^' and '<' keys. End of game disclosure for
attributes still uses a single-forward-pass text window.
Also, move the recently added weapon proficiency line from the new
'basic' section to right after the "you are wielding" line at the
end of the 'status' section.
Add a new line for one last missing status field: gold.
Also add one for proficiency with current weapon.
Move a few lines from 'characteristics' to 'background' and a few
more from 'characteristics' to new 'basics', leaving characteristics
with the six original characteristics: Str, Con, Dec, &c.
My "fix github issue #38 - indentation vs 'if {}'" patch, commit
d2ae45984e, broke finding unseen
monsters via searching. Most notable if blind, but applied to
invisible monsters too.
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.
Restore handling for keystrokes on PICK_NONE menus so that scrolling
via keys works for them. (That handling was disabled as part of the
patch to support MENUCOLORS.)
Enable [cancel] button for all menus. (That had apparently been
grayed out for PICK_NONE menus since day 1 for X11 windowing.)
Dungeon level wasn't included in ^X output, so it wasn't actually
giving all status fields and attempting to rely on it when turning
off 'status_updates' was leaving a gap in feedback for the player.
Add an extra line to the first section where character's name and
patron deity are reported, giving current location.
|You are in the Dungeons of Doom, on level 5.
or
|You are in the endgame, on the Elemental Plane of Fire.
The information is more explicit than the basic status field, but
you can already get similar information via #overview so it isn't
giving away extra info.
Move some 'roff macros from Guidebook.mn to new file tmac.nh.
Header for tmac.nh is not being updated, even after explicitly adding
it to .gitattributes. I'm not sure what I've done wrong. (I'm using
'git nhadd doc/' here rather than explicit 'git nhadd doc/tmac.nh'.)
In Guidebook.mn, change the ``setenv NETHACKOPTIONS'' example so that
it fits within one line in Guidebook.txt. (I looked at 3.4.3's
edition of that file and the example went not just beyond the margin
of the formatted text but beyond 80 columns, so wrapped in an ugly
fashion.) I had previously changed 'autoquiver' to 'color' to shorten
it, now have changed '!autopickup' to '!leg' to show an example of
truncated option name as well as shorten, and also 'fruit:papaya' to
'fruit:lime' to squeeze out the last two columns needed to fit within
the text margin while retaining 'name:Blue Meanie' as requested.
Guidebook.txt shows both NETHACKOPTIONS examples with indentation
suppressed, Guidebook.ps uses normal indentation (evidently using a
narrower font, even with \f(CR (constant-width Roman) to approximate
TeX's \tt, since the indented example fits fine and looks better).
Some Guidebook.tex catchup. I suspect that lots of bits and bobs
don't match between Guidebook.mn and Guidebook.tex these days.
Particularly quoting and variant font (italics, bold, \tt) usage.
Also the recently added box around the sample screenshot. This
modifies the screenshot to match Guidebook.mn's, reflecting change
in status field spacing by STATUS_HILITES.
Fixes#150
> A very minor one, but there are some situations where your encumbrance
> level can change, but the message (such as '`Your movements are now
> unencumbered.`') isn't given until your next move or turn, even though
> the status line updates immediately. For example, praying while weak
> and gaining a point of strength. Picking up or dropping items or
> interacting with containers does _not_ have this problem.
This is usually fixed on a case by case basis. Any attempt to add
blanket encumbrance check mid-turn (when updating status, for instance)
is sure to introduce message sequencing problems. Perhaps such a check
could be added at the end of the hero's move....
This fix handles the cases where prayer causes a change to strength:
major: fix starvation, minor: fix weak from hunger, boon: golden glow
(restore strength and satisfy hunger--probably no-ops in this regard
or would have had trouble fixed rather than receive a boon). Directly
curing stat loss (minor: poisoned) already dealt with encumbrance.
> Possibly related to the quirk whereby polymorphing into a form with
> different speed gives you one move movement at your old speed?
> (Polymorphing into a sessile monster gives you one last move.)
Not at all related. That movement bug affected 3.6.0 but was fixed in
3.6.1.
When trapped in a web, trying to move while wielding Sting gives the
message "Sting cuts through the web." In 3.6.1 and earler, that
also released you from the trap, but with 3.6.2-beta nothing happens.
It had nothing to do with the recent web spinning patch. My change
to have being trapped block levitating and flying included replacing
a lot of direct manipulations of u.utrap with set_utrap() and
reset_utrap() in order to keep the lev/fly blocking and unblocking
localized. Unfortunately, the old 'u.utrap = 0' when wielding Sting
while stuck in web was deleted in error at that time.
While looking at something else, I noticed that newsym() was checking
for pool and lava by examining the terrain type directly rather than
using the pool and lava checks, so it would never show a gas cloud at
a closed drawbridge (the spot in front of the portcullis). Level's
terrain at a closed drawbridge spot is DRAWBRIDGE_UP; need to look at
drawbridgemask field to figure out whether the accessible terrain at
that spot is moat or lava.
PatR