Inventory formatting for a single slime mold object would be strange
if the user entered a plural word or phrase for fruit name. Forcing the
user-specified value to be singular as it's being set up as current fruit
avoids that. [Something like <Someone>'s "bunch of grapes" is unaffected;
it's already singular and correctly handled as such by makesingular().]
This may have a side-effect of limiting the creativity of some players
who try to trick others via bones files gimickery, but I think the extra
consistency in object naming during ordinary play is worth it.
According to the cvs log info, this issue was actually mentioned in
a patch I made ("fix M203...") in October, 2005. I have no recollection
of that at all....
Each time save and restore is performed, the ffruit list gets
reversed. Since additions can be made when it is in backwards order or
in original order depending upon whether an odd or even number of save/
restore cycles have taken place, the numeric sequence of its entries is
ultimately arbitrary. So there's no point using extra code to force new
ones to be added at the end of the list; just put them at the beginning.
I almost abandoned this when Michael beat me to it, but besides
handling the fruit rename bug it also moves `current_fruit' into the
context structure to eliminate separate save/restore for that.
From a bug report:
The following steps do not yield the expected fruit:
1) start nethack in explore mode (with a wand of wishing)
2) change fruit name to "tomato"
3) save/restore
4) change fruit name back to "slime mold"
5) save/restore
6) wish for a fruit; you get a tomato
7) check options; fruit name is set to "slime mold"
If you specified a fruit name that already existed in the list,
fruitadd() always set current_fruit to the fruit with
the highest fid encountered in the list to that point, instead
of the fid of the matching entry.
The one `anything any' that was triggering a warning was shadowing
another `anything any' in the same function; no need to rename it, just
remove the unnecessary declaration. Also, mark the couple of arrays with
initializers that I'd noticed as static instead of letting them default
to auto. The abil_to_spfx()::abil2spfx[] one might need to be redone in
code as a switch if some compilers/linkers have trouble initializing it.
infrastructure for "system options" - things currently specified at build
time that should be changeable at install time or run time but not really
under user control
generalize contact info so it can be localized and it doesn't have to be
an email address
move recently introduced WIZARDS into sysopt
drop bogus OPTIONS=wizards possibility
new function build_english_list() to comma-ize and add 'or' from a whitespace separated list: A. A or B. A, B, or C.
syscf file now handles: WIZARDS SUPPORT RECOVER
SUPPORT specifies local support information
RECOVER will eventually supply port-specific and/or localized info on how
to run recover (or get it run for you).
Note: in sys/msdos I changed sys.o (generated from pcsys.c) to pcsys.o
Note: sys/msdos/Makefile.GCC has 2 rules for sys.o (now pcsys.o)
..\src\options.c(565) : warning C4101: 'opts' : unreferenced local variable
The code in initoptions_init() that uses opts seems to now be isolated to
UNIX and VMS.
Add options SYSCF (to add a system-wide configuration file) and SYSCF_FILE
(for a file-based implementation of SYSCF) - this allows a binary distribution
to be configured at install time. The only option supported at this time is
WIZARDS - a list of usernames which can use -D; currently only for unix-likes
but should be extendable to anything that has a concept of multiple users.
Add mac tty multiuser config using sgid.
It's possible for the player to put escape sequences into strings via
dogname/catname/fruit options (or probably interactively by using "\233"
instead of "\033["--the two character 7-bit version wouldn't work because
its leading ESC gets treated as player's request to abort current input,
but the 8-bit version probably works, I just can't test it because I don't
know how to type such things with this terminal emulator). Such sequences
can do funny things like clear the screen and say "game over" (or worse
with creative abuse of some terminals' "answer back" capability--when
reproducing the reported situation, I kept things simple and had my dog's
name underlined and fruit name blinking; they displayed correctly but
nethack was confused about how long they were since it doesn't expect to
be given characters which don't advance the cursor). This fix still lets
users experiment with such stuff during their own games, but it replaces
suspect characters while loading bones data, so if one player creates a
bones file with suspect strings in it, another can--I hope--be able to
use that file safely.
Monster and object names, engravings, and named fruits are handled.
For the last, if uncensored string matches one already present then it
leaves that alone, so bones data created with same OPTIONS=fruit:whatever
as being used in the current game will continue to keep the same value.
Something that pops up in the newsgroup periodically, with <Someone>
inevitably pointing out the bit of code that the user needs to tweak,
about control of feedback when hero is walking across floor objects.
Implement new option ``pile_limit'' which allows user to set the point
at which the game switches from listing the objects to giving "there are
several/many objects here". Default is 5, same as previous hard-coded
value (1 object gets listed via pline, 2..4 are listed in a corner popup,
5 or more objects yields a pline message instead). Setting pile_limit
to 0 means no limit, so objects will always be listed regardless of pile
size. Setting it to 1 effectively forces no listing since any non-empty
pile size is always at least that big, so can produce "there is an object
here" even though that's no briefer than a pline() to show one object.
Reported to the beta-testers list by <Someone> last April:
restoring a normal game save file in explore mode let you keep the file,
then after exploring and quitting without saving, you could restore it
again in normal mode and take advantage of whatever information you'd
gained. This makes nethack -X (or playmode:explore) defer the switch to
explore mode when used while restoring a normal mode save file. It now
performs a normal restore (with save file deletion) and then acts as if
the user had given the 'X' command interactively, requiring confirmation
to actually switch into explore mode.
Reorganize the recent wizard mode control: move set_playmode() from
xxxmain.c to the core, and have it call new authorize_wizard_mode() to do
the port-specific part. If the set_playmode() call during startup doesn't
result in running in wizard mode (either because not allowed or user
didn't request it), it will be called again during restore if the save
file is from a wizard mode game.
For ports which check character name for authorization, players will
have to use `nethack -u whatever -D' (or options for name and playmode) to
restore a wizard mode save file if WIZARD has been changed from "wizard".
plname[] from a wizard mode saved game will always have that value, so if
it's not the right one players will need to get authorized by the startup
code before loading the save file.
Relief for the command-line impaired. Allow player to request
explore or wizard mode via run-time config file or NETHACKOPTIONS.
Validation is left to xxxmain() and has been updated for Unix, VMS, and
ports which share pcmain. Mac and Be appear to allow any user to access
wizard mode, and may not need any modification, although they'll continue
to have the old buglet of running with both wizard and discover flags set
if player uses `nethack -X -D'. This may or may not work as-is for the
Qt interface depending upon whether it goes through one of the xxxmain()'s
mentioned above [someone needs to make sure that it doesn't allow Qt on
Unix to bypass the (username == WIZARD_NAME) test when user requests
wizard mode].
playmode:discov[ery] is a synonym for explor[e] and playmode:wizard
is one for debug. Using -X or -D on the command line overrides any
config file or environment playmode value. (We might want to add -N or
something to force normal mode when config/env specifies something else.)
This suffers from the same bug as `nethack -X' and `nethack -D': a
player can save a game in normal mode, then restore in explore or debug
mode and choose to retain the save file, obtain information about the
current game (identifying inventory or using enlightenment or mapping out
previously visited levels and so on), quit, then restore the original save
file normally in order to take advantage of the undeserved information.
This patch attempts to add some levels of unicode support
to NetHack.
The master on/off switch for any Unicode support is
defining UNICODE_SUPPORT in config.h. Currently
there is code support for two subsets of unicode support:
UNICODE_DRAWING
If UNICODE_DRAWING is defined, then the data
structures used to house drawing symbols are expanded
to the size of wchar_t, big enough to hold unicode characters.
A typdef called `nhsym' is involved and if UNICODE_DRAWING
is defined, it is wchar_t, otherwise it is uchar.
UNICODE_WIDEWINPORT
If UNICODE_WIDEWINPORT is defined, then the data
structures inside the window port are expanded to the size of
wchar_t, big enough to hold unicode characters. Both map
symbols and text within the window port are expanded, in order
for potential support for displaying multinational characters some
day, but this patch only provides viewing of map symbols.
A typdef called `nhwchar' is involved and if UNICODE_WIDEWINPORT
is defined, it is wchar_t, otherwise it is char.
The only window port with code support for UNICODE_WIDEWINPORT
currently is the TTY port. Don't enable UNICODE_WIDEWINPORT
unless:
- it is a TTY port
- the underlying platform specific routines can
handle the larger data structures.
Don't enable UNICODE_SUPPORT unless:
- your compiler can handle wchar_t.
- your compiler can accept L'a' characters.
- your compiler can accept L"wide" strings.
Note that if your compiler can handle the above, you could
enable the larger data structures (currently if TTY) even if your
platform can't actually display unicode or UTF-8, by messing
with u_putch() in win/tty/wintty.c to only deal regular chars.
That should be the only function that actually pushes wide characters
out to the display.
If you enable UNICODE_SUPPORT, and your platform is capable
you will need to turn on the unicode run-time option to be able to
load unicode character sets from the symbol file, to be able to
push unicode characters to the display. You'll also want to load
a unicode symbol set once the unicode option is toggled on. In
a config file you would do that via these two lines:
OPTIONS=unicode
OPTIONS=symset:Unicode_non_US
The repository was stamped with NETHACK_PRE_UNICODE
prior to applying this patch, and stamped with
NETHACK_POST_UNICODE afterwards. The code differences
between those two tagged versions are this patch.
The palette option is supposed to be allowed in the config file
without a value for win32 to trigger a load of a predefined
NetHack palette, but that wasn't working.
This fixes that. To prevent the use of any palette modification
code at all, just leave the palette option out of the config
file entirely.
Pat Rankin wrote:
> I was about to also suggest that there
> be a rogue/non-rogue (with perhaps a third choice meaning "both")
> attribute. That way we could keep the rogue choices from being
> listed in the "symset" menu and the non-rogue choices from the
> "roguesymset" menu. Players who deliberately wanted to switch
> over would need to modify the attribute, possibly on a cloned set.
> Or perhaps they could just explicitly set their desired choices
> via NETHACKOPTIONS or .nethackrc and not use the 'O' menues--the
> new attribute doesn't necessary have to block which sets get used
> where, just filter menu entries to display the most applicable
> candidates.
Clean up the preprocessing associated with the
loadable symbol stuff.
Base it on new LOADSYMSETS, rather than on the
previously existing ASCIIGRAPH preprocessor define.
- reduce the number of symbol tables for each graphics
set {PRIMARY, ROGUESET} from three {map, oc, mon}
tables for each of the display symbols, the loadable symbols,
and the rogue symbols, to one continguous table for
each:
showsyms: the current display symbols
l_syms: the loaded, alterable symbols
r_syms: the rogue symbols
- Modify mapglyph so that the index into the symbolt table is
available as a return value (it was a void function), rather than
just the char converted from the glyph.
- That makes it possible for a window port to use the same
index value to extract from another table (perhaps a unicode
table) for a different set of display symbols. The index
is much more useful than trying to convert the character
into another type of symbol, as some contributed patches
have done.
- It is much easier to load a single alternative flat table to
make substitutions, since the corresponding value just
has to get placed into the same index offset in the
alternative table.
This also fixes a bug I found in botl.c, where you could
go to the rogue level, and the bottom line gold symbol
was not being updated with the new character as it should.
The reason was because the gold value had not changed,
only the field symbol used had changed.
This updates multiple ports to place a (void) cast on
the mapglyph call, now that it returns a value, so this
is going to generate a lot of diff e-mails.
Pat Rankin wrote:
> Symbol set definitions need a description attribute, above and
> beyond allowing comments in the file, for inclusion in the 'O'
> command's menu entries for selecting them.
[...]
> mapglyph.c isn't the proper place to decide whether to define
> ROGUE_COLOR. That may need to become a symbol attribute,
> which we'd then specify on the Epyx rogue set(s).
Implement both of the suggestions above.
Pat Rankin wrote:
> When 'symbols' is missing from the playground, or is an empty
> file, picking either the symset or roguesymset option via the
> 'O' command just goes right back to the game display (or next
> pending compound option) without giving any feedback.
>
- Instead of checking for the Rogue level, check which
graphics are engaged (PRIMARY or ROGUESET) in the
SYMHANDLING() macro.
- track which graphics are active through 'currentgraphics'.
- Instead of symset and roguesymset and symhandling and roguehandling
variables, have symset and symhandling be arrays of two, with the
following indexes:
PRIMARY
ROGUESET
That reduced the amount of repeated code.
(Not to be confused with the 'symset' and 'roguesymset' config file options
both of which still exist)
- the symbol routines were adjusted to pass
the index , rather than 'rogueflag' and coding to roguesymset etc.
Other than fixing bugs that are encountered, this is probably
the last of the symbol stuff, with the exception of
making the symset and roguesymset config file options
accept the keyword value "default".
- tile2x11 would not build because drawing.c now depended on strcmpi which
was (via STRNCMPI not being defined) defined to strncmpi which is
implemented in hacklib.c which needs panic which is defined in... I gave up
on tracking down all the loose ends and changed the strcmpi to strcmp,
which means the handling is case sensitive, but it avoids a bunch of
changes to the way the util/Makefile.
- the symhandling changes introduced a chicken and the egg problem for
ASCIIGRAPH on Unix platforms, which was getting the defn from tcap.h but
that does not get included earlier enough nor often enough. I added a defn
to unixconf.h to mimic ntconf.h, since ASCIIGRAPH is normally defined on Unix.
- options.c included an unused decl for a function named graphics_opts
- Unix Makefile was not installing "symbols". I'm assuming this isn't
supposed to get the DLB treatment.
This is an overhaul to the NetHack drawing mechanism.
- eliminates the need to have separate lists in drawing.c
for the things and their associated explanations by grouping
those thing together on the same inializer in a struct.
- replaces all of these options: IBMgraphics, DECgraphics, MACgraphics,
graphics, monsters, objects, boulder, traps, effects
- drawing.c contains only the set of NetHack standard symbols for
the main game and a set of NetHack standard symbols for the
roguelevel.
- introduces a symbols file that contains named sets of
symbols that can be loaded at run time making it extensible
for situations like multinational code pages like those reported
by <Someone>, without hardcoding additional sets into the game code.
- symbols file uses names for the symbols, so offsets will not break
when new things are introduced into the game, the way the older
config file uchar load routines did.
- symbols file only contains exceptions to the standard NetHack
set, not entire sets so they are much less verbose than all of
the g_FILLER() entries that were previously in drawing.c
- 'symset' and 'roguesymset' config file options for
preselecting a symbol set from the file called 'symbols'
at startup time. The name of the symbols file is not under the
users control, only the symbol set name desired from within the
symbols file is.
- 'symset' config file option loads a desired symbol set for
everything but the rogue level.
- 'roguesymset' config file option loads a desired symbol set
for the rogue level.
- 'SYMBOLS' config file option allows the user to specify replacement
symbols on a per symbol basis. You can specify as many or as few symbols
as you wish. The symbols are identified by a name:value pair, and line
continuation is supported. Multiple symbol assignments can be made on
the same line if each name:value pair is separated by a comma.
For example:
SYMBOLS = S_bars:\xf0, S_tree: \xf1, S_room:\xfa \
S_fountain:\xf4 \
S_boulder:0
- 'symbols' file has the following structure:
start: DECgraphics
Handling: DEC
S_vwall: \xf8 # meta-x, vertical rule
S_hwall: \xf1 # meta-q, horizontal rule
finish
start: IBMgraphics
Handling: IBM
S_vwall: \xb3 # meta-3, vertical rule
S_hwall: \xc4 # meta-D, horizontal rule
finish
- 'symbols' file added to the source tree in the dat directory
- Port Makefiles/scripts will need to be adjusted to move them into
HACKDIR destination
Allow config file entries to adjust win32 console colours.
The following entries in a config file are examples:
OPTIONS=palette:black-0-0-0
OPTIONS=palette:red-210-0-0
OPTIONS=palette:green-80-200-0
OPTIONS=palette:brown-180-100-0
OPTIONS=palette:blue-0-0-200
OPTIONS=palette:magenta-128-0-128
OPTIONS=palette:cyan-50-180-180
OPTIONS=palette:gray-192-192-192
OPTIONS=palette:dark gray-100-100-100
OPTIONS=palette:orange-255-128-0
OPTIONS=palette:bright green-0-255-0
OPTIONS=palette:yellow-255-255-0
OPTIONS=palette:bright blue-100-100-240
OPTIONS=palette:bright magenta-255-0-255
OPTIONS=palette:bright cyan-0-255-255
OPTIONS=palette:white-255-255-255
This uses an undocumented way to adjust the console
colours in a win32 console application. The method and
code snippet used comes from www.catch22.net by James Brown.
This page:
http://www.catch22.net/about.asp
states the following:
"you do not have to pay anything to use the software, and there are no
licencing terms for any sourcecode that you may download from this site.
This means you can freely use any sourcecode or portions of code in
your applications, whether they be free software or professional, retail
products."
The devteam feedback was to place casts in the code
in question.
This puts explicit casts on some code that was being
compiled into 'int64' then stuffed into smaller types with
VC2005.
This patch by <email deleted> was released
when 3.4.1 was current and has been incorporated into slash'em. It is
extremely useful while using ranged weapons. When both autopickup and
pickup_thrown are enabled, walking across previously thrown objects will
pick them up even if they don't match the current pickup_types list.
[See cvs log for patchlevel.h for longer description.]
The recent fix for OPTIONS=noDECgraphics,IBMgraphics would have been
subject to lint complaints for some configurations. Declare the extra
variable with the same conditional tests which control its use; somewhat
messier, but lint free.
My previous fix only solves this problem for the initial config file
parsing. If you enable IBMgraphics (by any method), then interactively
use the 'O' command to try to enable DECgrahpics and to _simultaneously_
disable IBMgraphics instead of letting it be overridden, you will end up
with IBMgraphics on and DECgraphics off. That's because the menu entries
are processed in order, and after it has acted upon the request to set
DECgraphics on, the IBMgraphics flag will have been switched off; then
when it acts upon the request to toggle IBMgraphics, that flag will end
up being switched back on (switching DECgraphics back off in the process).
This erroneous behavior was the same prior to last week's patch;
I just hadn't noticed yet. It looks like we really do need to change
{ASCII,DEC,IBM,MAC}graphics into a single compound option.
Fix the problems From a bug report. So having
OPTIONS=IBMgraphcs
OPTIONS=noDECgraphics
would yield an ASCII display instead of showing IBMgraphics, but IBMgraphics
flag in the Options list would falsely show as on. Manually toggling it off
put things back into sync.
Avoiding the false setting is completely trivial. And fixing the
inappropriate override turns out to be easy too, unless I've bungled this.
One thing it does not do is try to warn about attempts to set conflicting
options like
OPTIONS=IBMgraphcs
OPTIONS=DECgraphics
Fixing that seems to be too messy to bother with, particularly since the
game runs ok (leaving the setting handled last in place).
Accept OPTIONS=pettype:horse quietly instead of issuing "unrecognized
pet type 'horse'" message. It doesn't actually do anything from player's
perspective--knights always get a pony and other roles always get a cat or
dog, as before.
I had a much more elaborate version which recognized "pony" (plus
"kitten", "little dog", "puppy" and assorted other variations of the
acceptable types), but it was absurd overkill for something that never
come up during actual play. If someone tries to specify "kitten" and gets
"unrecongized type", it shouldn't take him longer to figure out "cat" is
what's needed even without resorting to actually reading the Guidebook.
Can someone generate an up to date Guidebook.txt and check it in?
My previous change underwent a last minute simplification that changed
behavior. This puts things back to how I intended: at the "add new
autopickup exception pattern" prompt, empty input returns you to the upper
add/list/remove/exit menu and ESC returns you past that (back to play or to
other pending 'O' changes, if any). The previous change accidentally made
empty input behave the same as ESC.
1) in the autopickup exception sub-menu from 'O', change the selector for
"exit" from 'e' to 'x' so that the entries occur in alphabetical order.
Also frees up 'e' for some hypothetical future "edit" entry (I'm not
planning on attempting to implement anything along those lines though).
-1) I wanted to make 'x' start out preselected to show that it's the default
choice, but that doesn't work correctly--at least for the tty interface.
PICK_ONE menus don't know how to deal with having a preselected item and
in this case it ended up returning 'x' no matter what choice I made.
Even if that aspect gets fixed, it might have trouble with explicitly
picking the preselected entry since that would probably be toggled off
in the process. So the preselection bit of this menu is commented out.
2) at the prompt for adding new exceptions, quit adding instead of giving
"invalid syntax" warning if user enters empty input.
3) allow <ESC> in the "list" or "remove" submenu to quit all the way out of
the upper menu too.
4) simplify the way magic numbers are used for action_titles[] menu setup.
5) greatly simplify return value of special_handling().
6) avoid a potential for getlin() or strcat() buffer overflow if getlin()
were ever to be changed to return BUFSZ-1 characters instead of COLNO or
whatever its narrower current limit is.
I'm pretty sure that I've run into the issue of being unable to have a
preselected entry in a PICK_ONE menu before, but I can't recall if I ever
mentioned it. Fixing that looks like it'd be pretty messy and would need
to be done for all the interfaces. Ick.
I ran into a bit of a mess while working on some other minor change.
Remove trailing spaces and tabs, convert multiple spaces into tabs when
appropriate, discard spaces in <space><tab> sequences, plus a couple of very
small reformatting bits. No change in game behavior, or even any difference
in generated object file once line information is suppressed. Some of the
whitespace cleanup is for post-3.4.3 code, so the trunk and branch diffs
aren't equivalent.
o Add support for zlib compression via ZLIB_COMP in config.h (ZLIB_COMP
and COMPRESS are mutually exclusive).
o rlecomp and zerocomp are run time options available if RLECOMP and
ZEROCOMP are defined, but not turned on by default if either COMPRESS
or ZLIB_COMP are defined.
o Add information to the save file about internal compression options
used when writing the save file, particularly rlecomp and zerocomp
support.
o Automatically adjust rlecomp and zerocomp (if support compiled in)
when reading in an existing savefile that was saved with those options
turned on. Still allows writing out of savefile in preferred format.
o In order to support zlib and not conflict with compress and uncompress
routines there, the NetHack internal functions were changed to
nh_uncompress and nh_compress as done in the zlib contribution received
in 1999 from <Someone>.
I tagged the sources NETHACK_3_5_0_PREZLIB prior to applying these
changes.
Support negation syntax to restrict unwanted race, role, gender, align
options:
OPTIONS=role:!knight, role:!tourist, race:!orc
prevents them from being picked randomly or
appearing in the pick lists at the start of the game.
- always write plname into save file, no longer conditional
- add 'selectsaved' wincap option to control the display of
a menu of save files for ports/platforms that support it.
- add support for win32 tty using normal nethack menus.
- the win/tty/wintty code is generalized enough that any
tty port could support the option if the appropriate port-specific
code hooks for wildcard file lookups are added to src/file.c
specifically in the get_saved_games() routine. There is posix
code in there from Warwick already, and there is findfirst/findnext
code in there from win32. Warwick has the posix code only
enabled for Qt at present, but with wintty support, that could be expanded
to other Unix environments quite easily I would think.
Here is what the tty support looks like:
NetHack, Copyright 1985-2005
By Stichting Mathematisch Centrum and M. Stephenson.
See license for details.
Select one of your saved games
a - Bob
b - Fred
c - June
d - mine3
e - Sirius
f - Start a new character
(end)
The following files existed in the NetHack SAVEDIR directory
at the time:
ALLISONMI-Bob.NetHack-saved-game
ALLISONMI-Fred.NetHack-saved-game
ALLISONMI-June.NetHack-saved-game
ALLISONMI-mine3.NetHack-saved-game
ALLISONMI-Sirius.NetHack-saved-game
Note that despite the file names, the actual character name
is drawn from the savefile.
The WIN32CON support passes
USER-*.NetHack-saved-game
to findfirst/findnext where USER is your login name of course.
