The autocompletion was working, but you couldn't tell
because the text was overwritten with blanks. This was
a recent glitch created during fix for other cursor problems.
This brings things much closer to correct operation (I hope).
- The shift to only moving the cursor on input (<Someone>'s
changes) had a lot of complications, among them was
that sometimes, there is no more input. When the program was
exiting, or bombing the cursor synch never got done, so the
final messages could end up strewn any place the cursor
happened to be dwelling.
- There were two competing output systems in use: the
wintty stuff for the game, and the msmsg and error stuff
used by the sys/share/pcsys, sys/share/pctty, and
sys/share/pcunix routines. Those were meant to mimic
output to stdout, where stuff just got sent to a sequential
display. Over time, there were calls mixed in that depended
on the cursor tracked stuff from the core game, so you
really couldn't be sure where things were going to display.
It wasn't as much of an issue before, because the cursor
really did get moved around as expected. Everything
now ends up in the same output system.
- I even found a use of the real putchar() because
sys/share/pcunix didn't #include wintty.h the same
as the other files, and the macro never got defined.
Who knows where that character was being put -
the game certainly couldn't track it.
While everything I knew to be wrong yesterday is
now working, there may be some other glitches
lurking that I haven't discovered yet.
Please: test, test, test.
There were still some significant startup message problems
with win32tty.
I've spent a lot of time in the debugger tracing through them all.
I think I've got them all worked out now, certainly the ones that
I was aware of. There may be some I haven't discovered.
Testing welcomed of course!
This patch also attempts to diagnose the error where someone tries
to execute NetHack directly out of a zip file, and provide
them with a (hopefully) helpful message similar to what we
might end up telling them if they wrote in. If you want
to test that part, you can comment out the line in the
Makefile that adds "dungeon" to nhdat, and delete the nhdat
in your binary and src directories, and "make install".
Then add the value of your TEMP environment variable as a
DATADIR statement in defaults.nh (here's mine):
DATADIR=C:\DOCUME~1\ALLISO~1\LOCALS~1\Temp
The diagnostic code engages if the game fails to open
dungeon. It then checks to see if it the game dir is the
TEMP directory for your system, and if so it prints the
message.
the win32 cursor restriction stuff messed up any
messages displayed during abnormal start conditions
where the window system never got initialized properly.
among them:
- messages relating to lock files or games in progress
- dungeon errors
- early panic messages
From Newsgroups: rec.games.roguelike.nethack :
> <email deleted>
> Subject: question for windows tty users
>
> I am trying to hunt down a bug, and want to know if I have
> encountered another one of those bizarre "features" that only
> occur on my computer (I seem to get a lot of them).
>
> I can reproduce this bug, or whatever it is, in the official
> Windows binary like this: Start the tty version of NetHack by
> double clicking on the program. You won't see the bug if you
> start it from the command line. When the game asks, "Who are
> you?" press ^C. NetHack will respond with "^C abort. Hit
> <Enter> to end," and then it hangs. Pressing Enter does
> nothing, and the program does not end.
>
> Can anybody else reproduce this behaviour? Thanks in advance.
>
> -- <Someone>
fix by <Someone>, updated by <Someone> on r.g.r.n.
changes the colours of the windows tty port so that blue and
bright blue, and cyan and bright cyan are distinguishable. The chief
benefit of this is that floating eyes no longer look like shocking
spheres.
1. Switch to low-level console routines for performance improvements.
2. Instead of moving the cursor around like a real tty, just track the
destination coordinates of where the cursor should be, and
defer the movement until user input is expected.
Credit to <Someone> for #2.
> This patch fixes warnings relating to pointers (using int *
> instead of unsigned int * ), provides prototypes for some
> functions, and adds a missing argument to one of the functions
>
> It also changes a bit in the way flex/bison are used in the
> Borland makefile to allow me to test compilation with those
> utilities using a batch file.
- Move the code for keystroke handling into its own source file.
- Compile and link it as a dynamic link library.
- Dynamically load the keystroke handler at runtime
- Add support for specifying a different handler in defaults.nh
so that internationalization issues can be dealt with without
rebuilding nethack, just supply alternative handlers in HACKDIR.
The following exported functions need to be present in
the keystroke handler .dll:
ProcessKeystroke - returns an ascii value to NetHack
NHkbhit - allows peeking to see if a key/mouse press is waiting
SourceWhere - returns location for souce code for a keystroke handler
SourceAuthor - returns author information for a keystroke handler
KeyHandlerName - returns the full or short name of the keystroke handling dll.
Provide a way to have a port-specific debug-mode commands
if PORT_DEBUG is defined at build time.
Add a win32 keystroke checking routine to assist debugging
of international keyboards.
Fix a problem with the way NetHack was handling
international keyboards by letting ToAscii() come
up with an input character based on the virtual key,
and the shift and caps lock state.
The problem with the new autocomplete was tracked down to
be the result of differences between different implementations
of backsp(). The differences go all the way back to the
early MSDOS port by the look of it, and the win32,
and Mac tty ports all seemed to pattern themselves after the
MSDOS port for that routine. Apparently, it didn't cause any
harm until now.
The problem is that backsp() sends a character sequence
of 0x08, 0x20, 0x08 on at least those ports, where the Unix
tty code only sends 0x08. So the characters in the new
autocomplete were all being erased from the screen.
This patch only fixes the win32 tty port, so I've left the
conditional code in getline.c for DOS and Mac. I
CTRL+ALT was being treated as a valid ALT-sequence,
so the meta bit was being set on it, letting it slip past this
check in wintty.c "if (!i) i = '\033';"
This overhauls the ALT processing in nttty.c, some of
which was using scancode mappings from the DOS port
needlessly.
Add "travel" boolean option to enable/disable travel command.
Add "mouse_support" wincap option to enable/disable mouse.
- When running the win32 tty version full-screen, some people
complained about the square mouse cursor.
Newsgroups: rec.games.roguelike.nethack
Subject: Re: Getting rid of the cursor?
<email deleted> <email deleted>
Followup-To:
On Thu, 04 Apr 2002 00:20:06 <email deleted> wrote:
> Ok, let me be more specific: when playing the windows non-GUI version, is
> there a way to get rid of the large rectangular white cursor?
>
> <email deleted> wrote in message
> <email deleted>
>> Can you get rid of the cursor in the windows version? I really hate that
>> thing.
>>
<email deleted>
>Newsgroups: rec.games.roguelike.nethack
>Subject: Disabling Mouse Input
>
>I purchased an older P120 laptop to be able to play Nethack at the hotel.
>I find that I rest my thumbs on the mouse touch pad all too often and my
>@ moves unexpectedly at times. I took a peruse through defaults.nh, but
>came up empty.
>
>Anyone know if mouse input can be disabled?
>
>MRSisson
#649
<email deleted> on Friday, March 22, 2002 at 13:27:03
software: os: w2k workstation
nh: stock tty nethack.exe
comments: When you move onto a space and your pet moves onto the space
next to you on your left, your @ is displayed w/ normal attributes
instead of bright.
hilite_pet option is enabled
IBMGraphics option is disabled
#656
<email deleted> on Friday, March 22, 2002 at 16:59:37
nhfrom: 3.4.0 Official binary release for Windows 95/98/NT/2000/Me/XP
software: Windows 98 SE playing the ASCII version
comments: Sometimes when I'm standing next to my pet the @ turns grey, it goes
back to white after I move.
I didn't mean to override for any color in the mask. My
earlier patch caused it to make green, blue, or red all
become black (which still looked better than white on
grey).
This gets it right (famous last words), and only makes
the text character's color black if it is actually white
or bright white.
when hilite_pet was enabled. After checking into it, the
test was looking for the value:
(FOREGROUND_GREEN|FOREGROUND_BLUE|FOREGROUND_RED)
which signifies a white color on win32 console I/O. The
problem was that in some cases that was OR'd with
something else such as FOREGROUND_INTENSITY.
Fix it by checking only the bits that matter when
turning on the attribute.
Add absent prototypes to some core routines.
Also add some port function() to function(void) in some win32 routines.
Also updates the Borland C Makefile for win32.
The following fixes several bugs:
1) Mismatch between docs and game in definition of what '+' resolved in
favor of docs...
2) When game needs to be recovered a message box is shown. This is a very
deprecated fix. It pretty much answers just the conditions that require
this (a yn question to an erroneous winid), and is not useful for other
purposes.
3) The score file is written.
