Resets and repops

Adam Wiggins nightfall at inficad.com
Mon Mar 24 22:08:23 CET 1997


> 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

Ugh.  I really dislike this, to be honest.  This is exactly how the
split-screen mode in tintin works, and I've always avoided it.
My feeling is that text that scrolls in the game-pane should read more
less like a book.  We are very careful to re-route all 'system' messages
(such as "Invalid command" or "You do not see that here") to the system
message window (one line currently).  Also we have a thing called "newbie
notes" - until the player manually toggles off the newbie flag on
his account, he will get all sorts of little messages to help them along,
ie wield -> "The 'wield' command is useless here - type 'help hands'."
Then we make all game messages verbose in that you never type open door
and just get the message 'Okay.' or 'It seems to be locked.'
Instead your character actually walk up to the door and tries to open
it.  Everyone in the room gets the message that you tried to open it,
and if there are traps etc on the door they will be triggered.  (Assuming
they are set for touch.)
The result is that you get an unbroken flow of text that a third party
could read and follow easily, and it's never broken up by messages like
"You don't see that here", since they don't appear in that pane.

> '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.

Absoultely, although I really despise readline.  We have the standard
mud utility commands (!, ^, !<string>, !his) which I think are fine for
now.  We may go ahead and add tcsh-style command paging (up and down arrow
keys or ^P) sometime, but I've got more important things to thing about
at the moment :)

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

Not sure what you mean by this?

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

Snooping, remote charmie control, etc I assume

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

Hmmm.  Changed by the scenario?  We have auto word-wrap based on the
width the user specifies for their screen in the account configuration,
but I'm not sure why this would ever change?

> 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.

*nod* I considered this briefly; in fact I have long considered writing
a client for my own uses (tintin is horribly coded, tinyfugue is just
too obtuse for my simple needs), but have a thousand other more pressing
things to do.  We also thought of doing a client for our mud specifically,
but the vt100 codes do pretty much everything I want, and I like the
simplicity of telnet.  (I've found myself mudding from literally dozens
of sites over the years, often hopping back and forth...fooling with a client
would have put me off from a mud unless it was totally killer.)

> 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.

Um...actually telnet can't do much of anything, that I've seen.  It does
have these extended code thingies but you need a special telnet interpreter
(basically, a client), so I'm not sure what the point is.  At any rate I've
found that the vt-100 codes are pretty darn powerful.  In fact you can do
some pretty annoying things to people, such as turning on smoothscroll
(which you'll know SUCKS if you've ever used a raw VT100 terminal).
You can set up multiple scrolling windows, move the cursor around,
erase large chunks of text, query the user's terminal for its configuration,
and a whole host of other stuff.  I only use the windowing and cursor movement
stuff, as well as line clearing (extremelly nice to be able to clear a given
portion of the screen in one command).

Anyways I've gotten several requests for the vt100 stuff, so I went digging
around for it.  Remembered that I deleted all the related files off the
machine we develop the mud on, and the only other copy I had is on an old
hard drive formatted for DOS.  Unfortunately the drive isn't bootable and
I don't have any DOS boot floppies, so I'm gonna see if I can track one down
in order to get on there and try to find those docs.  If not I'll just
extract the relevant parts of my own code and post them here; however I only
use a tiny part of the functionality (setting up windows, clearing portions
of the screen, and saving/restoring/movign the cursor).




More information about the mud-dev-archive mailing list