Adds the "sortloot" compound option, with possible values
of "none", "loot", or "full". It controls the sorting of
item pickup lists for inventory and looting.
-Add a boolean option menucolors to toggle menu color
-Add MENUCOLOR -config file option
TODO:
-Better support for win32
-Support more windowports
-Update Guidebook
-Allow changing menucolor lines in-game
Re-run nhgitset.pl to install.
"perldoc DEVEL/hooksdir/nhsub" for details. General docs still to come.
Quick notes:
- "git nhsub" lets you apply substitutions to a file without involving any
version control.
- When doing nhadd/nhcommit, the working directory WILL reflect the results
of the substitutions.
Let's see what this breaks.
For those pro players who really want to try their hand
at that zen samurai, without needing to reroll thousands
of times to start with blindfold. Nudist starts without
any armor, and keeps tabs whether you wore any during
the game, for even more bragging rights.
Also makes the Book of the Dead readable even while
blind, for obvious reasons.
Instead of just "while helpless", the death reason will tell
more explicitly why the player was helpless. For example:
"while frozen by a monster's gaze"
This is Michael Deutschmann's use_darkgray -patch.
Adds a boolean option use_darkgray, settable in config file.
This patch has been in use on NAO for years, and I have heard
once someone say their terminal didn't support the dark gray
color.
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.
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)?
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
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.]
There was actually a fixes35.0 entry further down that covered off
that particular entry already which I missed first time around.
> many instances of physical damage were not taking Half_physical_damage
> into account when reducing your hitpoints
This is catching up on some things that were changed
in development years ago that Dave C. suggested be
documented.
For the record:
-The things that were evaluated and ruled out
are now documented in include/youprop.h so they don't
come up again.
- The things that were evaluated and deemed to be susceptible
to the intrinsic and thus led to a modification in the code
are listed below in this commit message.
Modifications:
- A crystal ball exploding on being applied
- Artifacts' blasting
- Being a fish out of water
- Being hit by Mjollnir on the return
- Being thwacked by an iron ball chained to you
- Boiling/freezing potions
- Broken wands
- Bumping head on ceiling by cursed levitation
- Burning (un)holy water
- Chest/door/tin traps
- Dipping a lit lamp into a potion of oil
- Exploding rings and wands (under all circumstances)
- Exploding spellbooks
- Falling downstairs
- Falling into a (spiked) pit
- Falling off or failing to mount a steed
- Falling on a sink while levitating
- Getting squished in a pit under a boulder
- Hitting your foot with a bullwhip
- Hitting yourself with your pick-axe
- Hooking yourself with a grappling hook
- iron-ball-pulling yourself out of a bear trap
- Jumping/Newton's-Thirding into something solid
- Kicking something that makes you go "Ouch!"
- Land mine explosion
- Sitting in a spiked pit
- Stinking cloud damage
- Thrown potion (bottle)
- Zapping yourself with a wand, horn or spell
- Jumping yourself out of a bear trap
From ais523's recent list of bugs:
If a long worm tail is blocking the door, and you're blind and not
telepathic, attempting to close the door marks the position of its head.
From an email received in late September 2014 before the git conversion:
> I was trying to close a door, not noticing that there was a garter
> snake there, and this message resulted:
> The garter snake stands in the way!
> I haven't tried it with any other monsters without feet, but
> "stands in the way" appears to be the wrong way to describe
> this situation...
Both of the above were found in the same function in lock.c
