Resets and repops

[Chris Gray]

:Yeah, we do this.  Although we don't chunk together the messages (no cr/lf's
:except to break up natural text blocks) in order to increase readability,
:we do have basically three seperate windows.  There is a single status bar
:line which replaces the normal mud prompt, and contains things like your
:fatigue level, what task you're currently doing, and whatever else you desire
:to throw in there.  Everything above this line is the text window, and
:everything below it is the command line.  This is user configurable, but
:normally you have a single line for text input, leaving screen height - 2
:lines availible for text output.
:I fooled around with ncurses for a while, trying to get it to work with
:descriptors, but it was both hacky and not very quick, so I finally gave
:up and just did it with raw vt-100 codes.  (If anyone wants the reference
:I used or the even the code let me know, I've posted it to r.g.m.a and
:alt.mud.programming before as well.)
:As it is we don't even support non-vt100 terminals, which I suppose is a bad
:thing.  One of these days I'll put support for 'normal' mud output (ie an
:undefined teletype style terminal), but the windowed thing is just soooooo
:nice that I'm loathe to actually do so.

Sounds similar to mine. I don't have a status line in the text window,
but the scenario could do that in the graphics window if desired. So,
there is no separation between the input line and the output area. This
makes is look quite natural when you hit RETURN, since your input line
is just inserted, prompt-included, into the output area. Do you use the
'readline' functions to allow input history editing? I find that quite
useful, especially when you get into situations like combat, where you
enter the same comands[s] multiple times.

I do output formatting in two places. The server does the main stuff,
based on three things:

    the current indent amount

    the current output prefix if any (I use this to distinguish output
	produced in some special way, e.g. from a remote viewer)

    the current output width (defaults to the width of the client's
	text area, but can be changed by the scenario)

The client will also do word-wrapping, but that's really only a fall-back
when you force the server to believe an incorrect width.

There can also optionally be a leading '@' to distinguish output produced
by apprentice code as opposed to full wizard code.

I've found that these, in combination with prompt-changing, allow me to
do pretty much everything I've thought of so far. Of course, I *do*
require a custom client for this. Without the custom client, I so far
don't do anything at all, so you get the usual mishmash of input and
output. Does anyone have any nice code for using the telnet protocol to
improve the output a bit? Right now I just use simple text I/O both ways,
but my understanding is that you can handshake with a telnet program to
get it to do some handy things for you. I know it can do password blanking,
but I'm hoping there is more there, too.

--
Chris Gray   cg at ami-cg.GraySage.Edmonton.AB.CA