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.
infrastructure for "system options" - things currently specified at build
time that should be changeable at install time or run time but not really
under user control
generalize contact info so it can be localized and it doesn't have to be
an email address
move recently introduced WIZARDS into sysopt
drop bogus OPTIONS=wizards possibility
new function build_english_list() to comma-ize and add 'or' from a whitespace separated list: A. A or B. A, B, or C.
syscf file now handles: WIZARDS SUPPORT RECOVER
SUPPORT specifies local support information
RECOVER will eventually supply port-specific and/or localized info on how
to run recover (or get it run for you).
Note: in sys/msdos I changed sys.o (generated from pcsys.c) to pcsys.o
Note: sys/msdos/Makefile.GCC has 2 rules for sys.o (now pcsys.o)
Picking up and putting on a +1 ring of protection while blind
resulted in having a "+1 ring (on {left|right} hand)" in inventory and
having ring of protection show up in the discoveries list. The problem
is the same as the one for wands which has been previously addressed
(but not 100% fixed...): when using an item whose effect is observable,
the item's type became discovered based upon that observation even if the
item itself had never been seen.
The code for removing ring of protection lacked its break statement
and fell into the case for removing ring of protection from shapechangers,
but didn't cause any noticeable problem.
1) the change yesterday to mark inventory as seen when recovering from
blindness neglected to handle blindfold removal;
2) fix grammar when using 'R' or 'a' to try to remove cursed lenses
(now "they are cursed" instead of "it is cursed");
3) attempting to put on a wielded or quivered blindfold, amulet, or ring
and failing because of already wearing one (or two in the case of
rings, where cursed gloves and ESC at "which ring-finger?" prompt got
similar result) unwielded/unquivered item rather than leave it as is.
I suspect--but have no way to test--that there is a subtle difference
in game play between perm_invent and !perm_invent involving object merging
or other activity that depends on whether or not object->dknown is set.
For objects pickup up while blind, where object->dknown is left as is,
the perm_invent config would have such items marked as seen sooner (since
there are umpteen places that call update_inventory() which will end up
setting the seen bit while formatting objects). Non-perm_invent wouldn't
have that done until the user examines invent (or asks to see a list of
objects at the "which object?" prompt for various commands). This patch
effectively examines inventory whenever blindness ends, so both modes get
dknown set as soon as possible. And if we ever add an "effect known" flag
for unseen objects which are used while blind, this would be a suitable
place to perform deferred object discovery.
..\src\options.c(565) : warning C4101: 'opts' : unreferenced local variable
The code in initoptions_init() that uses opts seems to now be isolated to
UNIX and VMS.
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.
The post-3.4.3 ring removal bug also applied to suit when wearing a
cloak and shirt when wearing a suit or cloak or both, although it would
never give "you have nothing else to take off" because the covering item
was always present as a likely candidate. The ring fix also fixed armor.
When testing that fix, I saw "you can't take that off" for trying to take
off a suit while wearing a cloak. That isn't new or a bug, but it seemed
awfully terse so I've changed it to give "you can't take that off without
taking off your cloak first". (Likewise, "cloak", "suit", or "cloak and
suit" as appropriate when trying to take off a shirt.)
This adds new routine `suit_simple_name()', comparable to 3.4.3's
cloak_simple_name() and post-3.4.3 helm_simple_name(). No doubt there
are other places besides "without taking off your X first" that could
make use of it but I haven't attempted to track them down. The "you are
already wearing _some armor_" one doesn't quite fit. It would need to
adjust "some" to "a"/"an" at times ("some mail" or "some dragon scales"
vs "a suit" or "a jacket").
