build system.
Anyone who wants to do a build from sys/unix and doesn't want to figure this
out just needs to do:
sh setup.sh hints/unix
instead of:
sh setup.sh
and then continue on as usual.
New files:
sys/unix/NewInstall.unx - the new directions
sys/unix/hints/* - the hints files. There will be more later.
sys/unix/mkmkfile.sh - helper for setup.sh
Summary of changes:
see NewInstall.unx for info on the new build system
introduction of various preprocessor symbols to turn options off that
are defaulted on historically
comment out nethackrc (and similar) entries that still use the old symbol
syntax.
commenting out of Makefile.* lines that now come from hints/unix
GAMEDIR is replaced with HACKDIR so the Makefiles and the C source agree.
Note that I have NOT changed the docs and/or Makefiles for be, msdos, os2,
vms, or winnt. If port maintainers don't then I will, but I can't test
those ports.
nethack.sh now handles the font path automatically
Get rid of most of the vestiges of the old warning code that was
replaced over 7 years ago. I left the list of colors which were used for
warning flashes.
In the newsgroup about three weeks ago someone described trying to
use the Bell of Opening to find the magic portal on the Plane of Water
and not succeeding. It's supposed to work like a wand of secret door
detection to mark nearby traps as known. And does, but it turns out
that the wand wasn't working as expected there either. They both require
line of sight, and since the water outside of the bubbles blocks that
they only found the portal if it was within the same bubble as the hero.
(Clouds on the Plane of Air posed a similar problem, although monster
activity usually reveals the portal on that level so this wasn't much of
an issue there.) Since the detection magic doesn't require the hero to
see the traps--wand and Bell both work while blind--this patch overrides
the line of sight requirement on the Planes of Water and Air. As long as
hero is within the detection magic's range, the portals on those levels
will get marked as having been seen and when the hero gets into the right
bubble or out of the clouds the portal traps will be shown on the map.
The line-of-sight override code is simple-minded and lets players
find traps through boulders when/if those are present (but the found
traps won't be seen yet since vision still controls the map display).
Also, it assumes that only water/air/cloud terrain is present so could
potentially yield strange results if any other terrain gets introduced on
either of those two levels.
Fix the problem From a bug report. His system has a logical name "DATA" pointing at some disk, and
when the dlb utility tried to open "data" for inclusion in the library
being built at install time, it attempted to access the wrong thing and
failed. He then attempted to fix it in a manner which let dlb finish, by
modifying dlb_main.c to append "." to file names that lack a dot, but
then nethack couldn't access "dungeon" in the library because string
comparison didn't match the altered dlb directory entry of "dungeon.".
NetHack was working around this unintended interaction with the
environment issue in fopen_datafile(), and dlb was doing so for fopen()
but not open(). This moves nethack's fixup out of src/files.c and into
sys/vms/vmsfiles.c, adds another routine there so that both open() and
fopen() are covered, and updates the vms Makefiles so that the various
utility programs all link with vmsfiles. (The build script vmsbuild.com
puts object files into a library and gets that last bit for free.)
From a bug report, when ice on the Valkyrie
quest home level was melted and a boulder filled the resulting pool, that
pool was described as a moat. This was actually a terrain issue rather
than a formatting glitch, so instead of tweaking waterbody_name() with an
extra special case, extend the level compiler to allow specifying ice as
frozen pool instead of always being frozen moat. There's no provision
for having both types of ice on the same level, just a level-wide flag to
control which of the two applies for ice on that level.
This change has a side-effect for the V quest levels: once ice has
been melted, a second blast of fire will now boil away the pool and leave
a pit. The unfrozen water locations on the home level already behaved
that way (ie, they are pools rather than moats) so this should be ok. I
also added <Someone>'s suggestion to make one of the two drawbridges
on the goal level start in random state instead of always being open.
Using F prefix when trying to move into a wall or closed door yielded
"you attack thin air". Like the recently fixed F-vs-boulder case, give
more appropriate feedback. Also like F-vs-boulder, initiate digging if
wielding a pick-axe. (Also handles axes versus trees and closed doors).
One thing which isn't handled but possibly should be: F vs closed
door when not wielding a pick or other axe might attempt to force the door.
(Right now it gives "you harmlessly attack the door".)
This is one of the items from "#Q397: List of Bugs from #nethack" sent
in Janurary by <email deleted> and containing a list
of things collected from the IRC channel associated with nethack.alt.org's
public server. Moving diagonally between segments of a worm tail is
conceptually passing right through the worm's body. This patch prevents
moving in such a fashion for both the hero and monsters (it's still
possible to fight in that position though). It only applies when the two
tail segments are consecutive.
|...... In the diagram here, where tail segments are represented by
|.w1?.. digits indicating relative sequence number, the @ can still
|..@2.. move between segments 2 and 5 to reach !, but can no longer
|.65!3. move between 1 and 2 to reach ?. [However, if there is a
|...4.. monster at the ? spot, it can still hit @ and vice versa.]
Missiles and wand zaps still pass through such diagonals without
noticing or affecting the worm. I'm not sure whether this ought to be
extended to change that--it might get pretty messy since it would need
to be considered during monsters' targetting as well as during the path
traversal itself.
It's possible for the player to put escape sequences into strings via
dogname/catname/fruit options (or probably interactively by using "\233"
instead of "\033["--the two character 7-bit version wouldn't work because
its leading ESC gets treated as player's request to abort current input,
but the 8-bit version probably works, I just can't test it because I don't
know how to type such things with this terminal emulator). Such sequences
can do funny things like clear the screen and say "game over" (or worse
with creative abuse of some terminals' "answer back" capability--when
reproducing the reported situation, I kept things simple and had my dog's
name underlined and fruit name blinking; they displayed correctly but
nethack was confused about how long they were since it doesn't expect to
be given characters which don't advance the cursor). This fix still lets
users experiment with such stuff during their own games, but it replaces
suspect characters while loading bones data, so if one player creates a
bones file with suspect strings in it, another can--I hope--be able to
use that file safely.
Monster and object names, engravings, and named fruits are handled.
For the last, if uncensored string matches one already present then it
leaves that alone, so bones data created with same OPTIONS=fruit:whatever
as being used in the current game will continue to keep the same value.
Redo the $WIZKIT overflow handling from a few days ago. Instead of
having two migration codes which both mean "with the hero", combine them
and add a mask flag to control scattering at the destination to be able to
get the alternate behavior.
Wizard mode's $WIZKIT can specify an unlimited number of items to
add to starting inventory and they'd be put there without regard to the
number of slots in use, potentially resulting in an arbitrary number of
'#' slot items. Cap at 52 slots, same as when picking up, and put any
excess items at the hero's feet. It's slightly tricky because the level
hasn't been created yet at the time the wizkit gets processed.
For GOLDOBJ configuration, relax the 52 object limit for inventory
when gold uses the special $ slot instead of a letter. Takes care of an
old buglist entry from the beta testers. [It will need to be revisited
if we ever implement multiple coin types that can't all fit in one slot.]
Also for GOLDOBJ, prevents nymphs and monkeys from stealing coins,
since allowing that made their steal-item attack be a complete superset
of leprechaun's steal-gold attack.
Reported to us by <email deleted>:
'You are beginning to feel hungry. You trip over it.'
and also recently in the newsgroup by "<Someone>":
There is ice here. *You see here an electric eel corpse.*
Bib hits the electric eel. Bib misses the electric eel.
Bib misses the electric eel. The electric eel misses Bib.
The electric eel misses Bib. *You trip over it.*
slip_or_trip() was oversimplifying things by assuming that if there
is one object at the hero's location, a message about what that object is
has just been given. Any timeout message which precedes Fumbling (lots
of candiates besides hunger) could intervene, as could monster activity
between the hero's move and timeout handling. Aside from the reported
cases, that code hadn't been updated to account for the new pile_limit
option which could be set to 1 and force a popup display instead of the
usual "you see <an item> here". This fix adds a flag that can be used
to track the most recent message. It is cleared by pline for every
message, so pline's caller sets it _after_ the message of interest has
been displayed.
From a four year old news posting: hero was levitating via #invoke
on the Heart of Ahriman, then dropping that artifact yielded:
You drop a gray stone named The Heart of Ahriman.
You float gently to the floor.
A gray stone named The Heart of Ahriman hits the floor.
That might be strictly correct, assuming that both hero and stone fall at
the same speed; if the stone was dropped from perhaps waist height then
the hero's feet would touch first. But it looks strange, like a cartoon
where something hangs in midair until someone notices that it should fall.
Removing the artifact from inventory causes the #invoke property to
toggle off. Unfortunately it has to be done here before the object can
be placed at its destination. Modifying message order seemed unviable;
this fix fiddles with the Levitation property in order to defer hero's
descent until after object handling is finished. Now same setup gives:
You drop a gray stone named The Heart of Ahriman.
A gray stone named The Heart of Ahriman hits the floor.
You float gently to the floor.
You see here a gray stone named The Heart of Ahriman.
From a 7.5 year old news posting (with a reply by Kevin Hugo speaking
on behalf of slash'em...): when a monster "nimbly jumps to evade" hero's
kick, it can pass through walls and grid bugs can jump off their grid.
Likewise when a joust or staggering blow knocks a monster back, it could
move grid bugs diagonally. This fixes both cases.
Offhand I can't think of any other non-standard movement situations
which might need similar handling, but it wouldn't surprise me if there
are some. Leashed movement is close but I don't think maybe_mnexto helps.
Implement <Someone>'s menu-mode for #name, primarily because it
is the natural place to add [re]naming entries in the discoveries list,
something that was requested in the newsgroup ten or so years ago. The
latter allows changing the type name of something which has previously
been named and is no longer being carried.
This also makes the C command become a synonym for #name or vice
versa; one or the other could now be reassigned to something else.
#name
What do you want to name?
a - a monster
b - a particular object in inventory
c - a type of object in inventory
d - a type of object on discoveries list
Menu group accelerators provide unseen alternate choices: C for monster,
y for individual object, n for object type (and d for discoveries, but
that's only interesting if inventory is empty so that usual b & c are
omitted and discoveries entry moves up to b). These alternates allow
`#name y' and `#name n' to work the same as before, for users who have
trouble retraining their fingers. Using C to name a monster now takes an
extra keystroke, but using `C C' for it could make that be less annoying.
From a bug report: amulet of strangulation
continues to kill hero if he polymorphs into a creature which doesn't
need to breathe or doesn't have a head or even a circulatory system.
Currently, the messages are different when the hero doesn't need to
breathe, but that doesn't seem good enough. This makes strangulation
stop when you polymorph into something which shouldn't be vulnerable and
restart if you poly into something vulnerable while still wearing the
bad amulet.
can_be_strangled() is doing more checks that necessary, in case the
strangulation property ever gets conferred by something other than an
amulet. Its criteria for protection from strangling might need tweaking.
Add #vanquished command to show the vanquished monsters list during
play. At present it's only available in wizard mode. Slash'em has it as
a regular mode command, and I found it handy sometimes: when I managed to
kill an unfamiliar monster, I could immediately get an idea of how the game
ranked its difficulty compared to other monsters. But having this command
available might encourage extinctionism. On the other hand, it might stop
some existing extinctionists from cycles of save+copy+restore+quit to view
disclosure data for their current game.
This also makes merging the wizard mode extended commands into other
extended commands be more robust. It will panic instead of going out of
array bounds if someone adds entries to debug_extcmdlist[] without also
expanding extcmdlist[] to make room.
From the newsgroup: Sunsword is ineffective against shades. It
gets a special bonus of double damage vs undead, but since it's not made
of silver it was only doing 1 point of damage against shades. Make the
bonus-vs-undead attribute override the silver-required criterion. (No
comparable handling for flimsy weapons against thick-skinned critters
this time.)
When testing the monster-breath-at-self patch I noticed that trying
to cure green slime by having hero breathe at self didn't work. The code
was calling buzz() with arguments that produced an attack directed against
the hero's location, but there was a chance for it to miss outright and
when it didn't, reflection would block it. This makes breathing at
yourself with `#monster' comparable to zapping a wand or casting a spell
at yourself: it always hits.
Extend makeplural/makesingular case-insensitivity to vtense() and to
wizard mode wishing for dungeon features. And the previous set of fixes
missed one: makesingular("zombies") was producing "zomby". Plus a bit of
groundwork for a likely second overhaul of makeplural/makesingular.
I stumbled across a copy of an old newsgroup bug report which
complained that wishing for "Gauntlets of Power" didn't work. I thought
that this was something which had already been fixed, but when I tried it
out, I discovered that you still couldn't wish for that. It was failing
because case-sensitive makesinglar() didn't recognize that "Gauntlets"
needs special handling. After the unwanted transformation, the case-
insensitive object matching would fail to find "gauntlet of power".
Removing case-sensitivity for special cases like "boots" and "gloves"
would have fixed that, but this patch goes further and removes case-
sensitivity entirely for both makesingular and makeplural. Words which
get their endings modified work when the input is upper or mixed case.
Any modified letters retain the case of the original, so the reason for
case-sensitivity--user specified fruits that aren't lower case--is covered.
Some makeplural fixes: the plural for dingo is dingoes (dictionary
says "-es", not "-s") and for roshi is roshi (just guessing here; most of
the Japanese names use same spelling for singular and plural, but we were
producing roshis). Several words which makesingular leaves in plural form
(boots, gloves, &c) are now recognized by makeplural (avoiding gloveses).
It also fixes a bunch of incorrect singularizations of plural monster
names: foxes, *wolves, lynxes, fungi/humunculi/succubi, mumakil, wumpuses,
baluchitheria, Aleaxes, *elves, erinyes, djinn, priestesses, & valkyries.
Some non-monsters that makeplural handles correctly were also not being
singularized right: feet, hooves, lice/mice, algae, children, nemeses.
Like their use of lizard corpses to defeat being turned into stone,
let monsters use wands of fire, fire horns, and scrolls of fire to try to
defeat being turned into slime. If the scroll is read while confused, it
won't succeed. Otherwise, monsters who don't resist fire will take some
damage in the process and might end up killing themselves (although with
the testing I've gone I've yet to see that happen--I guess that means
that handling for dying-in-the-process hasn't been adequately tested...).
So far, they don't know how to jump onto adjacent fire traps, nor
will fire breathing monsters breath at themselves. I don't know whether
I'll get around to tackling either of those.
New macro slimeproof() to decide whether something is susceptible
to turning into green slime. Most of this is just making use of existing
cached permonst values in damageum() and mdamagem() and shouldn't affect
anything. I wanted to avoid mixing that in with the actual slime changes
which are coming.
Something that pops up in the newsgroup periodically, with <Someone>
inevitably pointing out the bit of code that the user needs to tweak,
about control of feedback when hero is walking across floor objects.
Implement new option ``pile_limit'' which allows user to set the point
at which the game switches from listing the objects to giving "there are
several/many objects here". Default is 5, same as previous hard-coded
value (1 object gets listed via pline, 2..4 are listed in a corner popup,
5 or more objects yields a pline message instead). Setting pile_limit
to 0 means no limit, so objects will always be listed regardless of pile
size. Setting it to 1 effectively forces no listing since any non-empty
pile size is always at least that big, so can produce "there is an object
here" even though that's no briefer than a pline() to show one object.
From a bug report, mimics
which were exposed at the time the hero leaves a level remain unhidden
upon return no matter how long the hero is away. It was actually expected
behavior since the old level is stuck in stasis and hiders only hide when
it's their turn to move, but it was noticeably odd. This makes unhidden
hiders attempt to hide when hero returns to a previous level or enters a
bones level. I reorganized the monster handling in getlev() because the
relevant part was taking place before floor objects got restored, so
hidesunder() monsters had nothing to hide under at the time.
Noticed while looking at something else: zapping a wand of opening
or spell of knock downwards while riding causes your steed's saddle to
fall off, which in turn causes the hero to fall and take some damage.
If that damage was fatal, the saddle would be left worn in bones data.
This reorganizes mdrop_obj() to defer until last the part that ultimately
makes the hero fall off, and changes bhitm() to call that instead of
handling saddle removal inline, also gives new saddle-off feedback there.
Reported in Dec'04 by <email deleted>, the
monster spell "summon nasties" could mistakenly give a message of "a
monster appears" instead of "monsters appear" when more that one monster
gets summoned. Some of the candidate monsters for nasty() can produce a
group from makemon(), as can ones for msummon() which nasty() sometimes
calls in Gehennom. Compare the number of monsters before and after the
creation attempt(s) instead of assuming makemon() creates one at a time.
I don't know whether other routines face the same mis-count issue,
but I suspect there may be several.
Another item from the Dec'04 report sent in by <email deleted>. When prompted for a type of monster to polymorph
into, giving a monster class description like "dog or other canine" (or
single letter like 'd'), triggered "I've never heard of such monsters".
Instead of adjusting the message, this chooses a member from the class.
I put this into the fixes file as a new feature.
Move the code for determining monster class from user's input string
out of do_class_genocide() and into new routine name_to_monclass(). I'm
planning to use it when name_to_mon fails to match anything for controlled
polymorph (not ready for prime time yet).
Also, avoid getting stuck in a loop if hangup occurs while prompting
player for class of monster to genocide. ESC, whether deliberate or fake
input after hangup, will now be the same as specifying "none", throwing
away the genocide opportunity.
<email deleted> reported a long list
of inconsistencies and suggestions. This attempts to address the ones
about werecritters and vampires.
> Polymorphed player does not get werecreature changes. (intentional?)
> Player in were form does not turn into werehuman form, ever. (Previous
> bugged behavior was that player turned into a plain human)
> Player afflicted with a were cannot polymorph into werecreature or
> werehuman form.
The first guess is right; being polymorphed blocks lycanthropy state
changes. The second is not a bug either; hero is either a <werecritter>
when in beast form or a <role> when in human form, never human werecritter
monster. The last one feels more like a bug though; it happened because
all lycanthrope monster entries are marked NOPOLY. This patch extends
an earlier post-3.4.3 change to allow player with polymorph control to
explicitly specify werecritter when in role form or human werecritter when
in beast form to toggle shape. It also allows closely related monsters
to toggle from role to beast (ie, "giant rat" yields wererat).
> Vampire or Werecreature changing form may change sex.
Now the three semi-controlled changes--becoming a dragon due to armor,
toggling were form, and vampire into various critters--are prevented from
having the 10% chance of sex change kick in. For monsters, lycanthropy
didn't apply (sex never toggles) and vampire shifting is now covered but
turning into a dragon due to scales/mail remains susceptible to sex change.
Also, post-3.4.3 code made polymorphing into a vampire enable the
#monster command but neglected to tell the player.
Zapping cold at an ice location which has a melt timer would set
new timeout to a random value which could actually cause that ice to melt
sooner. Make sure the new value is always at least as big as the old one.
Also, MAX_ICE_TIMEOUT wasn't actually the maximum ice timeout; now it
is--if the generated value is higher, omit the timer so that that ice is
permanent. No fixes35.0 entries necessary; this is post-3.4.3 code.
Back in Nov'04, <Someone> pointed out that even with only 5%
chance for dropping a horn upon the death of a unicorn which has been
revived from corpse, it's still possible to produce a nearly unlimited
number of them for polypile fodder. This bumps the chance for a horn up
to 50%, but flags the horn as coming from a revived corpse and makes such
horns be treated by polymoprh as if they're non-magic (which practically
guarantees that they'll poly into mundane tools instead of magic ones).
Wielding a bow while kicking arrows gave a shooting bonus. Also,
From a bug report: applying a
polearm to hit at range never caused a pudding to split because the attack
gets treated as throwing. Likewise, confuse monster effect (hands glowing
red) didn't kick in for applied polearms.
<email deleted> reported back on 8/31/06 that elven weapons were not
affected when he poked a fire elemental with them. This is true, but
moreover, there was no code to have passive fire to affect attackers.
Now erode_obj() supports all the same damage types as rust_dmg(), and added
the connecting code to allow passive fire attacks do something.
There probably should be macros for the damage types used by rust_dmg
and erode_obj, and possibly these functions should be combined, but they
are slightly different and dealing with that requires more thought.
Make polymorphing or changing alignment perform a touch check (as is
done when catching lycanthropy) on wielded weapon(s) to see whether the
hero can still use them in his new form. Part [2 of 2] will update
retouch_equipment() to check all items in use rather than just weapon(s).
(A comment or two in part 1 already refers to expected behavior of part 2.)
Monster werecritters are vulnerable to silver when in human form as
well as when in beast form, but hero inflicted with lycanthropy was only
vulnerable while in beast form. Add pseudo-property Hate_silver to handle
that correctly. Also, add silver vulnerability to enlightenment feedback.
Lastly, hero vulnerable to silver had Con abused if hit by silver missile
but not when hit hand-to-hand; add an exercise() call to the latter.
Instead of duplicating the bits of spoteffects() which are relevant
to pools of water and lava when standing still, split spoteffects in two
in order to call the relevant half directly.
<email deleted>, escaping from being stuck
by lava via jumping--or simply walking--got you out of the lava while being
at the same location. You could then stay there for as long as you liked
without falling back in. This makes a lava and water check on turns where
time passes but hero hasn't moved, performing a subset of spoteffects().
I think the water case only matters when using wizard mode to wish for a
pool or moat, which gets created at hero's feet without making him fall in
(unlike wishing for lava, where hero does immediately fall in).
From a bug report, trying
to invoke a wielded artifact after changing alignment resulted in "the
<artifact> evades your grasp" but it remained wielded, contradicting the
message. This adjusts the message in touch_artifact() if the object is
already in inventory, and adds retouch_object() to handle cases where
failing to be able to touch ought to force unwearing/unwielding.
The majority of our calls to strncpy are in the form
(void) strncpy(dst, src, n);
dst[n] = '\0';
so add a new routine, copynchars, which does that. A few calls care
about strncpy's return value and at least one relies on it only copying a
substring without also terminating the output, but most don't care about
either and none seem to care that `n' ought to have type size_t instead of
int. The new routine matches our usage better, but I haven't gone through
to change the existing strncpy calls.
Dying at a shop doorway, or at the free spot one step in, while not
owing the shopkeeper anything would yield "<shk> gratefully inherites all
your possessions" but leave those possesions where the next hero could
just pick them up for free. Move them all the way inside the shop, as
happens when the hero dies while owing the shk. Also, if hero has gold
left after shopkeeper takes any payment owed, force it to go into shk's
inventory instead of having it end up in the pile of other stuff.
finish_paybill() duplicated much of drop_upon_death(), but not the
two-weapon hack to avoid curse() causing hero's secondary weapon to be
dropped while in the midst of removing it from inventory (but unlike the
old 3.4.1 panic for that, this one just triggered a warning about nonzero
worn mask). It also lacked the named fruit fixup, whatever that does.
Make finish_paybill() call drop_upon_death() instead of copying it.
Some groundwork useful for the interface code I've been working on.
If we already have some direction to name-of-direction code somewhere, I
couldn't find it.
Someone in the newsgroup complained about zapping probing at a large
box dropped by a quantum mechanic and being told that it was empty rather
than that it held a corpse or live cat. This sidesteps the issue by
reporting "the box seems empty" instead of "the box is empty", and not
setting its contents-known flag. (That message is the main difference
between probing and the assorted other methods of observation [telepathy
and monster detection and possibly Warning for live cat, object detection
and food detection for dead cat's corpse] which might be expected to
trigger the cat's fate but don't.) This also makes probing of self and
of monsters set the contents-known and locking-known flags for containers
in inventory, same as is done for probing which hits objects. (Display of
container contents still only occurs for loose objects, not in inventory.)
Reported to the beta-testers list by <Someone> last April:
restoring a normal game save file in explore mode let you keep the file,
then after exploring and quitting without saving, you could restore it
again in normal mode and take advantage of whatever information you'd
gained. This makes nethack -X (or playmode:explore) defer the switch to
explore mode when used while restoring a normal mode save file. It now
performs a normal restore (with save file deletion) and then acts as if
the user had given the 'X' command interactively, requiring confirmation
to actually switch into explore mode.
Reorganize the recent wizard mode control: move set_playmode() from
xxxmain.c to the core, and have it call new authorize_wizard_mode() to do
the port-specific part. If the set_playmode() call during startup doesn't
result in running in wizard mode (either because not allowed or user
didn't request it), it will be called again during restore if the save
file is from a wizard mode game.
For ports which check character name for authorization, players will
have to use `nethack -u whatever -D' (or options for name and playmode) to
restore a wizard mode save file if WIZARD has been changed from "wizard".
plname[] from a wizard mode saved game will always have that value, so if
it's not the right one players will need to get authorized by the startup
code before loading the save file.
