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.
Pat noted that I neglected to drop the SCCS lines on the files I've been
committing, so clean up those and any others I could find where the SCCS
line date is out of date.
PORTS: Please make sure I've done the right thing for/to your code.
This patch adds a new winproc that lets the window port approve or cancel
the suspend request - this should take care of the Mac Qt lockup issue.
In addition, Unix suspend is restricted to accounts that can use the shell
if SYSCF is defined.
It always struck me as odd that x_maze_max and y_maze_max were
initialized in main(). They're only needed when making new levels, so
don't have to come before saved game restoration. They could easily have
gone into init_dungeon() (although they make well predate that), or even
mklev() (reinitializing them for each new level wouldn't have been a big
deal). That's all moot, though, since it's trivial to initialize them at
compile time.
[See cvs log for src/role.c for a much longer description.]
When picking role, race, and so forth, new menu entries allow you to
pick any of the other items before the one currently being handled. After
picking all four of race, role, gender, and alignment (or if you answered
'y' to "shall I pick for you?"), there is a followup prompt to confirm the
choices. It's a menu which also provides a chance to rename the character.
This has only been implemented in win/tty's player_selection(), with
some support code in the core that might be useful to other interfaces.
And so far, the chance to rename is only presented as a menu choice if
you've given an answer to "who are you?" prompt earlier during startup.
Also, ports that use pcmain.c aren't able to perform hero renaming yet.
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)
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.
Wizard mode or explore mode can be forced on (via -D or -X on the
command line, or now via OPTIONS=playmode:debug|explore) when restoring
a saved game; explore mode handling was confined to restgamestate(), but
wizard mode handling was replicated in every main(). Treat `wizard' the
same as `discover'. Also, prevent a new game started when restore fails
from using the old game's option settings if partial restore attempt got
far enough to load the flags struct. And update bemain.c and macmain.c
to catch up with the others modified by the playmode patch.
Add putmixed() to the window port. It allows map symbols to
be included in the string by encoding them in a unique fashion.
This was done because Unicode symbols, for instance, could be
longer than the size of a char.
The encoding of the map symbols in this patch is done by
prefixing a glyph value with \GXXXX, where XXXX is a
random value for the current game. The reason for the random
prefix is to minimize the possibility that a player can trigger
the escape sequence processing within text under their control
(dog names, etc.) the way they could if the sequence was fixed
in the source code. The random prefix remains the same throughout
the lifetime of a game because message window strings are
saved in the save file.
(There was actually a bug present because of the embedded
character even before the recent symbol changes, because if
someone was using a different set of characters between games,
the saved messages would reflect the original characters, rather
than the current. That bug was introduced with the ability to
save messages to the savefile.)
A window port does not have to supply an XXX_putmixed() routine,
it can use genl_putmixed() which uses the old behavior of
embedding the sequence as a character within the string
and calling putstr(). genl_putmixed() takes care of the decoding
of the escape sequence.
This also #ifdef's out code in pager.c for converting a glyph
to a character, and uses mapglyph() to do that instead. Does
anyone see a problem with doing that through mapglyph instead
of repeating similar code within pager.c?
Move some internals-related code out of port-specific main so that
it isn't duplicated a bunch of times. One minor side-effect of this
change is that if you auto-pickup something at the very start of a game,
it will happen after any full moon/new moon/Friday 13th message rather
than before. There's a second change for some: the shared main() used
by several of the micro ports had a small difference in game play--if you
saved a game while on an engraving, it would automatically be read when
you resume--that will now occur for everybody [Elbereth weenies rejoice!].
pcmain() was also calling update_inventory() at start of play. That's
unnecessary for new games, where inventory initialization triggers a call
to it for each item added to your pack; but I wasn't sure about restored
games, so everybody gets it there now.
The Mac and BeOS ports evidently haven't been touched it some time;
they still referenced flags.move which got replaced by context.move quite
a while back. The Windows GUI code has a declaration for mswin_moveloop()
which appears to be non-existant, but I left it alone. I assume that the
Qt interface uses the existing main() routines; at least I couldn't find
any start of game code specific to it. vmsmain's revised main() is the
only one which has been tested.
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.
This provides the core support needed for status field highlighting.
This patch doesn't actually perform status field highlighting for any port,
but provides the core hooks for doing so.
The syntax is:
OPTIONS=hilite_status:{fieldname}/{threshold}/{below}/{above}
where {fieldname} is the name of a status field.
{threshold} is the value used as the threshold to trigger a display
change. It can also be set to "updown" to trigger
a display change whenever it rises or whenever it falls.
If you end the threshold value with %, then it signifies
that you want to trigger the display change based on the
percentage of maximum.
{below}, {above}
are the color or display attribute that you want to use when
the field value is underneath the threshold. Supported display
fields are: normal, inverse, bold, black, red, green,
brown, blue, magenta, cyan, gray, orange,
bright-green, yellow, bright-blue, bright-magenta,
bright-cyan, or white.
Valid field names are:
alignment, armor-class, carrying-capacity,
charisma, condition, constitution, dexterity,
dungeon-level, experience-level, experience,
gold, HD, hitpoints-max, hitpoints, hunger,
intelligence, power-max, power, score,
strength, time, title, wisdom
Refer to window.doc for details. Guidebook updates to come later.
Introduction of a new set of window port status display
routines. The new routines are conditional on
STATUS_VIA_WINDOWPORT
being defined in config.h. See the experimental section,
where the #define resides for the time being.
On September 11, 2003 "<Someone>" wrote:
> When we're going to have a different save file format, could
> the last messages in the message history be saved as well, so
> ^P would work the same before and after saving (possibly
> including a few less messages to make room for the startup
> messages?).
This seemed like a reasonable request. This patch:
- adds the core support required.
- adds the tty supporting routines.
Introduce a new set of functions to manage delayed killers in the trunk, used
in addressing the various reports of delayed killer confusion. Since existing
delayed killers are related to player properties, the delayed killers are
keyed by uprop indexes. I did this to avoid adding yet another set of
similar identifiers.
- the new delayed_killer() is used for stoning, sliming, sickness, and
delayed self-genocide while polymorphed. Some other timed events don't
use it (and didn't use the old delayed_killer variable) because they
use a fixed message when the timeout occurs.
- A new data structure, struct kinfo, is used to track both delayed and
immediate killers. This encapsulates all the info involved with
identifying a killer. The structure contains a buffer, which subsumes the
old killer_buf and several other buffers that didn't/couldn't use killer_buf.
- the killer list is saved and restored as part of the game state.
- the special case of usick_cause was removed and a delayed killer list
entry is now used in its place
- common code dealing with (un)sliming is moved to a new make_slimed function
- attempted to update all make dependencies for new end.c -> lev.h
dependency, sorry if I messed any up
<Someone> wishes to add a couple of new options to the wince port ("run fullscreen" and "do not use CE software keyboard").
The wincap field was full, so this adds a second field for
additional options.
Fix a documentation inaccuracy pointed out by Michael. Intended for
the 3.4.0 source tarball, even though it was submitted after the
code freeze. Does not affect compiled binaries.
Changes to the resource file used for the Macintosh port.
Specifically, remove hardcoded version string and popup dialogs.
This is formatted with BinHex so it can be stored on non-Mac
systems without losing the resource fork. Though it is text,
it is not intended to be human-readable.
to allow common parsing in the core, and direct access to the
results by the window port.
Notes:
o Adds a new field, wincap, to the window_procs
structure for setting bits related to the preference
features that the window port supports. This allows
run-time determination of whether a particular option
setting is applicable to the running window port. A
window-port is free to support as many, or as few,
of the available options as it wants. Ensure that
only the ones supported have their corresponding bit
set in window_proc.wincap. [see chart in
doc/window.doc for help with that.]
o The settings I stuck into wincap for each window
port are almost certainly not accurate, so each port
team should review them. You should only include
the ones that you will actually react to and make
adjustments for if the user changes that option.
Without the setting in wincap, the option won't even
show up in the 'O'ptions menu.
o preference_update() added to the window-port
interface, so that the window-port can be notified
if an option of interest (an option with its
corresponding bit set in wincap field) is
changed.
o provided a genl_preference_update() routine in
windows.c and used it for all the existing
window ports since they don't have a functional
one of their own yet.
o this messes around heavily with iflags and the options
arrays in options.c
o I hope I didn't break any port's existing code. I
tried not to. The Mac however, in particular, should
be looked at because it suffered a namespace collision
with what I was working on around fontname. It had
Mac specific font stuff in options.c. Please test
the Mac.
Several long-awaited updates for the Macintosh port, by Dean
Luick and myself. This set affects Mac-only files.
* Update the support for MPW compilers.
* Use new system call names provided for in the latest Apple
Universal Headers.
* Tune up some of the includes for CodeWarrior.
* Define YY_NEVER_INTERACTIVE for the dungeon and level compilers.
* Remove pointless debugging code.
* Clean up some unterminated comments.
