HDTenEightyP/NetNews huggingface dataset:
From: bds@edvac.cs.oberlin.edu (Ben Salter)
Subject: LRMUD
Organization: Oberlin College Computer Science
Distribution: rec.games.mud.lp
Date: Fri, 28 Aug 1992 01:59:58 GMT
X-Posted-From: edvac.cs.oberlin.edu
X-Posted-Through: sol.ctr.columbia.edu

Hello out there!  This post is for those following, or were following
LRMUD's production.  We got no site offerings (big surprise) from my
last post to USENET about LR, so we decided to build it on TMI.  We
are still, however, looking for a permanent site.  If you've got a
possibility, or are just interested in what the heck LRMUD is, please
don't hesitate to mail me (bds@occs.cs.oberlin.edu) about it, or just
stop by TMI and look in the /d/lr directory.

And to avoid flames from those who would do so about technicalities,
LRMUD IS an LPmud, or is built up from one.

The current LRMUD team is: me (Forlock), Descartes, Whitehawk, Hanse,
BTB, Fokker, Flamme, Grotto, and Mobydick.

(the team is getting big.  If I left out your name, PLEASE forgive me!
:) )

Ben "We don't need no stinking .sig" Salter

P.S. Buddha might be helping out LR a bit, as well.
From: chena@crs.cl.msu.edu (Antony Chen)
Newsgroups: rec.games.mud.lp
Subject: Re: * PEACE PLEASE! *
Date: 30 Aug 92 22:02:04 GMT
Organization: Michigan State University

mmcg@cs.monash.edu.au (Mike  Mc Gaughey) writes:

>A simple existence proof for Shattered World:

>1) TMI claims CD is not the best mud around, because TMI has done some
>   things better.  This is clearly correct, as TMI has some rather
>   talented people, a few of whom actually know what they are talking
>   about.

>2) CD claims TMI is not the best mud around, because CD has done some
>   things better.  This is clearly correct, as CD has some rather talented
>   people, a few of whom actually know what they are talking about.

>3) There are other drivers around, and most of them are available by
>   FTP.  But the people at CD and TMI will have examined these muds, and
>   incorporated their good ideas into their respective drivers.
>   Therefore, there can be no publically available drivers better than
>   CD's or TMI's.

>4) Since programming a mud is an intensely personal thing, anyone
>   maintining an extremely good driver will occasionally post about it.

>By lemmas 1 and 2, we know that neither CD's nor TMI's driver is the
>best.  By lemma 3, we know that there are no ftp'able drivers which
>surpass either one (so DR, etc, are out).  Therefore, there must exist
>at least one mud which is better than either of them, and, by lemma 3,
>better than all publically available drivers (since it is better than
>CD and TMI, and they are better than other drivers).

>But by lemma 4, we know that the authors of any really good driver will
>post about it.  The only people posting about the wonders of their non-
>distributed driver are Geoff and me.

>Therefore, Shattered's game driver exists and is the best one (un)available.

[ramblings deleted]

What the fuck is that?  If you want to take itt that far, let's delve deeper
into this hypothetical shit you're spewing...

1) The universe is infinite.
2) Muds exist.

OK, given axiom 1 and 2, it is true that muds do exist in other places and
dimensions besides what we know.  Therefore, since the universe is infinite,
there is no best driver, since there will always be a driver out there in
infinity that is better.  Ha!

BTW, your logic doesn't make any sense.  It sounds kinda like one of those
lame-o proofs I did in high school Geometry.  Hope your code doesn't read
like that...hehe

Melvin@TMI

****************************************************************************
MMMMM      MMMMM  Antony Chen aka MELVIN @ University of Michigan, Ann Arbor
 MMMM      MMMM   GO BLUE!!  THE FAB 5 RULES: Mama said knock you out! 
 MMM MM  MM MMM   Mud-related mail: tonychen@engin.umich.edu
 MMM  MMMM  MMM      Personal mail: Antony.Chen@um.cc.umich.edu
 MMM   MM   MMM          Misc mail: tchen@churchst.ccs.itd.umich.edu
MMMMM      MMMMM  ***********************************************************
Newsgroups: rec.games.mud.lp
From: geoff@cs.monash.edu.au (Geoff Wong)
Subject: Re: MudOS a ripoff?
Organization: Computer Science, Monash University, Australia
Date: Thu, 27 Aug 1992 02:30:44 GMT

jlw@HEBREW.CC.COLUMBIA.EDU (James Waldrop) writes:

>Several changes to the object struct, and a few to the sval struct

Wow! - Hours of hard work and a complete re-writing; obviously.

>A completely rewritten eval_instruction (it uses pointers to functions
>  instead of the large switch())

Yawn - I did that 18 months ago. It's irrelevant anyway - a good
compiler (gcc 2.0+) will do the job automatically anyway. Simply makes
the code easier to work on.

>Our own version of mappings, mainly snagged from Perl
>Wrappers around malloc(), realloc(), and free() which allow keeping
>  track of memory (for a small overhead)

Hot stuff! Catching up with the Joneses.

>A change in the way objects compile to allow 'true' virtual objects
>A file is read in to set certain parameters that used to be #defined
>Several more calls to master.c at various points
>Many many changes to efuns...

Changing/adding efuns does not change the basic structure of the
driver. The only real reason to add efuns is for added speed
in critical regions or to cope with such wide spread usage that a library
function is inappropriate.

>When the name changed to MudOS, I was of the opinion that it was a
>bit premature.  As things stand now, though, I think it is undoubtedly
>a wholly different driver. 

I doubt it - still uses the same string hashing, same backend, 
same chained hash tables for objects etc.
Simply your arrogance in thinking you've produced a new
product has caused you to change it's name. I doubt whether
your changes are particularily significant. Certainly not
a "new" mud started from scratch - hence it doesn't really deserve
a name change.

geoff
--
Ho Hum.
The vorpal blade went snicker-snack.

Newsgroups: rec.games.mud.lp
From: ins894r@aurora.cc.monash.edu.au (Aaron Wigley [Wigs])
Subject: Re: * PEACE PLEASE! *
Organization: Monash University
X-Newsreader: Tin 1.1 PL5
Date: Mon, 31 Aug 1992 07:38:09 GMT

Adam Beeman (beeman@cats.ucsc.edu) wrote:
: >>: Hey, can you tell me if they *really* exist anymore?
: 
: >>I can. We exist. Here's our player motd:
: >[...]
: 
: This doesn't prove ANYTHING!
: Anyone can write an motd and post it to news.   You haven't proven a damn
: thing.  Sorry, bud, I refuse to accept this "evidence"...

Who says I was posting it as evidence? Did I label my diagrams/figures?
Do I document my code? Do I exist?
*bwhahaha*

: >I should point out that like all the other postings
: >originating from here, Wiggs is a figment of our
: >collective hallucination...
: 
: Just like your mud.

Does our MUD exist? Stay tuned folks, for the next exciting napalm drop,
same time, same MUD channel. :-)

: >Mike.
: 
: Adam, unfortunately also Buddha@TMI

ps. At this rate, I don't think I'll need to worry about heating bills,
for the next year, all this flamage does wonders recycled.

The Wigs of Oz, Just another figment of your collective hallucinations.
Hunter@SomeMudSomeWhere

Newsgroups: rec.games.mud.lp
From: djohnson@cs.ucsd.edu (Darin Johnson)
Newsgroups: rec.games.mud.lp
Subject: Re: SW Quests?
Date: 31 Aug 92 03:28:32 GMT
Organization: =CSE Dept., U.C. San Diego

>But then again he should also get the "Even Stupider than Stupidest Award"
>for posting the solutions to quests which do not exist on SW.

Ah, then I should go try implementing the "stay alive for 2 hours"
quest...  Wonder if I'll survive two hours against frustrated players?
-- 
Darin Johnson
djohnson@ucsd.edu
    "Are you a doctor?"   "No, but I watched."
Newsgroups: rec.games.mud.lp
From: kjetilho@ifi.uio.no (Kjetil Torgrim Homme)
Subject: Accessing attributes (was: Re: Virtual Rooms and Objects)
Organization: Dept. of Informatics, University of Oslo, Norway
	<1992Sep3.112652.6641@uniwa.uwa.edu.au>
	<185q2tINN59v@darkstar.UCSC.EDU>
Date: Fri, 4 Sep 1992 01:30:48 GMT
Originator: kjetilho@holmenkollen.ifi.uio.no

In article <185q2tINN59v@darkstar.UCSC.EDU> beeman@cats.ucsc.edu (Adam Beeman) writes:
   however, compare:
   set_foo(value) with set("foo", value).  If you know what set() does, you will
   know that all this is doing is setting a variable named "foo" to a given 
   value.  You don't have to check and see what set_foo() does in addition to
   this.

Pros:
  - the objects look more clean without all those set_* and query_*
  - you can have more functions for each variable: add(), remove(), in() to maintain
    a set.
  - you can make a tree structure of the variables, ie. set("property>>visibility", 50)

Cons:
  - you can get lots of stray variables (from typoes or misuse)
  - in a trivial implementation, security is non-existant
  - if you want to redefine the interface, you'll have big problems
  - problems with variable name clash

The first three cons can be rectified by having a master object
validating the access to the variables.

Some code from my toy mudlib to show what I have in mind (a little
edited):


std/include/validate.h:
=======================
/* Normal objects would call validate_{set,query}(O_OBJECT, varname)
 */
#define O_OBJECT 0	/* All kinds of objects */

/* The player object must overload the functions because its variables must be
 * handed with care, and calls validate_{set,query}(O_PLAYER, varname) instead.
 */
#define O_PLAYER 1	

std/util/validate.c
===================

#include <validate.h>

/* The mappings should contain an entry for every legal attribute name
 */
mapping *ok_set, *ok_query;

create() {
    ok_set = allocate(2);
    ok_set[O_PLAYER] = ([ "level" : "ml_access",
		           "name" : 1,
	                   "id"   : 1 ]);
    ok_set[O_OBJECT] = ([ "level" : 1,
			  "name"  : 1,
			  "id"	  : 1 ]);
}
		
validate_set(int type, string var) {
    string func;

    if (!(func = ok_set[type][var])) {
	write_file("/log/admin/bogus_set", file_name(previous_object()+": '"+var+"'\n");
	return 0;
    }
    return stringp(func) ?  call_other(this_object(), func) : 1;
}

/* similar code for validate_query(), but allow the function to return
 * a real value, so that e.g. query("ac") may change without breaking 
 * compatibility.
 */



I don't think name clash will be a great problem. It is after all the
coder of the mudlib's responsibility to ensure good and fitting
variable names, and to keep them unique shouldn't be a problem. If the
concern is that wizards may use variable names that the mudlib may
annect later, well, then this system is none different in that respect
from the traditional set_* and query_* method.


Kjetil T. (aka Tenghil)

PS. I first saw the idea about using one mapping instead of lots of
variables on TMI. Great concept, Buddha :)
--
	``so you can make me cum that doesn't make you Jesus'' - Tori Amos
Newsgroups: rec.games.mud.lp
From: craig@ec.uwa.oz.au (Craig Richmond - division)
Subject: Re: * PEACE PLEASE! *
Organization: University of Western Australia
Date: Mon, 31 Aug 1992 09:58:20 GMT

michael@iastate.edu (Michael M. Huang) writes:

>Come on guys.  I do believe most of us can spend the time flaming here in
>something more productive (sheeesh, even playing in muds is more productive
>than all these flames).  First few hundred flames are okay.  But, when you 
>get into millions.... Well, time to stop, people.

I reserve the right to make "silly", "inane", "deragatory", "pointless",
"worthless" and even the occasional "useful" reply to any article I see
posted.  Besides, some people (including me) say the dumbest things and
deserve everything they get!

>But, then again, whoever listens to anyone on the net anyway. ;)

I listen.  I then tend to ignore and do my own thing anyway :-)

Craig
--
Craig Richmond.  Computer Officer -  Dept of Economics (morning) 380 3860
  University of Western Australia    Dept of Education (afternoon)
craig@ecel.uwa.edu.au                              Dvorak Keyboards RULE!
     "Only users are allowed to make messes on their computers"  I.M.VI
From: u912148@daimi.aau.dk (Thomas Skou Hansen)
Newsgroups: rec.games.mud.lp
Subject: Try Grimne MUD, NOW!
Date: 26 Aug 92 14:20:15 GMT
Organization: DAIMI: Computer Science Department, Aarhus University, Denmark

Here I bring the internet address for Grimne MUD, it isn't a LP MUD but a
DIKU I MUD, but it's great anyway.

Grimne MUD:  129.241.36.200 4000

See ya on Grimne (I hope).

- Thomas S. Hansen

My E-mail address is: mono@daimi.aau.dk
From: trsnyder@mcs.Drexel.edu (Bob Snyder)
Newsgroups: rec.games.mud.lp
Subject: Re: Driver additions
Date: 2 Sep 92 16:21:07 GMT
	<TRSNYDER.92Sep1121937@queen.mcs.Drexel.edu> <37544@sdcc12.ucsd.edu>
Organization: GE Aerospace, Advanced Technology Labs, Moorestown, NJ

>>>>> On 1 Sep 92 18:45:10 GMT, djohnson@cs.ucsd.edu (Darin Johnson) said:


>I'm not saying if this is good or bad, but this is what I see as the main
>advantage.

Darin> Naw...  The main advantage is that you don't have to fix all the bugs
Darin> and add all the new features yourself (while not dumping your old
Darin> mudlib).

But any god worth anything immediately starts hacking on the mudlib anyways,
all the bugs in 2.4.5 are well-known to everyone except the newbie god.  The
point about not losing the existing mudlib is valid, but not for a mud that
is just opening.

Fordan, god, Dragon's Den LPmud (129.25.7.111 2222)
Newsgroups: rec.games.mud.lp
From: oakley@contra.enet.dec.com (The Zeeker)
Subject: Re: Driver additions
Organisation: Treadstone Seventy-One
Organization: Digital Equipment Corporation, Maynard, MA.
Date: Thu, 27 Aug 1992 12:22:19 GMT


In article <1992Aug27.072103.23330@uniwa.uwa.edu.au>, guddt@uniwa.uwa.edu.au (David Bennett) writes...
>oakley@contra.enet.dec.com (The Zeeker) writes:
>>In article <17h567INNs0r@darkstar.UCSC.EDU>, beeman@cats.ucsc.edu (Adam Beeman) writes...
>>>closely for comparison... nor have I seen anything of BatMUD's.  But
>>>there is no standardization committee, there is no real agreement.
> 
>>	Seems to me that it would be a good idea to START a standardization
>>	committee.  From what I see, everything's pretty chaotic right now.
> 
>Can you seriosly see Amylaar and the CD people to agree on something?
>Or for that matter TMI agreeing with the rest of the world.  Everyone
>has their own idea's however strong.  This language is not like C where
>a committe creates a standard for it because everyone uses it.  Even
>then....  How many #define's for different machines do you see in any
>given bit of "portable" C code?  Whats so standard about C anyway...

	Dosen't anyone want to at least TRY?  At least have a committee
	to set up standard releases of game drivers, mudlibs, etc. 
	I'm sure that if a committee was set up, many good ideas could
	be incorporated into a single LP driver/mudlib without making it
	too chaotic.  Nice tools could be made and distributed, etc.

-----------------------------------------------------------------
Brought to you by Treadstone Seventy-One Corporation.
--- --- --- | /  "Come not between the dragon and his wroth!"
 /  |-  |-  |    		- Lear, King of England
--- --- --- | \
_________________________________________________________________
Newsgroups: rec.games.mud.lp
Subject: What is shadowing?
From: russells@ccu1.aukuni.ac.nz (Russell Street)
Date: Tue, 1 Sep 1992 02:38:26 GMT
Organization: University of Auckland, New Zealand.

What does the "shadow" external function do in LPC?
How does/would one use it? And what is it good for?

Trying things like:
	shadow(object, 1);
gets you messages like:
	"The shadow must not reside inside another object"

Thanks for any help....
--------------------------------------------------------------
Russell Street (russells@ccu1.aukuni.ac.nz)

Secombe:  Right Mr Greenslade, segergate the sinful sexes ...
Milligan: Wait -- how many sexes are there?
Secombe:  Two.
Milligan: It is not enough, I say! Go out and order some more!


Newsgroups: rec.games.mud.lp
From: mmcg@cs.monash.edu.au (Mike  Mc Gaughey)
Subject: Re: saving object pointers
Organization: Computer Science, Monash University, Australia
Date: Fri, 28 Aug 1992 21:48:34 GMT

jlw@HEBREW.CC.COLUMBIA.EDU (James Waldrop) writes:

>than indulging in immature name-calling.  I am assuming, of course, that
>you CAN answer the question, because you will have thought through this
>problem, since you've been doing it for 15 months.  If instead you have
>side-stepped it by throwing away your object pointers, or just cloning a
>new object with a new set of variables, then that would be a useful thing
>to know too, although at that point we'll all be wondering just who is
>full of shit and who isn't.

If you had bothered to read the original post, you would see that I said
that this is _precisely_ what I do.

This is the reason I never had time for you - you never bothered to
understand things which were explained to you before spouting off your
opinions on them.  As I found out on Swat, there is simply no point in
talking to you - you don't listen, and even when you do, you don't
think about what you hear.  Therefore, you never say anything
interesting about it.

In the same vein: you were willing to badger me for a tutorial on how
game drivers work, but you weren't willing to go and read the code
yourself.

When I talk to most other people - from TMI or elsewhere - they are
proud of their work, the innovations they have made - and rightly so.
But they are also aware of how easy or difficult or significant or
trivial each of the changes are.  They are, in short, aware of what is
especially significant and interesting, and what is a small, neat hack,
and they treat things that way - to do otherwise is to insult your
audience's intelligence.  You, on the other hand, are extremely vocal
yet embarrassingly ignorant about such matters.  Essentially, a waste
of time.

Mike.
--
Mike McGaughey			AARNET:	mmcg@bruce.cs.monash.edu.au

"Head stompin', ass kickin', finger licking nastiness"
From: jlw@HEBREW.CC.COLUMBIA.EDU (James Waldrop)
Newsgroups: rec.games.mud.lp
Subject: Re: Rewriting MudOS??
Date: 27 Aug 92 00:20:27 GMT

kjetilho@ifi.uio.no (Kjetil Torgrim Homme) writes:
>djohnson@cs.ucsd.edu (Darin Johnson) writes:
>   I believe in putting in bug fixes - but the SHOULD BE GOING INTO
>   3.1.3!!  Someone really should be working on this *sigh*.
>
>I agree totally! So far, it seems like the MudOS team is the most
>willing to add other people's patches into their own. Unfortunately,
>they may be a little to ambitious, and rewrite too much too fast.

Heh, too ambitious?  I'm not sure what you mean by things getting
rewritten too quickly.  Yes, the version has been incrementing at
a rapid rate lately, while what (will be/is) 0.9.0 is worked on.  This
is mainly because of minor bugfixes, though.  The idea is to make
0.9.0 as clean and stable as possible (no memory leaks, no spurious
crashes, and no "major new things" just waiting to be added).

>Agreed! A Sun-3/50 has more than enough CPU to run a mud with 20-30
>players. Just make sure you have a local disc. And don't try to run
>TMI or CDlib :)

Yeah, yeah, you can run one of those ugly 2.4.5 things just fine.  :)

Sulam, who is wondering why you'd want to.

ps.  I know for a fact that a TMI mudlib can run just fine on a
sun 3/50, as it was done local to me for about 3 months.  And this
was over NFS, too (yes, ls was a bit slow, but the standard things
worked just fine).
Newsgroups: rec.games.mud.lp
From: M. Nutter <manutter@grove.iup.edu>
Subject: What happened to Overdrive?
Organization: iup
X-Xxdate: Fri, 28 Aug 92 12:21:47 GMT
X-Useragent: Nuntius v1.1.1d7
Date: Fri, 28 Aug 1992 11:19:30 GMT
X-Posted-From: mozart.cc.iup.edu
X-Posted-Through: sol.ctr.columbia.edu

Anybody know what happened to Overdrive?  I haven't been able to
connect for over a day now, and I'm starting to get the dt's. :)
From: demon@sequent.com (Dave Richards)
Newsgroups: rec.games.mud.lp
Subject: Re: MudOS a ripoff?
Date: 27 Aug 92 23:04:47 GMT
Article-I.D.: sequent.1992Aug27.230447.15809
Organization: Sequent Computer Systems Inc.


It's too bad it's not Winter here.  This would make a great Wintertime
discussion.  :-)

	Dave
Newsgroups: rec.games.mud.lp
Subject: Re: Virtual Rooms and Objects (was: Re: MudOS a ripoff?)
From: siannce@polyslo.csc.calpoly.edu (Huthar)
Date: Wed, 02 Sep 92 02:06:27 GMT
Organization: Huthar@Portals|Overdrive|TMI|Genocide

>     I'm not saying anything is wrong with it, but stuff like this can move
>from being single ".c" files to a database (*ack*).  This can cause more
>problems when a newbie wizard starts coding and says ooh this is easy.  In
>the long run, more and more Power LPC programers will dissappear and slowly,
>LPC may take a back door on mudding instead of advancing into the future with
>all types of MU*(and beyond...).
>
>Erik (Gunther God@Dragon's Den -- 129.25.7.111 2222)

Hmm. This appears to be the fallacy of 'slippery slope' they told us of in
critical thinking. :) Nah, I doubt that would happen. The players would be 
bored in places where there were just simple 'cookie cutter' rooms, and would
go to the more interesting places. And since from my experience most wizards
are very power hungry they want the players to like their realms so they can
get their precious promotions. Thus there will always be somebody trying to
out do the other guy so that they stand out. Ah the beauties of capitalism. :)
    -Stephan (Huthar@portals|TMI|Genocide|OD)

-- 
-------------------------------------------------------------------------------
-Stephan Iannce (siannce@polyslo.CalPoly.EDU)	          // YAAJ (Yet Another
Huthar@Portals|TMI|Overdrive (LPmuds)            	\X/      Amiga Junkie)
-------------------------------------------------------------------------------
From: mly@sei.cmu.edu (Michael Yacht)
Newsgroups: rec.games.mud.lp
Subject: Overdrive
Date: 3 Sep 92 18:46:26 GMT
Article-I.D.: sei.1992Sep3.184626.22142
Organization: Software Engineering Institute

I have been trying to get to Overdrive for quite some time...any clues as to
why I cannot connect?




-Mike Yacht
-Carnegie Mellon University -- School of Computer Science
====================================================================
Mike Yacht             || specter+@CMU.EDU