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"
In order for 'make depend' to be able to handle both Qt4/5 and Qt3,
they need to operate on different object file names.
renames qt*.o to qt3*.o for Qt3
renames qt*.cpp to qt3*.cpp for Qt3 (not essential but seems worthwhile)
moves Qt3's headers from include/qt*.h to win/Qt3/qt3*.h
copies include/qt_xpms.h (before rename) or win/Qt3/qt3_xpms.h (after)
to win/Qt/qt_xpms.h so that Qt4/5 no longer shares one header file
modifies win/Qt3/*.cpp and win/Qt3/qt3_win.h to reflect new header names
modifies Makefile.src to have Qt3 'moc' commands use new names
updates Makefile.src via re-running 'make depend'
'make depend' was only looking at include/*.h to find nested inclusion.
Now it will also look at win/*/*.h. That found a bunch of missing
dependencies for the old gnome sources and a few for Qt3.
Building without Qt still works. Building with it (any version) has
not been tested.
Izchak implemented the mysterious force and as far as I'm concerned,
it's here to stay. But it can be fine tuned. This is an experimental
attempt to make it happen less. Each time it happens, the chance for
it happening again later will usually go down by an amount proportional
to how far it sent the hero back. So chaotics will be sent back--or
"side to side"--less often than in 3.6.x but the tapering off of such
occurrences will be slower for them. Lawfuls will also be sent back
less often--still potentially farther down than others--but tapering
off of send backs for them will be quicker.
I'll let somebody else figure out the before and after values for
number of attempts to climb up it takes to finally get out of Gehennom.
The numbers might need tuning.
Handle recently changed armoroff() differently. There should be no
change in behavior.
boots_simple_name(), shield_simple_name(), and shirt_simple_name()
are for no-delay armor types so won't be called by armoroff(). But
they'll undoubtedly get some use in the future.
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).
Performance profiling showed that multiple strcmpi() calls were
occurring each and every time a character was going to the map.
This update:
- honors the WC_COLOR capability
- It allows a window-port to control individual color availability should the window-port wish to do so.
- Makes checking on the individual colors for the active window-port is a straightforward table lookup at the CLR_ offset.
iflags.use_color remains a master on/off switch for use of color, regardless of the capability
compiled into the game (default TRUE).
The has_color() routine, which is now a shared routine in src/windows.c, could likely be made
into a simple macro to eliminate the function call, but this update does not go that far.
This hits a lot of port files due to the window-port interface change, mostly cookie-cutter.
Move option variable goldX (True: treat gold as BUC unknown, False:
treat gold as uncursed during BUCX filtering) from iflags to flags
so that it persists across save/restore.
Get rid of a few obsolete things from struct flags.
Try to make the 'cursesgraphics' option work although I don't think
that it was ever functional enough for anybody to use so probably
could have been removed instead.
Bump EDITLEVEL; any current save files are invalid.
Demote status from Beta to Work-in-Progress.
I modified src/sfdata.c manually (not included here) to get a full
build. The Unix Makefile.src needs to be taught when and how to
regenerate it.
Add 'eating' (synonym 'continue') to the list of things that can be
set via paranoid_confirmation to require "yes" instead of "y" when
the user is prompted about something, in this case "Continue eating?".
dat/opthelp was missing a few of the paranoid_confirmation choices.
