on Sunday, April 4, 2004 at 20:27:06:
> On occassion when restoring a game where the
> character is wielding Sting, floor glyphs
> will show up before the --more-- prompt.
> These floor glyphs usually correspond to the
> location of monsters (sometimes they are just
> cavern features such as walls). Some of these
> floor glyphs are not in the character's line
> of sight upon restoring.
Also in this patch is a restore of Sting's ability
to glow blue.
Give more information about your attributes in debug mode
via Control-X.
I'd like to see some way of getting bits of this info to the
player during the game (from the Oracle or something),
but this patch keeps it limited to debug mode.
Move the counter for the next attribute check to the context
structure.
This increments patchlevel so previous save and bones
files are unuseable after applying.
Try to fix the report of a doppelganger (created from using stone-
to-flesh on a fake statue of Demogorgon) having 1700 hit points after
reverting to its native form. The problem was due to the special monster
level of Demogorgon rather than anything to do with shape changers; the
actual bug was use of `mdat->mlevel' where it should have been using
`mtmp->data->mlevel'. But the whole section of code was rather suspect
since it didn't attempt to handle other types of monsters (dragons, golems,
elementals) which have non-standard hit points, so I knocked some out.
Monsters who have gained or lost levels prior to changing form will no
longer carry that adjustment along; the new form will always be a brand
new one of its type. However, if the old form is injured at the time of
change, the new form will be too (same as before).
>If you hit a cockatrice with a weapon that immediately breaks
>(like a potion, mirror, or cockatrice egg) you get stoned,
Add a parameter to passive() to make it possible to pass
additional information that indicates that the weapon was
there at the start of the turn, but destroyed during the turn.
<Someone> wrote:
> "You kill the invisible storm giant. The boulder fills a pit."
> [...] why did I find the corpse *lying on* and not *buried in* the
> former pit?
Ensure that the corpse ends up buried in that case.
<Someone> wrote:
> You have much trouble removing u - a helmet.
> You have much trouble lifting a plate mail. Continue? [ynq] (q)
> You have much trouble removing R - a plate mail.
> You have much trouble removing N - a leather cloak.
> Why am I told that I have trouble "lifting" a plate mail?
1. Add strsubst() routine to hacklib to replace a word or phrase in a string in place.
2. Correct the inconsistency reported.
Extend the previous patch to cover all blown instruments. Also covers
the case of the player strangling. The test is moved to a new can_blow
function to keep the test in one place. It supports any monster, although
all current tests are for the player.
<Someone> drew attention to the silly message in the newsgroup
Since I'm not sure if the act of polymorphing has a sound,
I opted to use a new usmellmon() routine to put out a
message based on the smell of the resulting monster
under those circumstances.
Not every monster has a recognizable smell, so no
message at all is given in that case.
olfactory(youmonst.data) will determine whether
you are capable of detecting smells.
There is lots of room for enhancement, and some of the
existing smell-related messages in the source should perhaps
be checking olfactory(youmonst.data) too, but this patch
doesn't go that far.
It was possible to get a shopkeeper to carry the Amulet from the
bottom of the dungeon up to the location of his shop, thereby bypassing
the usual labor of lugging it up yourself. [Drop the Amulet somewhere;
rob a shop so that the Kops are summoned and the shk comes after you;
when shk is next you, level teleport to the Amulet (probably two hops,
one to the Valley and another deeper into Gehennom); walk to the vicinity
of the Amulet; shk will eventually pick it up (shopkeepers like to pick
up magic items); now, pay him for the stolen goods--he'll be pacified
and migrate back to his shop, taking his inventory with him; lastly,
return to his shop and relieve him of his burder.] This patch makes
shopkeepers drop the Amulet or invocation tools if/when they set set to
migrate to their normal location.
Also fix another long standing risk that a monster that is sent
away (nurse when healing, Kops when you pacify a shopkeeper) might be
carrying the Amulet or one of the invocation tools and make the game
unwinnable. I doubt that that's ever actually happened but I think it'd
be possible if a monster that likes magic items ever got polymorphed
into a Kop. Such dismissed monsters will now drop the same stuff as
the shk above prior to leaving the game.
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.
This provides the core support needed for status field highlighting.
This patch doesn't actually perform status field highlighting for any port,
but provides the core hooks for doing so.
The syntax is:
OPTIONS=hilite_status:{fieldname}/{threshold}/{below}/{above}
where {fieldname} is the name of a status field.
{threshold} is the value used as the threshold to trigger a display
change. It can also be set to "updown" to trigger
a display change whenever it rises or whenever it falls.
If you end the threshold value with %, then it signifies
that you want to trigger the display change based on the
percentage of maximum.
{below}, {above}
are the color or display attribute that you want to use when
the field value is underneath the threshold. Supported display
fields are: normal, inverse, bold, black, red, green,
brown, blue, magenta, cyan, gray, orange,
bright-green, yellow, bright-blue, bright-magenta,
bright-cyan, or white.
Valid field names are:
alignment, armor-class, carrying-capacity,
charisma, condition, constitution, dexterity,
dungeon-level, experience-level, experience,
gold, HD, hitpoints-max, hitpoints, hunger,
intelligence, power-max, power, score,
strength, time, title, wisdom
Refer to window.doc for details. Guidebook updates to come later.
<Someone> reported something along the lines of
"You are hit by a little dart."
[ "The dart was poisoned." -- this expected message was missing ]
"The poison doesn't seem to affect you."
Remove the overloading of ``chance for fatal poison'' and ``thrown weapon''
(which reduces that chance, among other things) for the arguments passed to
poisoned() and change how it decides whether feedback about being poisoned
is needed. Also, move poisoned() and poisontell() from mon.c to attrib.c.
Introduction of a new set of window port status display
routines. The new routines are conditional on
STATUS_VIA_WINDOWPORT
being defined in config.h. See the experimental section,
where the #define resides for the time being.
Groundwork for forthcoming stethoscope fix: add an object list
traveral routine (there must be something like this already, but I
couldn't find it...) and a couple of timer access routines.
For now, the code is conditional on BARGETHROUGH
being defined, while it gets tested further. While behavior is
different with and without BARGETHROUGH defined, savefiles
are the same either way.
After this patch is applied, only the riders have the M3_DISPLACES
bit set, but the Wizard and Vlad probably should too. Any others?
[ Caveat: compiles ok on branch code but only play tested on trunk code;
the do_wear.c diff is a lot different between the two variants and the
trunk one includes some whitespace cleanup. ]
<email deleted> reported that having a spellcasting monster
destroy some armor while you're in the midst of using 'A' to take that
armor off would result in a crash. The problem was actually more
widespread than that: having a nymph steal worn items (accessories as
well as armor), or a succubus remove them, or being interrupted by monster
activity and then reading a scroll of destroy armor prior to resuming 'A'
could all produce a similar crash. 'A' relied on stale context and could
attempt to manipulate an equipment slot which had become empty, ultimately
leading to an attempt to dereference a null pointer.
The 'R' command didn't have this problem since any accessory gets
removed immediately. The 'T' command already had handling for this:
there's only one item to deal with and multi-turn take off only applies
to some of the slots; the donning() check followed by cancel_don() took
care of those. Only 'A' was vulnerable to the problem and it wouldn't
necessarily need to be interrupted and resumed; loss of the current
multi-turn item or any pending item would be enough--but I'm not sure
whether such item loss could occur without also interrupting the current
activity, so resumption of previous 'A' was probably a requirement for
triggering the crash.
This makes shield and shirt handling be similar to other types of
armor instead of relying on the fact that none of them need to have any
attribute adjustments when put on or taken off. However, there are
still assumptions (the `cancelled_don' stuff) that some slots don't have
any eligible items requiring more than a single turn to use; that should
probably be changed.
External names longer than 31 characters trigger a compiler warning
for me about truncation, and that causes make to quit. So shorten the
two long names. Also, call the cleanup routine for the FREE_ALL_MEMORY
configuration.
An enhancement to the original to allow
two types of exceptions:
always pickup
never pickup
To specify "never pickup", begin the pattern string with '>'
which is NetHack's down direction symbol (for "leave it down")
To specify "always pickup", begin the pattern string with '<'
which is NetHack's up direction symbol.
For example, to pick up all arrows, regardless of the pickup_
types setting:
autopickup_exception = "<*arrows"
Add config.h experimental option AUTOPICKUP_EXCEPTIONS.
It's an interface-only change which allows you to add lines to your
config file to selectively avoid autopickup of items based on their
text description that is displayed when you pick them up. It does
it by matching a pattern against the xname singular return value.
For example:
autopickup_exception = "*corpse" will avoid picking up corpses, even if
food (%) is in your pickup_types.
autopickup_exception = "*brown*"
will avoid picking up any brown items (why, I do not know)
autopickup_exception = "*loadstone"
will NOT avoid picking up loadstones, unless they are already
identified, because the xname string will be "gray stone", so no
match there.
The matching has no knowledge of in-game objects, it is just
a text pattern match, thus it is an interface change, not a gameplay
change, and it is meant as a convenience for players.
> The new ^V wizmode menu is nice, but it is rather misleading; most of
> the levels it lists are "you can't get there from here". Would it be
> possible either to make it only list levels that can be reached
> directly, or alternatively to allow you to reach the ones you
> ordinarily couldn't (maybe by forcefully changing u.uz.dnum to yoink
> you into the right branch, and even summarily issuing you with an
> Amulet if you ask to teleport to the endgame).[...]; being able to bamf
> quickly to Minetown from DL 1, for example, would be damn useful in > testing stuff.
Allow fairly free roaming of the dungeon via the wizard mode teleport menu.
<email deleted> wrote:
> When wielding greyswander and a black light explodes, the
> message is still "You are freaked by a blast of kaleidoscopic
> light!" giving no indication that you are immune to
> hallucination. Maybe something like "You see a blast of color,
> but seem unaffected" would be more appropriate?
return the changed status back to the caller from
make_hallucinated().
- store the variety of tin at tin creation time
rather than at tin-opening time (as a negative
value in spe just as homemade was; spinach
is still spe 1)
Allow wishing for a particular variety of tin
from the tin variety list:
"deep fried", "boiled","broiled","candied"
"dried", "french fried", "homemade"
"pickled", "pureed", "rotten", "sauteed"
"smoked", "soup made from", "stir fried",
"szechuan"
Example: "tin of soup made from orc"
non-debug player could randomly fail on the
variety specification 1 in 4 times
This brings things much closer to correct operation (I hope).
- The shift to only moving the cursor on input (<Someone>'s
changes) had a lot of complications, among them was
that sometimes, there is no more input. When the program was
exiting, or bombing the cursor synch never got done, so the
final messages could end up strewn any place the cursor
happened to be dwelling.
- There were two competing output systems in use: the
wintty stuff for the game, and the msmsg and error stuff
used by the sys/share/pcsys, sys/share/pctty, and
sys/share/pcunix routines. Those were meant to mimic
output to stdout, where stuff just got sent to a sequential
display. Over time, there were calls mixed in that depended
on the cursor tracked stuff from the core game, so you
really couldn't be sure where things were going to display.
It wasn't as much of an issue before, because the cursor
really did get moved around as expected. Everything
now ends up in the same output system.
- I even found a use of the real putchar() because
sys/share/pcunix didn't #include wintty.h the same
as the other files, and the macro never got defined.
Who knows where that character was being put -
the game certainly couldn't track it.
While everything I knew to be wrong yesterday is
now working, there may be some other glitches
lurking that I haven't discovered yet.
Please: test, test, test.
There were still some significant startup message problems
with win32tty.
I've spent a lot of time in the debugger tracing through them all.
I think I've got them all worked out now, certainly the ones that
I was aware of. There may be some I haven't discovered.
Testing welcomed of course!
This patch also attempts to diagnose the error where someone tries
to execute NetHack directly out of a zip file, and provide
them with a (hopefully) helpful message similar to what we
might end up telling them if they wrote in. If you want
to test that part, you can comment out the line in the
Makefile that adds "dungeon" to nhdat, and delete the nhdat
in your binary and src directories, and "make install".
Then add the value of your TEMP environment variable as a
DATADIR statement in defaults.nh (here's mine):
DATADIR=C:\DOCUME~1\ALLISO~1\LOCALS~1\Temp
The diagnostic code engages if the game fails to open
dungeon. It then checks to see if it the game dir is the
TEMP directory for your system, and if so it prints the
message.
the win32 cursor restriction stuff messed up any
messages displayed during abnormal start conditions
where the window system never got initialized properly.
among them:
- messages relating to lock files or games in progress
- dungeon errors
- early panic messages
My cvs tree had the correct code. When I did a cvs update
it didn't pull anything down. When I deleted the include/extern.h
file from my cvs tree, and did an update with the "get the clean copy"
switch, it pulled down an extern.h that was indeed missing the
prototype. In all cases my local cvs reported that it was 1.130.
I applied the prototype change to the cvs copy, did a cvs diff
to ensure nothing else was out of sync and re-committed.
Cutting a shopkeeper poly'd as a long worm would generate strange messages
and could result in a crash. cutworm didn't deal with all the intricacies
of duplicating a monster. Fixed by changing cutworm() to use clone_mon()
to do most of its dirty work. It seems to me that without this change,
cutting a tame long worm could also have similar bad effects.
Other side effects of this change:
- clone_mon now takes x,y coordinates, 0,0 results in previous behavior
- clone_mon no longer always makes cloned monsters tame/peaceful if player
caused the clone, using the same formula previously in cutworm. Someone
else may wish to tweak this for gremlins.
- clone_mon will christen the new mon with the old shopkeeper's name, even
though clones are never shopkeepers (game can't handle 2 for a shop)
- cutworm can now be called during conflict or pet combat, although I
added no such calls (yet)
<Someone> wrote:
- You currently appear to be able to specify '~' and have it try
to detect monsters (though it won't detect any long worms)
Show the entire worm when specifying either '~' or 'w' now.
Allow migrated objects to break on arrival. Added code to obj_delivery to
cause this, along with a flag to keep breakage from occurring. The new
flag isn't used yet, because all the current object migration involve
objects that were moving/dropping. To help make this change, rloco now
returns whether the object was placed or not, so caller can know if an obj
pointer is still valid or not.
Making the breakage messages for MIGR_NEAR_PLAYER objects show up after the
new level is displayed required some effort (rather than while the old level
was still displayed, which was confusing), due to the needs of goto_level.
- obj_delivery now has 2 passes, one for before player arrives, another after,
allowing the two cases to be treated differently
- goto_level calls obj_delivery twice (run_timers is not called twice,
since the run required before the level is displayed will have already run
any timers on migrating object)
- kill_genocided_monsters now kills eggs on the migrating_objs list too
20000922 Water should flow into pits from broken WoD, or DoE.
This addresses the Wand of Digging part, but does not
do anything about Drum of Earthquake.
add a new melt_ice_away timer for ice created via zapping
a wand/spell of cold.
Some follow-up adjustments to the length of time before
the ice melts may be necessary. Ideally, I'd like to
have it so that the shorter the length of time since
the ice was created, the lesser the chance that it will
melt out from under you. Likewise, the longer it has
been, the more risky it will be to venture onto it.
At the moment, however, each spot of ice is just
getting a somewhat random time always greater
than 50, which is less than ideal.
Reported a while back, a (stonable) hiding monster will hide at a location
containing only a cockatrice corpse. While it would be interesting to
allow monsters to try, and stone themselves as a result, I chose the
simpler fix which is to not have monsters hide in such situations. I found
the hiding code was duplicated in several places, so I moved it into a new
hideunder() function that works for both the hero and monsters.
On September 11, 2003 "<Someone>" wrote:
> When we're going to have a different save file format, could
> the last messages in the message history be saved as well, so
> ^P would work the same before and after saving (possibly
> including a few less messages to make room for the startup
> messages?).
This seemed like a reasonable request. This patch:
- adds the core support required.
- adds the tty supporting routines.
Introduce a new set of functions to manage delayed killers in the trunk, used
in addressing the various reports of delayed killer confusion. Since existing
delayed killers are related to player properties, the delayed killers are
keyed by uprop indexes. I did this to avoid adding yet another set of
similar identifiers.
- the new delayed_killer() is used for stoning, sliming, sickness, and
delayed self-genocide while polymorphed. Some other timed events don't
use it (and didn't use the old delayed_killer variable) because they
use a fixed message when the timeout occurs.
- A new data structure, struct kinfo, is used to track both delayed and
immediate killers. This encapsulates all the info involved with
identifying a killer. The structure contains a buffer, which subsumes the
old killer_buf and several other buffers that didn't/couldn't use killer_buf.
- the killer list is saved and restored as part of the game state.
- the special case of usick_cause was removed and a delayed killer list
entry is now used in its place
- common code dealing with (un)sliming is moved to a new make_slimed function
- attempted to update all make dependencies for new end.c -> lev.h
dependency, sorry if I messed any up
This patch introduces a change to yname() and Yname2() that avoids the
possessive "your" for the hero's normal, fully identified artifacts.
Quest artifacts still get the possessive, as do all other objects and all
objects not in the hero's possession. shk_your()/Shk_Your() are used in
many places with a specific, generalized name for the object, so I didn't
introduce the artifact behavior there, although I did change them to append
a space, which simplified some other code. Through added use of yname(),
there may be some places that used to just say "corpse" that will now be more
descriptive via yname()'s use of cxname(). I'm sure <Someone> will point
out any such places that are too onerous, although nothing obviously is.
I took the opportunity to inspect many uses of "your" and even Your(). Two
new functions are also introduced, yobjnam() and Yobjnam2(), which work
like aobjnam() and yname() combined, because I found that many uses of
aobjnam() were preceeded by "your" and I couldn't generally provide the
desired behavior for artifacts (or future artifacts) without a combined
function. In some cases, this change allowed better sharing of code.
rust_dmg() still takes a string as input which is sometimes initialized
from xname() and often prepends "your" to it. Currently, this isn't a
problem since there currently are no normal, armor artifacts. If/when any
are introduced, rust_dmg() will need to be addressed.
The patch is for the trunk only. A lot of research was required and I
didn't feel the upside was there for repeating it in the 3.4.3 branch.
<email deleted> wrote:
> If more monsters fall through a trap door than can fit on the
> level below, when you go down the stairs, you get the following
> message:
> "Program in disorder - perhaps you'd better #quit.
> rloc(): couldn't relocate monster"
> This message seems to appear once for every monster-too-many that
> fell through the hole. I originally found this while
> intentionally completely filling a level with black puddings
> (there was a trap door I didn't know about). I also confirmed it
> in a wiz-mode test using gremlins and water.
[confirmed: moveloop -> deferred_goto -> goto_level ->
losedogs -> mon_arrive -> rloc -> impossible]
This patch:
- causes rloc() to return TRUE if successful,
or FALSE if it wasn't.
- adds code to mon_arrive() in dog.c to deal with
the failed rloc()
- allows the x,y parameters to mkcorpstat() to
be 0,0 in order to trigger random placement of the
corpse on the level
- if you define DEBUG_MIGRATING_MONS when you build cmd.c
then you'll have a debug-mode command #migratemons to
store the number of random monsters that you specify
on the migrating monsters chain.
> NetHack feedback form submitted by
> <email deleted>
> on Tuesday, September 9, 2003 at 06:41:34
> Hi, Just thought I'd point out a sort of inappropriate word
> choice or typo that I came across in Juiblex's Swamp. I got this
> message, after pushing a boulder into the swamp: There is a large
> splash as the boulder falls into the moat. Obviously it's a swamp
> and not a moat so that sounds a bit wrong. It says the same sort
> of thing when I #dip a scroll in the swamp as well.
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.
