This started out as some formatting cleanup for src/windows.c but
ended up removing calloc() from the WINCHAIN code, plus fixing a
couple of compiler complaints for win/chain/wc_trace.c.
I tried to actually run with +trace enabled and never managed to
get anything to happen. trace_procs_init() was never called. I've
never tried to use it before so don't know whether something which
used to work has gotten broken or I'm just doing it wrong.
With the code as it stood, receipt of BL_CHARACTERISTICS would
trigger a flush of output which may not have been the
intention.
Ensure the flush code is only on BL_FLUSH (or BL_RESET).
I saw dumplog text in a newsgroup posting and the only way I could
recognize what version generated it was that "You entered the dungeon
N turns ago" included the missing-until-recently final period. So,
put nethack's one-line version information as the very first dumplog
text and follow it with the dumped game's start and end date+time.
(That information is useful to know in its own right, but also should
prevent the build date+time shown with the version from confusing
anybody about when the dump was written.)
Along the way, I noticed that the 'counting' phase for artifact_score
was being repeated for '#if DUMPLOG' even though it doesn't generate
output. That had a side-effect of adding points for artifacts twice
(applicable when final score was for an ascension or dungeon escape).
The recently added dumplog code assumed that 'time_t' is 'long int'
or at least will give sensible results when formatted with '%ld'.
This is more of a Band-Aid(tm) than a proper fix.
Make genl_status_update behave approximately the same as basic bot2
when processing the second status line. Preferred order:
Dlvl Gold Hp(HpMax) Pw(PwMax) AC Xp Time Conditions
Alternate orders if above exceeds COLNO (note several extra spaces
get sequeezed out). First one is used if everything except time fits,
second one is used if everything except experience (which can be wide
if 'showexp' option is on) and time fits, third is last resort:
Dlvl Gold Hp(HpMax) Pw(PwMax) AC Xp Conditions Time
Dlvl Gold Hp(HpMax) Pw(PwMax) AC Conditions Xp Time
Hp(HpMax) Pw(PwMax) AC Conditions Dlvl Gold Xp Time
Basic bot2 currently has Conditions as
Stone Slime Strngl FoodPois TermIll <hunger> <encumbrance> Blind Deaf
Stun Conf Hallu Lev Fly Ride
genl_status_update has
<hunger> <encumbrance> Stone Slime Strngl FoodPois TermIll Blind Deaf
Stun Conf Hallu Lev Fly Ride
which is as close as it can get with the current field organization.
Tested by temporarily changing tty_procs.status_init and .status_update
to use genl_* instead of tty_*.
Adding deafness to the status line spurred me on to something I've
wanted to do for a long time. This adds 'Stone' and 'Strngl' as
new status conditions, and moves the five fatal ones: "Stone Slime
Strngl FoodPois TermIll" to the front of the status list since
information about them is more important than any of the others.
"Ill" has been renamed "TermIll"; "Df" has been renamed "Deaf";
"Lev", "Fly", and "Ride" are three additional new conditions, with
Lev and Fly being mutually exclusive. After the fatal ones, the
order of the rest is now
<hunger> <encumbrance> Blind Deaf Stun Conf Hallu Lev Fly Ride
To handle the longer potential status line, the basic bot2() is now
smarter. If the line is wider than the map, 'T:moves' is moved from
the middle to the end. If the line without time is still wider than
the map, then experience (HD if polyd, Xp:M/nnnnnn is showexp is on,
or Exp:M) is moved in front of time at the end. If the line without
experience and time is still wider than the map, dungeon level plus
gold is moved from the beginning to be in front of experience. The
fields are just reordered, not truncated, so if the interface code
can display lines wider than the map they'll retain the extra info.
The gist is than health and associated fields (Hp, Pw, Ac) get first
priority, status conditions get second priority, then the rest. In
the usual case where there aren't many conditions, status display is
the same as it has been in the past.
STATUS_VIA_WINDOWPORT has been updated too, and it builds for tty
and X11. But the bot2() revision to reorder sections has not been
implemented for that.
win/win32/mswproc.c has been updated but not tested.
STATUS_VIA_WINDOWPORT without STATUS_HILITES had several compile
problems; now fixed for core and tty. STATUS_VIA_WINDOWPORT with
STATUS_HILITES has not been tested.
This should avoid two of the three bogus clang complaints about
retaining the address of a stack variable after it has gone out of
scope.
Plus a recreation of some formatting I did a while back and then
accidentally clobbered before committing.
Changes to be committed:
modified: doc/window.doc
modified: include/qt_win.h
modified: include/trampoli.h
modified: include/winX.h
modified: include/wingem.h
modified: include/winprocs.h
modified: include/wintty.h
modified: src/display.c
modified: src/windows.c
modified: sys/amiga/winami.p
modified: sys/amiga/winfuncs.c
modified: sys/amiga/winproto.h
modified: sys/wince/mswproc.c
modified: sys/wince/winMS.h
modified: win/Qt/qt_win.cpp
modified: win/X11/winmap.c
modified: win/chain/wc_chainin.c
modified: win/chain/wc_chainout.c
modified: win/chain/wc_trace.c
modified: win/gem/wingem.c
modified: win/gem/wingem1.c
modified: win/gnome/gnbind.c
modified: win/tty/wintty.c
modified: win/win32/mswproc.c
modified: win/win32/winMS.h
print_glyph now takes a second parameter.
Tiles on tiled ports always looked odd on places like the plane of air
where the background color of the tile didn't match the general background
of the surrounding area.
3.6 made that even worse and more glaringly noticeable with the introduction
of darkened room tiles.
The code to actually send something useful through the new parameter
for window ports to take advantage if they want will follow.
Changes to be committed:
modified: include/botl.h
modified: include/extern.h
modified: include/wintty.h
modified: src/botl.c
modified: src/options.c
modified: src/windows.c
modified: win/tty/wintty.c
get the tty versions started
Changes to be committed:
modified: include/extern.h
modified: src/botl.c
modified: src/options.c
modified: src/windows.c
defer notification of the window port until after
proper initialization. Options are processed very
early in 3.6.0
Changes to be committed:
modified: include/botl.h
modified: src/botl.c
modified: src/windows.c
modified: win/tty/wintty.c
Move the windowport stuff out of botl.c and into windows.c
where it belongs.
Have genl_putmsghistory() pass the message to pline() for the !restoring
case, so that quest summary lines are delivered as ordinary messages.
No effect on tty or win32, which have their own putmsghistory routines.
But for X11, which has a multi-line message window but no save/restore
implementation for its contents, this makes the quest summary lines
actually show up somewhere. (I looked at maybe implementing
X11_getmsghistory() and X11_putmsghistory() but don't have the energy to
tackle it.)
Other interfaces which lack their own history save/restore will see the
quest summary messages too. Presumeably they'll all have multi-line
history windows so the extra line won't be displacing the most recent
message. If not, they'll essentially get the long quest messages twice,
once in full via popup window, then the one-line summary via pline.
I'll push a formatting guide at some point. There may still be
outstanding changes, but please feel free to resolve those as you arrive
a them.
To the best of my knowledge, there is no changes to the actual code
content, but the formatter does have the occasional bug. If you run into
an issue, please fix it!
[See cvs log for include/rm.h or doc/window.doc for more complete description.]
Attach hero info, death reason, and date+time to a level that's being saved
as bones. Read such data back when loading a bones file, then treat it as
part of that level for the rest of the game. Dying on a loaded bones file
will chain the new hero+death+date to previous one(s) if new bones get saved.
outrip() now takes an extra argument of type time_t, and interface-specific
implementations of this routine need to be updated to handle that.
This is the code I built trying to figure out the large window size issue.
It completely compiles out if not needed (see -DWINCHAIN in hints/macos10.7)
and except for one call during setup has zero overhead if compiled in and
not used. See window.doc for more info.
Defs for UNUSED parms. I know this has been controversial, so use is isolated
to the chain code and windows.c (where it shouldn't be intrusive and saves about
50 warnings).
Hints file for 10.7, but the build process still needs to be migrated from
the branch.
Provide a mechanism for cleanly moving between tentative window system
selections during startup. Now, before a second (or later) system is selected,
the first will be notified that it is losing control. See window.doc.
Some time ago we received a patch submission which attempted to
handle the Alt key for terminals or emulators which transmit two char
sequence "ESC c" when Alt+c is pressed, but I can't find it. I don't
remember the details but recall that it had at least once significant
problem (perhaps just that it was unconditional, although it may have
been implemented in a way which interferred with using ESC to cancel).
This patch reimplements the desired fix, making the new behavior be
conditional on a boolean option: altmeta. That option already exists
for the Amiga port, where it deals with low-level keyboard handling but
essentially affects the same thing: whether Alt+key can be used as a
shortcut for various extended commands. This one affects how the core
processes commands, and is only available if ALTMETA is defined at
compile time. I've defined that for Unix and VMS; other ports don't
seem to need it. (I'm not sure whether "options" created by makedefs
ought to mention it. So far, it doesn't since this isn't something
users are expected to tweak. The setting of the non-Amiga altmeta
option doesn't get saved and restored, so won't affect saved data if
someone does toggle ALTMETA and then rebuild.)
When [non-Amiga] altmeta is set, nethack's core will give special
handling to ESC, but only during top level command processing. If ESC
is seen while reading a command, it will be consumed and then the next
character seen will have its meta bit set. This introduces a potential
problem: typing ESC as a command will result in waiting for another
character instead of reporting that that isn't a valid command. Since it
isn't a valid command, this shouldn't be a big deal, but starting a count
intended to prefix your next command and then typing ESC after deciding
to abort that count runs into the same situation: nethack will wait for
another character to complete the two character sequence expected for
"ESC c". There's not much that can be done with this, other than have
the Guidebook mention that an extra ESC is needed to cancel the pending
count, because digits followed by ESC could actually be a numeric prefix
for Alt+something rather than an attempt to abort the count.
..\src\windows.c(329) : 'boolean (__cdecl *)()' differs in parameter lists from 'boolean (__cdecl *)(void)'
Committed on the Free edition of March Hare Software CVSNT Server.
Upgrade to CVS Suite for more features and support:
http://march-hare.com/cvsnt/
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.
[Third of three message history patches.]
Add another argument to putmsghistory() so that it can tell whether
it's processing multiple messages for restore (which should be treated as
being older than any current messages) or a single message to stuff into
history (which should be treated as the most recent message even though
it hasn't been displayed in the message window).
[First of three message history patches.]
The post-3.4.3 hangup changes broke the post-3.4.3 message history
save/restore for tty (and maybe Win32, if it supports hangup handling;
other interfaces haven't implemented message history save/restore yet)
during hangup saves by preventing interface-specific getmsghistory() from
being called. Relatively benign; hangup save just behaved as if message
history was empty, so restore had no old messages to put back. Naturally
post-hangup restore is when players would be most interested in reviewing
the previous session's messages, so benign failure isn't acceptable. Fix
is to leave getmsghistory() intact when replacing windowprocs with the
I/O-free routines. [I can't trigger real hangups for testing, but can
call hangup() from within the debugger to force an approximation of one.]
If nhwindows_hangup() were to get called a second time, it would have
saved hup_exit_nhwindows() as the previous interface's shutdown routine.
Then if/when exit_nhwindows() gets called, hup_exit_nhwindows() would
have called itself with uncontrolled recursion. So guard against that by
preventing the hangup shutdown routine from ever being saved as previous
interface shutdown routine.
Also, avoid the exit_windows macro when using it as a pointer rather
than for a function call, since pre-ANSI compilers might be confused by
its expansion.
From two weeks ago:
> The last of my intended hangup overhaul. Once hangup is detected,
> replace currently loaded windowing routines with stubs that never do any
> terminal I/O. Real interface routines call their siblings directly rather
> than via the windowprocs pointers, so this shouldn't pull the rug out from
> under them, but it also can't prevent whatever they have in progress at
> the time of hangup from attempting further I/O once the handler returns.
hangup_nhwindows() shouldn't call exit_nhwindows() prior to replacing
windowprocs with no-ops. Even though the original intgerface can still
access its own routines directly, the exit_nhwindows() routine probably
releases its dynamic data structures. And those could be in active use if
the hangup occurs while an interface routine is executing.
The last of my intended hangup overhaul. Once hangup is detected,
replace currently loaded windowing routines with stubs that never do any
terminal I/O. Real interface routines call their siblings directly rather
than via the windowprocs pointers, so this shouldn't pull the rug out from
under them, but it also can't prevent whatever they have in progress at
the time of hangup from attempting further I/O once the handler returns.
[We might want to change nhwindows_hangup() into winprocs.hangup_nhwindows()
so that each interface has more control over its own fate.]
This assumes that user input of ESC and menu selection result of -1
everywhere in the core will eventually cause active function calls to
unwind their way back to moveloop() rather than to continually re-prompt.
(This assumption is not a new one, just a bit more explicit now.)
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.
