Have being crowned Hand of Elbereth/Envoy of Balance/Glory of Arioch
give a minor extra benefit beyond resistances and an artifact and maybe
unlocking the artifact's skill: one extra skill credit, making it
feasible to earn 30 rather than 29. (Previously the only way to get any
was to receive one for each new experience level, so you could gain one
29 times when going from level 1 to level 30.) Added as a new feature.
Remove some clutter from the wish handling code, mostly by taking
advantage of the fact that the wizard flag is valid even for the !WIZARD
configuration. No change to game play.
This is all tiny stuff - allow overriding WIDENED_PROTOTYPES from the hints
file, missing NO_SIGNAL conditionals, remove a GCC-ism, conditional indentation,
void return in a non-void function.
From a bug report, assigning
a vault guard a name such as Marcel could result in messages like
|The Marcel, confused, disappears.
Many of the guard messages had article "the" hardcoded. This gets rid
of g_monnam() and uses noit_mon_nam() instead.
I haven't been able to test all the modified messages; it's a pain
trying to get some of them to occur.
Fix a bug From a bug report: while stunned he tried to close
an adjacent open door and when his choice of direction got changed to
some non-door spot, no time elapsed so he could just keep repeating the
attempt until eventually getting the correct direction. Trying to open
an adjacent closed door and trying to remove the saddle from an adjacent
monster via #loot behaved similarly. Applying keys and lock-picks also
did so in 3.4.3, but had already been changed to use up time in the dev
code. There may be other actions which need fixing.
MAC is defined for MacOS 9 but not for 10 (and it shouldn't be). Add a MACOSX
define and use it in eat.c to pick up the joke meant for all Mac systems.
Add missing check for NO_SIGNAL in PANICTRACE versionof NH_abort().
Fix indentation of pre-processing directives.
Add #endif comments to make things clearer.
..\src\windows.c(329) : 'boolean (__cdecl *)()' differs in parameter lists from 'boolean (__cdecl *)(void)'
Committed on the Free edition of March Hare Software CVSNT Server.
Upgrade to CVS Suite for more features and support:
http://march-hare.com/cvsnt/
On crash signal or panic(), use a configurable method to get a stacktrace
the user can easily report to us. Currently only for Unix/Linux and only
ifdef BETA. Hopefully ports can add additional methods.
Bits:
- linux hints file had PREFIX definition in the wrong place
- sample sysconf file used wrong delimiter for WIZARDS
- fix grammar error in support message when using sysconf.wizards
- options.c comment typo
- capitalize "Crash test" output from #panic command
PORTS: Please make sure I've done the right thing for/to your code.
This patch adds a new winproc that lets the window port approve or cancel
the suspend request - this should take care of the Mac Qt lockup issue.
In addition, Unix suspend is restricted to accounts that can use the shell
if SYSCF is defined.
From a bug report, attempting to respond with ESC when playing an instrument
just continued with the playing sequence. This adds a q choice to the
"Improvise? [yn]" and "Play passtune? [yn]" prompts, and also checks
for ESC as the 5-note tune when not improvising, yielding "Never mind"
and not using up a turn if the player opts not to play any music.
I put the fixes entry in the new features section since the old
behavior wasn't much of a bug.
From a bug report, if you entered water
while blind and any spellbooks got blanked, you would know they became
"plain spellbooks" iff their original description was known. The same
situation applied to scrolls and potions; if they had been previously
seen you'd learn they'd become blank or clear. This fix resets the
obj->dknown flag during transformation so that altered objects are only
known by their class when blind, never their description, the same as
when they hadn't been seen before being blanked. (When sighted, the
dknown flag gets set again the next time the object's name is formatted,
so the player shouldn't be able to notice that any reset took place.)
Unpaid objects which get blanked should be treated as used up for
shop billing purposes (force the hero to buy), but there aren't any pools
in shops so aside from the added comment I'm going to pretend I didn't
notice that that isn't being done....
Potions seen before becoming blind which become diluted while blind
will be known to be diluted since there's no way to know the description
without also knowing the dilution. I don't think that's important enough
to track known-dilution separately, although I suppose we could overload
the cknown (contents-known) flag for that if necessary.
This also removes an inaccurate comment about the effects of Luck.
Its maximum is always 13 regardless of whether the moon is full, so 5%
for the lowest chance of blanking via submersion was impossible.
From a bug report, you could write a
spellbook with a magic marker while blind and were told the description
(often a color) of the resulting book. This prevents books from being
written while blind, just as they can't be read in that situation, and
it adds an extra test when attempting to write scrolls while blind.
(When you succeed in writing a scroll while blind, you're just told that
the result is ``x - a scroll'' as it's moved to its new inventory slot.)
This also removes a couple of overly hyper exclamations when writing
fails. Someday somebody ought to go through the whole program and decide
which messages actually warrant exclamation points, but I doubt that
that'll ever happen.
A few other fixes:
- bug: text window does not scroll left on left arrow
- pcmain.c: fix warning: _fileno() returns void* in Windows CE SDK
3.5.0 only:
- files.c: compile error: don't include <signal.h> if NO_SIGNAL is defined. WinMo does not support POSIX signals
- version.c: compile error: append_port_id() is undeclared
- link error: mktime() is unsupported -> define it in celib.c
-<Someone>
The dungeon_overview bits in the rm structure were being
clobbered by a run-length encoding save/restore because
they weren't taken into consideration.
This patch pulls that data out of the rm structure completely.
It also adjusts the run-length encoding checks to take the
candig bit into consideration and adds a comment to rm.h
reminding people to make run-length encoding adjustments
in save.c for any new bits that get added.
Someone in the newsgroup has a keyboard where typing '#' is difficult
or impossible to do, and mentioned that he could use Alt+r to get #rub but
was playing a knight and had no way to get #ride. Turns out that there
are several normal-mode extended commands that lacked a meta shortcut.
Since meta chars are case sensitive, I've added Alt+R for #ride, plus
M-A for #annotate, M-O for #overview, M-C for #conduct, and M-T for #tip.
Unfortunately, I've been unable to test them. It turns out that
nethack mode in PuTTY doesn't change the Alt key into a meta shift, it
causes the digits on the number pad to send vi-style movement letters
(with support for shift+digit and ctrl+digit to send modified letters).
That seems relatively useless to me, and I haven't figured out how to
force on high bit for arbitrary characters so can't activate nethack's
meta-key shortcuts.
The Guidebook has been updated via copy+paste and is untested too.
From a bug report, drinking a potion of
polymorph which is wielded would trigger an "object lost" panic if hero
took on a form that was forced to drop its weapon. Once weapon/potion
got dropped, subsequent useup() of the potion was no longer operating on
an inventory object.
Unwield the potion at start of drinking, so that dropping doesn't
come into play. (If we ever introduce a monster form incapable of
holding inventory so drops everything, this will have to be revisited.)
From a bug report, it was possible to get
|You hit the with all your might. You stop digging.
if a boulder went away--in his case, it was picked up by a giant--while
you were occupied trying to break it with a pick-axe. The code explicitly
used "" to fill in the message when dig_target had an unexpected value.
This just avoids giving the message in a case like this. Possibly
extra stop_occupation() calls should be done instead, but I didn't want
to try to figure out how many would be needed (monster picks up object,
monster zaps wand of striking, others?).
Noticed while testing the "<obj> is no longer poisoned" fix; killing
an engulfer via "the poison was deadly..." led to an "obj not free" panic.
It was due to post-3.4.3 changes, so no fixes entry.
From a bug report, message sequence
when throwing a poisoned weapon which loses its poison was confusing.
|The dart is no longer poisoned.
|The dart hits the acid blob.
|The poison doesn't seem to affect the acid blob.
This patch makes the first sentence come out last.
[It appears that poisoned weapons thrown/shot by monsters or traps
never lose their poison. That can't be right....]
From a bug report, a stunned monster
moved away from the hero, but remained holding him. That behavior was
still present in the dev code, although the hero was free to move and
would become unstuck as soon as he did so. I don't know how many fixes
for this sort of thing have been made, but they evidently haven't been
made in the proper place. [Perhaps it really ought to be done as a
monster is placed somewhere on the map?]
From a bug report, if you were a mimic
who was hiding (via #monster, becoming a strange object) and polymorphed
into some other monster type, you retained the hidden/object form. That
didn't happen when reverting to normal form, or when polymorphing into a
monster while involuntarily mimicking gold, but handling for the latter
inadvertently blocked dealing with the hiding-voluntarily case.
From a bug report, black dragon breath
destroys closed doors didn't acknowledge hitting secret doors. bhit()
reveals secret doors, but zap_over_floor() (called by buzz() for ray-type
wands and spells, and for breath attacks) didn't check for hitting those.
When testing the fix, I noticed that feedback for an explosion caused
by breaking a wand was worded oddly for zaps like magic missile which don't
damage doors. "The door absorbs your bolt" didn't make much sense; what
bolt? That was first changed to "absords your blast", which still sounded
weird, then to "absorbs the blast", which seemed better but was inaccurate.
Next was "absorbs some of the blast" since the explosion continues to hit
adjacent spots, but since it still has full strength that wasn't accurate
either. It's finally become "The door remains intact." Unlike with zaps,
there is no additional range being lost, so no reference to absorption.
From the newsgroup: player saw "The spell hits the <monster>?"
where the question mark punctuation reflected negative damage occurring.
Another player diagnosed it as a 2 point force bolt (from 2d12 dice role)
modified by -3 penalty for hero who has Int less than 10. This changes
spell_damage_bonus() to avoid reducing damage below 1 point.
Add sys/unix/sysconf, a sample sysconf file.
Move defines from topten.c to config.h so they can be seen globally.
Add persmax, pers_is_uid, entrymax, and pointsmin to struct sysopt, use
in topten.c, populate in files.c
Warning cleanup in files.c.
BUGFIX: don't crash in unixmain.c if WIZARDS left unspecified.
hints/macosx10.5: don't hardcode "keni"; install sample sysconf; install
sample ~/nethackrc
makedefs: add "system configuration" to compiled-with options list.
BUGFIX: if a game doesn't meet the criteria for making the record file it's
shown to the user as having zero points because t1->points is set to zero
to indicate that it doesn't get written back; display u.urexp instead.
From the newsgroup: someone using <Someone>'s level-flip patch
(to transpose special levels left-to-right or top-to-bottom or both in
order to get more variety from them) ended up in solid rock. When
climbing the stairs up from the Valley to the Castle, goto_level() was
hardcoded to find a spot in the extreme lower right corner. If the level
is turned upside down, solid rock from an unused row at the top edge of
the map ends up at the bottom, and the placement code could put the hero
there. That code only checked for walls and monsters being in the way,
not rock. Also, if the level is flipped side-to-side than hero ends up
in same area as the upstairs rather than on opposite side of the Castle.
This switches to the same teleport-region code used for other level
changes which don't arrive on stairs; such regions get flipped along with
map by that patch (I hope). Even though no such fix is currently needed
for unmodified nethack, this change gets rid of the special case Castle
placement code entirely, simplifying both goto_level() and u_on_sstairs()
in the process.
The Castle's existing from-below region covers the rightmost half-
dozen or so columns across all rows, so offers a bigger landing zone than
just the bottom corner. That could be tweaked within castle.des but I
don't think it needs to be.
Add questpgr formatting codes to support pronouns for leader,
nemesis, deity, and artifact.
%lh -> "he" or "she" for leader; %nh for nemesis; %dh for hero's god;
%li -> "him" or "her"; likewise %ni, %di;
%lj -> "his" or "her"; and %nj, %dj;
H, I, and J modifiers yield capitalized form of same.
%oh -> "it" or "they" for artifact (Eyes of the Overworld is plural);
%oi -> "it" or "them";
%oj -> "its" or "their"; plus capitalization with uppercase modifiers.
Also, %O yields shortened artifact name ("the Foo" in place of "the Foo
of Bar"). These provide support for terser summary lines, but can also
be used in the regular quest text passages.
A couple of nemeses don't specify gender. The random choices need
to be made early so that the leaders' messages can get them right. This
chooses during role initialization and then uses that result once the
corresponding monster is eventually created. It does the same for leader
even though no current leader needs it, and for deity too.
[Make use of recent message history changes.]
Add support to makedefs and the core for including a line of summary
text with quest messages that don't use pline() delivery. The multi-line
record structure of quest.txt begins each entry with %C and ends with %E.
makedefs now examines the %E lines looking for "[anything]" and adds that
to quest.dat where deliver_by_window() can find it. The square brackets
are required in the input and intentionally carried along to the output.
putmsghistory() is used to put the summary text into the message history
buffer for use by ^P, without being displayed first. (So this is a no-op
for interfaces which haven't implemented putmsghistory yet. Maybe
genl_putmsghistory() should pass such text to pline() as a quick hack?)
This adds a few summary lines to quest.txt so that the feature can
be tested. Most of them were written by <Someone> nearly three years
ago. I'm planning to add a couple of new control codes that'll allow some
of them to expand into shorter text. (The one where the Archeologist
leader tells you that the nemesis stole the artifact so your mission is
to find the goal level, defeat the nemesis, and return with the artifact
ends up being roughly 160 characters long.)
[Third of three message history patches.]
Add another argument to putmsghistory() so that it can tell whether
it's processing multiple messages for restore (which should be treated as
being older than any current messages) or a single message to stuff into
history (which should be treated as the most recent message even though
it hasn't been displayed in the message window).
[First of three message history patches.]
The post-3.4.3 hangup changes broke the post-3.4.3 message history
save/restore for tty (and maybe Win32, if it supports hangup handling;
other interfaces haven't implemented message history save/restore yet)
during hangup saves by preventing interface-specific getmsghistory() from
being called. Relatively benign; hangup save just behaved as if message
history was empty, so restore had no old messages to put back. Naturally
post-hangup restore is when players would be most interested in reviewing
the previous session's messages, so benign failure isn't acceptable. Fix
is to leave getmsghistory() intact when replacing windowprocs with the
I/O-free routines. [I can't trigger real hangups for testing, but can
call hangup() from within the debugger to force an approximation of one.]
Recent newsgroup discussion complained about a pearl ring becoming
rusty. That has no effect on game play but does feel weird. Rings which
are described by their gems specify a material based on the gem rather
than on the band, so making pearl rings be made out of iron didn't fit.
The substance pearls are made of is the same as in the shells of the
oysters or whatever critters excrete them. The closest matches available
seem to be mineral and bone; I've gone with bone here.
From a bug report, the 'D'
command would list 'u' as an item category choice if you were carrying
unpaid items inside a container, but if those were the only unpaid items
then nothing would happen once the dropping stage was reached. Applied
to all menustyles (except partial, which bypasses categories and goes
straight to a menu listing all items). There were two alternatives for
the fix: suppress 'u' as an applicable category when it only applies
to container contents, or include the container among the drop candidates
even though it isn't an unpaid item itself. I went with the latter; it's
simpler to implement and also feels a little more intuitive than behaving
like there aren't any unpaid items present.
It always struck me as odd that x_maze_max and y_maze_max were
initialized in main(). They're only needed when making new levels, so
don't have to come before saved game restoration. They could easily have
gone into init_dungeon() (although they make well predate that), or even
mklev() (reinitializing them for each new level wouldn't have been a big
deal). That's all moot, though, since it's trivial to initialize them at
compile time.
