Allow a way to configure NetHack to run entirely from a USB stick
or other removable device in a way that allows everything to
reside entirely on the USB stick, and nothing on the computer's
hard drive. That could be done in versions prior to 3.6.3.
Sample:
i: is a USB stick
i:\nhdist contains the NetHack Windows distribution and a sysconf
file dropped into that distribution with the following entry in it:
portable_device_top = nethack
No device is included in the portable_device_top entry, the device
is always the device that the nethack exe resides on. If you try
to specify a device in the portable_device_top path, the device
portion will be ignored.
portable_device_top specifies the folder on the device that is writable
by NetHack and as such it cannot be the same folder that the executable
resides in.
i:\nhdist\nethack --showpaths
Variable playground locations:
[hackdir ]="i:\nethack\"
[leveldir ]="i:\nethack\"
[savedir ]="i:\nethack\"
[bonesdir ]="i:\nethack\"
[datadir ]="i:\nhdist\"
[scoredir ]="i:\nethack\"
[lockdir ]="i:\nethack\"
[sysconfdir]="i:\nhdist\"
[configdir ]="i:\nethack\"
[troubledir]="i:\nethack\"
NetHack's system configuration file (in sysconfdir):
"i:\nhdist\sysconf"
The loadable symbols file (in sysconfdir):
"i:\nhdist\symbols"
Basic data files (in datadir) are collected inside:
"i:\nhdist\nhdat363"
No end-of-game disclosure file (disabled).
Writable folder for portable device config (sysconf portable_device_top):
"i:\nethack\"
Your personal configuration file (in configdir):
"i:\nethack\.nethackrc"
Without that sysconf file in the NetHack distribution folder on the
USB stick with the 'portable_device_top = ' entry, the paths
return to the default locations for 3.6.3 on Windows:
i:\nhdist\nethack --showpaths
Variable playground locations:
[hackdir ]="C:\Users\JaneDoe\NetHack\3.6\"
[leveldir ]="C:\Users\JaneDoe\AppData\Local\NetHack\3.6\"
[savedir ]="C:\Users\JaneDoe\AppData\Local\NetHack\3.6\"
[bonesdir ]="C:\ProgramData\NetHack\3.6\"
[datadir ]="i:\nhdist\"
[scoredir ]="C:\ProgramData\NetHack\3.6\"
[lockdir ]="C:\ProgramData\NetHack\3.6\"
[sysconfdir]="C:\ProgramData\NetHack\3.6\"
[configdir ]="C:\Users\JaneDoe\NetHack\"
[troubledir]="C:\Users\JaneDoe\NetHack\3.6\"
NetHack's system configuration file (in sysconfdir):
"C:\ProgramData\NetHack\3.6\sysconf"
The loadable symbols file (in sysconfdir):
"C:\ProgramData\NetHack\3.6\symbols"
Basic data files (in datadir) are collected inside:
"i:\nhdist\nhdat363"
No end-of-game disclosure file (disabled).
Your personal configuration file (in configdir):
"C:\Users\JaneDoe\NetHack\.nethackrc"
the prompting on Windows wasn't working correctly if a prior game had crashed
and the self-recover feature was trying to kick in. This impacts tty, curses,
and mswin (GUI).
While not a path exactly, the dumplog file isn't placed somewhere
fixed so being able to see where it is placed could be useful.
This cascaded a bit during testing. Fix one of the warnings from
hardfought (fqn_prefix_names[]). And a few more that came up with
SYSCF disabled (panictrace_gdb, two unused variables if files.c).
Fixes#240
Monster versus monster (melee and throwing) didn't handle shades
(need silver or blessed weapon to take damage) or silver feedback
(extra info when silver-haters are hit).
I did a lot of test, revise, re-test but didn't always re-test
everything that had previously been tested, so bugs that I thought
were quashed might have crept in.
Now if a missile weapon "passes harmlessly through the shade" it
will continue on and maybe hit something else. (Regular misses
still stop at the missed target.)
A couple of minor ball&chain changes accidentally got included.
Move makeplural(body_part(FINGER)) into its own routine, with option
to substitute gloves when wearing such.
Wearing slippery gloves (ie, wearing gloves while having slippery
fingers) wouldn't let you put on a ring because you can't take the
gloves off, but removing a worn ring lacked the same restriction.
After changing that, teach prayer that slippery gloves is another
reason why a ring of levitation can't be removed.
Add
--showpaths
early option to show where NetHack is expecting to find certain files
without starting up a game. It exits afterwards.
Windows sample (for illustration only, locations may differ for you):
Variable playground locations:
[hackdir ]="C:\Users\JohnDoe\NetHack\3.6\"
[leveldir ]="C:\Users\JohnDoe\AppData\Local\NetHack\3.6\"
[savedir ]="C:\Users\JohnDoe\AppData\Local\NetHack\3.6\"
[bonesdir ]="C:\ProgramData\NetHack\3.6\"
[datadir ]="C:\personal\nhdev\363\test\binary\"
[scoredir ]="C:\ProgramData\NetHack\3.6\"
[lockdir ]="C:\ProgramData\NetHack\3.6\"
[sysconfdir]="C:\ProgramData\NetHack\3.6\"
[configdir ]="C:\Users\JohnDoe\NetHack\3.6\"
[troubledir]="C:\Users\JohnDoe\NetHack\3.6\"
Your system configuration file (in sysconfdir):
"C:\Users\JohnDoe\NetHack\3.6\sysconf"
Your system symbols file (in sysconfdir):
"C:\Users\JohnDoe\NetHack\3.6\symbols"
Your personal configuration file (in configdir):
"C:\Users\JohnDoe\NetHack\3.6\.nethackrc"
Linux (for illustration only, locations may differ for you):
Your system configuration file:
"/home/johndoe/nh/install/games/lib/nethackdir/sysconf"
Your system symbols file:
"/home/johndoe/nh/install/games/lib/nethackdir/symbols"
Your personal configuration file:
"/home/johndoe/.nethackrc"
Slippery fingers would transfer from bare hands to gloved hands if
you put gloves on. The reverse, transfering from gloves to bare
hands when taking gloves off, was already being prevented for
directly taking them off, but still allowed the slipperiness to
transfer when gloves were lost. This prevents putting on gloves
when fingers are slippery and attempts to handle cases where gloves
get unworn by ways other than 'T' (or 'R') or 'A'.
There's no slippery attribute for objects (way too much work for too
little value); slippery gloves is just the combination of wearing
gloves and having slippery fingers (which now has to have happened
while already wearing those gloves). This changes inventory to use
"(being worn; slippery)" when applicable and much of the patch deals
with funnelling Glib changes through new make_glib() to try to make
sure that persistent inventory adds or removes "; slippery" right
away when changes happen.
If gloves are taken off involuntarily (shapechange to a form that
can't wear them, destruction via scroll of destroy armor or monster
spell of same or via overenchantment, theft), slippery fingers ends
right away instead of the usual few turns later.
A few symbol-related modifications:
- fulfill a request from a blind player to allow them to
specify a unique/recognizable character for all pets and/or
the player in the config file for use when using a screen
reader (S_player_override, S_pet_override). Requires sysconf
setting ACCESSIBILITY to be set to have an effect, although
they can still be specified in the config file.
- Config file SYMBOLS entries were not working properly on
the rogue level. Allow ROGUESYMBOLS as well as SYMBOLS to be
specified in the config file independently.
- When values are moved into showsyms[], the overriding SYMBOLS
or ROGUESYMBOLS entry from the config file is used if there is
one; if there is no overriding value for a particular symbol,
the loaded symset value is used; if there is no symset entry
loaded for the symbol then a default symbol is used.
Fix a couple of bugs I stumbled across while testing something else.
The sell prompt for a container dropped in a shop had phrasing issues.
This fixes a couple but there are more. The message composition
assumes that contents fall into two categories: those already owned
by the shop and those the shopkeeper is offering to buy from the hero.
But there is a third: stuff the shopkeeper doesn't care about so
won't buy. The count_contents() routine can supply total contents or
shop-owned contents. Subtracting one from the other yields combined
hero-owned without any way to separate out shk-cares and don't-care.
Subject was "display crash while in curses mode". Restoring with
perm_invent set in config file or NETHACKOPTIONS when the save was
made while swallowed (regardless of perm_invent at that time) resulted
in a crash when invalid u.ustuck was referenced before restoration had
done its pointer fixups.
init_nhwindows() is called with perm_invent On;
restgamestate() temporarily turns it Off (3.6.2 restore hack);
if/when update_inventory() gets called, curses notices that the
persistent window has been disabled so it tears down all its windows
in order to redraw the screen without that one;
docrt() sees non-Null u.ustuck and calls swallowed();
swallowed() tries to use the value of that pointer rather than just
Null/non-Null but the value is from the previous game session, not
valid for the current session;
crash.
Make yet another attempt to prevent update_inventory() from being
called during restore. curses won't try to redraw and the crash
won't happen. But the invalid pointer is still lurking (until an
eventual fixup later during restore).
An earlier fix for update_inventory() during restore actually handled
this problem (for the most common trigger, setworn(), but not in
general), so the 3.6.2 behavior is a regression.
phase_of_moon and friday_13th determined using rn2() instead of local
time if fuzzing. Don't reseed using init_random() if fuzzing. Allow
set_random to be called outside of hacklib. rn2_on_display_rng uses
rn2 if fuzzing so that we have a single source of random that we can
ensure is reproducible. Implement rul() that returns a random unsigned
long. Fix bug in fuzzer handling of ntposkey which would cause us to use
unitialized values for x and y. Added command line arguments to allow
auto starting and stopping of fuzzer. Add a logging facility for the
fuzzer to use to record activity. Added some scripts used to automate
fuzzer testing on windows.
Extend support for highlight rules that specify percentages from HP
and spell power to experience level and experience points. For both
of those, the percentage is based on progress from the start of the
current Xp level to the start of the next Xp level. 100% isn't
possible so is used to enable highlighting a special case: 1 point
shy of next level, most likely to occur after losing a level.
This is something I had in mind a long time ago and then forgot all
about until fiddling with the final disclosure of experience points
recently. It turned out to be trickier than expected because it needs
to check whether Xp should have a status update when it hasn't changed
but Exp has gone up. The latter might hit a percentage threshold that
switches to another highlight rule. Fortunately changes to Exp, at
least that aren't part of level gain or loss (which always trigger
status updating), are all funnelled through a single place (I hope).
One of the claims in #H8849 was that a monster which zapped a wand
that the hero had fully identified made hero's knowledge of it revert
to "a wand". That doesn't happen; it had to have been a different
wand which hadn't been seen up close yet. But the hero should lose
track of known number of charges if a wand is zapped outside his/her
view. When implementing that I noticed that a monster playing a fire
horn to burn away slime was using the routine that gives wand
feedback. Add a separate, similar routine for magical horn feedback.
Half this diff is due to moving a naming support routine from mhitm.c
to do_name.c.
Fix a couple of glitches and add an enchancement. The monster
attributes structure left the 'hidden' field uninitialized unless user
specified "hidden". Mimics were being flagged with mon->mundetected
because they pass the is_hider() test but they 'hide' by taking on an
appearance rather than being unseen due to mundetected. hides_under()
monsters fail the is_hider() test, but can become mundetected if there
is at least one object present. Eels/other fish are neither is_hider()
nor hides_under() but can be mundetected at water locations. So alter
'hidden' handling to deal with these various circumstances.
Asking for 'hidden' for any type of creature will result in having its
location be highlighted if it can't be actively seen or detected. So
using '2000 ^G piranha' will fill up the Plane of Water "normally" but
'2000 ^G hidden piranha' will result in a ton of draw-glyph/delay/
draw-other-glyph/delay sequences and take a painfully long time. Moral
of the story: don't combine 'hidden' with a large count unless you
want to spend quite a while watching the level's fill pattern. Turning
off the 'sparkle' option will cut the flashing in half but still take
a long time. If you really need to fill a level with hidden creatures
and can't bear the flashing/highlighting, use blessed potion of monster
detection or #wizintrinsics to have extended detect. Then all created
monsters will be seen so none will trigger location highlighting.
If you create a 'stalker' or 'invisible stalker' or 'invisible <other-
mon>' its location won't be highlighted, but for 'hidden stalker' or
'hidden invisible stalker' or 'hidden invisible <other-mon>' it will
(provided you don't actually see it due to See_invisible or sensemon()).
Throwing or kicking a lit lamp, lit candle, or lit potion of oil
wasn't giving off any light as it travelled to its destination.
Now it does, and dungeon features, objects, or monsters that are
temporarily seen as it moves from square to square till appear on
the map. In the monster case, they go away as soon as the light
moves beyond range, but when it finishes moving the "remembered,
unseen monster" glyph will be drawn at their location. I think that
part has some room for improvement, but mapping temporarily seen
terrain features is the primary impetus for this change.
Also, any message delivery while the "lit missile" travelled still
showed its light around the hero. Noticeable for lamps or stacks
of sufficient candles if hero has no other light source.
This cannibalizes the monst->mburied bit for temporarily seeing a
monster. It has been present but unused for ages. I needed to
replace a couple of vision macros to make sure they didn't examine
it any more so that overloading for transient lighting doesn't
introduce any vision oddities. For version $NEXT, monst->mtemplit
can be given its own bit. It is only set during bhit() execution
and cleared by the time that returns, so has no effect on save files.
placebc was triggering an impossible sometimes on the plane of
water
It turned out to be because movebubbles issued an
unplacebc(), but a downstream function called
placebc(), so when movebubbles() issued its own
placebc() there was a problem.
The downstream function that beat movebubbles to the placebc()
turned out to be unstuck(). There could be others.
Changing an inventory item's bknown flag wasn't followed by a call to
update_inventory() in many circumstances, so information which should
have appeared wasn't showing up until some other event triggered an
update.
Even though a goodpos failure in mnearto() would return 0 to
the caller and trigger proper overcrowding handling for mtmp,
the 'othermon' would be left with its mx,my set to 0,0 under
that circumstance and then trigger a mon_sanity_check()
failure and accompanying impossible() message a short while
afterwards.
This also includes the addition of some flags that proved useful
for troubleshooting the mystery sanity_check failure and helping
to understand some of the code paths the struct monst data had
been through. They are only used for inspection when issues are
reported or when debugging, they don't presently control the
code flow. Their setting and use is done in an overloaded way
that should not intrude on the existing use of mspare1 for
MIGR_LEFTOVERS. mon->mstate is just a pseudonym for mon->mspare1
and does not alter save file content.
Add a bc sanity check. It seems to work ok--in other words, not
trigger--under normal punishment. I don't have any test cases to
exercise its warnings.
This dragged in a couple of minor bc changes that were pending. I
should have cleared those out before tackling the sanity checking.
During shop repair, give a message about the shopkeeper using a spell
(if hero is close enough) before "Suddenly, <various repairs occur>."
And when shop repair is for a single untrap of landmine or bear trap
adjacent to shk (and the hero can see it happen), say "<Shk> untraps
<trap>" rather than just "Suddenly, a trap is removed from the floor!"
Change in meaning of mnearto()'s return value wasn't progagated to
shkcatch(). Make it an int instead of boolean so that it can
communicate both 'moved successfully' and 'moved but had to move
another monster out of the way to do so'.
Take care of a minor 'TODO' and make another stab at getting truncated
encumbrance and/or level-description to reset to full size when enough
space becomes available.
Put the prototypes for routines in botl.c into the same order as the
corresponding functions are in the file. Also a few were missing and
another few used STATIC_OVL when STATIC_DCL was appropriate.
When the 'time' option is on and context.botl isn't already set,
call a simpler status update routine that ignores all other fields.
When that flag is already set, full status update takes care of time
along with the other fields.
Expected to reduce bottom lines processing time but not screen I/O.
Only lightly tested.
