When a wish request for "<foo> armor" fails to match anything, check
whether it matches "<foo> mail" before resorting to selecting a random piece
of armor. Most of the suits are named "mail", and while I don't think many
people will ask for "ring armor", I do think that "crystal plate armor" and
"gray dragon scale armor" are sometimes tried.
This also greatly simplifies the handling for spelling variant "armour"
by rewriting it to "armor". Unfortunately "grey" vs "gray" can't be handled
the same way since both spellings are used by the program.
A user recently complained that he started an activity such as
searching and specified a repeat count, right after getting--and not
realizing the significance of--the first message in the countdown
sequence for turning into stone. He suggested that subsequent messages
interrupt multi-turn activity so that the player has a chance to do
something to prevent imminent death. This implements that, with the
added wrinkle that it won't interrupt if the activity is something that
might save the character's life: attempting to eat a tin that is either
sure to help (if ID'd as food that cures stoning) or a desparate gamble
(if unID'd). Some hooks for similar behavior for other conditions like
turning into slime are included, although no tins can help for anything
other than petrification so far.
Shouldn't fatal illness have an end-is-near countdown too?
Implement a user suggestion that tame humanoids should avoid eating
corpses of their own species. Prevent them--except for kobolds, orcs, and
ogres--from doing so unless starving. Arbitrary: tame elves won't eat
other elves even when starving. A polymorphed character will incur the
effects of cannibalism when eating either his/her underlying race _or_
the current one (player orcs and cavemen aren't affected though).
o Add support for zlib compression via ZLIB_COMP in config.h (ZLIB_COMP
and COMPRESS are mutually exclusive).
o rlecomp and zerocomp are run time options available if RLECOMP and
ZEROCOMP are defined, but not turned on by default if either COMPRESS
or ZLIB_COMP are defined.
o Add information to the save file about internal compression options
used when writing the save file, particularly rlecomp and zerocomp
support.
o Automatically adjust rlecomp and zerocomp (if support compiled in)
when reading in an existing savefile that was saved with those options
turned on. Still allows writing out of savefile in preferred format.
o In order to support zlib and not conflict with compress and uncompress
routines there, the NetHack internal functions were changed to
nh_uncompress and nh_compress as done in the zlib contribution received
in 1999 from <Someone>.
I tagged the sources NETHACK_3_5_0_PREZLIB prior to applying these
changes.
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.
Support negation syntax to restrict unwanted race, role, gender, align
options:
OPTIONS=role:!knight, role:!tourist, race:!orc
prevents them from being picked randomly or
appearing in the pick lists at the start of the game.
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.
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).
- always write plname into save file, no longer conditional
- add 'selectsaved' wincap option to control the display of
a menu of save files for ports/platforms that support it.
- add support for win32 tty using normal nethack menus.
- the win/tty/wintty code is generalized enough that any
tty port could support the option if the appropriate port-specific
code hooks for wildcard file lookups are added to src/file.c
specifically in the get_saved_games() routine. There is posix
code in there from Warwick already, and there is findfirst/findnext
code in there from win32. Warwick has the posix code only
enabled for Qt at present, but with wintty support, that could be expanded
to other Unix environments quite easily I would think.
Here is what the tty support looks like:
NetHack, Copyright 1985-2005
By Stichting Mathematisch Centrum and M. Stephenson.
See license for details.
Select one of your saved games
a - Bob
b - Fred
c - June
d - mine3
e - Sirius
f - Start a new character
(end)
The following files existed in the NetHack SAVEDIR directory
at the time:
ALLISONMI-Bob.NetHack-saved-game
ALLISONMI-Fred.NetHack-saved-game
ALLISONMI-June.NetHack-saved-game
ALLISONMI-mine3.NetHack-saved-game
ALLISONMI-Sirius.NetHack-saved-game
Note that despite the file names, the actual character name
is drawn from the savefile.
The WIN32CON support passes
USER-*.NetHack-saved-game
to findfirst/findnext where USER is your login name of course.
This is a minor addition to Pat's doorganize() patch.
This just allows you to press '?' in the midst of an #adjust command
to see what letters are already in use. It is a PICK_NONE menu for
viewing only, because your actual response to the #adjust must not
be limited to the letters already used. It helps to be able to see
what's already consumed without having to terminate the command,
inventory, then start it again.
From a bug report:
> If the Summon Nasties monster spell gates in two minions instead of one,
> the message still says "A monster appears from nowhere!"
The code wasn't counting any summoned monsters who had an opposite alignment
to the summoner. It also assumed that the 10% chance for demon summoning
in Gehennom always yielded exactly one monster even though that can produce
zero or more than one.
On Sat, 18 Dec 2004 14:07:14 +1300, <email deleted> wrote:
> Adding one of several candles to a candelabrum which already has six
> gives an ungrammatical message.
<Someone> wrote:
> From the mkclass() comments:
>
> /* Assumption #2: monsters of a given class are presented in ascending
> * order of strength.
> */
>
> And monst.c:
>
> * Rule #2: monsters of a given class are presented in ascending
> * order of strength.
>
> * Rule #4: monster subclasses (e.g. giants) should be kept
> * together, unless it violates Rule 2. NOGEN monsters
> * won't violate Rule 2.
>
> Inspecting my monster-difficulty spoiler, I see the following places
> that these precepts are violated: do they cause potential problems?
> (Insofar as occasionally incorrectly miscalculating the probabilities
> for monster generation is a "problem", that is...)
>
> SPECIES DIF
> ~~~~~~~~~~~~~~~~~~~~~~ ~~~
> d dog 5
> d large dog 7
> d dingo 5
>
> d warg 8
> d winter wolf cub 7
> d winter wolf 9
>
> u white unicorn 6
> u gray unicorn 6
> u black unicorn 6
> u pony 4
>
> H frost giant 13
> H storm giant 19
> H ettin 13
>
> P black pudding 12
> P green slime 8
>
> S pit viper 9
> S python 8
> S cobra 10
>
> Z giant zombie 9
> Z ghoul 5
>
> @ nurse 13
> @ soldier 8
> @ sergeant 10
>
> & horned devil 9
> & succubus 8
>
> & balrog 20
> & sandestin 15
>
> (I've just realised that these may have already been fixed, and
> waiting on a file-compatibility-breaking release; if so, ignore me :-)
<Someone> wrote:
>> If the previous character was non-neutral, the unicorn would have
>> started off as hostile. When a bones file is loaded, I don't think
>> hostiles are made non-hostile, although the reverse is certainly true
>> (pets of the deceased are usually hostile).
>
> In the general case, they are, or rather their hostility is
> re-evaluated with respect to the new character; see the peace_minded()
> call in getlev(). However, co-aligned unicorns always being created
> peaceful is a special case in makemon(), _not_ part of peace_minded(),
> so they'd just have the usual chance of being made peaceful or not
> depending on alignment strength, as for any other co-aligned monster
> not explicitly declared always peaceful or always hostile.
<Someone> wrote:
> The "/* Fix up the quest nemesis */" code in role_init()
> adds M3_WAITFORU but _doesn't_ remove M3_CLOSE;
> since the Master of Thieves as the Rogue Quest Leader is
> defined with that flag, he keeps it when acting as the Tourist
> Quest Nemesis. Thus, when STRAT_WAITFORU
> is cleared by your actions, STRAT_CLOSE may stay in
> place making him stay meditating when another Nemesis
> wouldn't.
<email deleted> wrote on Friday, December 10, 2004:
> I was in a barracks with the soldiers sleeping. I started fighting one soldier
> and threw a potion of acid on him. I got the "The soldier shrieks in pain!"
> message, but none of the other soldiers in the barracks woke up.
<Someone> complained that his compiler was giving these
warnings:
cmd.c:2119: warning: declaration of `expl' shadows a global declaration
dungeon.c:292: warning: declaration of `rand' shadows a global declaration
exper.c💯 warning: declaration of `exp' shadows a global declaration
files.c:278: warning: declaration of `basename' shadows a global declaration
hack.c:1102: warning: declaration of `expl' shadows a global declaration
pickup.c:2081: warning: declaration of `select' shadows a global declaration
role.c:1060: warning: declaration of `conj' shadows a global declaration
<Someone> complained that his compiler was giving these
two warnings:
weapon.c:835: warning: `static' is not at beginning of declaration
version.c:132: warning: `static' is not at beginning of declaration
[Attention: This patch increments EDITLEVEL in patchlevel.h, rendering all
previous save and bones files obsolete.]
Here's the first cut at the two recommended flags lknown and cknown.
I've attempted to stay close to Pat's recommendations:
"Containers ought to have two new flags: lknown for lock status known,
and cknown for contents known (ie, `secret'). Formatted box and chest
descriptions should include locked/unlocked/broken when that is known
and empty/nonempty (or something like "holds N items") when contents
are known. The contents indicator would also apply to nonlockable
containers."
I probably overlooked a place where a flag should be adjusted, but this
should give us a good starting point.
I wasn't sure what to do with the case of the auditory feedback for
magical locking "Click" and "Clunk". The question that came to my mind
was: Should those reveal the locked or unlocked status of a box?
I suppose if you knew the type of wand you were zapping or the spell
you were casting, you could argue that they should.
In the end, I opted for setting lknown right off the zap/cast effect
for anyone playing a Wizard role, and not setting it for anyone else,
thus advancing class differentiation a little bit too.
I haven't checked the cknown results under all flags.menu_style options
at this point, only MENU_FULL.
Fix for first issue reported in this bug report:
<email deleted>
Sent: Thursday, December 09, 2004 7:13 AM
Subject: Two wrong messages
I would like to report two cosmetic issues:
1. "its gaze is reflected by the invisible [pet]'s shield."
Wrong capitalization.
2. The message given when decapicating an ettin {,zombie} with the Vorpal
Blade fails to mention the second head. This could be pretty tricky to
fix, but, per <Someone>'s suggestion, the easiest explanation would be
to say that the blade's wielder cuts off both heads at once.
The patch would look similar to:
*dmgptr = 2 * mdef->mhp + FATAL_DAMAGE_MODIFIER;
> if(mdef->data==&mons[PM_ETTIN]
> ||mdef->data==&mons[PM_ETTIN_ZOMBIE)
> pline("%s goes through both necks of %s at once like butter!",
> wepdesc, mon_nam(mdef));
> else
pline(behead_msg[rn2(SIZE(behead_msg))],
wepdesc, mon_nam(mdef));
otmp->dknown = TRUE;
(and the same for youdefend)
Add the extra feedback suggested by <Someone> so that being blinded
by moving into a stinking cloud is explicitly pointed out to the user. It
makes things more verbose but seems reasonable. You get blinded for 1 turn
with every step, so the message gets repeated each time too, but since you
also get a choking or coughing message on each step it's only a modest
increase in the overall verbosity.
From a bug report: when a black light explodes and triggers
hallucination, its own monster symbol--or warning marker for same--could
be seen changing. Since nothing is left after it explodes, you shouldn't
hallucinate anything at its location. Fix by killing it off (so removing
it from the map) before initiating Hallucination.
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.
<Someone> reported that riding a steed into a magic portal can
give "steed is still eating" message, feedback normally used to explain why
you can't go down stairs. Rather than preventing portals from activating
in that situation, just force the meal to be finished in order to suppress
the message. Proper fix is probably to prevent all steed movement while
eating, but that would most likely result in no one ever riding again.
Fix the wizard mode crash From a bug report. Move the WIZKIT
message suppression to a lower level instead of trying to guard against
present and future pline() calls in the wishing code. The way that was
being handling wasn't suitable for dealing with quest feedback.
This also includes a couple of additional wishing synonyms.
Someone in the newsgroup expressed surprise that he didn't get any
special message after surviving the eating of a cockatrice corpse. Combine
the cliche that unconventional meat inevitably tastes like chicken with
the mythology that cockatrices are a bizarre hybrid of chicken and reptile
(or whatever). This will give a message about tasting like chicken for
corpses or smelling like chicken for tins when the hero has petrification
resistance (poly'd into a xorn, for instance) or is hallucinating.
A user reported that when breaking potions inside a box in a shop, he
wasn't charged for them. The code was calling stolen_value() as intended,
but that routine only charged for types of items which the shop normally
carries. That meant that breaking the contents of a box in a general
store would charge for them but doing so in a tool shop would, not even
though the tool shopkeeper would gladly sell such things when you picked
them up instead of causing them to go away.
When fixing this, I noticed that stolen_value() was only charging
for single items. Most of the time that was right, because throwing and
kicking things always split one off, but there are cases (such as zapping
a wand of teleportation at shop goods) where an entire stack gets stolen
as a group. This makes stolen_value() handle all quantities.
