When testing singularizing of fruit names I noticed that "bunches of
grapes" became "bunche of grapes". makesingular() had a comment about
not recognizing "es" and suggesting that recursion could solve it. But
makeplural() already handled things like that without resorting to
recursion, and it also recognized more compounds than just "foo of bar"
and "*man-at-arms" (such as "pie a la mode" and "soup du jour"). This
moves the compound phrase recognition into a separate routine so that
both makesingular() and makeplural() will handle the same stuff, and it
modifies makesingular() to do as well as makeplural() when processing the
front half of compound phrases (the "foo" part in "foo of bar").
Also, a minor plurization tweak: algae was recognized as already
plural but larvae and several similar words weren't.
Inventory formatting for a single slime mold object would be strange
if the user entered a plural word or phrase for fruit name. Forcing the
user-specified value to be singular as it's being set up as current fruit
avoids that. [Something like <Someone>'s "bunch of grapes" is unaffected;
it's already singular and correctly handled as such by makesingular().]
This may have a side-effect of limiting the creativity of some players
who try to trick others via bones files gimickery, but I think the extra
consistency in object naming during ordinary play is worth it.
According to the cvs log info, this issue was actually mentioned in
a patch I made ("fix M203...") in October, 2005. I have no recollection
of that at all....
Each time save and restore is performed, the ffruit list gets
reversed. Since additions can be made when it is in backwards order or
in original order depending upon whether an odd or even number of save/
restore cycles have taken place, the numeric sequence of its entries is
ultimately arbitrary. So there's no point using extra code to force new
ones to be added at the end of the list; just put them at the beginning.
I almost abandoned this when Michael beat me to it, but besides
handling the fruit rename bug it also moves `current_fruit' into the
context structure to eliminate separate save/restore for that.
From a bug report:
The following steps do not yield the expected fruit:
1) start nethack in explore mode (with a wand of wishing)
2) change fruit name to "tomato"
3) save/restore
4) change fruit name back to "slime mold"
5) save/restore
6) wish for a fruit; you get a tomato
7) check options; fruit name is set to "slime mold"
If you specified a fruit name that already existed in the list,
fruitadd() always set current_fruit to the fruit with
the highest fid encountered in the list to that point, instead
of the fid of the matching entry.
From the newsgroup: if no co-aligned artifacts are available when
attempting to give the first divine gift for an offered corpse, nothing
would be given. Since the gift counter stayed at 0, subsequent attempts
to select one would still treat it as first gift and always fail again.
The first divine gift from offering corpses must match the hero's
alignment; after that, nonaligned artifacts (Frost Brand, Giant Slayer, &c)
are added to the pool of choices for further divine gifts. It's pretty
easy for a chaotic character to use up the co-aligned artifacts before
getting any divine gift. There aren't many chaotic ones and some are
inelgible due to being race-specific items. Wishing for Stormbringer--or
loading a bones file which contains it--and creating Sting and Orcrist
via naming will do the trick for an elven hero.
This patch expands the pool of candidates to include nonaligned
artifacts during first gift selection if no co-aligned ones are available.
use makedefs --grep in Makefile.doc
call make clean in doc from make clean in top
add commented out rule to produce mdgrep.h from mdgrep.pl
macosx1.5: don't chown/chgrp for single-user install
unixmain.c: work around C90 warning for Mac-specific code, fix last fix
makedefs.c: temporarily disallow blank after control introducer until docs
catch up
mdgrep.pl: add ALLDOCS, clean up generated file's header
Finally found a flag combination that will complain about declarations mixed in
with other code: -ansi -pedantic.
Clean up the violations of that I just introduced and add that flag to the
Mac 10.5 hints file. (Note that there is one warning left in unixmain.c -
it's in Mac-specific code.)
Add SHELLERS - people allowed to use ! command with same syntax as WIZARDS.
Add new hints file for 10.5, since the rules and commands for groups changed
(new commands introduced in 10.4, old ones removed in 10.5; creating a new
user under 10.4 gave you a matching group, in 10.5 it doesn't). Also move
shared build into roughly right place in file system when being installed
for root - don't use ~root.
Makefile.top - don't remove ./-p unless it exists (that's always annoyed me).
fix error invoking macosx.sh
A change yesterday made putting on an amulet of restful sleep avoid
clobbering the timeout from having already eaten one, only replace it if
the new timeout is shorter. This does the inverse; when eating one, if
you're already sleepy from also wearing that type of amulet, only replace
the timeout if new one is shorter. And don't clobber the other intrinsic
bits with FROMOUTSIDE, just add it to whatever ones might already be set.
Neither should have any observable effect on game play, so no fixes entry.
From a bug report, wearing
(or removing) an amulet of restful sleep was overriding permanent
sleepiness which had been obtained previously via eating another amulet.
The setting of timeout clobbered the non-timeout bits for that intrinsic.
This also adds the timeout counter for sleepiness to enlightenment
feedback in wizard mode. Unrelated: rephrase enlightenment feedback for
adornment to more accurately describe what that does.
Pat Rankin wrote:
> That patch looks incorrect. `CONSUME' increments argv,
> so now a different value is being passed to the function when
> initializing that variable than was passed before.
From a bug report, archeologists were
inadvertently starting out at basic skill level in sling because of their
carried touchstone, which is flagged as being sling ammo.
More warning bits that never got committed.
More appropriate compiler flags for warning checks (macosx only for the moment).
The changes in dgn*[lc] just rename line_number to nh_line_number to avoid a
clash, so no need to regenerate the lex output.
get macosx down to one hints file (default tty, single user) for
tty, x11, qt and single or multiple users
preliminary bits that might allow a macosx qt build
Add MAXPLAYERS to SYSCF config file; deprecate (but continue to support)
MAX_NR_OF_PLAYERS in nethack.sh since it is trivially overridden in many
(all?) cases and isn't useful for ports that don't use nethack.sh.
This code (except for some of the argument parsing changes) is not used yet.
mdgrep.pl generates mdgrep.h; like the lex and yacc files we ship mdgrep.h
pre-generated; there is no need for perl on end-user/end-compiler systems.
(In fact mdgrep.h is so simple mdgrep.pl is probably overkill.)
mdgrep.h creates an array reflecting the compiler options in effect
The changes to makedefs break the Mac OS9 compile; if necessary the fix is
simple and documented (but I think that port is permanently dead).
With that port out of the way, makedefs can be allowed to take real options;
none of the current options have been changed. Instead, a second sub-main
routine has been added to handle options starting with two hyphens and all
the new options start with two hyphens:
--input specifies the input file (- is stdin)
--output specifies the output file (- is stdout)
--grep causes the input file to be filtered into the output file
--grep-showvars dumps the info from the array in mdgrep.h
--grep-trace turns on tracing of the grep filtering
Docs for the filtering language are in the source.
Follow up to the patch that adds a fake inventory entry for the
swallowed hero when probing an engulfer. Make the header for the hero
be plural to match those of object classes, and prefix the hero entry
itself with a/an to reflect its count of 1.
| Swallowed Creature -> Swallowed Creatures
| > - elven ranger called wizard -> > - an elven ranger called wizard
Reported recently by <Someone>: probing feedback while engulfed
shouldn't claim that the monster is not carrying anything when the hero
is inside of it. The simple case where it's not carrying anything else
was a trivial one line change; handling inventory plus hero was trickier
and I wouldn't have bothered if I'd realized what it was going to take.
But it's done now; trivial case
The purple worm is not carrying anything besides you.
and harder case
The purple worm's possessions:
Weapons
a - an uncursed dagger
Swallowed Creature
> - human archeologist called wizard
Throwing an object while engulfed and then quitting triggers a panic
when the end-of-game code tries to clean up the thrown object. Throwing
code wasn't reflecting the fact that adding the missile to the engulfer's
inventory already handles the thrown object. 3.4.3 wasn't affected; it
didn't bother trying to clean up `thrownobj' in done().
Readability tweak; use `WAND_BACKFIRE_CHANCE'. This code for giving
cursed wand a chance to explode when engraving is in the branch too, but
the macro wasn't added there.
From a bug report: in the irregularly
shaped temple on the C quest home level (the room where the leader is
located), the lit south wall contained a dark spot where a secret door
is located. It stayed blank until you got right next to it rather than
just until you got to a good angle facing it. (Magic mapping hides the
problem by showing that spot as a wall instead of leaving it as unseen;
you have to walk or teleport to that room in order to see the problem.)
The code that lights walls and doors which border lit rooms neglected
temporary walls produced by secret doors.
Implement something <Someone> suggested a long time ago: eating a
disenchanter corpse has a chance to remove an intrinsic. Uses the same
routine as nighttime gremlin attacks, which chooses an intrinsic randomly
and attempts to remove it, so has no effect if it chooses one the hero
lacks. This can be used to remove "aggravate monster" but is much more
likely to target something the player wants to keep. [By the way, a lot
of potential candidates are missing: sleep, shock, and disintegration
resistance and teleport control come immediately to mind.]
Also, it has been bugging me that you can get both strength and
fire/cold/shock resistance from the same fire/frost/storm giant corpse.
The code prevents mind flayer corpses from conferring both intelligence
and telepathy, so strength handling was inconsistent (even though it
predated mind flayers...). This causes strength boosting to be treated
as an extra candidate when selecting an intrinsic to confer, so you'll
either get strength or resistance (which might be a no-op) but not both
from those giants. And it special cases the other giants to have the
same 50% chance for boosting strength, even though the alternative in
their case is to do nothing instead of trying to confer something else.
Lastly, it now gives a message when you succeed in gaining strength.
From a bug report,
the message when dipping one stack of potions into another triggers an
explosion says "BOOM" yet nearby sleeping monsters remained undisturbed.
From a bug report: an exposed eel in an isolated
pool--swamp rooms sometimes produce those--would never re-hide no matter
how long you left its vicinity. Re-hiding is part of post-move handling
and an eel with no adjacent water to move into would never reach that bit
of code since it didn't move anywhere. The code used to re-hide monsters
when you return to a previous level was ignoring eels altogether. Give
unhidden eels a chance to hide earlier during monster movement and also
when the hero returns to their level.
Also a really minor bit to slow down hit point loss of eels out of
water. I don't think anybody reverse genocides krakens to get experience
any more since they don't provide a big bonus when they're out of water,
so this change won't have much of an affect.
The one `anything any' that was triggering a warning was shadowing
another `anything any' in the same function; no need to rename it, just
remove the unnecessary declaration. Also, mark the couple of arrays with
initializers that I'd noticed as static instead of letting them default
to auto. The abil_to_spfx()::abil2spfx[] one might need to be redone in
code as a switch if some compilers/linkers have trouble initializing it.
Three years ago <email deleted> reported that
stepping off the end of inventory via typing space to go to the next menu
page wasted his identify scroll. He suggested that some people might do
that because they don't know how to back up in a multi-page menu. I
pointed out the Guidebook section that describes < and ^ to go back one
page or back to start and left things at that. However, traditional mode
reprompts if you step through all of inventory without choosing something,
so this changes identify-via-menu to do likewise. You can dismiss the
menu with ESC to really avoid choosing anything.
This also makes identification of N items when you're carrying N or
fewer unID'd things behave the same as identify all: identify everything
without any prompting.
The characteristics display checked for cursed rings of sustain
ability but neglected to check for uncursed ones locked in place by
cursed gloves or weapon. And the half-hearted attempt to check for
future items conferring Fixed_abil couldn't handle an uncursed thing
covered by something cursed either, so just get rid of it.
Use sentences for the characteristics (instead of "Strength = 15") to
match the rest of the enlightenment display. When showing ATTRMAX, phrase
as "limit" rather than "maximum" since magical ajdustments can exceed max.
And be more selective about which alternate attribute numbers to show:
Your strength is 14 (current; base:13). => +1 ring of gain strength
Your strength is 13 (current; peak:14). => lost a point to poison or abuse
Your strength is 14 (current; base:13, peak:14). => combo of both of those
Your strength is 14 (current; limit=18/50). => you're a gnome
instead of always showing all of base & peak & limit when any of the three
are interesting. During play, a limit which is different from normal human
(18 or 18/100) is considered to be interesting; for end of game disclosure,
it's interesting iff the final value hasn't reached maximum, regardless of
what that max is.
I'm not a contender to win any spelling bees. (Mimicker does't
seem to even be a real word; I'm not sure if it ought to end in "or"
instead of "er". But changing it to "mime" would be too weird.)
Augment killer reason when slain by a shapechanged creature:
"killed by a foo" becomes "killed by a chameleon immitating a foo" or
"killed by a vampire in foo form" or "killed by the Wizard of Yendor
disguised as a foo" (after double-trouble, when the clone starts out
mimicking something).
I put the fixes entry in the new features section.
I was testing something with #monpolycontrol enabled and got a
series of "Change it into what kind of monster? [type the name]" prompts
when I went to a new level. It was asking about monsters that were being
created (in this case, multiple vampires for top level of Vlad's Tower)
and naturally I couldn't see them since the level wasn't finished yet.
This switches to noit_mon_nam() to at least be informed about the type
of creature you're being asked to specify a shape for, and adds the map
coordinates so that it doesn't appear to be reprompting for the same
monster over and over when multiple similar ones are being created.
In the process I discovered that #monpolycontrol would let you give
any type of monster for the shape of vampires. Unlike chameleons, they
don't change into arbitrary shapes so that was inappropriate. [And
trying to test the fix for this is what led to the previous ^G patch.]
A while back there was a change in how the initial shape for a
shapechanging monster gets chosen during monster creation, and a side-
effect of that lets/makes you choose the shape when #monpolycontrol is
enabled. But ^G was overriding your choice by forcing the shapechanger
to start out looking like the type of monster that you specified (to ^G,
not to subsequent #monpolycontrol prompting), hence always in its natural
shape. The intent for ^G was that if asked for a unique monster but got
a doppelganger instead, it would initially look like the requested unique
monster. Post-3.4.3 code, so no fixes entry needed.
Three years ago <Someone> reported that even though exercise of
attributes other than wisdom is suppressed while the hero is polymorphed,
attribute gains or losses due to pre-existing exercise can still take
place in that situation. Since it's an entirely different set of attrs
which will be replaced upon rehumanizing, there's not much point. (The
same is actually true for wisdom, but I didn't change how exercise works
for it.) Adopt his one-liner fix: old exercise won't cause attribute
changes while polymorphed; it will silently fade as it does when its
magnitude is insufficient to trigger a change.
While checking that out, I noticed that exerchk() was using `/= 2'
to fade out old exercise/abuse. That will produce platform-dependent
results for negative values (ie, for the abuse case) since C's integer
division doesn't specify whether to truncate towards zero or towards
negative infinity. In particular, -1 / 2 could yield -1 rather than 0
as the code expected. (Its impact on play was negligible though.)
This reduces the code for displaying the messages which accompany
attribute gain/loss. A few were repharsed in order to simplify that.
The recent SYSCF patch introduced a build problem even though I
haven't attempt to use that new stuff yet. My compiler complained that
`out' in build_english_list() was used without being initialized, which
in turn caused make to quit. The compiler was right; only the words==1
case actually set up the output buffer. Once that buffer was fixed, the
routine to copy a single word was overwriting it on each call instead of
building up via appending as intended.
I changed the 3 or more case to yield "A, B, or C" like Keni wrote
in his description rather than the "A, B or C" which was being produced.
I'm pretty sure that both forms are considered acceptible; I've always
used the first one with an extra comma in front of and/or.
