[quake3-bugzilla] [Bug 4799] New: Client tty console (con_tty.c) buggy [patch attached]

[bugzilla-daemon at icculus.org]

http://bugzilla.icculus.org/show_bug.cgi?id=4799

           Summary: Client tty console (con_tty.c) buggy [patch attached]
           Product: ioquake3
           Version: SVN HEAD
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Misc
        AssignedTo: zakk at icculus.org
        ReportedBy: nlandys at gmail.com
         QAContact: quake3-bugzilla at icculus.org


Created an attachment (id=2481)
 --> (http://bugzilla.icculus.org/attachment.cgi?id=2481)
Fix for client con_tty.c issues

OK I've already sent this out on the ioquake3 mailing list.  So I'm just going
to copy and paste most parts of the email here.
================================================

First let me give you a little bit of background to justify why I spent so much
time fixing these bugs.  Let's say I'm hanging out with my clan and we find a
scrim.  Someone writes a text message over Mumble with an IP address, port,
and password to the scrim server.  So currently, I have to try to memorize
this information or minimize my game window so I can type as I read.  It's
really annoying.  Back in the old days I could just copy and paste the info
into my X terminal.  Yes, I'm running Linux.

So, my mission for the past couple of days has been to fix con_tty.c.  I know
there were many issues with the old [client] version, and as far as I know
I've addressed all the issues.  Now my patch (attached) does
not enable the tty console on clients.  My patch also doesn't modify the
behavior of the console on servers (well, almost doesn't; it does fix two
small bugs, see #5 and #9 below).  So, if you're using my patch on either the
server or on the client you'll hardly even notice that the patch is applied!

If you would like to start _using_ my patch and trying it out, you'll have to
edit the Makefile to change "client/con_passive" to "client/con_tty" in the one
spot where you see it.  If this change to the Makefile is made, I'm not really
sure how many other systems it affects other than Linux.  I have not gotten
that far into fixing the other consoles yet.  For example, by changing the
Makefile in the way suggested, it may cause Windows client builds to use
con_win32.c.  I really don't know at this point.  However, just fixing
con_tty.c is a step in the right direction.  If needed, I will fix any other
version of the console as well (such as Windows).


Here is a rundown of the changes in my patch:


1. The tty prompt can be changed to any string consisting of one or more
characters (well probably zero or more characters but alas, I didn't actually
test the zero case; the code should handle it from what I recall).  The tty
prompt is defined via TTY_CONSOLE_PROMPT.  Right now it's set to the original
"]" for servers and to "ioq3-tty]" for clients.  You can change it to a better
value before committing my change.

2. Commands typed in the tty console can optionally be sent to appear in the
in-game console.  Right now that feature is turned on.  It's controlled via
TTY_COMMANDS_VISIBLE_IN_GAME (tests presence of this being #defined).

3. [removed]

4. Using the symbolic STDOUT_FILENO more consistently instead of 1 in
write() calls.
5. If a user types Enter at the tty prompt, the empty string will no longer
be added to the history.  Only commands consisting of one or more
characters (even if it's a space) will be added to the console history.
This change affects the server console too.

6. On tty console initialization [especially for clients], make sure that the
prompt appears immediately and not only after a call to Com_Printf().  When
the game starts and a user doesn't see the prompt, it may lead to poor
user experience.

7. Only commands are allowed in the tty console.  No chats.  (This is the old
behavior.)  To make that more clear in the client console, all commands will
have a '\' prepended to them.  This '\' will appear before the command when
it's entered (visually) and the '\' will be present in the history.  The '\'
is not prepended if a '/' starts the command.  A '\' is also not prepended when
the command length is at capacity (length 255).  This only applies to a client
tty console; the server console is completely unchanged in this respect.

8. CON_Input() returns the stuff after a '/' or a '\' if such a character
precedes the command string.  In other words, autocompletion is no longer
broken.  Like I said in #7, a '\' is prepended to every command, so seeing
that '\' whether you used autocompletion or not makes things very consistent
and causes a delightful user experience.  This change does not apply to the
server console.  (In server console, the command string is treated literally
including any preceding slashes.)

9. CON_Print(), which is called as a result of any Com_Printf(), only
does the CON_Show() of the prompt when the string being printed ends with
a '\n'.  I have a very good explanation of how this works in the comments
to the code.  The problem with outputting a prompt on a line that doesn't end
with a '\n' is that the output can get garbled, especially if the prompt
consists of more than one character.  This is the only other change that
affects the server console.  It's not a dangerous change; it only improves
things.  It does not cause any problems even if every string passed to
CON_Print() never ends with a '\n' (it will only look a little bit unpleasant,
but won't be any more unpleasant then before).


Let's test out and proofread my changes!  Hopefully this patch can make it
into the ioquake3 SVN source tree!

If you see any problems please let me know.  I can work on making this as
good as you need it.

I have already tested this change on a server and on a client with
TTY_COMMANDS_VISIBLE_IN_GAME on and off.

Also we need to figure out what other console code needs to be fixed
before enabling tty console in the Makefile.

-- 
Configure bugmail: http://bugzilla.icculus.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.