-----Original Message-----
From: peter hartman <wart@KUNTRYNET.COM>
To: CIRCLE@post.queensu.ca <CIRCLE@post.queensu.ca>
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:
http://www.cmpcmm.com/cc/standards.html
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?
--Mallory
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST