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
Changes to be committed:
modified: doc/fixes36.1
modified: include/extern.h
modified: src/mon.c
Fixes H4148 (bz246) and H4150 (bz248)
comments:
I wielded a c-corpse against a shapeshifting vampire bat (checked with a
stethoscope, it said "shapeshifter".) The bat turned to stone and spawned a
vampire. I hit the vampire and it also turned to stone, so I had two statues
from one monster (vampire bat and vampire.) Not sure if this is a bug or a
feature...
comments:
Engulfed by a fog cloud that was actually a Vampire,
and got the message: "You break out of the vampire!"
Bug bz14, no web id.
Steps to reproduce:
- have a stethoscope handy.
- place an amulet in a doorway and move one square outside the room's door.
- create and lead an invisible stalker to be on top of amulet, with you
just outside the room beside the door square.
- zap the stalker asleep with a wand of sleep.
- put on a blindfold.
- quaff a potion of object detection.
- amulet shows in the doorway.
- save the game and keep the savefile for ease of returning to this point.
Bug 1 observed (remember that you're blind due to blindfold):
- zap a wand of death at the stalker that you know to be on top of
the amulet, but that the game gives no indication of.
- if the stalker left a corpse, and you apply a stethoscope to the
doorway, the game tells you that "You determine that that unfortunate
being is dead" yet no being or corpse is displayed, still just the amulet.
Fix that by calling map_object(corpse, TRUE) in its_dead() under these circumstances.
The circumstances in the original report were also reproduced, specifically:
If a stethoscope finds an unseen monster on a square with an
object-detected object while blind, after killing the monster, the
object isn't remembered.
That remains unfixed because the I (invis monster glyph) aleady overwrote the
detected object glyph, so it is a much tougher situation.
This is a fix for H4101, bz192.
add non-audio (felt) outcome to yelp()
This also add #wizintrinsic command because testing this was a pain
without a simple, straightforward way to go deaf that didn't time-out
before the situation being tested recurred.
Changes to be committed:
modified: doc/fixes36.1
modified: src/ball.c
I looked up the original bug report that led to bug page C343-20
"When dying immediately on entering a level, the map may show you dying on the previous level."
It was received public report U891:
> When one is being punished and goes down a staircase and dies because the
> ball and chain fell on their head, one gets the message about their death
> while the old level is still being displayed. I wasn't sure whether this
> was a bug or not because on one hand it wouldn't make much sense to
> generate a new level if the character is going to die anyway. However,
> that being said it does make a difference if the character is about to go
> down into a level where one cannot leave bones files, ie medusa or the
> first level of the mines (if i remember correctly). So, if your character
> dies from this does the bones file get left on the level you were on
> (which is still displayed at the time of death) or the level you died as
> soon as you got to (but was never displayed)? Thanks!
Pat had remarked in response: "So this is just a display issue; game play works as intended
(for the program; I imagine you weren't planning to get killed."
A debug trace in wizard mode 3.6.1 beta shows that the relevant code path is this:
NetHack.exe!done(int how) Line 908
NetHack.exe!losehp(int n, const char * knam, char k_format) Line 2678
NetHack.exe!drag_down(...) Line 823
NetHack.exe!goto_level(d_level * newlevel, char at_stairs, char falling, char portal) Line 1316
NetHack.exe!next_level(char at_stairs) Line 1157
NetHack.exe!dodown(...) Line 954
NetHack.exe!rhack(char * cmd) Line 3416
NetHack.exe!moveloop(char resuming) Line 464
NetHack.exe!main(int argc, char * * argv) Line 104
This patch clears the display for the situation in drag_down(),
so the old level is not shown.
Changes to be committed:
modified: doc/fixes36.1
modified: src/dogmove.c
A bug reporter wrote:
> comments:
> "You sense a little dog appear where Poes was!"
>
> seems strange to me, perhaps it should be "appearing", or the hero shouldn't
> notice at all if it's out of sight.
>
> Not sure it was out of sight, anyway, because I saw the d from the shop
> doorway.
>
Change the wording to:
"You sense that a little dog has appeared where Poes was!"
Changes to be committed:
modified: sys/share/pcmain.c
modified: sys/winnt/nttty.c
modified: sys/winnt/stubs.c
Bug 123 Report 4030:
Minor thing I've noticed - if I quit the game, at the "Hit <Enter> to end."
prompt, if I close the window rather than pressing Enter, I get the following:
Bug 138 - #H4045:
"nethack -s" leads to "-s is not supported for the Graphical Interface".
That's wrong.
(The Graphical Interface comes with "nethackw".)
Changes to be committed:
modified: win/win32/winhack.c
sys_early_init was never called for win32 GUI. That was causing "rnd(0) -
program in disorder" in tt_oname.
Changes to be committed:
modified: sys/winnt/Makefile.msc
I've noticed odd output from some of the echo statements
used in the Microsoft nmake Makefile before, but never
bothered to investigate why.
Pat observed that it was due to conversion of \t
in the path that resulted from expansion of the target
macro $@
This change uses the macro character substitution
feature to convert the back slashes to forward slashes
in the message, making the quirky conversion go away.
Changes to be committed:
modified: src/objects.c
modified: win/share/tilemap.c
Warnings during tile builds (and incorrect tile mappings
at run time when MAIL wasn't defined):
Creating 16x16 binary tile files (this may take some time)
warning: for tile 325 (numbered 325) of objects.txt,
found 'ETAOIN SHRDLU' while expecting 'stamped / mail'
warning: for tile 326 (numbered 326) of objects.txt,
found 'LOREM IPSUM' while expecting 'ETAOIN SHRDLU'
The recent addition of the first new extra scroll descriptions in a
very long time caused this problem to show up when MAIL was undefined.
There was a magic number in use that made an assumption that there
were only 4 such extra scroll descriptions, those being
"FOOBIE BLETCH", "TEMOV","GARVEN DEH","READ ME"
Changes to be committed:
modified: Files
deleted: sys/winnt/Makefile.bcc
modified: sys/winnt/Makefile.gcc
modified: win/win32/winMS.h
Since borland Makefile isn't operational, remove it for
this release as recommended.
Changes to install.nt pending.
nhmall