Saving the game while punished, not carrying the attached ball,
and while swallowed by a purple worm resulted in losing the
ball and chain.
Since the required information was not being written to the
save file at all, I couldn't come up with a clean way to do this
for the branch, and preserve save file format. I could think
of lots of kludgy ways to do it (insert ball and chain into
the hero's inventory prior to saving, and remove it on restore, etc.)
Saving the game while punished, not carrying the attached ball,
and while swallowed by a purple worm resulted in losing the
ball and chain.
Since the required information was not being written to the
save file at all, I couldn't come up with a clean way to do this
for the branch, and preserve save file format. I could think
of lots of kludgy ways to do it (insert ball and chain into
the hero's inventory prior to saving, and remove it on restore, etc.)
When testing the spoteffects/drown hack I noticed that draining myself
with Stormbringer (toss up, get hit on head) while in iron golem form gave
messages about it drawing or draining life. (I'm sure that this has come
up before....) I've altered the artifact hit message rather than making
golems become resistant, although the opposite approach seems at least as
valid. The drain life spell uses different wording and isn't affected.
Attempt to fix a buglist item: if hero poly'd into iron golem form
enters a pool of water and drowning triggers reversion to human/whatever
form due to water damage, he will fall into that pool again, crawl or
teleport out, then redundantly crawl or teleport out for the initial entry.
[ spoteffects -> drown -> losehp -> rehumanize -> polyman -> spoteffects
-> drown ]
I don't have a lot of confidence in this fix. It does handle the
reported problem, and hasn't broken a couple of earlier tricky cases
(ice melting to water, land mine turning into a pit). But drown() and
lava_effects() seem to leave a trail of special case handling wherever
they appear so they--or spoteffects, or both--ought to be redone somehow.
I can't find the report about this; I must have deleted it after
reading, or else recently reread something so old that I'm not going back
far enough now. When you perform the invocation ritual to create the
stairs down to Moloch's Sanctum, any trap at your location gets deleted.
But if you were in a trapped state at the time then you got left in that
state. Descending stairs doesn't check for traps so you wouldn't notice
unless you tried to move around on the same level first. Then you'd get
"you're stuck in a pit/beartrap/web" even though it wasn't there anymore.
While testing the hiding vs traps patch, I became a mimic and hid.
It gets stuck to you.
Huh? Nothing was visible; nothing became visible (aside from the ']' at my
position changing back to 'm'). Display the invisible monster glyph when
an unseen monster bumps into you while you're hiding or mimicking gold.
That's usually handled by the hit and miss routines, but they aren't used
when you're just brought out of hiding instead of attacked.
From a bug report, the game gave feedback
about a monster becoming stuck in a web but there seemed to be no monster
around because it immediately began hiding under an object at the web's
location. Prevent monsters--or poly'd hero--from hiding when trapped in
anything other than a pit or spiked pit. Also, prevent them from hiding if
they're holding you or you're poly'd and holding them. I'm not sure whether
either of those cases ever actually happened but big mimics are capable of
both hiding and grabbing on.
Fix the problem From a bug report, where
giving a temple donation of the appropriate amount would fail to restore
protection previously stolen by gremlin attack iff the old protection amount
was big enough that the donation wouldn't have yielded a bonus in the normal
not-stolen case. It shouldn't be checking the magnitude of u.ublessed at a
time when lack of the intrinsic renders that value inoperative. After this
fix, the lost intrinsic will be granted and the old protection value will
be restored, same as happens when a prayer boon yields divine protection
(where no u.ublessed magnitude check is made) and as happened with donations
when the old protection was a more modest amount (magnitude test passed).
Yesterday's change to have enlightenment give "you have a <small,
moderate,&> defense bonus" instead of "you are protected" would yield
"you have a small defense penalty" if the combined protection value (from
rings, divine gift, and spell) was 0. This changes the formatting routine
to give "you have no defense bonus" in that situation, then changes the
caller to only display the protection/defense attribute when non-zero so
the "no bonus" case will never actually happen.
The bug report about losing/regaining the Protection intrinsic reminded
me of a couple of things. First, as an intrinsic, Protection seems to be
completely useless and we ought to redo it. Second, periodically people in
the newsgroup have complained about how it's nearly impossible to figure
out the important--possibly crucial--armor attribute of magic cancellation.
Wearing a cloak greatly increases characters' survival rates, but beyond
that, magic cancellation is just spoiler fodder.
This doesn't do much about Protection other than to change "you are
protected" into "you have a <small,moderate,&c> defense bonus" similar to
how the attributes conferred by rings of increase damage and increase
accuracy are handled. For magic cancellation, it adds new feedback:
You are protected. -- mc factor 3
You are guarded. -- mc factor 2
You are warded. -- mc factor 1
(with no extra feedback for mc factor 0, the normal naked state. The mc 3
case might cause some confusion over the changed meaning of a previously
existing item, but I think it'll be ok and not need re-wording.)
From a bug report, specifying role and race
along with invalid alignment for that role/race combination resulted in a
prompt of "pick the alignment of your chaotic human Valkyrie". This fixes
that particular problem, but the role selection code is incomprehensible
and I don't have a lot of confidence about whether other combinations have
similar trouble.
This also fixes an obvious typo in ok_align(). Unfortunately I can't
figure out what to do with the if-then-else block in root_plselection_prompt
which has identical code for its `then' and `else' halves (in the alignment
code that the new ok_align() test skips).
From a bug report, monsters with the wait
strategy (described as "meditating" by stethoscope probing) could be
affected by music but left meditating. Various wake up attempts shared
the same situation. Finish waiting if the monster would have been woken
(or pacified). I didn't search for places that diddle the msleeping bit
directly instead of calling one of the assorted wake() routines.
A fair bit of this is making usage of DEADMONSTER() be consistent.
Sooner or later there'll be another monster movement overhaul and those
if (DEADMONSTER(mon)) continue;
statements will all go away. (Probably just wishful thinking.)
When high priests have their affiliation suppressed to avoid giving
away which altar is which on the Astral level, the name formatting also
bypasses the code that converts "priest" into "priestess" for females.
(The bug report was about Moloch's high priestess; the occupant of the
Sanctum's temple gets similar handling to those on Astral.)
Also a tidbit for a change made a couple of days ago. Avoid using
"Manlobbi the invisible shopkeeper" or "Asidonhopo the newt" in the message
given when a shk refuses an attempt to be renamed via the 'C' command.
From a bug report, the 'C' command wasn't reporting that
"<shopkeeper> doesn't like being called names" even though the user's
supplied name was ineffective. Same thing for temple priests and other
minion monsters; the name was accepted but didn't do anything. Make such
monsters reject new names.
Fix a bug described in the slash'em bugs page at Sourceforge. When
attributes are undergoing adjustment (from drinking a potion of gain
ability, for instance), don't display "you feel wise" or "you feel weak"
messages if worn equipment is keeping the relevant attribute at some point
below max or above min and the current value doesn't actually change.
The old logic just checked whether you were at max or min and assumed that
when not, the value would be changing. Now it checks whether the value
actually did change. But it doesn't intercept attempts to go over max or
under min at the same point any more; I hope it hasn't introduced any new
bugs in the process.
Add a patch attached to one of the bug reports sent by <email deleted>
which prevents shopkeepers who have been polymorphed into animals from
speaking. Some messages are altered so that the player gets informed about
shop interactions without it seeming to be spoken by the shk, other messages
are suppressed outright. I cleaned it up a bit (mostly formatting, but the
``getcad'' section seemed to have a logic error--using goto to jump into
the middle of an if-then-else is evil...) and implemented a TODO comment he
added (to use mbodypart() when second shopkeeper at end of game shakes his
head; also, skip that phrase if shk is in headless form--futility while
attempting to test this led to discovery of the misplaced parenthesis bug).
Fix something I accidentally broke nearly three years ago (post 3.4.2,
so the bug appeared in 3.4.3). A misplaced closing parenthesis caused an
in-sight check to always fail, so the "<shk> looks at your corpse, shakes
his head, and sighs" message when game ends would never occur. That
situation is extremely rare anyway; it only happens after some other shk
has taken the hero's possessions.
<email deleted> wrote:
> While levitating, I put on an unknown pair of boots. They turned out to be
> elven boots. I received the message, "You finish your dressing maneuver. You
> walk very quietly." Incidentally, I was hallucinating at the time.
>
> It seems to me that levitating individuals shouldn't be able to tell that they
> walk quietly.
Add the capability of sorting the entire spellbook by various criteria,
augmenting the existing ability to swap pairs of spells. In the menu that's
put up for the '+' command, add a non-spell entry after the last known spell
+ - [sort spells]
Selecting that brings up a new menu
View known spells list sorted
a + by casting letter
b - alphabetically
c - by level, low to high
d - by level, high to low
e - by skill group, alphabetized within each group
f - by skill group, low to high level within group
g - by skill group, high to low level within group
h - maintain current ordering
z - reassign casting letters to retain current order
'a' corresponds to the normal ordering; 'b' through 'g' cause the order
to change, but during the current invocation of the '+' command only.
(Entry 'h' is a no-op, something aside from ESC to get out without doing
anything. 'a' is only a no-op if you haven't picked any of 'b' through
'g' yet.) After making a choice, you're taken back to the '+' command to
view the spells in the requested order. And once back there, you can pick
'+' again to come back to this menu, where picking 'z' will cause casting
letters to be shuffled such that present display order becomes the actual
spellbook order. Newly learned spells get appended to the end as usual;
the most recent sorting order isn't sticky even if finished off with 'z'.
No doubt seeing it in action will be clearer than this description.
This also updates the Guidebook to mention the spell retention field added
to the '+' menu some weeks back.
When the hero receives the quest artifact "got it" message, set the
artifact's dknown bit in case the hero is blinded. That message describes
the object by name, effectively the same as seeing it up close. (This
would have prevented the "now wearing an Eyes of the Overworld" grammar bug
for monks but not for non-monks, so the previous fix is still necessary.)
Putting on the Eyes while blind causes sight to be regained, which in
turn causes xname() to set the dknown bit and start using the previously
unseen object's name. But obj_is_pname() was being called before xname in
the "you are now wearing ..." message, while dknown was still clear. So
obj_is_pname thought the name was being suppressed and returned false,
resulting in "an Eyes" instead of "the Eyes". Fix is to call xname first.
Be deliberately careful with copies taken of
oextra pointers and clear the pointer if it
truly is a redundant copy that will become
invalid if/when the original holder is deallocated.
This patch by <email deleted> was released
when 3.4.1 was current and has been incorporated into slash'em. It is
extremely useful while using ranged weapons. When both autopickup and
pickup_thrown are enabled, walking across previously thrown objects will
pick them up even if they don't match the current pickup_types list.
[See cvs log for patchlevel.h for longer description.]
The code to have Izchak recognize the Candelabrum of Invocation
instead of just being uninterested in an item not stocked in his shop was
being skipped when the character is hallucinating. Make it work for any
lighting store (slash'em sometimes has another candle shop, run by a
randomly named shopkeeper), and make it recogize Izchak even when
hallucinating. Also, have him give a message about the need for 7 candles
if the candelabrum doesn't already have them attached.
Fix the bug From a bug report.alt.org server, where killing a monster by closing the
castle drawbridge resulted in a panic after the dead monster's possessions
were dropped into the moat and a potion of acid exploded in the process.
water_damage() deleted the object but had no way to tell flooreffects()
that it was gone, so flooreffects() couldn't tell its own caller not to
place and stack the object. After that, a chunk of freed memory became
part of the floor objects chain and eventually triggered a panic which
tried to make a save file but whose reason didn't get logged properly.
<email deleted> wrote:
> * You can't sell a candelabrum (with candles attached) to a lighting store.
You still can't sell the candelabrum after this, but acknowledge
the situation by having Izchak say something unique.
Provide a common routine that always does the right
thing with respect to timers and weight when altering
obj->corpsenm, and use it throughout the code.
From a bug report.c was first creating a corpse
complete with revive timer if it was a troll, or without
a timer if it was a lizard or lichen corpse. Then it might
change the corpse type, leaving strange corpse
types that revived, or that lasted forever.
I've forgotten who pointed this out recently, but the hero was having
wisdom exercized (if true rumor chosen) or abused (for false one) whenever
level creation made a random floor engraving which used a rumor for its text.
To fix the gibberish rumor observed by at least a couple of players on
Windows (where if rumors.tru had <cr><lf> line ends and DLB was defined,
makedefs built a file that caused nethack to end up in the wrong place when
it reached EOF and tried to jump back to the first false rumor), change
the way that makedefs builds the rumors file. It now will collect more
information about the true and false rumors. Instead of one hex value on
the second line, there are nine values (three groups of three).
1,2,3;4,5,6;7,8,9
1 = number of true rumors; not previously collected and not currently used
2 = size in bytes for all true rumors (in decimal, as is #1)
3 = offset to first true rumor (in hexadecimal; not previously collected)
4,5,6 = same as 1,2,3 but for the false rumors section
7,8 = always 0 (imaginary third section has no entries, no size)
9 = offset to end-of-file (could be used for sanity checks; currently isn't)
Adding #2 with #3 yields #6; adding #5 with #6 yields #9. The old format's
lone entry was the same as the new format's #6. #2, #3, and #5 are values
which nethack was previously calculating on the fly after opening the file.
This also extends rumor_check() a little bit (displays the last rumor
for both sections in addition to the first), but I think it can probably
now be demoted to ``#if 0'' and removed from the extended commands list.
Provide a command to easily verify that the rumor true/false
boundary offsets are correct for the rumors file.
If the boundary is pointing mid-line, the rumor at the boundary
won't decrypt properly.
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
Axes can't dig through the floor, but attempting to dig down with one
shouldn't just "scratch the floor" if there is an armed land mine present.
Have it set off a land mine or bear trap, in addition to the possibility
of chopping your way out of being stuck in a bear trap (a recent change).
Add Hojita Discordia's Dungeon Map overview as
conditional code for experimentation and testing.
Everything is guarded by
#ifdef DUNGEON_OVERVIEW
#endif
The notes that accompanied the original patch follow.
Dungeon Map Overview Patch for Nethack 3.4.3
Version 3
=============================================================================
Changelist:
v3: Changed #level to #annotate to avoid #levelchange collision. Fixed
handling of elemental planes and astral plane (oops). Changed
formatting to be slightly closer to print_dungeon()'s. Should be
"final" version for 3.4.3.
v2: Added tracking of trees. Changed ctrl-m command to ctrl-o. Portals
displayed as "sealed" instead of "closed".
v1: First release.
(Note: all versions are mutually save compatible.)
=============================================================================
This patch creates a dungeon map overview that is recorded as the player
explores the dungeon. I was tired of returning to a game a few days later
and having no idea what the dungeon looked like. Trying to name pieces
of armor with shorthand didn't work so well as an intermediate solution
either, especially around nymphs.
It can be assumed that this map is in the mind of the hero and thus
can't be stolen, can be read when blind, or when buried, or when the hero
doesn't have any hands, or eyes, or hands free, or...etc. On the other hand,
this implies that the hero doesn't remember all of the details ("a fountain",
"some fountains", "many fountains") and that the map is subject to amnesia
when applicable.
This overview tracks fountains, altars, stores, temples, sinks, thrones,
trees, and dungeon branches. It attempts to not spoil the player nor
reveal more information than the hero knows. For this reason, it only
tracks dungeon features found in the guidebook and dungeon branches.
This patch breaks save file compatibility. Sorry.
Added commands
=============================================================================
#overview (ctrl-o, if not in wizard mode) - displays overview
#annotate (ctrl-n, if using numpad) - names current level
Example Output From #overview
=============================================================================
The Dungeons of Doom: levels 1 to level 15
Level 1:
A fountain
Level 3: (My stash.)
An altar, some fountains
Stairs down to The Gnomish Mines
Level 7:
Many fountains
Level 8:
Stairs up to Sokoban, level 7
Level 15:
A general store
Sealed portal to The Quest
The Gnomish Mines: levels 4 to level 7
Level 7: <- You are here
Many stores, some fountains, a temple
More Details
=============================================================================
The overview shows only levels that have anything interesting to display and
doesn't show branches that don't have any interesting levels.
To avoid the map revealing more information than the hero knows, the overview
only displays things that the hero has seen or touched. (If the hero
blinds herself, levitates above a known fountain, and obliterates it with a
wand of digging, the overview will still say that there is a fountain.)
This is done, sadly, by adding 6 bits to the rm struct to track the last
known dungeon type. On the other hand, this change could potentially allow
a window port to do something like drawing an item and a fountain on the same
square.
Things That Could Be Better And Maybe Some Feedback Would Help
=============================================================================
"<- You Are Here" is pretty goofy
-...but an indicator of some sort is nice.
=============================================================================
Many thanks to all the kind folks on r.g.r.n. who had very good feedback
about this patch, in particular L (for the trees), <Someone> Papaganou (for the
#annotate suggestion and some formatting feedback), and <Someone> (for the suggestion
of just overriding ctrl-o instead of using the very broken ctrl-m.)
=============================================================================
20060311. Hojita Discordia. (My usenet email is bogus. Sorry.)
From a bug report, a steed hit by disintegration
breath survived via life-saving, but the program was confused about whether
the hero could still ride and issued some impossible warnings. The code
to disintegrate a monster's inventory didn't bother to unwear worn items as
it destroyed them, presumeably assuming that the monster was sure to die,
so steed was left with a flag bit set claiming it was saddled even though
the saddle was gone. This fixes that, and the rider will end up being
dismounted as the saddle gets destroyed, regardless of whether the steed
ultimately survives. [Since the steed is still present at the time of
dismounting, the hero will get bumped to some other location, possibly to
the next spot about to be hit by the same black dragon breath attack which
just vaporized the steed. That's suboptimal, to put it mildly....]
I couldn't test the circumstances of the original report. Post-3.4.3,
ki-rin has been marked no-hands and is no longer capable of wearing armor
or amulets. I looked to see whether any other potential steed could wear
an amulet of life-saving and couldn't find one. But the original bug also
applied to conferred properties of special armor worn by non-steed monsters
too, so the fix was needed anyway.
The branch and trunk patches are different. For the trunk, I moved a
big chunk of code out of buzz() into a seperate routine. That actual fix
is the same in both variants.
Move part of the recent "munstone fixes" patch to the branch code
since one of those fixes prevents accessing freed memory. The part that
lets monsters eat tins of lizard meat or tins of acidic monsters in order
to get the same benefit as the corresponding corpse has been left out.
There were routines that were passed the
object name as an argument. Before the oextra
patch, ONAME() always returned a valid pointer
to a location within the obj struct. The oextra
patch worked around those cases by
using a temporary variable that was either set
to ONAME (if the obj passed the has_oname() test),
or to "" (pointer to an empty string) if no name was
present.
Since that might be a common thing to do, provide
the safe_oname() routine that you can use as a
function parameter without having to worry about
about whether ONAME(obj) is valid, and without
the need for the temporary variable.
It seemed inappropriate to allocate and tack on an oextra
structure just to mark it as unmergable, and the oextra
struct itself wouldn't be released until a save/restore took
place.
This uses one of the freed up oattached bits to prevent the merge.
