<!-- MHonArc v2.4.4 -->
<!--X-Subject: Re: Resets and repops (a really short post) -->
<!--X-From-R13: pynjNahyy.arg -->
<!--X-Date: from major.globecomm.net [207.51.48.5] by mx4.ibm.net id 859237481.78138-1 Mon Mar 24 21:04:41 1997 -->
<!--X-Message-Id: 3336ed2965b2002#msgSFO01,schwab.com -->
<!--X-Content-Type: text/plain -->
<!--X-Reference: 199703220443.EAA168392#out2,ibm.net -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, Re: Resets and repops (a really short post)</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:claw#null,net">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">
<font size="+4" color="#804040">
<strong><em>MUD-Dev<br>mailing list archive</em></strong>
</font>
<br>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg00196.html">Previous</a>
| <a href="msg00201.html">Next</a>
]
Thread:
[ <a href="msg00206.html">Previous</a>
| <a href="msg00203.html">Next</a>
]
Index:
[ <A HREF="author.html#00200">Author</A>
| <A HREF="#00200">Date</A>
| <A HREF="thread.html#00200">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>Re: Resets and repops (a really short post)</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: Multiple Recipients of MUD Design Mailing List <<A HREF="mailto:mud-dev#null,net">mud-dev#null,net</A>></LI>
<LI><em>Subject</em>: Re: Resets and repops (a really short post)</LI>
<LI><em>From</em>: <A HREF="mailto:claw#null,net">claw#null,net</A></LI>
<LI><em>Date</em>: Mon, 24 Mar 97 08:34:02 -0800</LI>
<LI><em>Reply-to</em>: <A HREF="mailto:claw#null,net">claw#null,net</A></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
On 21/03/97 at 11:09 AM, Nathan Yospe <yospe#hawaii,edu> said: >On
Wed, 19 Mar 1997 claw#null,net wrote:
>:On 18/03/97 at 10:00 AM, Adam Wiggins <nightfall#inficad,com> said:
>:><Chris Gray:>
>: Built in rumour systems
>
>Macroscopic approximation, if you must have it. This allows a rumor
>to traverse a dead area with no CPU burn, and when a Player finally
>encounters the Rumor, he/she will have no clue whether it propogated
>live or not.
For me there are two problems here:
1) It assumes that Players (or their equivalants) are the only items
which define "interesting" in the server's world. ie the reactions of
internal systems to the rumour is insignificant, or can be entirely
predicted and constructed as of any later time. I presume this is
centered about your concept that the universe should be
auto-predicted/auto-generated and not maintained in real time.
2) It requires that rumours be managed by a centralised control
which precludes localised specialised rumour processing without the
HQ's implicit knowledge. (eg accellerated rumour decay, mutation,
direction of spread, interest content, probability of delivery, etc)
It also precluded (well, makes more difficult at least), localised
inconsistant rumour systems which are not part of the global rumour
system.
I'm not real comfortable with either point. For me MUD worlds are a
question of accidental ongoing unforseen synergy and going the route
of auto-generating areas as of time-predicted states just loses that.
Its not that your magic system encourages players to hoard dead rats,
its that dead rats discourage most rumour mongers from visiting you
(aversion to dead, aversion to rats), and thus you can better conceal
the fact that you are running a rat breeding/slaughter factory above a
pool of TC's which feed mana to your highly unstable hoard of super
magical objects. Hang on! You're not supposed to be breeding rats!
Why not? Rats will eat dead TC's. TC's will eat dead rats. Ensure a
fairly steady food supply (divert a stream?) and voila! You have one
huge mana factory. Best of all there's no external mana leakage to
make your area appear on mana flow detectors.
Its compleatly unplannable for -- but its the sort of thing players
(or at least players like me) would and will do.
>: Newspapers
>
>Er... how does this differ from rumors?
They're codified and accuracy of transmission is guaranteed. (eg the
rumour starting in one town is "Bob died from a fall.", but mutates
into "There was a horrible murder!" by the next town, whereas a
newspaper guarantees that its content will not alter with travel)
>: OBE (Out of Body Experience)
>
>OBE would, by definition, have a manifest Player controlled bodyless
>Character. Sounds perfectly susceptible to the normal rules to me.
Depends on your implementation. For me it doesn't. I merely create
an object in the visited location and re-route all IO received by the
object to the player. As such its compleatly transparent to the
traveller, and almost compleatly undetectable to the contents of the
visited room (they can watch the room's inventory, and so detect it).
To handle the body aspects, the remote object is also a spoof on the
player's body (it just as a different location). Thus all
commands/events directed to the remote object which would normally
affect, affect the "home" body instead.
Its a lot cheaper doing it this way than forging a fake remote
character. (Tho now I think of it, ghosts might be a neat idea).
>:Scrying
>
>Again, this would create a local Player controlled bodyless Character
>manifestation, and adhere to the rules.
Same as above except I don't bother with a spoof (not needed, scrying
is concious), and allow control of the cry location/tracking.
>: High altitude overview (for those with 3D)
>
>Occupied Areas get slow refreshes even in unoccupied Rooms. Anything
>covered by line of sight from a Player is operating full speed.
Accepted. A problem can result in an area which is in sight from
above (say a cavern with a hole into the roof to outside), being state
dependant on an area which is always out-of-sight from above (the
water flowing thru the cavern is dependant on hundreds of activities
further up and down stream). Now Bubba on his Pern dragon teleports
to a position at 10,000' from which he can look into the hole in the
cavern roof.
>:Indirect viewing ("typical" magic eye objects, or your clairvoyance).
>
>Again, creates a manifest bodyless Player controlled Character
There are two Magic Eyes. Each one allows a player or mobile to look
thru it to see everything the other matching MT sees. One is sitting
lost in the grass by the side of a well travvelled path. The other is
located in the lost Dungeons where the Goblin King is planning his
next assault.
>object. : Remotely controlled/possessed mobiles.
>
>Sounds like a Player controlled Character to me.
Again, depends on implementation. I allow a player to place a geas on
a mobile, essentially allowing the player to order the mobile to
follow a course of action in fair certainty that it will. (Spoofs are
wonderful here -- they sit on the mobile and trigger on external
events to insert forged events into the mobile's stream to make the
mobile do what they want)
>: 'Bots.
>
>Player controlled.
Actually the most useful 'bots are player independant. See earlier
discussion.
>:This is of course all pretty well MUDLib stuff, but I think it
>:should be accounted for. I'm a big fan of automated rumour systems
>:with built-in local reactions to parsed rumours for one.
>
>I don't mind any of this stuff, but not a thing above has violated my
>system, and I think all of it could be implemented in Physmud++
>without a recompile.
I'm a little curious here. How do you define a phsyical law system to
your server? Is it capable of auto-predicting say Clement's "Mission
into Gravity", from base laws? Could you handle PK Dick's (Or was it
Farmer?) "The Man in Black" (a single character is responsible for the
iterative translation of a universe of chaotic physical laws into a
single law system)? I'm trying to get some feel for the method of
your scoping here.
>:-- When an object changes state such that a new state should be
>:achieved some time in the future, then that object logs an event to
>:that effect. (Standard example: mobile is killed, and needs to be
>:replaced in some form)
>Agreed.
>:-- The event that is logged is actually a fairly simple: :
>:1) At XXX time check conditions if the new state is
>:allowable/logically consistant.
>Ah. Not bad. Often, the logged event is to create a new instance at a
>future date, but with a few distinct and unique characteristics. For
>example, were I to implement a fantasy, and desire the new shopkeeper
>to replace the old scenario, I would have a generic shopkeeper, and a
>set of pick and choose features, which would be applied to the
>generic shopkeeper randomly by his predecessor upon death, and
>scheduled for an appearance at some later date.
I can do this (haven't) by having a data blob passed down from the
original event:
Bubba Shopkeeper dies.
Logs reincarnate check event with attached data blob XXX.
Reincarnate event runs, checks out OK
Instantiate event logged with attached data blob XXX.
Instantiate event runs, parses data blob for preferred paramaters
for new instantiation.
At the moment I allow the instantiation event to figure out its own
thing.
>:Its this randomity factor
>:that prevents the known repop times. Instead its now: Whoozis will
>:start thinking about repopping in 15 minutes, with a 0.5%
>probability :of actually repopping in any given minute after the 15
>minutes are up :(so could be right on 15 minutes, or could be 6 days
>from now).
>I can see how this would be nice. Damnit, now you got me thinking of
>scrapping my Event system and rewriting. Don't do that! *grin*
I'm really really really sorry. I promise to do it again.
>:3) If no, and if the re-instatement is still "possible", relog the
>:same event as in #1 but for a yet future time.
>I do have "delay" scheduling.
?
>:The clever stuff comes of course in the recreating of the state,
>:which is where I finally followed ChrisG's tack <nod> and split my
>:object model into class objects (which must be unique, and may
>:inherit from multiple parents), and instances (which must inherit
>:from a single class object, and need not be unique). FWIW the
>:driving gain for moving to this split was standardised ctors and
>:dtors for object instantiation.
>My OLC object vs instance model.... and there are other advantages...
Close to. Chris Gray described this way back before your list, except
that he AFAIR splits it down to having objects store individual
methods, and "objects" in the MUD world sense are then collections of
tiny single method/attribute objects into an "intelligent" whole. (I
don't go that far)
>modification of an OLC object, however, under my system, does not
>change any of the instances... quite. Lazy copy model, which means
>somewhere out there will be floating a copy of the original
>characteristics, until the last copy of them is destroyed...
Ahh, here changing the base code for a class object causes every
dependant child to rebuild their inheritance trees the next time they
are touched/loaded. (Lazy rebuild?) Touch a root object and the
whole MUD will re-orient like a fifteen tonne charging rhinocerous
doing a 360 on a dime.
This of course can be thought of as a Good Thing, or a very Bad Thing.
>...so if
>you modify, say, an OLC version's description, the String will cut
>loose and bindto one of the instances... if that instance dies, it
>will bind to another, and so forth. Certainly saves on the String
>overheads.
Because my memory image is so fluid (everything resides on disk) I
haven't looked much at using in-memory compression. I do reference
count and fold strings tho, and the whole DB cache with the requested,
modified-but-not-committed, committed, etc states, along with the
interested party lists is pretty tight.
>:Handling minor details like closing opened doors, re-locking chests,
>:and resetting traps and the like is similarly handled, with the
>:secondary event either doing it directly ("A sudden strangely cold
>:breeze slams the dtor shut"), to the animation and trekking of a
>:work-horse mobile to the door/trap/whatever to reset it "manually"
>:(cf MirrorWorlds "man in a white lab coat")..
>Ugh. Lets just have it happen when no one is looking.
As pointed out earlier on this thread, the problem is that an object
in a well travelled location (ie constant player traffic) will never
reset. While this may be a Good Thing on the face of it, there should
be an automated system to retrieve the object to allow the reset.
>Incidentally, I
>have explained my system to allow a Player to experience an
>Occurance, the results of which are permanent to that Player, and
>that Player alone, haven't I?
On the old list only, and then during its final death throes. It
would probably be a good idea to go over it again.
>Things like blowing up a complex or
>triggering a thermonuclear detonation can be coded to become a part
>of that Player's history, and that Area will forever after be a
>destroyed complex or glass lined crater to that Player's
>Characters... and anyone else that is introduced to the aftermath.
Which presents a very interestingly fluid aspect to time. Were I to
do this I could see having mobiles set up to edit character's
timelines for a fee, adding or deleting event histories to allow
travel to different time tracks.
(Always the rebel)
The thing that bugs me about it is:
Bubba and Boffo (two RL players) are stting side by side in their dorm
room, MUDding on PhyMUD++.
Bubba: Hot diggity! I just nuked the collosseum!
Boffo: Oh wow! Lemme see! I'll be there in a sec.
(sound of frantic typing)
Boffo: Hang on! I just walked into the colloseum and its fine!
Bubba: But I jut nuked it! See! Look at my screen...
>:Aside:
>:
>:At the moment I've been intending to make the TrashCollectors (cf
>:earlier discussion with ChrisG on removing waste objects) do this as
>:a side effect of their normal rounds. The base purpose of the TC's
>:are to accellerate object decomposition, and provide an amusing
>:(cheap) target and toy for users.
>:
>:Essentially the TC's would wander the land in slightly overwhelming
>:numbers, finding and collecting any loose odd objects that happen to
>:be laying about (eg torches, dropped EQ, weapons, newly programmed
>:and abandoned user objects etc). How the TC's handle that junk
>:comes in a number of flavours:
>So far sounds like Midgaard janitors.
Accursed insult! Die foul fiend! Begone loathsome malingerer!
<<Like Midgaard indeed! Ha! The bloody nerve>>
>:-- If the object is small they pick it up and continue on. -- If a
>:larger object they englobe the object and decay it and any carried
>:objects at an accellerated pace. Once the object(s) have
>:destructed, the TC will move on, having grown slightly. This
>:process produces considerable mana.
>-- If the object is too large to
>:englobe, it will suck its own thumb and grow until it is large
>:enough to englobe the object(s). Once the object(s) have
>:destructed, the TC will split into multiple new TC's . This process
>:consumes considerable mana. Should there be insufficient local
>:mana, the TC consumes the mana, dies, and scatters a spore for each
>:unborn TC.
>:-- If the object is a TC corpse, the TC will eat it and
>:grow by a factor smaller than the size of the TC eaten. There is no
>:net mana change.
>:-- If the object is another TC, a small percentage
>:of the time one TC will eat the other, and both will die, producing
>:four TC spores in the process.
>:-- If the object is in some way
>:special/wanted the TC picks up the object, drops anything else it is
>:carrying, and attempts to convey it back to a (special
>:characteristic specific) dumping group. (This makes TC's preferred
>:hunting targets for players) A carrying TC will produce significant
>:mana in each room it passes thru.
>:-- The TC will spoof the object
>:found, and disappear. The action of the spoof is to speed the delay
>:of the object, and to drop a TC spore (that will grown into a new
>:TC) into a percentage of rooms it passes thru which don't contain
>:TC's or TC spores. In the mean time the base object continues to
>:behave as normal until it destructs. There is no net mana effect.
>-- If the object is a TC spore, the TC will eat the spore and
>:increment the count of the number of spores it will release when
>:it dies.
>Intersting. Extremely complex. Very interesting. Can't imagine how
>hard to program that's gonna be.
Not that tough to code. I'd estimate an afternoon. The nice bit is
that each of the above "feetures" is self contained. The only thing
that really varies is when its invoked. Ergo: TC enters location,
checks local inventory of objects, generates random value, enters
switch/case of possible handlers, invokes handler. Everything from
there is a transparent bolt-on.
>:Once a TC has grown past a specified size, or if it successfully
>:consumes more than X objects, it will split into two otherwise
>:identical TC's. A TC in normal operation (moving, whatever),
>:continually and slowly produces mana. However, very high mana
>:levels are quickly fatal to TC's _unless_ they find an object to
>:englobe.
>:TC's have a set (short) lifespan. They are born from spores, grow
>:on objects found, move quickly, and produce spores when they die.
>:As far as resets are concerned, should a TC find an object with a
>:reset() method, with a set RESET_ME flag, the TC will call the
>:reset() method a percentage of the time (percentage depending on age
>:of requested reset, plus object-specific fudge factor).
>:
>:A TC spore will consume all mana in its area. The rate of
>:development of a TC spore is porportional to the rate of mana
>:consumption. Should their be no mana, the spore will lay dormant.
>Hmmm. Wierd world you have going here. *grin*
Yup. They way I see it, I only need to maintain enough reference and
duplication with the real (ie non-MUD) world to allow users to have
some chance of understanding and predictably handling what is going on
in the MUD world. Its a question of ensuring there are enough shared
referrants to be playable,
Its sort of the opposite viewpoint really. Rather than attempting to
make the MUD more "real", I'm working to make the MUD only as "real"
as it has to be to be playable, but absolutely no more. The real
fight then is to make the MUD *internally* consistant. I want to see
a MUD which obeys its own world rules rather than attempting to be a
pale imitation of a dreamed reality.
>:This way to do this is to implement base systems which automagically
>:generate rumours/news events etc, which are then carried about and
>:reacted to by mobiles, and communicated to players etc. Once you
>:have a base, automatic rumour system (one that requires no
>:supporting code in other objects) most of the rest should pretty
>:well come for free.
>I've created a class derived from my Communication class that
>essentially does this. It spawns, splits, mutates, decays and jumps
>from Character to Character. When it jumps to a PC, it causes the
>previous holder to tell the rumor to the PC. It cannot live on non
>sapients, and certain personalities will also kill it. PCs can spread
>rumors by typing "tell <name> about <something from the rumor key>"
>IE, if the PC had recieved the rumor with the message 'The ugly old
>man tells you, "Hey, buddy, did you hear about the king's daughter
>and the horse trainer?"', you can later type "tell uffoogu about the
>king's daughter" and it will autotell the rumor for you.
Neat.
>:eg Mana comes in two forms, +ve and -ve. Mana is required to do
>:magic (sign dependant on magic used). Magical objects have a mana
>:sign (-ve or +ve), and consume mana of that sign, thus slowing or
>:stopping their decay. Magical objects react to opposite sign mana
>:by accellerating their decay. Should a magical object find no mana
>:to consume they decay VERY quickly (no mana is worse than bad mana).
>:TC's and a few other objects produce mana (always in matched +ve
>:and -ve pairs) at various rates. Mana flows like a liquid thru
>:rooms and spaces, attempting to have no two locations adjacent with
>:different mana levels.
>Cool!
Thanks.
>:What's this mean? Magical objects have a definite life span. Don't
>:feed them enough mana and they destruct. The more magical objects
>:you have together, the more quickly your local area becomes mana
>:depleted (mana flows slowly) and the more quickly they decay. Get
>:sufficient highly powered magical objects together and they'll all
>:destruct within seconds. Keep only one or a few magical objects,
>:and they'll survive on the local mana. Want lots of magical items?
>:Better keep them all right beside a major mana producer (eg a farm
>:of TC's you continuously feed trash).
>I like this! Consistant laws! (Which means it can be implemented in
>Physmud++!!)
>:Magic fights also become travelling affairs. No-one can afford to
>:stand still -- they run out of mana. Then again, manage to locate
>:yourself by a major mana producer, and you have a huge advantage. :
>:You sure as heck won't find any super powered over-armed magical
>:users or mobiles wandering about -- they may have the Spear of Icy
>:Death, the Greaves Of Incredible Footwork, the Magical Nose Ring Of
>:Killer Snot, and the Goggles Of All Making All Tits Bigger, but
>:unless they work their butts off keeping them fed enough mana, six
>:steps later they'll all turn to dust.
>Love your item names.
Yeah, and those are the toned down versions. I've had some rather
interesting days of late.
"That kill3r snot is a gnarly c00l w3apon dood."
<<Of course some prefer the googgles>>
>Hmmm. A possibility: enchant an opponent's sword to destroy it?
Yup! Especially if you know there's not enough mana about to support
the enchantment, which is likely, considering that your spell soaked
up a bunch of mana to create the effect.
>Or inconvenience the enemy, at the least.
The true test of a battle:
UggUgg slashes at you with his Sword of Instant Beheading
and minor discomfort!
> cast soakhole on uggugg
You cast the dreaded mana eater soakhole on UggUgg!
UggUgg sneezes and buries your in green snot!
Your armour suddenly dissappears!
Your spell of magical summon protection fails!
Your spell of magical sight fails!
UggUgg's Nose Ring of Killer Snot dissappears!
UggUgg's Belt of Gas Containment dissappears! Phew!
UggUgg's dagger of wart removal dissappears!
> cast create mana
You create 5,000 units of mana!
Your mana stores are now empty.
>cast $my_protections
You are now magically potected from summons.
You can now see all magically hidden objects.
UggUgg thows a blade of painful castration at you!
> jump!
You leap mightily.
The blade misses! You are still a baritone.
> attack uggugg with spear
You ram UggUgg through with the spear of Icy Death!
UggUgg now has the flu and looks a bit watery about the eyes.
UggUgg picks up a rock.
UggUgg bases you with a rock! Ouch! That hurt!
> throw TC at uggugg
You throw the charmed trash collector at UggUgg.
The TC englobes UggUgg!
UggUgg gives you the Sword of Instant Beheading and minor
discomfort.
UggUgg gives you the Boots of Mighty Chilblains,
UggUgg gives you the Goggles of Big Farts.
UggUgg gives you Super Nose Hair Puller.
The TC has eaten everything UggUgg was carrying! Yech!
UggUgg is naked!
Your spell of magical summon protection fails!
Your spell of magical sight fails!
Your spell of magical tummy tuck fails!
Your spell of power voice fails!
Your spell of land control fails!
Your spell of bowel control fails!
Your spell of toe cheese protection fails!
> stat spells
You have no spells.
> stat mana
There is no mana here.
> strangle uggugg
You wrap your hands about UggUgg's neck and begin to squeeze!
UggUgg prays to the Great God GooGoo!
GooGoo mana blesses the area!
There is a LOT of mana here! You skin prickles!
> i
You have a mana shielding sack
> l in sack
There are 5,000,000 TC spores in the sack.
>empty sack on UggUgg
The spores eat all the mana!
There are 5,000,000 TC's here! Wow.
All the mana is gone!
...
The real weapons now are mana attacks. But then woe be the chap who
sneaks in with a non-magical bodkin and pricks the battling mages in
the arse while they mana fight. He might just win the war.
>Or
>would it drain from you by proximity?
Both really. The objects don't care where the mana comes from.
>That could be cool... an
>overenchanted sword that must feed off of magical prey constantly, or
>drain its owner dry.
Easy enough to do -- just have magical prey eat mana by adding it to
their inventory (up to a set level, and from there on destroy it).
>I can just see it.... here, unicorn, unicorn,
>unicorn.... my sword really wants to make your acquaintance!
cf The Book Of Swords, SoulBiter etc.
>I have to say, you guys create universes every bit as cool as my own.
>And killer bases for those universes. No wonder the newsgroups have
>decayed so much... we keep sapping out the talent.
There are still some out there. I'd love to get people like Stephan
White, Greg Hudson, David Engberg, Hollenbeek (sp?), Reese, etc in
here at some point. Even that AEMud chap, and as long as I don't have
to tolerate the NT line, the MUNT fellow.
--
J C Lawrence Internet: claw#null,net
----------(*) Internet: coder#ibm,net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00196.html">Re: Resets and repops</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00201.html">Re: Resets and repops</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00206.html">Re: Resets and repops (a really short post) <= hah!</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00203.html">Re: Resets and repops (a really short post)</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00200"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00200"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><STRONG>Re: VT102 codes</STRONG>, <EM>(continued)</EM>
<ul compact>
<LI><strong><A NAME="00215" HREF="msg00215.html">Re: VT102 codes</A></strong>,
Adam Wiggins <a href="mailto:nightfall#inficad,com">nightfall#inficad,com</a>, Wed 26 Mar 1997, 14:29 GMT
</LI>
<LI><strong><A NAME="00221" HREF="msg00221.html">Re: VT102 codes</A></strong>,
Adam Wiggins <a href="mailto:nightfall#inficad,com">nightfall#inficad,com</a>, Wed 26 Mar 1997, 23:25 GMT
</LI>
</ul>
</LI>
<LI><strong><A NAME="00210" HREF="msg00210.html">VT100 codes ...</A></strong>,
Khanone <a href="mailto:Khanone#aol,com">Khanone#aol,com</a>, Wed 26 Mar 1997, 03:25 GMT
<LI><strong><A NAME="00206" HREF="msg00206.html">Re: Resets and repops (a really short post) <= hah!</A></strong>,
Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Tue 25 Mar 1997, 23:44 GMT
<LI><strong><A NAME="00200" HREF="msg00200.html">Re: Resets and repops (a really short post)</A></strong>,
claw <a href="mailto:claw#null,net">claw#null,net</a>, Tue 25 Mar 1997, 05:04 GMT
<UL>
<li><Possible follow-up(s)><br>
<LI><strong><A NAME="00203" HREF="msg00203.html">Re: Resets and repops (a really short post)</A></strong>,
Nathan Yospe <a href="mailto:yospe#hawaii,edu">yospe#hawaii,edu</a>, Tue 25 Mar 1997, 16:33 GMT
</LI>
<LI><strong><A NAME="00241" HREF="msg00241.html">Re: Resets and repops (a really short post)</A></strong>,
claw <a href="mailto:claw#null,net">claw#null,net</a>, Fri 28 Mar 1997, 05:17 GMT
</LI>
<LI><strong><A NAME="00242" HREF="msg00242.html">Re: Resets and repops (a really short post)</A></strong>,
Adam Wiggins <a href="mailto:nightfall#inficad,com">nightfall#inficad,com</a>, Fri 28 Mar 1997, 13:01 GMT
</LI>
<LI><strong><A NAME="00248" HREF="msg00248.html">Re: Resets and repops (a really short post)</A></strong>,
Nathan Yospe <a href="mailto:yospe#hawaii,edu">yospe#hawaii,edu</a>, Sat 29 Mar 1997, 04:09 GMT
</LI>
</UL>
</LI>
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>