Eliminate some redundant monster sleep handling pointed out by <email deleted>. I'm not sure if this is the right fix for mattackm(),
but the wakeup-after-hit was definitely wrong for the case where that hit
put the target to sleep. (I didn't try to make that actually take place
but it is a possible outcome of monster-against-monster combat.)
From a bug report: you could vomit when polymorphed into a rat but real life
rats can't/don't vomit. The latter was confirmed by <Someone> and <Someone>.
While testing a fix for this, I discovered a couple of other problems.
Healing magic which cured sickness failed to heal Vomiting (potion or
spell; unicorn horn deals with them separately). Enlightenment failed to
report Vomiting (it's not shown on the status line). Most significant was
that vomiting_dialogue() called vomit() twice (also make_confused() and
make_stunned() three times for every once intended). It was dividing the
remaining turns by 3 and then using that value to decide what to do, but
only message display took into account that the same divided value would
occur on 3 consecutive turns (or just 2 for the final countdown to 0,
because dialog routine gets called before timed-property decrement).
From a bug report, but just received:
you can't affix candles to the candelabrum while underwater, because the
underwater check (can't light candles while underwater) is made too soon.
If you somehow managed to get a lit lamp, candle, or candelabrum while
underwater, you wouldn't be able to extinguish it for same reason. The
bug report included a URL for a fix, but I didn't look at that. This
changes use_candle() to rely on use_lamp() for underwater handling, and
changes use_lamp() and use_candelabrum() to check for extinguishing
before making the underwater check.
Clean up the code at the end of goto_level(). The only change in
behavior, aside from eliminating a couple of wizard mode quirks, is that
if a hangup save occurs while staring at the quest entry message, it will
be flagged as seen and not show up again if you leave and return to the
quest after restore. (For wizard mode, you'll no longer find the Wizard
waiting if you use the level teleport menu to jump directly to the Astral
Plane from outside the endgame, and level teleporting away from astral
level to one of the elemental planes then returning won't make more fake
players or another guardian angel.)
From a bug report. (Michael forwarded a newsgroup posting about it back
then, but I had trouble reproducing it and didn't figure it out until
trying again now.) If hangup occurred while entering the quest, the magic
portal could be rendered inactive for the hero but still work for monsters.
That's because the hangup save stored the old value of u.uz0 before
goto_level set it to the new u.uz, and a magic portal won't operate when
u.uz0 differs from u.uz (to prevent a pair of portals from getting stuck
sending the hero back and forth). The problem could also occur going from
the quest back to the dungeon, or either direction for Ft.Ludios, but the
--More-- prompt when the quest entry text is being displayed makes hangup
during level change most likely to occur during initial quest entry.
This is just a bandaid, and the SAFERHANGUP config wouldn't be hit
by this situation.
#Q85: Bug: wrest a wand in one turn through engraving
From a bug report: engraving with an empty wand while not levitating, then using
ESC to abort when asked for the text to write, let you attempt to wrest
the last charge without using up a turn. Between the time this report was
sent and received, someone else reported similar issue with levitation,
where no prompting occurs. The fix for it also fixed the original problem.
Somewhat inadvertently though, since you can now no longer write in the
dust with a empty wand. I'm going to leave it this way; all that's needed
is some feedback about failing to engrave.
Set up to be able to use the m command prefix to request menu mode
for commands other than just pickup. As a side-effect, a hardcoded ','
referencing that command is eliminated. Also, the command handling for
pickup was accepting the other prefix characters (F,g,G,M,numpad 5) as
synonyms for m; this reverts all but 'm' to movement modifiers only (it
may be reasonable to retain M and 5, but this doesn't).
If nhwindows_hangup() were to get called a second time, it would have
saved hup_exit_nhwindows() as the previous interface's shutdown routine.
Then if/when exit_nhwindows() gets called, hup_exit_nhwindows() would
have called itself with uncontrolled recursion. So guard against that by
preventing the hangup shutdown routine from ever being saved as previous
interface shutdown routine.
Also, avoid the exit_windows macro when using it as a pointer rather
than for a function call, since pre-ANSI compilers might be confused by
its expansion.
From two weeks ago:
> The last of my intended hangup overhaul. Once hangup is detected,
> replace currently loaded windowing routines with stubs that never do any
> terminal I/O. Real interface routines call their siblings directly rather
> than via the windowprocs pointers, so this shouldn't pull the rug out from
> under them, but it also can't prevent whatever they have in progress at
> the time of hangup from attempting further I/O once the handler returns.
hangup_nhwindows() shouldn't call exit_nhwindows() prior to replacing
windowprocs with no-ops. Even though the original intgerface can still
access its own routines directly, the exit_nhwindows() routine probably
releases its dynamic data structures. And those could be in active use if
the hangup occurs while an interface routine is executing.
The hangup check added to xwaitforspace() (which gets tty user's
response to --More-- and "Press Return to continue: ") wouldn't be good
enough if hangup occurred while that routine's input loop was executing.
NOSAVEONHANGUP isn't documented anywhere. I don't see why it should
wipe out recoverable level files just because it doesn't want to build a
save file out of them during the hangup. Leave them intact if checkpoint
is active. If someone really wants to make them always go away, they'll
need to disable INSURANCE as well as enable NOSAVEONHANGUP.
tty's getret() -> xwaitforspace() could get stuck in a loop after
hangup, depending upon the state of terminal shutdown (accepting EOF or
ESC cares about cbreak mode?). Make xwaitforspace() become a no-op during
hangup processing.
vms's call to hangup() from an exit handler took place after the
terminal has been reset (the exit handler for the latter is registered
later so executes sooner). Then exit_nhwindows() resulted in a second tty
reset attempt and settty() -> setctty() encountered an error (which it
reported, triggeting a getret() call). Make the vms code correctly guard
against multiple resets.
Make yellow dragon breath destroy iron bars (unless their wall_info
is marked as non-diggable, which I think is currently impossible for bars).
The shop handling is untested; no shop has iron bars for its walls or
includes them as interior obstacles. (The latter would require changes
to shop repair because lost bars will become solid wall if/when rebuilt.)
Thrown potions of acid and spat or thrown splashes of acid venom
don't affect bars--at least so far--because those always pass through
without hitting. Monsters who have a non-ranged attack which does acidic
damage can't use such attacks against iron bars.
A fairly recent change had a mistake in it which allowed monsters to
throw, shoot, and zap through walls and closed doors if there was at least
one unobstructed spot between the attacker and the wall or door.
From a bug report: if you
attempted to engrave with an empty wand while levitating, it wouldn't use
a turn unless you successfully wrested an extra charge out of the wand.
So you could always get such charge in a single elapsed turn of game time
if you didn't care about zapping in any particular direction; extremely
useful for wishing.
Noticed when checking this: when you did wrest the extra charge,
the engraving code accessed freed memory for the wand after it had been
used up.
Lastly, wands producing certain effects always become discovered,
even when you don't yet know what they look like. (This part of the patch
is trunk-only since it utilizes the routine which fixes similar case for
zapping.)
From a bug report: if you
were at one of the map edges and kicked away from map center while blind,
you'd get impossible("show_glyph: bad pos ..."). That was due to calling
feel_location() for the out of bounds location, which occurred after the
kick code had made use of invalid data so other problems might occur too.
Now you kick "nothing" as if it was something (hence possibly wounding
your leg, taking some damage, potentially dying). I didn't want to try to
classify the surrounding terrain as rock or air or whatever, and the thing
being kicked only shows up if the kick is fatal.
From the newsgroup: if polymorphed into a metallivore, you could eat
artifacts that you couldn't touch with your hands. Now you can't eat ones
which evade your grasp, and you take some damage from other touchy items
on--actually, prior to--the first bite. (Those still "taste delicious" if
you survive; I'm not sure whether this ought to be changed.)
Attempting to loot while suffering from confusion and not on top
of a container will drop gold if hero is carrying some, but it behaved
differently for GOLDOBJ config (gold dropped over a hole or down stairs
always stayed on current level) than for !GOLDOBJ (gold had a chance to
fall to lower level) when done at some location other than a throne.
This makes GOLDOBJ use dropx() instead of dropy(), same as !GOLDOBJ.
And with access to a throne it can be used to repeatedly summon
monsters until they're extinct. This makes it check for confusion before
finding containers, but the chest/exchequer code doesn't always kick in
so can't be attempted as many times before confusion expires, throttling
summoning a little. Also, when placing hero's gold into a chest, it now
clears the contents-known flag and relocks the chest.
Fix a typo in some conditional (NOSAVEONHANGUP) code, and tweak
SAFERHANGUP so that it doesn't defer hangup handling if the game hasn't
started yet or has already finished (it's possible to be waiting for a
--More-- prompt at end of game code before the hangup handler is reset,
so the regular handler could be called in that state). Also, undefine
SAFERHANGUP if NOSAVEONHANGUP is defined, since there's no point in
deferring hangup for the latter.
The last of my intended hangup overhaul. Once hangup is detected,
replace currently loaded windowing routines with stubs that never do any
terminal I/O. Real interface routines call their siblings directly rather
than via the windowprocs pointers, so this shouldn't pull the rug out from
under them, but it also can't prevent whatever they have in progress at
the time of hangup from attempting further I/O once the handler returns.
[We might want to change nhwindows_hangup() into winprocs.hangup_nhwindows()
so that each interface has more control over its own fate.]
This assumes that user input of ESC and menu selection result of -1
everywhere in the core will eventually cause active function calls to
unwind their way back to moveloop() rather than to continually re-prompt.
(This assumption is not a new one, just a bit more explicit now.)
[See cvs log for src/cmd.c for more complete description.]
This turns clearlocks() into a no-op during the period when the UNIX
port is asking the user to confirm whether to overwrite an existing game.
Also, this removes the duplication of code and function between hangup()
and end_of_input(), and it simplifies the check for whether hangups are
supported by adding new macro HANGUPHANDLING. (I don't think global.h is
the best place to be defining that but I couldn't figure out where else
it would fit, other than repeating for individual xxxconf.h files.) And
adds a couple more done_hup checks to try to cope with situations where
rhack() is being bypassed. Lastly, having readchar() return EOF was
ignored for non-UNIX configs; now everybody gets ESC instead of letting
EOF be seen further inside the core.
The previous "hangup cleanup" didn't accomplish much (other than to
give everyone a good view of extern.h). This one achieves more, and also
tries to fix the bug From a bug report:
> Buglet: Destroy old game -prompt can make game unrecoverable
>
> I haven't confirmed this myself, but few people playing on NAO
> have had the following happen:
> 1) play nethack
> 2) your network connection gets cut
> 3) reconnect, and get "Destroy old game" -prompt
> 4) your network connection gets cut, again, before you get to answer 'n'
> 5) game is not recoverable, because the level 0 file is gone.
The reason for #5 is simple to explain; it's the expected behavior of
current hangup() routine (although that hasn't always called clearlocks();
I don't know why it was added). The puzzle is why #2 left any lock files
around in the first place. I suspect it was because SAFERHANGUP defers
until rhack(), and rhack() doesn't get called if the hero is immobilized or
in the midst of a counted operation. I don't know how long a disconnected
process is allowed to run, but I don't think it's forever. (Alternatively,
nethack might be attempting further terminal I/O and getting stuck on the
hung connection; this won't help much if that's the case.)
This turns clearlocks() into a no-op during the period when the UNIX
port is asking the user to confirm whether to overwrite an existing game.
Also, this removes the duplication of code and function between hangup()
and end_of_input(), and it simplifies the check for whether hangups are
supported by adding new macro HANGUPHANDLING. (I don't think global.h is
the best place to be defining that but I couldn't figure out where else
it would fit, other than repeating for individual xxxconf.h files.) And
adds a couple more done_hup checks to try to cope with situations where
rhack() is being bypassed. Lastly, having readchar() return EOF was
ignored for non-UNIX configs; now everybody gets ESC instead of letting
EOF be seen further inside the core.
From the newsgroup: slash'em lychanthrope character could throw
while in wolf form. That came straight from nethack; any animal capable
of manipulating an object--possibly with its mouth--could throw things.
Now hands are required. This doesn't require free hands, although it
probably should; it's kind of tough to imagine making a competent throw
while your hands are stuck to a cursed two-handed weapon.
While looking at a bug report from two months ago about how having
hangup take place while at the "destroy old game?" prompt causes an
interrupted game to become unrecoverable, I decided to try to clean up
convoluted hangup() a bit. Didn't achieve much there, but did notice that
the Unix port was handling SIGXCPU (whatever that is...) inconsistently.
This attempts to fix that, but I have no way to test it.
The original bug report is still unresolved.
makedefs ought to add something for SAFERHANGUP and NOSAVEONHANGUP
to the #version output.
[ This is the missing bit from the patch on Monday which accidentally
included all of extern.h as its log entry message. ]
From a bug report: shopkeeper
wouldn't move to block his doorway if there was a grave at that location.
Nothing supernatural; shopkeeper and temple priest movement was too
specific about what sort of terrain might be present and didn't know that
room floor might be replaced by a grave.
Simplify the insertion into and removal from of gold in inventory for
the !GOLDOBJ configuration. If GOLDOBJ ever becomes unconditional this
will be superfluous, but in the mean time it unclutters the container and
drop code. Also, tweak a recent getobj() hack so that its purpose might
be a bit clearer.
A recent change to force gold in inventory (during multi-item Drop or
applying/looting containers) to have '$' for its inventory letter for the
!GOLDOBJ configuration has revealed a bug which 3.4.3 has for the GOLDOBJ
configuration. Specifying a count followed by '$' to use a subset of
carried gold didn't work under tty; the $ was treated as a group accelator
and overrode the count, so full stack was always used. (The code a few
lines above this which counts the occurrences of group accelators already
includes this same fix: ignore an item's group accelator when it matches
the selector.)
I wouldn't be surprised if other interfaces are subject to the same
problem; since I can't test those I'm not attempting to fix them blindly.
"You carefully open the <container>..." is rather tedious after
you've opened that container multiple times, so omit "carefully" once the
contents and lock-status are both known. (I don't think it's possible
for a container to still be trapped in such circumstances, but even if it
is, you'll now stop being careful....)
"<The container> is empty." becomes "<The container> is now empty."
if it just released Schroedinger's Cat. Do the same if a cursed bag of
holding just destroyed the last of its contents. Also, there's no need
to count the number of items inside a container; that dates to before the
container-and-contents overhaul done for 3.1.0.
And for the loot menu, change "q - do nothing" to "q - done" if some
prior action (prodding the Cat into life or death, loss of any cursed bag
contents, or using ':' to look inside when contents aren't yet known) has
been enough to cause this container access to use up a turn. I haven't
bothered to do the same in the help text for non-menu looting, which seems
like more trouble than it'd be worth.
- force time_t to be 32 bits via Makefile. (If struct u gets changed to not
store a time_t field, this can be removed).
- Latest Windows SDK (supporting Vista) causes a warning due to
a prototype in sys/winnt/nttty. Since we don't actually link with that
function and rely on a DLL find procedure at run time, comment out
the prototype. The function is now officially in the SDK in the
windows header files anyway.
Reduce the number of questions issued when applying or looting a
container, and offer the opportunity to put things inside before taking
things out. Instead of "Do you want to take something out? [:ynq]",
followed by "Do you want to put something in? [ynq]", this gives just one
prompt; the result is similar to menustyle:full where you start out by
choosing between out, in, and both. There are now two additional choices:
reversed, for both in the opposite order, and stash, to put a single item
inside. Prompt phrasing is rather clumsy; I wanted to keep it short:
"Do what with <the container>? [:oibrsq or ?]", where picking '?' pops
up a brief help window. Inappropriate choices (like 'o'and 'b' when
container is empty) are suppressed from the prompt but still acceptable as
input; " or ?" is suppressed if the cmdassist option has been toggled off,
but entering '?' still works to get help.
Menu mode wouldn't allow 'b' when inventory was empty, despite the
fact that first taking things out might change that. Now 'b' is a viable
choice if the container isn't empty, and the new 'r' is a vialble choice
when inventory isn't empty even if the container is.
Some miscellaneous changes preparatory to enhancing the container
interface. This also fixes a minor inconsistency in object manipulation:
askchain() wouldn't let you split a stack of welded weapons but getobj()
would, so you couldn't get rid of part of the stack using 'D' or #loot,
but you could with 'd' (and post-3.4.3, with #adjust). Now getobj() will
behave like askchain(); if you have 3 cursed daggers welded to your hand,
you won't be able to drop 1 or 2 of them anymore.
From the newsgroup: you weren't charged anything if you broke the
lock of a box or chest which was owned by a shop. Force the hero to pay
for the damaged container; any contents remain owned by the shop and don't
affect the cost of the forced purchase. This existing entry in fixes35.0
is adequate to cover the fix:
various actions--such as enchanting--performed on an unpaid shop object
either force the hero to buy the item (when its value is lowered) or
increase the current bill (when its value is raised)
Don't use the phrase "seems to be locked" when you discover that a
container is indeed locked. Also, using an alternate naming routine is
a simpler way to avoid redundant "the empty <container> is empty" than
suppressing the contents-known handling for xname.
Newsgroup posts mention "boulder forts" from time to time, where the
player surrounds the hero with boulders in order to prevent the majority
of monsters from being able to attack. Since the hero can shoot or throw
or zap over/around/through boulders, monsters ought to be able to do so
too. This makes the test for whether a monster is lined up properly for
its ranged attacks try harder when the original line-of-sight check fails.
If there aren't any terrain obstacles found, it allows a chance to attack
based on the number of locations in the path that contain any boulders.
Giants and any monster carrying a boulder-destroying wand of striking get
to ignore boulders, overriding the random chance.
Implement <Someone>'s suggestion/request that co-aligned unicorn not be
used for statue traps, so that the hero won't get hit with a big luck
penalty for killing such a unicorn when the trap releases one which is
hostile. I think that set_malign() probably ought to override that, but
this just changes the monster type selection for the trap's statue.
Also, noticed in adjoining code: avoid counting the template monster
used to generate inventory for the statue towards extinction. It gets
immediately discarded, and later statue activation counts the resulting
monster then.
Someone in the newsgroup claims to have reported this in mid-October,
but he uses a fake address in news and maybe he did so with his mail too,
resulting it not being delivered. Anyway, arming a land mine on the Plane
of Air, then setting it off, produced a pit in the air. This fixes that
directly, in case someone manages to do it again, and it also prevents
land mines and bear traps from being armed in midair in the first place.
Ditto for Plane of Water; water/pool locations were already covered (can't
arm there), and the bubbles ought to be treated similarly to Plane of Air.
When testing this, I managed to get a crash while restoring a saved
game. I had worn a blindfold and armed a land mine on the water level
(with just the no-pit part of the patch in place), then saved. When
restoring, I got a crash in restore_waterlevel() at one or the other of
these lines (traceback pointed at the first, but it has to have actually
been the second; an access violation from an address derived by applying
a small offset to a null pointer):
ebubbles = b;
b->next = (struct bubble *)0;
After that, I couldn't reproduce it with a wished-for trap and couldn't
stay in one place long enough again to successfully arm a trap object.
So there may be a nasty bug still present, perhaps now hidden by no longer
being able to create a new trap on that level.
Thrown boomerangs travelled in a clockwise path, appropriate for
left-handed throwing. But nethack heroes are treated as right-handed by
the weapon wielding and shield wearing code, so make boomerangs travel
counterclockwise instead. Switching is straightforward, in case we ever
implement user-specified or random handedness.
Noticed while testing crysknives; a post-3.4.3 change (not present in
the branch code) introduced a bug that prevented scrolls of enchant weapon
from being used up properly when read.
Make worm teeth and crysknives be stackable. Positively enchanting
a stack of multiple worm teeth produces a single crysknife, negatively
enchanting a stack of multiple crysknives produces a single worm tooth.
A dropped stack of N fixed crysknives has 90% of remaining N crysknives,
10% of becoming a stack of N worm teeth, rather than produce an average
of 0.9*N crysknives and 0.1*N worm teeth. (The code which handles that
transformation operates on loose objects so cannot handle stack splitting
because it wouldn't have any idea of what to do with extra objects.)
Terminate multi-shot volley throwing of boomerangs if one comes back
and isn't caught. The sequence throw-catch-throw-catch is odd, but would
take a substantial amount of code and effort to be changed to the more
intuitive (for rapid volley throwing) throw-throw-catch-catch. Even if
feasible, doing that for underused boomerangs would be a waste of effort.
Reading the comments in the previous patch, I realized that keeping
the old behavior for monsters who are shooting multiple missiles was
leaving an obscure but potentially serious bug. I haven't attempted to
trigger it but 3.4.3 is bound to be vulnerable.
Make all stackable weapons capable of multi-shot volleys when thrown.
Affects knives, spears & javelins, and boomerangs; requires advanced skill
assignment (skilled: 1-2 missiles per throw, expert: 1-3 missiles) or
role-specific bonus (ranger class's general +1 bonus is the only one that
applies to any of these weapon types). For monsters, prince-caste get 1-3
missiles and lord-caste get 1-2, as before, with fake player monsters now
also getting 1-2; those counts apply to all stackable weapons regardless
of whether the species or role ordinarily uses whatever is being thrown.
Related changes: monks now get a role-based +1 count for shuriken,
throwing 1-2 instead of just one (they're only allowed to achieve basic
skill so won't reach any higher volley count). Monster monks and ninjas
get that too; ninjas now get the same for darts and they're guaranteed
weapons in starting inventory. Also, fake player rogues now sometimes
get orcish daggers instead of short sword, providing a decent chance to
occasionally have Grimtooth be randomly generated on the Astral level.
Potentially controversial: wizards can still become expert in dagger
skill and receive the to-hit and damage bonuses for that when throwing as
well as when wielding, but the number of missiles for them has now been
reduced to 1-2 (in other words, going from skilled to expert no longer
improves the max count for the volley amount for wizard role). They're
supposed to be spellcasters; being able to throw up to three +7 daggers
at a pop was a big temptation for resorting to brute force, particularly
since they'll already want highest dagger skill for wielding Magicbane.
To do: throwing multiple boomerangs either needs to behave as if
they're all in flight before the first returns, or else the volley needs
to be cut short if one comes back and isn't successfully caught. The
latter is a lot easier to do but the former fits better with what multi-
shot volley is supposed to represent. Another alternative is to change
them to no longer be stackable, then this sequencing issue goes away.
To do too: make worm teeth and crysknives become stackable like the
other knife-skill weapons.
A suggestion from the newsgroup: when potions are hit by fire and
get the "boil and explode" result, potions of oil should burn instead of
boil. Even though oil can be heated to boiling, nethack's potions of oil
are noticeably flammable [just (a)pply one...] so having them burn makes
sense. It's just a message change; no actual explosion has been added.
destroy_strings[] was implemented as an {N} x {3} array that used
manually computed indices into one-dimension. This changes it into a two-
dimensional array instead. However, it's still being indexed by a bunch
of magic numbers.
Refine a recent change: Moloch should only have a chance to blast
you for offering the Amulet at an ordinary altar (instead of high altar)
when you're still in Gehennom (Orcus' Level or Valley of the Dead), not at
the unaligned altars in a couple of quests.
