Re: [code] vt100/ansi definitions

From: Gary Barnett (gbarnett@POLARNET.COM)
Date: 03/24/98

-----Original Message-----
From: peter hartman <wart@KUNTRYNET.COM>
To: <>
Date: Tuesday, March 24, 1998 6:10 AM
Subject:  [code] vt100/ansi definitions

>Greetings and Salutations:
>  I've been recently pondering the idea of enhancing the prompt.
>Eseentialy, I kno wthat with vt100 emulation you can 'window' your screen.
>In essence, what I mean is that I've seen programs that will allow you to
>have maybe a line or two of constant data (the prompt) and then the rest
>of the screen being the window of action.  That would save a lot of
>repetitive sends, since the prompt would be more or less constant on the
>bottom of teh screen.  In order to implement this idea, I was wondering if
>anyone had a resource on vt100/ANSI definitions and control codes?  Or,
>has anyone implemented this idea before?  I'll keep digging around on the
>net, but any help would be appreciated.

I have it working for several features.. more or less. I use it for a
top/bottom non-scrolling prompt, for automatic terrain screen updates during
combat, and will use it for the space travel screen so you get a realtime
update of your position and so on. This is primarily done to avoid redrawing
a map every update.

The trouble is that each mud client does things just a bit differently. When
I have more time I will download all the ones I can run, create a toggle
client <client_name> option and be done with it. You could also give them a
set of options they can try along with test routines so they can
self-configure their client without knowing what a cursor or scrolling
region is :-)

All in all, it's something I wish I could post a neat function and point to
all the mud client developers and say, "do it this way.", but I doubt that'd
work, even if I tried. After all, the RFC is there and that isn't even being
faithfully implemented.

My advice for someone who really wants to do it: read the rfc's and use a
known-compliant telnet app to create your library of callable functions to
handle each task. Then, you will be able to add client specific behaviors
with a minimum of fuss. Saves a lot of debugging time, as your favorite mud
client probably does at least one thing completely wrong and a bunch more
either barely supported or partially supported.

Here's a good place to bookmark for standards info:

BTW.. Anyone using RIP?

My understanding is that you need the following to write a rip based mud:

1) Players who _buy_ a copy of the proprietary terminal app (which lacks mud
client features and costs money)

2) A server license to use the proprietary protocol.

Am I right? dead wrong?


     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     | |

This archive was generated by hypermail 2b30 : 12/15/00 PST