Changes to be committed:
modified: doc/fixes35.0
modified: include/extern.h
modified: src/apply.c
modified: src/zap.c
On 3/23/2015 6:41 PM, a bug reporter wrote:
> When you're hiding under an item (e.g. via garter snake polyform), and
> that item gets polyshuddered into nonexistence, you continue hiding
> (under nothing).
This was addressed previously.
> (Incidentally, it's a bit weird that you use > to aim at items that are
> flavorwise above you at the time.)
This addresses the flavorwise concern.
Restricting the text display only to the end of game disclose,
so it doesn't clutter the inventory during gameplay and so that
the readability of t-shirts is not given away.
Bag of tricks that had been used at least once was being described
as "empty" regardless of charge count, because it always fails the
Has_contents() test. After half this patch fixed that, it started
being flagged as "empty" as soon as the last charge was used rather
than after attempting to use it again after that, since 'cknown' was
being set whenever it was used. Only set that flag when applying
the bag has been observed to fail.
My dog bit an acid blob and triggered a crash, caught by SYSCF panictrace
but yielding confusing information. The backtrace included a call from
'rustm()+N' that turned out to be passivemm(), which was deferencing a
null pointer since no weapon was involved.
On 3/23/2015 6:41 PM, a bug reporter wrote:
> When you're hiding under an item (e.g. via garter snake polyform), and
> that item gets polyshuddered into nonexistence, you continue hiding
> (under nothing).
This addresses the "hiding under nothing" bug, but does not
address this flavor comment also included in the report:
> (Incidentally, it's a bit weird that you use > to aim at items that are
> flavorwise above you at the time.)
On 3/23/2015 6:41 PM, a bug reporter wrote:
> If the game generates a graveyard, the graveyard places a normal
> demon, but all normal demons are extinct at the time, then morguemon (at
> mkroom.c line 423) indexes mons with NON_PM (the return value of
> ndemon() if it can't find a reference), which is an invalid pointer
> dereference. According to the testbench, this mostly seems to happen on
> dlvl 12.
This fixes the code violation, but the logic will now drop down to the
ghost/wraith/zombie code when that happens.
Is that desireable, or should something else happen (for variety)?
DECgraphics, IBMgraphics, and MACgraphics used to be recognized when
at least 3 letters were supplied back when they were true boolean
options. When they got demoted to shortcuts for the symset option,
they started needing 10 (DEC and IBM) or all 11 (MAC), otherwise
triggering "bad syntax in NETHACKOPTIONS" (or config file). Revert
to having the first three letters be sufficient.
This old feature alert from 3.3.0 is pretty stale, so remove
if from the code because everybody has probably suppressed
it by now.
/* Because 'Q' used to be quit... */
if (flags.suppress_alert < FEATURE_NOTICE_VER(3,3,0))
pline("Note: Please use #quit if you wish to exit the game.");
With SYSCF, the SYSCF_FILE name was overwriting the
default config file name making it unavailable for
subsequent user config file options handling.
- Keep the name of the last config file successfully opened.
- Do it without orphaning the default config file name needed
for the next pass.
Reported by Alex, the probabilites shown in the comment about the effect
of the mysterious force have been wrong ever since they were added 20 or
so years ago. Lawfuls and neutrals are much more likely to go down just
one level rather than 2 or 3.
No, not a blindness cure. :-} Post-3.4.3 revisions to makesingular()
inadvertently made it impossible to successfully wish for "the Eyes
of the Overworld" because the string got changed into "the Eye of the
Overworld" which doesn't match anything. So don't singularize "eyes".
(After this fix, wishing for "the Eyes of the Aethiopica" no longer
yields the Eye of same, but I think that's the correct behavior.)
Since that line of code is used by a lot of different ports, I decided to
recant its removal and just add #ifdef to ensure it isn't compiled on WIN32.
I think other ports might encounter the same issue where the first pass with
filename set to 'sysconf', is then going to overwrite the hard-coded user
config file name, but I can't fix or test those so for those ports, it
will be now be back the way it was.
Whenever SYSCF was enabled on Windows, the option
processing would go bonkers with illegal options
at startup. I noticed it months ago, and Derek
had it happen the other evening.
It turns out, the hard-coded 'defaults.nh' setting
was being overwritten with the name sysconf on
the first SET_IN_SYS pass, so all subsequent passes
were re-opening the SYSC_FILE instead of the
user config file.
I opted to take it out as I couldn't ascertain
why it was there in the first place.
Things won't build for ports that first
define SYSCF.
This moves assure_syscf_file() from unixmain.c
to files.c and adjusts extern.h to get it
out from under #ifdef UNIX.
The call to assure_syscf_file() in options.c was
only #ifdef SYSCF, SYSCF_FILE and not UNIX,
so new ports #defining SYSCF would get an erro.
assure_syscf_file() will be utilized by mswin
when SYSCF is defined.
Restore the variant phrasing used when more than one stack of potions of
acid explode while being inflicted with water damage. First message:
"a potion explodes" or "some potions explode"; second and subsequent
messages: "another potion explodes" or "more potions explode". This
trivial feature stopped working when erosion handling was overhauled and
old water_damage was split into current water_damage_chain+water_damage.
Augment the message so that vague "potion" is only used when the object's
dknown flag isn't set (ie, object hasn't been seen yet). Use "<color>
potion" or "potion of acid" otherwise, depending upon whether such potions
have been fully discovered.
Look up remembered dungeon features, not user-visible glyphs,
and ignore uninteresting features (room, corridor and wall tiles).
Original patch by Patric Mueller, from UnNetHack
If getenv("DEBUGFILES") yields a value then it takes precedence over
sysconf.DEBUGFILES or sys.c's #define DEBUGFILES. (It probably should
only be controlled via environment since it is not a system-wide
attribute, but I haven't taken out the SYSCF handling for it.)
Bug report included a pointer to a fix; this patch is a superset.
Gold pieces dropped on an altar by the player got their bknown flag set,
which is incorrect since bless/curse doesn't apply to coins. If a
monster (in reported case, a slain temple priest) dropped gold there too
then the two stacks wouldn't merge. For the normal !GOLDOBJ config, the
problem goes away as soon as the gold gets picked up. I didn't test for
GOLDOBJ but think two inventory slots containing gold can result.
The superset part is to not break agnostic conduct by dropping gold
on an altar since no information is revealed when doing that.
[This was one of the very last patches checked into the old cvs repository,
where the somewhat out of date message above was accidentally omitted.]
* 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).
