From broehl  Tue Jun  9 10:14:31 1992
Received: by sunee.waterloo.edu
	id <AA22978>; Tue, 9 Jun 92 10:14:31 -0400
From: Bernie Roehl <broehl>
Message-Id: <9206091414.AA22978@sunee.waterloo.edu>
Subject: The Netgame Mailing List
To: netgame@sunee
Date: Tue, 9 Jun 92 10:14:30 EDT
X-Mailer: ELM [version 2.3 PL11]


                   Welcome to the Netgame Mailing List

By now, several of you on the list are probably wondering why it's been so
quiet.  The answer is simple: I've been waiting for the initial rush of people
joining the list to taper off to a trickle.

The list now stands at 30 people, which strikes me as a manageable number.

ADMINISTRIVIA:

This is intended to be a relatively low-traffic list.  Many of us are on
half a dozen different lists (and I'm administering several myself); we don't
want to have to deal with information overload.  Keep your messages to the
point, and move any (potentially) long-winded debates to direct email.

In other words... if it isn't of interest to the whole list, just send mail
to the person you're responding to, discuss it with them, and let the list
know if the two of you come up with anything that other people might find
useful.

Remember, if you want to be added to or deleted from the list, send mail
to netgame-request@sunee.uwaterloo.ca (NOT to the list itself!).  To send
mail to the list, address it to netgame@sunee.uwaterloo.ca and it will be
forwarded automatically.

THE ARCHIVE SITE:

I'm maintaining an archive of the list, as well as a collection of documents
and proposals people have written; it can be found on sunee.uwaterloo.ca in
the pub/netgame directory.  If you want something added to this collection,
mail it to me (NOT to the list!) and I'll be happy to add it.

If you don't have FTP on your system, send a mail message containing
just the word "help" (in the body, not the subject line!) to
ftpmail@decwrl.dec.com, and you'll receive mail back telling you how to get
the files via email.  If you have problems with ftpmail, please direct them
to a newsgroup... again, NOT to this list!

The archive is a bit of a jumble right now; I hope to find some time to clean
it up later this week.  In particular, there is some duplication and at least
two incomplete works.  Please wait until early next week before retrieving
anything.

THE NAME AND CHARTER OF THIS LIST:

A few people have wondered about the name "netgame".  It was chosen because
most of the people who initially expressed an interest in shared virtual
environments were looking at them from the standpoint of multi-user games.

The name is not intended to limit discussion to games; the focus of the list
is on techniques, data formats and protocols that will allow multiple users
to share a common virtual space.  It is intended to be a fairly "techie" kind
of list; things like "wouldn't it be neat to have a virtual tennis match"
would only be appropriate if accompanied by a discussion of some of the
technical problems involved in doing so (or better yet, solutions to those
problems!).

Some of the issues we expect to see discussed on the list are:

   - network topologies
   - client/server models -- who should do what?
   - restrictions imposed by limited bandwidth and network "burstiness"
   - representation of objects: polygon, wireframe, CSG, other...?
   - caching -- where and how
   - synchronization
   - protocols

Before posting anything on any of these, please read the things people have
already written (in the archive).  Remember to wait until next week when the
archive is cleaned up.

If you have any questions or concerns, direct them to me (Bernie Roehl,
broehl@sunee.uwaterloo.ca) and I'll try to deal with them.  I tend to get
pretty busy, but I will get back to you as soon as I can.

From imagesys!clifford.imagesys.com!SHANNON@uu.psi.com  Tue Jun  9 13:27:26 1992
Received: from vesta.unm.edu by sunee.waterloo.edu with SMTP
	id <AA16102>; Mon, 8 Jun 92 21:02:12 -0400
Received: by vesta.unm.edu (5.57/0.1)
	id <AA20817>; Mon, 8 Jun 92 16:50:06 -0600
From: Brennan Underwood <evilted@vesta.unm.edu>
Message-Id: <9206082250.AA20817@vesta.unm.edu>
Subject: hello?
To: netgame@sunee
Date: Mon, 8 Jun 92 16:50:05 MDT
X-Mailer: ELM [version 2.3 PL8]

Is any traffic going on here or am I missing it?

Anyway, here's my ideas: (they keep changing, I admit)

----------------------------------------------------------------
info file for KLUGE. last updated. june 8, 1992
written by Brennan Underwood. Copyright Brennan Underwood 1992
Hellaciously messy notes.
----------------------------------------------------------------

KLUGE interprets each incoming line according to the first character:

Prefix  What it's for  
---------------------------------------------------
  >     Marks a room name (for a title above the view)
  <     Sets clear color for screen buffer
  * 	exit coordinates
  !     Marks piece's name for further operations
  $     gives room dimensions (maybe)
  #     Remark--ignore
(..)    anything between ()'s is a comment (for stuff like object(#12) )
  :     end of line
If it's A-Z, it gets printed in the text window, unless it has a '_' and
no spaces, in which case it's probably a attribute name and can be discarded.

When a player enters a room, the following command is issued:
kping -- command to fetch desc_ attributes and @emit them to player. Fetches
the name of the room too and @emits it with a >.
Since kping is a global command (or will on graphic MUSHes), all this
stuff is 'hidden' under the text things. Of course, The text stuff can
be entirely omitted. This is good, I think, as existing MUSHes could
just start adding graphics to existing areas.
Attributes used:
desc_
xmode_  (whether this is a graphic client (on/off) )
parent_ (needed for people who enter a room 'late', so to speak)
loc_	( ditto ... )

So as the client reads along, it deals with each prefix.
>  change title bar of window
< change color of rectangle used to clear the screen at each refresh
* shows what location a player has to be at to auto execute the exit name
$ gives room dimensions
# will be ignored
:  is treated the same as end-of-line. this lets more info be crammed
   onto one line, like:
&desc_ here=<clearcolor stuff:Some text about the room...:!^here/map

Put '!^objtoexamine/key' somewhere in your desc_ line.
Clients will issue 'examine objtoexamine/key*' command.
So any attributes starting with "key" will be echoed at the client for
processing.
Note that object info can be attached to any VISUAL-set object, not necessarily
the object being looked at. This is how you can be carrying a sword:
If you have sword(#20):
kemit !^#20/sword and have all the
swords desc-attributes start with sword...like sword_1,sword_2..etc
kemit is a global command that needs to be installed. It will send the
text to everyone with their xmode_ set to "on". Useful for getting along
with text-only players.

(By the way, base means the piece of an object that all other pieces
depend on)

Object desc format:
!groupname.piecename par parentname obj objname pos XxYxZ rot XxYxZ\
shi XxYxZ sca XxYxZ col CCI mod MM.
Example:
!joe.chest par joe.base obj cube pos 0x0x0 rot 0x0x0 shi -1x1x1 sca 2x1x3 col\
45 mod 00.
If a keyword is left out, a default is assumed...
Parent: root
Object: cube
Position: 0x0x0
Shift: 0x0x0
Scale: 1x1x1
Color: 000
Mode: 00
If you pick up something, it will do something like '@emit !itsname:base
(using @osucc and @succ or something)
par yourname.hand' which will reparent it to you, searching for a piece
named yourname.hand...so be sure to use the right names for your pieces
suggested:
base (but use it as an invisible object to build off of--important)
head
neck
chest
rightupperarm
leftupperarn
rightlowerarm
leftlowerarm
righthand
lefthand
pelvis
rightthigh
leftthigh
rightcalve
leftcalve
rightfoot
leftfoot
---------
...so most objects can reparent themselves correctly. We don't want
hats stuck to our feet, now do we? :) Of cource, if you WANTed it
that way....kemit-ing '!hat.base par myname.rightfoot' would do the trick.
If an object can't find something on you that matches to reparent to, the
reparenting is aborted. This is a feature. (I swear! :) ) This lets you
do stuff like having a sword try first for the pelvis, then for the belt,
then for any scabbard. it will 'snag' on the latest one...so put them
in order.
!sword.base par name.hand par name.pelvis par name.belt par name.scabbard

It will nuke everything but yourself and what you're carrying
when you go enter another room.

Hopefully the gods on the MUSH will be nice and set the
Move attribute to hidden. when you connect, your client will send
'@move me=REFRESH_KEY' so it will know when it reset your world db.
This should help world_resets to be non-spoofable.

I am planning on having an /attach command so you can attach your view
(to your head object, normally).

I have a vanilla MUSH 2.0 running right now for me to experiment. Mail me
if you want a character to use it with. (It only has a few rooms right
now, but I'm still playing with it.) Type 'xyzzy' to pop into the master
room, and examine the MCP (shades of Tron :) to see how I did 'kping'
and 'kemit'.
--------------------------------------------------------------------------
-- 
evilted@vesta.unm.edu

From evilted@vesta.unm.edu  Tue Jun  9 01:17:25 1992
Received: from vesta.unm.edu by sunee.waterloo.edu with SMTP
	id <AA19228>; Tue, 9 Jun 92 01:17:25 -0400
Received: by vesta.unm.edu (5.57/0.1)
	id <AA23462>; Mon, 8 Jun 92 23:17:08 -0600
From: Motley Athelstane <evilted@vesta.unm.edu>
Message-Id: <9206090517.AA23462@vesta.unm.edu>
Subject: Re: Netgame
To: spm@atmos.dar.csiro.au (McEWAN Shane)
Date: Mon, 8 Jun 92 23:17:07 MDT
Cc: netgame@sunee
In-Reply-To: <9206090445.AA01895@atmos.dar.csiro.au>; from "McEWAN Shane" at Jun 9, 92 2:45 pm
X-Mailer: ELM [version 2.3 PL8]

> 
> G'day! I just got your post about your MUSH and I'm _VERY_ interested.
> I've been thinking along similar lines for some months now but unfortunately
> I don't have a machine I can _LEGALLY_ run a MUD on. ;-)
> 
> I just have a few questions:
>
> What platforms can/will the clients run on? I was going to use the REND386
>libraries for my client but that's only because I no nothing about 3D graphics
> programming on PC's. *grin*
I am currently doing this in X windows. I think Bernie Roehl is interested
in using REND386 for this as well. (Heck, if I had a 386, I'd be DONE by
now! :)
> 
>How will the world database be built? Manually entering in the information for
> descriptions, etc would be too tedious and difficult to learn. I've been 
> thinking about a world description language or even a graphical "tool" in
> which you can add, delete, move and rotate objects in a similar way as you
> would using a CAD package. Once you had decided on the "look" of what you
> have created, the client would then transmit the necessary commands to @dig
> rooms, @link exits, and @desc objects.
As for now, manual data entry how I'm doing it. I want to get the client
up and running before I work on a builder.
> 
>How would the user "move" within the world? That is, would the user be able to
> move around the scene on the screen even if he doesn't go through an exit?
> How will his movement be shown to other users in the same scene? Transmitting
> each movement would probably generate a lot of net trafic. Perhaps a similar
> system, like the ones they have in the Sierra games, where you use the mouse
> to click on the part of the scene you wish to travel to and the computer
> moves the character for you. That way you would only need to transmit the
>destination coordinates to everybody and their local machines can animate your
>character walking to the new position, while locally on your machine you would
> see your view change as you walked.
Well, as it is now, a series of
!myname.base loc XxYxZ 's would have to be sent. Kinda oogy. Ideally,
there would be a 'tween'ing macro. On the after-1.0 list of things to do. :)
> 
> 
> I'm sorry if you've discussed these things before. I've only just joined the
> list. In fact, your post was the first I've seen. *grin*
>If you want, I could post this to the list if you think it will stimulate some
> action. *smirk*
I decided to Cc netgame in my answer. (Obviously.) Hope that's ok.
> 
> BTW, could I have a character on your MUSH so I can have a look around?
> 
Sure, I'll send it in a different message.
> Shane McEwan
> spm@dar.csiro.au
Note about the MUSH: It is completely bare-bones. Not a whole lot to look
at right now. But it's open to people who want to use it to try out
clients/protocols/ideas.
-- 
evilted@vesta.unm.edu

From broehl  Tue Jun  9 10:14:31 1992
Received: by sunee.waterloo.edu
	id <AA22978>; Tue, 9 Jun 92 10:14:31 -0400
From: Bernie Roehl <broehl>
Message-Id: <9206091414.AA22978@sunee.waterloo.edu>
Subject: The Netgame Mailing List
To: netgame@sunee
Date: Tue, 9 Jun 92 10:14:30 EDT
X-Mailer: ELM [version 2.3 PL11]


                   Welcome to the Netgame Mailing List

By now, several of you on the list are probably wondering why it's been so
quiet.  The answer is simple: I've been waiting for the initial rush of people
joining the list to taper off to a trickle.

The list now stands at 30 people, which strikes me as a manageable number.

ADMINISTRIVIA:

This is intended to be a relatively low-traffic list.  Many of us are on
half a dozen different lists (and I'm administering several myself); we don't
want to have to deal with information overload.  Keep your messages to the
point, and move any (potentially) long-winded debates to direct email.

In other words... if it isn't of interest to the whole list, just send mail
to the person you're responding to, discuss it with them, and let the list
know if the two of you come up with anything that other people might find
useful.

Remember, if you want to be added to or deleted from the list, send mail
to netgame-request@sunee.uwaterloo.ca (NOT to the list itself!).  To send
mail to the list, address it to netgame@sunee.uwaterloo.ca and it will be
forwarded automatically.

THE ARCHIVE SITE:

I'm maintaining an archive of the list, as well as a collection of documents
and proposals people have written; it can be found on sunee.uwaterloo.ca in
the pub/netgame directory.  If you want something added to this collection,
mail it to me (NOT to the list!) and I'll be happy to add it.

If you don't have FTP on your system, send a mail message containing
just the word "help" (in the body, not the subject line!) to
ftpmail@decwrl.dec.com, and you'll receive mail back telling you how to get
the files via email.  If you have problems with ftpmail, please direct them
to a newsgroup... again, NOT to this list!

The archive is a bit of a jumble right now; I hope to find some time to clean
it up later this week.  In particular, there is some duplication and at least
two incomplete works.  Please wait until early next week before retrieving
anything.

THE NAME AND CHARTER OF THIS LIST:

A few people have wondered about the name "netgame".  It was chosen because
most of the people who initially expressed an interest in shared virtual
environments were looking at them from the standpoint of multi-user games.

The name is not intended to limit discussion to games; the focus of the list
is on techniques, data formats and protocols that will allow multiple users
to share a common virtual space.  It is intended to be a fairly "techie" kind
of list; things like "wouldn't it be neat to have a virtual tennis match"
would only be appropriate if accompanied by a discussion of some of the
technical problems involved in doing so (or better yet, solutions to those
problems!).

Some of the issues we expect to see discussed on the list are:

   - network topologies
   - client/server models -- who should do what?
   - restrictions imposed by limited bandwidth and network "burstiness"
   - representation of objects: polygon, wireframe, CSG, other...?
   - caching -- where and how
   - synchronization
   - protocols

Before posting anything on any of these, please read the things people have
already written (in the archive).  Remember to wait until next week when the
archive is cleaned up.

If you have any questions or concerns, direct them to me (Bernie Roehl,
broehl@sunee.uwaterloo.ca) and I'll try to deal with them.  I tend to get
pretty busy, but I will get back to you as soon as I can.

From imagesys!clifford.imagesys.com!SHANNON@uu.psi.com  Tue Jun  9 13:27:26 1992
Received: from uu.psi.com by sunee.waterloo.edu with SMTP
	id <AA25948>; Tue, 9 Jun 92 13:27:26 -0400
Received: from imagesys!clifford.imagesys.com by uu.psi.com (5.65b/4.1.031792-PSI/PSINet)
	id AA07120; Tue, 9 Jun 92 13:06:44 -0400
Received: from underdog by ingemar (3.2/2.1-Image Systems Technology)
	id AB29692; Tue, 9 Jun 92 12:01:00 EDT
Received: From CLIFFORD/WORKQUEUE by underdog.imagesys.com
          via Charon 3.4 with IPX id 100.920609114638.832;
          09 Jun 92 12:01:19 -0500
Message-Id: <MAILQUEUE-101.920609114624.288@clifford.imagesys.com>
To: netgame@sunee
From: "Shannon 'Libertarians R Us' Posniewski"  <imagesys!SHANNON@uu.psi.com>
Date:     9 Jun 92 11:46:47 EDT
Subject:  Re: Netgame
X-Mailer: Pegasus Mail v2.3 (R1).

>> What platforms can/will the clients run on? I was going to use the REND386
>> libraries for my client but that's only because I no nothing about 3D graphics
>> programming on PC's. *grin*
> I am currently doing this in X windows. I think Bernie Roehl is interested
> in using REND386 for this as well. (Heck, if I had a 386, I'd be DONE by
> now! :)
I have access to a couple SGI Indigo's, a Sun 386i, and a Sun4, not
to mention a bunch of 386's and 486's.  Does your MUSH compile on any
these?  Does it exist at any ftp sites?

[...questions about moving around int the MUSH...]

I was also confused by this.  All of the MUDs I've played were all
"room" based.  You walked into a room.  You did everything from
there.  You didn't really walk around the room.  How does this work
in the MUSH?

I also haven't seen any traffic on netgame, but I hope we have
sparked some.

>> BTW, could I have a character on your MUSH so I can have a look around?
>>
> Sure, I'll send it in a different message.

We don't have any telnet access outside of our installation, so I
wouldn't be able to try it out.  I am interested an any other info
as to how it works that you can give, though.

Poz

From spm@atmos.dar.csiro.au  Tue Jun  9 20:51:42 1992
Received: from shark.mel.dit.CSIRO.AU by sunee.waterloo.edu with SMTP
	id <AA02014>; Tue, 9 Jun 92 20:51:42 -0400
Received: from atmos.dar.csiro.au by shark.mel.dit.csiro.au with SMTP id AA12795
  (5.65c/IDA-1.4.4/DIT-1.3 for <@shark.mel.dit.CSIRO.AU:netgame@sunee.uwaterloo.ca>); Wed, 10 Jun 1992 10:51:35 +1000
Received: by atmos.dar.csiro.au (5.65+bind 1.5+ida/910805.SGI/DAR)
	for @shark.mel.dit.CSIRO.AU:netgame@sunee.uwaterloo.ca id AA16481; Wed, 10 Jun 92 10:51:34 +1000
Date: Wed, 10 Jun 92 10:51:34 +1000
From: spm@atmos.dar.csiro.au (McEWAN Shane)
Message-Id: <9206100051.AA16481@atmos.dar.csiro.au>
To: netgame@sunee
Subject: Moving around a MUD.

>From: "Shannon 'Libertarians R Us' Posniewski"  <uu.psi.com!imagesys!SHANNON>
>Date:     9 Jun 92 11:46:47 EDT
>
>[...questions about moving around int the MUSH...]
>
>I was also confused by this.  All of the MUDs I've played were all
>"room" based.  You walked into a room.  You did everything from
>there.  You didn't really walk around the room.  How does this work
>in the MUSH?

The way I would implement it would be to have each room describe a scene, its
boundaries, its exits and the objects in the room. Then, all movements within
the scene are processed locally and transmitted over the net as a series of
pose commands. i.e. :move x,y,z
The other clients will receive: Fardwark move x,y,z    and they will update
their screens as necessary. The clients will know which object to move because
the name in prepended my the MUD software ("Fardwark") and they will know
that it's a change in position because of the "move" command and they will
know where because of the "x,y,z" component.
--------------------------------------------------------------------------------
"Life.........Don't talk to me about life."   - Marvin the paranoid Android.
--------------------------------------------------------------------------------


From evilted@vesta.unm.edu  Tue Jun  9 21:01:12 1992
Received: from vesta.unm.edu by sunee.waterloo.edu with SMTP
	id <AA02398>; Tue, 9 Jun 92 21:01:12 -0400
Received: by vesta.unm.edu (5.57/0.1)
	id <AA03160>; Tue, 9 Jun 92 19:01:05 -0600
From: Brennan Underwood <evilted@vesta.unm.edu>
Message-Id: <9206100101.AA03160@vesta.unm.edu>
Subject: Re: Moving around a MUD.
To: netgame@sunee
Date: Tue, 9 Jun 92 19:01:04 MDT
In-Reply-To: <9206100051.AA16481@atmos.dar.csiro.au>; from "McEWAN Shane" at Jun 10, 92 10:51 am
X-Mailer: ELM [version 2.3 PL8]

spm@atmos.dar.csiro.au writes:
> The way I would implement it would be to have each room describe a scene, its
> boundaries, its exits and the objects in the room. Then, all movements within
> the scene are processed locally and transmitted over the net as a series of
> pose commands. i.e. :move x,y,z
> The other clients will receive: Fardwark move x,y,z    and they will update
> their screens as necessary. The clients will know which object to move because
> the name in prepended my the MUD software ("Fardwark") and they will know
> that it's a change in position because of the "move" command and they will
> know where because of the "x,y,z" component.
Yes, this is how I am doing it. I am not using the pose command right now
because I want to coexist with text-only mudders as well.
What you would do is use 'kemit' to send text only to graphical clients so:
kemit !Fardwark.base pos (new positioning)
Since all the parts of your body are attached to other parts, moving the
'invisible' base part will make all the other part's positions be recalculated
as well and your whole body will move at once. (Actually, the client will be
doing the 'kemit'ing.)

Also:
I want to know people's opinions on spoofing. Spoofing is very easy to
accomplish. Should we go to the trouble of having keys and such (not
impossible) or just go with the simplicity of openness?

-- 
evilted@vesta.unm.edu

From spm@atmos.dar.csiro.au  Tue Jun  9 22:01:12 1992
Received: from shark.mel.dit.CSIRO.AU by sunee.waterloo.edu with SMTP
	id <AA03229>; Tue, 9 Jun 92 22:01:12 -0400
Received: from atmos.dar.csiro.au by shark.mel.dit.csiro.au with SMTP id AA14060
  (5.65c/IDA-1.4.4/DIT-1.3 for <@shark.mel.dit.CSIRO.AU:netgame@sunee.uwaterloo.ca>); Wed, 10 Jun 1992 12:01:05 +1000
Received: by atmos.dar.csiro.au (5.65+bind 1.5+ida/910805.SGI/DAR)
	for @shark.mel.dit.CSIRO.AU:netgame@sunee.uwaterloo.ca id AA18593; Wed, 10 Jun 92 12:01:01 +1000
Date: Wed, 10 Jun 92 12:01:01 +1000
From: spm@atmos.dar.csiro.au (McEWAN Shane)
Message-Id: <9206100201.AA18593@atmos.dar.csiro.au>
To: Brennan Underwood <evilted@vesta.unm.edu>, netgame@sunee
Subject: Re: Moving around a MUD.

Spoofing can, and I believe will, be a problem. It doesn't do much damage
on normal MUDs....apart from a bit of confusion. But on a client based MUD 
where commands actually change your attributes, spoofing would be a major
security problem.

How would the keys be impemented? There would have to be some way of knowing,
on the client level, whether a command is valid or a spoof.
================================================================================
Shane McEwan
CSIRO Division of        
Atmospheric Research   "Money talks. The secret is to hold onto it long enough"
Aspendale, Victoria                  to hear what it says."
Australia  3195                               - W.G.P.
+61 3 586 7503          
spm@dar.csiro.au
================================================================================


From evilted@vesta.unm.edu  Tue Jun  9 22:11:12 1992
Received: from vesta.unm.edu by sunee.waterloo.edu with SMTP
	id <AA03354>; Tue, 9 Jun 92 22:11:12 -0400
Received: by vesta.unm.edu (5.57/0.1)
	id <AA03552>; Tue, 9 Jun 92 20:11:06 -0600
From: Brennan Underwood <evilted@vesta.unm.edu>
Message-Id: <9206100211.AA03552@vesta.unm.edu>
Subject: how to break spoofing
To: netgame@sunee
Date: Tue, 9 Jun 92 20:11:05 MDT
In-Reply-To: <9206100201.AA18593@atmos.dar.csiro.au>; from "McEWAN Shane" at Jun 10, 92 12:01 pm
X-Mailer: ELM [version 2.3 PL8]

The way to prevent spoofing in my mind is thus:
1. Set a certain attribute as Hidden (so only wizards can read it)
2. Fill this attribute with your personal, changeable key.
3. Have every 'kemit' be prepended with the kemitter's name and your
key (since the master object is/will be set WIZARD)
4. Your client can decide whether to believe it or not.

This is how I have spoof-prevented moving around. Since MOVE is now
hidden, no-one but WIZARDs can echo it at you. It would complexify
things muchly, but might be worth it.

Also: cyberportals. I think anyone who is planning on making their system
distributable should make their system cyberportal-compatible.
Anyone agree/disagree?
-- 
evilted@vesta.unm.edu

From hlab@u.washington.edu  Thu Jun 11 04:07:07 1992
Received: from milton.u.washington.edu by sunee with SMTP
	id <AA29589>; Thu, 11 Jun 92 04:07:07 -0400
Received: by milton.u.washington.edu
	(5.65/UW-NDC Revision: 2.22 ) id AA11474; Thu, 11 Jun 92 01:07:03 -0700
Date: Thu, 11 Jun 92 01:07:03 -0700
From: Human Int. Technology Lab <hlab@u.washington.edu>
Message-Id: <9206110807.AA11474@milton.u.washington.edu>
Sender: hlab@milton.u.washington.edu
To: netgame@sunee
Subject: Keep Netgame in Netgame.


Bernie,

The mailer is spilling out into sci.virtual-worlds.  Can you
halt the steady flow?

Bob Jacobson
Moderator
s.v-w

From broehl  Fri Jun 12 10:41:37 1992
Received: by sunee
	id <AA14756>; Fri, 12 Jun 92 10:41:37 -0400
From: Bernie Roehl <broehl>
Message-Id: <9206121441.AA14756@sunee>
Subject: The archive
To: netgame@sunee
Date: Fri, 12 Jun 92 10:41:36 EDT
X-Mailer: ELM [version 2.3 PL11]

The archive of proposals related to shared virtual environments is now
cleaned up.  It can be found on sunee.uwaterloo.ca in the pub/netgame
directory.

-- 
	Bernie Roehl, University of Waterloo Electrical Engineering Dept
	Mail: broehl@sunee.waterloo.edu OR broehl@sunee.UWaterloo.ca
	BangPath: uunet!watmath!sunee!broehl
	Voice:  (519) 885-1211 x 2607 [work]

