* Replace variadic debugpline() with fixed argument debugpline0(str),
debugpline1(fmt,arg), and so on so that C99 support isn't required;
* showdebug() becomes a function rather than a macro and handles a
bit more;
* two debugpline() calls in light.c have been changed to impossible();
* DEBUGFILES macro (in sys.c) can substitute for SYSCF's DEBUGFILES
setting in !SYSCF configuration (I hope that's temporary).
Move debugging output into couple preprocessor defines, which
are no-op without DEBUG. To show debugging output from a
certain source files, use sysconf:
DEBUGFILES=dungeon.c questpgr.c
Also fix couple debug lines which did not compile.
This also includes fixes due to Derek Ray to depugpline to work better
on other platforms.
1) add graves to the dungeon features being tracked;
2) report on known bones (determined by seeing map spot(s) where previous
hero(es) died since there's no guarantee of graves or ghosts);
3) add automatic annotations for oracle, sokoban, bigroom, rogue level,
Ft.Ludios, castle, valley, and Moloch's sanctum. For bigroom and rogue
level you just need to visit that level, for the others you need to get
far enough along to learn something specific (oracle: her room, sokoban:
annotation is either "solved" or "unsolved" depending upon whether all
the holes and pits have been filled, fort and castle: see the drawbridge,
valley and sanctum: see inside the tended temple). Discovering the
relevant locations via magic mapping counts as "far enough along".
There should probably also be automatic annotations for Medusa and the
vibrating square but I'm not sure what criteria should be used for the
former or what phrasing to use for the latter. Demon lord/prince lairs fall
into similar category as Medusa.
TODO: add final #overview as an end of game disclosure option. (I was
planning this even before I saw that nitrohack has implemented it....)
Noticed while working on #overview/#annotate revisions, one of which
will key off the oracle's welcome message. On a bones level, the oracle
could be outside her room, or the room's one time welcome message could be
used up, or both. During bones creation, discard her if she's on the wrong
level (probably not possible, aside from wizard mode ^G), try to put her
back into her room if she's outside it on the right level, and restore the
room's type (if she's still in it, or has been successfully moved back into
it) so that next hero who loads the bones will get her welcome message the
first time that room is entered.
Other special rooms could be fixed up too, provided that they're
sufficiently intact (stealthy hero might enter and get the one-time message
then run away and die elsewhere on the level; at present, next hero won't
get the room's entry message) but this doesn't attempt to deal with that.
The wizard mode sequence
load bones? y, unlink bones? y, die, save bones? y
works, but
load bones? y, unlink bones? n, die, save bones? y, replace old bones? y
fails if/when external compression is in use. The file gets uncompressed
before being opened to check its existence, then immediately closed, and
re-compressed, changing the file's name, before the deletion attempt takes
place. Then delete_bonesfile() can't find it via the uncompressed name
and the bones saving code reports "cannot unlink old bones".
The code involved doesn't seem to have changed since the current cvs
repository was set up, so this bug has gone unnoticed for a long time.
There's no reason this fix shouldn't go into the branch too, other than the
fact that I don't have that checked out on this machine. If someone wants
to apply it there, be my guest (and move the fixes entry to fixes34.4).
[See cvs log for include/rm.h or doc/window.doc for more complete description.]
Attach hero info, death reason, and date+time to a level that's being saved
as bones. Read such data back when loading a bones file, then treat it as
part of that level for the rest of the game. Dying on a loaded bones file
will chain the new hero+death+date to previous one(s) if new bones get saved.
outrip() now takes an extra argument of type time_t, and interface-specific
implementations of this routine need to be updated to handle that.
From a bug report, receiving the
message "Your body rises from the dead as an <undead>..." gives away
the fact that bones are being created (and its absence when applicable
undead kills the hero gives away the fact that bones aren't being
created). Not very interesting for single player installations where
5-10 seconds later the player is going to check the playground for new
files, but matters on multi-user installations where players don't have
access to the directory and sometimes race each other to juicy bones,
such as nethack.alt.org.
At the end of disclosure, give the message whether bones are being
saved or not (for cases where it would have happened when bones are
created). Player won't know whether new bones are becoming available.
Also, prevent risen undead-from-hero from being given random monster
inventory, but explicitly give mummy-from-hero a mummy wrapping if the
hero isn't already carrying one. It will end up being worn; that's
the only armor mummies are allowed to put on.
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.
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.
New hero would remember part of old one's terrain discoveries (such
as presence of fountains) for bones levels. Also, some topology changes
(such as fountain destruction) can be detected by touch while blinded but
dungeon overview continued to remember the old feature. Post-3.4.3 code.
splatter_burning_oil() is called when a lit potion of oil gets
broken, and it can dish out fatal damage to the hero. An earlier fix
to prevent a light-source panic (thrown item is not on any of the object
lists) during bones creation didn't address leaving that lit potion
intact if it was on the floor (which can happen if the breakage is caused
by striking or force bolt rather than its being thrown or kicked). Use
the existing obj->in_use mechanism as a more general fix, after teaching
bones code that it applies to other things besides the hero's inventory.
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.
From a bug report: entering lava cures sliming,
but if you got [re-]afflicted by green slime after becoming stuck in lava,
#sit failed to cure it. Fix that, and have sinking farther into lava cure
it too (although not necessarily right away).
Also, suppress leaving the corpse in a bones file for death caused by
being dissolved in lava. Lastly, suppress the "you rise from the dead as
a <monster>" message during bones creation when the game ends due to being
turned into green slime since you transformed rather than died (and sliming
timeout gives "you have become green slime" just prior to that).
This patch by <email deleted> was released
when 3.4.1 was current and has been incorporated into slash'em. It is
extremely useful while using ranged weapons. When both autopickup and
pickup_thrown are enabled, walking across previously thrown objects will
pick them up even if they don't match the current pickup_types list.
[See cvs log for patchlevel.h for longer description.]
There were routines that were passed the
object name as an argument. Before the oextra
patch, ONAME() always returned a valid pointer
to a location within the obj struct. The oextra
patch worked around those cases by
using a temporary variable that was either set
to ONAME (if the obj passed the has_oname() test),
or to "" (pointer to an empty string) if no name was
present.
Since that might be a common thing to do, provide
the safe_oname() routine that you can use as a
function parameter without having to worry about
about whether ONAME(obj) is valid, and without
the need for the temporary variable.
move oattached and oname and other things that vary
the size of the obj structure into a separate
non-adjacent oextra structure, similar to what has
already been done for mextra. The obj structure
itself becomes a fixed size.
New macros:
#define ONAME(o) ((o)->oextra->oname)
#define OMID(o) ((o)->oextra->omid)
#define OMONST(o) ((o)->oextra->omonst)
#define OLONG(o) ((o)->oextra->olong)
#define OMAILCMD(o) ((o)->oextra->omailcmd)
#define has_oname(o) ((o)->oextra && ONAME(o))
#define has_omid(o) ((o)->oextra && OMID(o))
#define has_omonst(o) ((o)->oextra && OMONST(o))
#define has_olong(o) ((o)->oextra && OLONG(o))
#define has_omailcmd(o) ((o)->oextra && OMAILCMD(o))
changed macros:
has_name(mon) becomes has_mname(mon) to correspond.
The CVS repository was tagged with
NETHACK_PRE_OEXTRA
before commiting these, and
tagged with
NETHACK_POST_OEXTRA
immediately after. The diff
between those two tags is this oextra patch.
The associated mail daemon changes to use an oextra
structure instead of a hidden command located in the
name after the terminating NUL, have not been tried
or tested.
The logic in cant_revive() was a little off, so reviving a unique
corpse or statue on a bones level would recreate that unique monster instead
of making a doppelganger who's imitating it. Fixing that was simple but had
the unintended side-effect of making it impossible to deliberately create
unique monsters with ^G in wizard mode. So create_particular() has been
modified to let the user override the zombie or doppelganger conversion.
And then when not overriding, shapechangers took on random appearance, so
this also changes create_particular() to override shape changing. And that
has the side-effect of making chameleons or vampires start out as themselves
instead of as random critters or bats/fog clouds. [Better stop now! :-]
resetobjs() also needed to have extra corpse handling when saving bones
because the fix for revival wouldn't prevent you from turning to stone by
eating apparent-Medusa's corpse. Statues of uniques and corpses of special
humans like vault guards and shopkeepers didn't need anything extra; they
can retain original form until an attempt at revival is tried.
I'm not going to try to adapt this for 3.4.4.
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.
Try to address the problem From a bug report: turning the Wizard
of Yendor to stone preserves monster information with his statue and
presence of that information overrides the statue animation check
intended to prevent players from creating the Wizard (or other unique
monsters). That's ok for the current game--the monster had to have been
in play in order to be turned to stone--but is a problem if the statue
is found in a bones file. The report was for placing such a statue at
the location of an untriggered statue trap by a player who leaves bones,
but stone-to-flesh by the player who loads bones is a simpler way to
trigger this. (Aside from getting unique monsters earlier than usual
under some degree of player control they won't have their starting
inventory so special items like the Candelabrum might not get created.)
Using undead turning to revive corpses found in bones was another way to
get into the same trouble (I thought corpses of special monsters were
already excluded from bones?).
It looks like it's also possible to get strange quest behavior if
a corpse or statue of the leader or nemesis is brought into the dungeon,
left in bones, then revived by the second player, but I didn't attempt
to reproduce it. More work is probably needed; this tightens up leader
handling a bit but doesn't do anything about the nemesis. This patch
has already been spreading tentacles and I've got to cut it off....
The patch discards saved monster traits for corpses and statues of
unique monsters while saving bones; reviving or reanimating them will
produce doppelgangers instead of the original monsters, same as stone-to-
flesh on wished-for statues behaves. It also discards saved traits for
shopkeepers (also temple priests and vault guards--their traits weren't
saved in 3.4.2 though). That info might be useable when the corpse or
statue is on the same level as the monster started (ie, where its special
room is located), but that's a complication I'm going to bypass. This
patch also adds chameleon handling for statue activation--it wouldn't
have mattered in 3.4.2 since shapechangers didn't get their traits saved;
it does matter now but was omitted when trait-saving was extended to all
statues a while back. (It adds chameleon handling to corpse revival too,
but they still don't get their traits saved with corpses so that's just
protection in case of future modifications.)
Other bits: `cant_create()' is renamed to `cant_revive()' since
the latter is a more signicant use than wizard mode <ctrl/G> handling.
Now save traits with nymph corses so that cancellation can be propagated
if they're revived; that doesn't matter much but matches statue handling
(where it was more important since it dealt with succubi as well as with
nymphs). Explicitly initialize the shape-changer field of all monsters
instead of relying on implicit initialization to 0 (CHAM_ORDINARY).
There'll be a *much* shorter patch for 3.4.3 which will have to get
by with most of these obscure problems--fortunately they're unlikely to
impact many (any?) players.
Bones loading was only checking to see if a
monster was marked extinct, it wasn't adding
up the born count of a species in the current
game with the number of that species on the
bones level being loaded. That made it possible
to exceed the correct number of nazgul and
erinys via bones.
This adds a common routine called propagate()
that makemon() and restmonchn(ghostly) share,
for incrementing the born count and checking for
extinction, etc.
When a bones level is loaded, restmonchn()
will flag an illegal monster (duplicated unique,
or too many of a species) by setting the
individual monster's mhpmax to the cookie
value DEFUNCT_MONSTER. Before getbones() finishes
loading the bones level, it will purge those
monsters from the chain.
As reported, if you're twoweaponing and die, your secondary weapon may
become cursed and drop. But, the bones file code is dropping everything
and tries to drop it again, causing a panic. drop_upon_death just clears
things out, so follow suit for uswapwep.
Forwarded from the newsgroup: when a monster gets hit by wand or
spell of polymorph, any armor that fell off was protected from being
hit by that same zap, but a dropped weapon wasn't. Nor was the whole
dropped inventory in the case where the monster is killed by system
shock rather than transformed. Protect its entire inventory.
Michael pointed out that bones will never occur while swallowed because
makemon of the ghost will always fail. I suggested that the outcome made
sense, since your body may be digested, torn apart, whatever. But, there
was no explicit check for this to make it obvious this was occuring.
Pat added some error information to create_levelfile.
This does the same for create_bonesfile, but the
only place it is logged is in the paniclog, unless
you're in wizard mode. If bones file creation is
silently failing for someone and they aren't getting
bones files, this provides a way to diagnose why.
Update the other trickery situation. I don't know how I managed
to miss this. The disadvantage of suppressing extern.h from normal
dependencies I guess.
