'Poisoned by a rotted gray ooze corpse' should have been
'Poisoned by a rotted glob of gray ooze'.
eatcorpse() is called for non-corpse globs and then corpse_xname()
is called for them too to set up death reason for make_sick(), but
it didn't know anything about globs. Now it does. Blob size is
ignored since it's not relevant for cause of death.
Stepping onto lava destroyed water walking boots if they weren't
fireproof but didn't do that for other types of boots unless hero
was not fire resistant and got killed by the lava. Burn up all
non-fireproof leather boots when stepping onto lava.
Also #terrain command with dark_room on showed lit room floor on places with
objects or traps. We don't want to show dark room symbol anyway, because
the dark room symbols are only for line-of-sight, and #terrain should
override that...
ck_server_admin_msg() is only available for '#if (UNIX && MAIL)' but
moveloop() tried to call it unconditionally. Call if from the UNIX
edition of ckmailstatus() instead.
It's occasionally important for public servers to notify
all the players. Sending a mail is not reliable, as not everyone
wants to break conduct, or have mail on.
This adds a compile-time defined filename, which NetHack
will monitor. The contents of the file are in the same
format as SIMPLE_MAIL: "sender:message" on one line.
Fix the vault guard error in dochug() discovered by Alex K. The
behavior of a vault guard ignoring Conflict when confronting the
hero in the vault and escorting him through the temporary corridor
isn't affected. 3.4.3 already behaved that way. (I didn't track
the cause of that down so don't know whether it's intentional.)
Steps to make sure 'kickedobj' didn't end up as a stale pointer
prevented it from being around to format the reason for death when
a kicking attempt was fatal.
Move autopickup exception, menucolor, and message type entries
in the options menu under "Other settings" -header, and reorders
them into alphabetical order.
Also use enums instead of hardcoded values.
Changes to be committed:
modified: src/files.c
modified: sys/share/pcmain.c
Related to #H4170, bz274
The current startup code seeks out the SYSCONFPREFIX using:
envp = nh_getenv("COMMONPROGRAMFILES");
which is fine and usually translates to something like
"C:\\Program Files (x86)\\Common Files\\
NetHack then tacks on the NetHack subfolder to the path
"C:\\Program Files (x86)\\Common Files\\NetHack\\"
That should always be the definitive location.
However, in the event that there is no SYSCF_FILE actually
located at that system-wide spot (and ONLY in that event),
fall back to a secondary location of HACKDIR for locating
the SYSCF_FILE.
Also, there's some explicit tweaking added for the Microsoft
visual studio compiler debug execution to all a debug
session to correctly locate things. By default, on a
visual studio build, the executables are linked down in
subfolders of the build directory (Release, or Debug,
depending on visual studio build configuration options).
Bug 271 - #H4167: vampires being fog clouds show up as bats on telepathy
A bug reporter wrote:
> In top level of Vlad's, the vampires hiding as fog clouds in the closets show
> up on telepathy as B, when far-looked as vampire bat. once the door opens they
> are fog clouds.
>
> I currently have telepathy from the PYEC.
The vampire /was/ shapeshifted into a vampire bat, but once the secret door
was revealed, it shifted into a fog cloud in order to pass under the door.
If you were to blast the door with a wand of striking from a distance,
you would have encountered the vampire bat.
This clarifies the situation through better messaging.
--------
Original debug call stack trace:
NetHack.exe!newcham(monst * mtmp, permonst * mdat, char polyspot, char msg) Line 3140
NetHack.exe!vamp_shift(monst * mon, permonst * ptr) Line 1598
NetHack.exe!m_move(monst * mtmp, int after) Line 1219
NetHack.exe!dochug(monst * mtmp) Line 566
NetHack.exe!dochugw(monst * mtmp) Line 100
NetHack.exe!movemon(...) Line 707
NetHack.exe!moveloop(char resuming) Line 105
NetHack.exe!main(int argc, char * * argv) Line 105
Requested by a blind player. The message "Fido moves only reluctantly"
didn't convey enough information to be useful. Describe the reason why
the move is reluctant: "Fido steps reluctantly over <some object>."
If there is a pile, it will describe the top item rather than whichever
cursed item the pet doesn't want to step on.
Change "unlockable" to "broken" so that it won't be misunderstood to
mean "capable of being unlocked". The accompanying suggestion to omit
"broken" unless/until a lock or unlock attempt is made is no good since
the main reason for describing the broken lock is to avoid unnecessary
attempts to lock or unlock a container that the hero knows to be broken
but the player may have forgotten.
I also changed remote look-at for objects to use distant_name(doname)
instead of distant_name(xname) so that qualifiers like "empty" and
"broken" will show up on chests you've investigated before but aren't
standing on now. Monster type for corpse also gets shown, instead of
just 'food (corpse)'. Other remote items will become more verbose,
but only those that the hero has already seen up close.
From a report sent directly to devteam: the #terrain command had the
same bug as the '`' command (which was one of the very first ones
reported): impossible("add_menu called before start_menu"). Only X11
notices.
Reported directly to devteam: teleporting or polymorphing a sink when
dropping the relevant ring into it was suppressed if the hero couldn't
see it happen.
Being unable to see the sink transform or vanish shouldn't stop that
from happening. Since the hero is known to not be levitating (because
of the sink), it can be assumed that he can feel the transformation or
vanishment (is that a real word?), so use the same messages regardless
of blindness.
Noticed while testing a potential change to running while confused:
when confusion timed out, I kept running even though I was headed in
the wrong direction. Timeout calls stop_occupation() but running is
not an occupation.
Make stop_occupation() also stop counted activity under control of
the player (ie, multi > 0). Some places in the code use both
stop_occuation() and nomul(0), some just use one or the other. But
most of those probably intend for both.
