Based on a bug report from beta testers in 2010. mintrap()
already had partial checks for this (now fire vortex also burns
a web, as per suggestion in the bug report) but mfndpos()
lacked checks so mintrap() code was almost never exercised.
read_config_file() has used a buffer of size (4 * BUFSZ) since 3.4.x
so parse_config_line() needs a buffer of the same size to avoid
buffer overrun. Allows my old .nethackrc to work again.
<Someone> reported that being killed by a monster with a long name
can result in nethack going into an infinte loop printing spaces. Handle
this by detecting attempts to wrap the topten output on a word that is too
long and just inserting breaks in the middle of the word in this case.
I did some research, and technically, a jellyfish does indeed have no head
(and, technically, no brain, just a "nerve net"). The part on top is a
"bell" used for buoyancy, not a head.
<email deleted> reported back on 8/31/06 that elven weapons were not
affected when he poked a fire elemental with them. This is true, but
moreover, there was no code to have passive fire to affect attackers.
Now erode_obj() supports all the same damage types as rust_dmg(), and added
the connecting code to allow passive fire attacks do something.
There probably should be macros for the damage types used by rust_dmg
and erode_obj, and possibly these functions should be combined, but they
are slightly different and dealing with that requires more thought.
Qt windowport crashed on startup because a couple alloc() calls in files.c
were not zero'ing out the memory afterward. This resulted in uninit'd
memory access if there were no saved games. This bug is in new dev code.
From a bug report, if you polymorph into
something, like a killer bee, that causes you to drop your weapon, but the
weapon is a wielded, in-use leash, the leash would be dropped but retain
it's in-use state. However, the leash was tied to you, so it seems it
should remain attached, just unwielded, just as it would if it hadn't been
wielded. I've changed the behavior to do this. I wonder whether one
should be able to wield an in-use leash.
One from the way-back machine. A nurse would hit you-as-cockatrice repeatedly
and never turned to stone. With this change, nurses will turn to stone (and
also don't heal cockatrices, which seems fair). I considered giving them
gloves, but that seemed like too much effort. There are other cases where a
monster "hits" but will not petrify. However, it doesn't seem like passiveum
detects all the specific ways the monster "hit" you so I left them alone.
<Someone> pointed out that bugles, although noisy, only affect soldiers.
This didn't make sense to me either. Added code so they will also affect
monsters near the bugler.
Recently reported to the list, a fireproof container dropped in lava would
catch fire and burn. Add the missing check; this looks an oversight when
the idea of fireproof was added, since other fireproof objects get handled
later in the cascading if().
<Someone> reported the longstanding behavior that when dragging, the chain
does not always remain directly between the player and the ball. This occurs
when the player zigzags. Added a check to the simple drag code to try to
keep the chain directly between the player and the ball. But, don't do this
if the player is walking thru rock or if it would move the chain into rock.
Pat recently forwarded a discussion that Elbereth was ignored unless there
was an object on its location. Mostly. It was also respected if the hero
was Displaced, no matter where the hero was. No one commented on his
message, which I took for assent to address this. Removed the qualifiers, so
now Elbereth is always respected, just like a scroll of scare monster.
<Someone> noticed that when a monster escaped upladder in the wizard
tower, it ended up outside the tower. This is due to the "wander" code in
monster migration. Rather than add code to try to keep the monster from
crossing the undiggable wall, just add REGIONs on the tower levels within the
area, which then utilizes the existing in-a-room constraint behavior of
monster migration. Of course, one can still fill a tower level with fodder,
and then when another monster climbs the ladder, it will still end up
outside the tower.
stinking clouds extend their timers, causing the "ttl == 0" check in
visible_region_at to be inappropriate; technically it was never quite
right, since the ttl is set to 0 one turn before removal is considered. But
with the Eyes on, this caused a visible change in the region although the
region still existed. Introduced a new -2L value to designate that the
region is being removed (-1L means it's permanent), which is what
visible_region_at was really trying to test.
- the cause of of the odd "~" with DECgraphics appears to have been caused
by the Is_rogue_level(&u.uz) tests occurring before rogue_level was
initialized. Perhaps there's a better way to deal with this than what I did?
- tile2x11 would not build because drawing.c now depended on strcmpi which
was (via STRNCMPI not being defined) defined to strncmpi which is
implemented in hacklib.c which needs panic which is defined in... I gave up
on tracking down all the loose ends and changed the strcmpi to strcmp,
which means the handling is case sensitive, but it avoids a bunch of
changes to the way the util/Makefile.
- the symhandling changes introduced a chicken and the egg problem for
ASCIIGRAPH on Unix platforms, which was getting the defn from tcap.h but
that does not get included earlier enough nor often enough. I added a defn
to unixconf.h to mimic ntconf.h, since ASCIIGRAPH is normally defined on Unix.
- options.c included an unused decl for a function named graphics_opts
- Unix Makefile was not installing "symbols". I'm assuming this isn't
supposed to get the DLB treatment.
> Michael Allison wrote:
> There are unresolved functions in the trunk if you build without WIZARD
> defined and attempt to link:
Also to a lesser extent, in the 3.4.4 branch.
some rather complex boolean operations needed more parentheses to avoid
warnings. I think I put them in the right places.
A couple other items: naked assignments in if stmts, and an extra function decl
Normal maze levels are initialized from x == 3 thru COLNO-1. However,
levels that use the INIT_MAP spec go thru mkmap, which initializes the level
starting at x == 1. This usually makes no difference, but does in the case
of levels that also use GEOMETRY:left. This was the case with the Ranger
start level and caused the leftmost 2 locations to be room locations but
unreachable. The Juiblex level actually had the same behavior, but this
was harmless because the MAP in that case was smaller.
Fix is to set the xstart=1 for levels with INIT_MAP and GEOMETRY:left.
The rest of sp_lev works just with this (when INIT_MAP was used, that is).
Submitted by <Someone> 12/3/05. player poly'd as guardian naga produced a
different attack than a real guardian naga. The fix causes an algorithm
similar to that used in spitmnu to be used in dospit.
Only 5 months old. The Unix code to find saved games, currently only enabled
for Qt use, fails to use fqname and SAVEPREFIX, so it doesn't find saved
games when prefixes are in effect.
First reported 12/13/2003, I think, but my archives contain more recent reports
too. Special level specs like NON_PASSWALL and NON_DIGGABLE only apply
to the map sections for which they are specified. So, on special levels of
Sokobon, the large surrounding area is stone, but have no special flags set.
So, it was possible to teleport a Xorn and have it appear in this outer area.
Addressed this by checking the perimeter of the map(s) and if all are
nondiggable and nonpassable, propagate this to the surrounding stone.
This appears to be the intent on such levels, so there is no need to
force the affected special levels to explicitly specify this.
Combo fix based on several reports and additional research.
In quest.txt and/or data.base, the Grand Master, Arch Priest, Ixoth, Master
Kaen, Nalzok, Scorpius, and the Master Assassin are all referred to as male
via reference: his or him. Ideally, there would be a way to parameterize
this in the quest.txt, but I don't see a clear way to do that at this time.
For the time being at least, set the M2_MALE flag for these monsters.
The Dark One was referred to via "his" once in the quest.txt. This case
I was able to modify the offending text rather than forcing a gender.
Orion and Norn are referred to as a giant in data.base but their size did
not correspond. I left the symbol as S_HUMAN although perhaps it should
be S_GIANT. Finally, Orion, the Norn, Cyclops and Lord Surtur, as
giant-types, should be able to tear webs.
I noticed this a while back while inspecting an unrelated report.
It seems to me the breath of a dragon is more like broiling than baking
and thought the message wasn't consistent with this.
From a bug report. <Someone> as slashem-Bugs-883643 on 1/24/2004. To avoid
using the possibly invalid object pointer after calling bhit(), changed as
suggested to add another level of indirection allowing bhit to null the
object pointer before returning. Callers that are affected update their
object pointers after bhit returns.
While wearing EotO, ";" and selecting a monster behind a wall would display
"normal vision" as well as "astral vision". This is because cansee() gets
set for things seen via astral vision. However, couldsee() is only set for
things that could be seen normally, so check both values.
From a bug report, it is possible for the hero to
appear embedded in the wall after destroying the drawbridge. This is because
The variable "lev1", which was the entity's location, was being referenced
after e_died, but e_died can change the entity's location. So, as <Someone>
suggested, refer to the current location directly.
While auditing nomul() I noticed unconscious() treats (multi < 0 && !nomovemsg)
as unconscious. This explains the behavior in M29 (unconscious message
while performing #turn). I checked all the places with this combination,
and found a few that did not appear to fall under the "unconscious" category.
Most I changed to use You_can_move_again to ensure the same display w/o the
unconscious behavior. Also:
- found another string that unconscious() should have considered
- vomit() now sets nomovemsg, one caller was also doing this redundantly
- vomiting_dialogue() was calling stop_occupation() after vomit(), which can
reset multi. I reversed the order and removed a doubly-redundant nomul call.
tele() still has a problem: some cases where multi < 0 should probably take
a branch like the unconscious() branch but with a different message.
doturn()'s behavior - turn then wait - is also less than perfect, but I
think this is a known problem.
Finally apply the patch sent by <Someone> in 11/2003 for slashem-Bugs-799278,
updated to match the current code and handle additional cases. The fix
is brute force: always ensure nomovemsg is set when nomul is called with
a negative value. I also scanned the code for places manually setting
multi negative, they all set nomovemsg. It would be nice to have a function
that did the right thing, but there are several special cases and I was
not feeling creative.
<Someone> reported: You kill it! A potion of invisibility shatters!
Change the rule in hero_breaks() to avoid giving info for things out of
sight, except when from_invent is set, to preserve desired behavior.
Several places were not using safe_qbuf or anything equivalent to avoid
overflowing a QBUFSZ buffer. Add more uses plus one special case. For
the current max lengths returned by xname(), I think this is
sufficient. This addresses a reported buffer overflow for a
"thoroughly rusty thoroughly corroded helm of opposite alignment", plus more.
As From a bug report, twice. Change max_passive_dmg to multiply the
result by the number of direct attacks the aggressor can make. This way, a
tame mind flayer, for example, will avoid pounding on a spotted jelly and
dying as a result of the Nth passive response.
As reported, you'd get the "float gently to the ground" message even while
riding a flying steed. Rearranged the code and added a new case for this.
I found it odd that Hallucination protected you from falling out of the
saddle due to the Sokoban air currents. The message implied otherwise, so
I've made the sokoban_trap code apply in both cases.
<Someone> reported that if you polymorph into a flying monster while in a
pit, you must take u.utrap turns to first climb out before you can fly. Of
course, once you're out, you can swoop down into the pit to pick things up
w/o delay. Rather that have you automatically fly out (e.g. like quaffing
a potion of levitation), I thought it was better to take a turn to fly out,
so that's what I've implemented.
The code to deal with exiting a pit is moved to a new climb_pit function
and the "up" command now lets you climb from a pit too (something I've
found non-intuitive in the past).
Finally, I noticed that non-moving monsters could still go up/down even
though they couldn't move around. Added non-moving checks in doup/dodown.
move the message so it's before the mintrap test. newsym's are needed
to ensure the display is correct if a --More-- prompt results. I left the
"frighten" message alone, except for tense. As per Pat's suggestion, I
changed the wording to future-proof the message.
I found I was no longer able to start "nethack", I think due to the change
in the save file structure. But, it looks like the Unix-specific check in
bufon() was never quite correct. I'd have to guess we've been lucky up
until now.
<Someone>, I think, noticed there was no copyright on the window.doc.
Add one. I don't recall when I originally wrote it, but I last changed
it in 2003, so that's the year I'm putting in. Anyone else that wants to
share the blame, please add your name and update the year as needed.
This is a followup to the patch I made a couple months ago. It replaces
the "!Levitation && !u.uswallow" checks with can_reach_floor(), which
makes a more complete set of checks and is more consistent. I applied
this to fountains too. I doubt that fountains hit the ceiling, and the
checks also seem reasonable for heights in between (e.g. while mounted).
The same occurred for fountains and drinking surrounding water while
underwater.
I also added a !Levitation check for sinks, like already exists for
fountains. I cannot believe sinks are taller than an altar, and if you
can't pick up stuff from an alter while levitation, it stands to reason you
cannot drink from a sink then either.
Patch was sent in by <Someone> on Sep 8:
This bug causes a number of impossible messages (starting with splitbill:
no resident shopkeeper??)
Repeat by:
Enter a large shop.
Wish for a large stack of projectiles.
Sell your projectiles and then pick them up again.
Trap shopkeeper against the door with a scroll of earth.
Throw the projectiles at the shopkeeper to anger him.
Move away from the boulder trap and wait for the shopkeeper to leave the
shop.
Throw one of the projectiles at the free space.
This isn't really a bug, but I find it does make the map scrolling in
the generic X11 version a lot less distracting. The original behavior
produces certain boundaries where, when the cursor moves back and forth
across that boundary, the map scrolls with each crossing. This is
particularly annoying in places like Sokoban where the player makes that
kind of movement frequently causing large jumps of the map each time.
Changing the border and delta constants in winmap.c as below eliminates
that behavior, as well as making the cursor easier to track by tending
to recenter it whenever the map shifts.
It appears that the Athena text widget in recent XFree86 distributions
does not properly honor the XawtextScrollWhenNeeded flag, so the text
widget created by X11_display_file() does not have a vertical scroll bar
when the text does not entirely fit in the window. I have seen this bug
in XFree86 versions from 4.0.2 through 4.3.0. Using XawtextScrollAlways
for the vertical scrollbar ensures it will always appear.
Play a character without see invisible. Wear speed boots. Generate a troll.
Zap it with a wand of make invisible. Kill it. Stand on the same square and
wait for it to rise from the dead. It will appear as a 'T'. Hitting it then
produces the normal "Wait, there's something here you can't see!"
[ incorporate slashem-Bugs-951439 fix ]
While trying in vain to find code that would cause the reported
priest-on-players-location behavior, I did find that the code to find
a usable teleport or similar trap was disallowing lots of locations due to
an && that should have been an ||.
The previous change only affected mimics that started mimicing after the
level was created. This change tries to perform a similar behavior for
randomly placed mimics that are forced to mimic a boulder on special levels.
In this case, since the symbol is fixed and the location is "random", try
several times to find a non-trap location for such a mimic.
On mazelike levels, mimics will mimic either boulders or statues (of giant
ants, as it turns out). However, it does not make sense to mimic a boulder
on a hole or even a pit, since boulders would typically fall in. Also,
statues are not typical objects in Sokoban. So, skip statue special case
in Sokoban and always avoid the forced emulation of a boulder when on a
trap location outside a room. This is a bit drastic, but I couldn't think of
an argument for adding the code to do this only for pits, holes, et al,
which are the most likely traps outside rooms anyway.
Since the rogue level does not have closed doors, mimicking one there makes
no sense. Similar to what wand of locking does there, make mimics that end
up there mimic a wall instead of a door.
There was already code to ensure that if a hidden monster moved, it would
no longer be hidden. However, if the monster is asleep or whatever under
a rotting corpse, when the corpse rotted away, the monster would not
immediately become detected. Add a check to the rot code before the newsym.
Attempting to go > while blind and floating over unknown stairs/ladder
would refer to the stairs in the "high above" message (however, the
stairs/ladder remained unidentified on the map). Change this case so
it only refers to stairs/ladder if that's what the hero remembers on the map.
If you kick something while in the air (i.e. on the Air level or while
in a bubble on the water level), 1) greased objects were treated specially
and 2) messages were given about the object sliding.
- add checks for kicking in the air, and always increased distance a bit
(I didn't add any checks to deal with the transition from air to water or
visa versa)
- don't set the flag that causes the "slides" message in these cases either
This patch simply keeps the score from wrapping by capping it at LONG_MAX.
If someone wants to change the score to be unsigned, some changes will
need to be made to tweak this code (and use ULONG_MAX instead).
I'm assuming that our platforms all have limits.h.
David Cohrs