HDTenEightyP/NetNews huggingface dataset:
From: djohnson@cs.ucsd.edu (Darin Johnson)
Newsgroups: rec.games.mud.lp
Subject: Re: **** TOP 10 LPMUDs ****
Date: 25 Aug 92 23:00:48 GMT
Organization: =CSE Dept., U.C. San Diego

>>Am I missing something?

Yep, I *was* missing something.  I suspected the missing 12% to be
due to errors.  I hadn't realized the heart_beat loop was interrupted
if it took too long...
-- 
Darin Johnson
djohnson@ucsd.edu
  - I'm not a well adjusted person, but I play one on the net.
From: mario@netcom.com (Mario)
Newsgroups: rec.games.mud.lp
Subject: Valhalla needs a home.
Date: 31 Aug 92 23:47:33 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

If you've got a good mud-able site.  Mail me or Flet at tlim@cats.ucsc.edu.

	     -= Branden Spikes (mario@netcom.netcom.com) =-
    -= God of Rogue (Player Slayer Mud) (boobytrap.spies.com 2222) =-
Newsgroups: rec.games.mud.lp
From: mmcg@cs.monash.edu.au (Mike  Mc Gaughey)
Subject: Re: Sarcasm and Ember
Organization: Computer Science, Monash University, Australia
Date: Fri, 28 Aug 1992 22:53:56 GMT

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

>You're implying that this isn't happening.  Have you ever talked to me
>about the MudOS driver, or TMI in general?

Well, *I* have.  You knew fuck all about it, since Buddha did
most of the interesting bits (you hadn't even *read* it!
Jesus, and you want people to *listen* to you?).

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

"Head stompin', ass kickin', finger licking nastiness"
Newsgroups: rec.games.mud.lp
From: craig@ec.uwa.oz.au (Craig Richmond - division)
Subject: Re: Driver additions
Organization: University of Western Australia
Date: Thu, 27 Aug 1992 10:05:57 GMT

pariah@tartarus.uwa.edu.au (Michael Malone) writes:


>    short = "A room";
>    long = "line1"
>           "line2"
>           "line3";
>    items = ({ ({ ({ "clock", "time" }), ({ "broken", "wall" }) }) });

Spot the bad software engineering.  Making implicit assumptions of data
structures not defined in your module.  Whose a naughty Boy then? :-)

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: jlw@gestalt.austin.tx.us (James Waldrop)
Newsgroups: rec.games.mud.lp
Subject: Re: saving object pointers
Date: 30 Aug 92 23:28:06 GMT
Organization: Los Alamos National Laboratory, NM

mmcg@cs.monash.edu.au (Mike  Mc Gaughey) writes:
>jlw@HEBREW.CC.COLUMBIA.EDU (James Waldrop) writes:
>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.

More specifically, I badgered you about how YOUR game driver worked,
since it seemed interesting, and the code wasn't available for
perusing.  I believe there were two points when our discussions
strayed into topics that are general to all LP drivers, but I
was mainly interested in yours.  Exactly how was I supposed to go
read the code?  In fact, we had this same discussion concerning
saving object variables, and you said you had done that, but consistently
refused to tell me how.

>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.

I think a simple hack that produces useful results is far more worth
getting vocal about then a difficult one that gives mixed results
at best.  The amount of labor that goes into something does not directly
correlate to the affect it has on those who use it.  I will get quite
vocal about something as simple as putting the wrappers around malloc(),
or changing the switch() in eval_instruction to a list of pointers.  The
reason for this is that I've tried to compile with smalloc on a NeXT,
and I know people who have been unable to compile the driver under Vax
Unix because of the extreme length of eval_instruction.  On the other
hand, I see things like Amylaar's alists efuns, and I can't get too
terribly excited.  They are confusing, and as such, not terribly useful.
Yet I'm sure that he put quite a lot of time into them, and I respect
him for that effort, but it doesn't go much further.  Likewise, I
respect Shattered Worlds for the things you seem to have done, but it
doesn't really affect anything, so I can't get terribly excited about
it.  Excuse me for my humanistic approach.  ;)

Sulam
-- 
James Waldrop
jlw@hebrew.cc.columbia.edu

I walk along the path muttering about signs and portents.
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: Fri, 28 Aug 1992 02:21:02 GMT


In article <37334@sdcc12.ucsd.edu>, djohnson@cs.ucsd.edu (Darin Johnson) writes...
>I'd try.  Get much more done with all the forces pointing in the same
>direction.  Be nice to get Lars consent to start upping the numbering.
>Maybe CD computer clubs consent, but they seem to have their own
>plans.

	I'll try too.  Anyone else interested?  We might just have
	an ANSI-LPC committee brewing here. ;-) ;-) ;-)

-----------------------------------------------------------------
Brought to you by Treadstone Seventy-One Corporation.
--- --- --- | /  "Come not between the dragon and his wroth!"
 /  |-  |-  |    		- Lear, King of England
--- --- --- | \
_________________________________________________________________
From: beeman@cats.ucsc.edu (Adam Beeman)
Newsgroups: rec.games.mud.lp
Subject: Re: Driver additions
Keywords: compat-mode, MudOS, CD, standardization, etc.
Date: 3 Sep 92 07:23:39 GMT
Organization: University of California; Santa Cruz
NNTP-Posting-Host: am.ucsc.edu


In article <1992Sep2.231508.21397@uniwa.uwa.edu.au> guddt@uniwa.uwa.edu.au (David Bennett) writes:
>
>Parse_command is stable too.  It has a couple of bugs...  But it works.
>
>I should know :)  If you want the parse_command bug fixes mail me...  I
>assume the CD one also has these fixes.  Well I told em the problems so
>they should have fixed it.

I think they totally rewrote it again (in the CD driver). ;-)

>
>David.
>[DDT] Pink fish forever.

-Adam
Buddha for a little while.

-- 
#include <std/disclaimer.h>
#define NAME	"Adam Beeman"
#define EMAIL	"beeman@{cats, ucscb}.ucsc.edu"
inherit SIGNATURE; // enhanced .sig virus
Newsgroups: rec.games.mud.lp
From: mmcg@cs.monash.edu.au (Mike  Mc Gaughey)
Subject: Re: security holes in 2.4.5
Organization: Computer Science, Monash University, Australia
Date: Thu, 27 Aug 1992 06:33:54 GMT

beeman@cats.ucsc.edu (Adam Beeman) writes:

>>>In case no one decides to tell you, there are quite a few non-obvious
>>>security holes in 2.4.5.  I'm sure you'll find them soon, though.

>--- cut here --- 

>/*
> * use_init.c
> * while the author of this file intends no actual harm, please
> * take note of what is possible here.
> * The only effective prevention of this is suppressing awareness of this
> * or conversion to "native mode".

Native mode my arse.  Write a decent security system - none of this
unix-based shit (if there's anything that you _don't_ wanna copy from
unix, it's the uid/euid system.  Not, at any rate, in a system using
security _all the time_).

From Shattered (a modified 2.3):

> goto l
Who is an admin?  :You feel nervous.
gandalf
rm(): No write permission.
In players/gandalf/l (gandalf:20); (top level) "init" line 35

Yeah, Gandalf is a god.  But the object, even though it's suid gandalf (because
it comes from his directory), is only level 20, and so can't rm things.

Been this way for a couple of years, AND posted the details to the net
18 months ago.  Pity only about 5 sites used it.  The most secure and
unobtrusive system I've seen.

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

"Head stompin', ass kickin', finger licking nastiness"
From: beeman@cats.ucsc.edu (Adam Beeman)
Newsgroups: rec.games.mud.lp
Subject: Re: Driver additions
Date: 27 Aug 1992 09:08:43 GMT
Organization: University of California; Santa Cruz
NNTP-Posting-Host: am.ucsc.edu


In article <1992Aug27.032921.4270@fy.chalmers.se> jacob@fy.chalmers.se (Jacob Hallen) writes:
>
 [ stuff deleted ]
>

Yeah. What he said.
We have a lot of work to do, and it would be wonderful if we can work together
more on this.  I don't think that just one gamedriver can meet everyone's 
needs unless we *plaster* it with compile-time options.   But we can certainly
share more of our feelings and avoid unproductive flamage.

A further little note about TMI and MudOS:
I never claimed TMI's mudlib was the best, since I helped write a large
part of it, and I know I'm not the best coder out there.  But, at least
I think at this point the TMI people and the CD people seem to be
communicating a bit more than the SW people are, at least as far as
friendly, useful correspondence...  Never have I seen anyone so snide and
arrogant and Geoff and Mike... my respect for them is seriously diminished...

I'd be interested in seeing some cooperation.  
It does look like a rewrite could be useful, in all honesty... in C++,
if it's portable enough... that seems to be the big problem.  If LPmud
were written in C++ then I suspect there would be less than half as many
as there are now.

>
>Jacob Hallen


Adam Beeman


-- 
#include <std_disclaimer.h>
#define NAME	"Adam Beeman"
#define EMAIL	"beeman@{cats, ucscb}.ucsc.edu"
inherit SIGNATURE; // enhanced .sig virus
From: sword@buast7.bu.edu (Bill Mackiewicz)
Newsgroups: rec.games.mud.lp
Subject: Re: Anyway to find *all* instances of a clone object?
Date: 1 Sep 92 21:57:03 GMT
Organization: Astronomy Department, Boston University, Boston, MA, USA

In article <1992Sep1.043438.885@ccu1.aukuni.ac.nz> russells@ccu1.aukuni.ac.nz (Russell Street) writes:
>(Another LPC question)
>Is there *easy* anyway find all instances of a cloned object
>(say a monster)?

Depends on what you mean by "easy".  I'd suggest scanning
through all objects, and trying to use find_object() to locate 
it, incrementing the clone number by one.  You'll probably
get a Too long evaluation error, though, so you might want
to use call_out() to put the work in a few batches.


Bill Mackiewicz                                   \\ /
obsidian@gnu.ai.mit.edu                           - o_____
sword@buast7.bu.edu                              / /| |\\ \\
Mutara@World of Mizar                           |_//___\\\\_|
       LPCC                                      \\ \\   / / 
       Infinity                                   \\ | | // 
          .                                        \\\\ //
          .                                         \\|//
          .                                          \//
Newsgroups: rec.games.mud.lp
From: michael@iastate.edu (Michael M. Huang)
Subject: * PEACE PLEASE! *
Organization: Iowa State University, Ames IA
Date: Sat, 29 Aug 1992 01:40:08 GMT

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.

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

-michael

-- 
Michael Ming-Yang Huang                                michael@iastate.edu
PV Student Dev. Group &                                (michaelhg@ids.net)
Carver/Vis. Lab Assist         "A mind is such a terrible thing to waste."
Iowa State Univ, Ames, IA      I speak for myself an' not of my employers.
From: beeman@cats.ucsc.edu (Adam Beeman)
Newsgroups: rec.games.mud.lp
Subject: driver bugfixes (was: Re: **** TOP 10 LPMUDs ****)
Date: 28 Aug 92 22:09:41 GMT
Organization: University of California; Santa Cruz
NNTP-Posting-Host: am.ucsc.edu


In article <37392@sdcc12.ucsd.edu> djohnson@cs.ucsd.edu (Darin Johnson) writes:
>>Problems with the 3.1.2 driver...hmm..here's some I thought of off hand.


>>     * inherit chains
>
>Er, what are these?

file a.c:

inherit "/u/b/buddha/b";

file b.c:

inherit "/u/b/buddha/a";

Watch the mud go >down<.
Actually, rather than crash, it hangs, and starts gobbling up memory like
you wouldn't believe. 

>>     * recursion problems
>
>What problems?  There is a max function call depth.  If you think it's
>too low, raise it.

Apparently there's a few things that don't get caught all the time,
and so it *misses* this check for the maximum evaluations, and the game
hangs until someone comes along to kill the processes.

>
>>     * non-portability unless you're a GD god where you probably should write
>>       one on your own to suit your own needs
>
>And MudOS is more portable?  Sure, it's been ported to "major" machines.
>With LP, everytime something didn't compile right, Lars fixed it in the
>next release.

MudOS actually runs on more platforms.

>Darin Johnson
>djohnson@ucsd.edu
>    "I wonder what's taking Guybrush so long..."

Adam Beeman

-- 
#include <std_disclaimer.h>
#define NAME	"Adam Beeman"
#define EMAIL	"beeman@{cats, ucscb}.ucsc.edu"
inherit SIGNATURE; // enhanced .sig virus
From: jacob@fy.chalmers.se (Jacob Hallen)
Newsgroups: rec.games.mud.lp
Subject: Re: Driver additions
Date: 27 Aug 92 03:39:11 GMT
Organization: Chalmers University of Technology, Physics Departement, Gothenburg

In article <1992Aug26.005902.829@engage.pko.dec.com> oakley@contra.enet.dec.com (The Zeeker) writes:
>
>	As far as I can see, 2.4.5 IS a standard.  Nice, it works, not
>	very buggy.  I have yet to see a 3.0 Mudlib in vanilla state
>	that ACTUALLY WORKS !!  That was the great thing about 2.4.5
>	Mudlib, you could do whatever you wanted with it.  BUG-FREE!

Should I cry, laugh or try to sell you the Brooklyn bridge? I worked for
a long time with Genesis 2.4.6, which was never released (unfortunately), so
I know about all the bugs and loopholes we found in 2.4.5. In fact, the
main factor that promted us to throw away everything old when creating
the new Genesis was that we realised that we would never get on top of all the
bugs in 2.4.5. Evolution had taken it beyond the point where a revision
would make it stable again.

Jacob Hallen
Newsgroups: rec.games.mud.lp
From: vanderwerkend@lonexc.rl.af.mil (Dan Vanderwerken)
Subject: Re: dragonfire?
Organization: RL
Date: Fri, 21 Aug 92 11:52:48 GMT

In article <2A8857E3.9643@noiro.acs.uci.edu> kchang@orion.oac.uci.edu (K_Shibuya) writes:
>
>In article <1992Aug5.231112.57897@cc.usu.edu> sl8wm@cc.usu.edu writes:
>>Does anyone have any new information on the status of
>>the Dragonfire mud? I know why its down but any info
>>on when it will be up again?
>>
>>Thanks
>>bj
>>
>
>=>It should be back up mid August (hopefully)
>
>kchang@orion.oac.uci.edu
>
>KC

DF is _up_ until 1 Sep 92.  It's at 18.43.0.102 port 4444 if you're using
tingfugue.  Guest login is at 18.43.0.177.  

We're moving to pioneer.unm.edu after 1 Sep.  I don't know when it'll be
back up.  I believe the new site is 129.24.9.217 port 4444.

--Sifu on DF
-- 
Dan Van Der Werken          | 
Rome Laboratory/IRDO        | 
Griffiss AFB, NY 13440-5700 | 
(315) 330-3127              |
From: jlw@hebrew.cc.columbia.edu (James Waldrop)
Newsgroups: rec.games.mud.lp
Subject: Re: Subobjects
Date: 29 Aug 92 05:29:15 GMT

mmcg@cs.monash.edu.au (Mike  Mc Gaughey) writes:
>jlw@HEBREW.CC.COLUMBIA.EDU (James Waldrop) writes:
>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.

More specifically, I badgered you about how YOUR game driver worked,
since it seemed interesting, and the code wasn't available for
perusing.  I believe there were two points when our discussions
strayed into topics that are general to all LP drivers, but I
was mainly interested in yours.  Exactly how was I supposed to go
read the code?  In fact, we had this same discussion concerning
saving object variables, and you said you had done that, but consistently
refused to tell me how.

>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.

I think a simple hack that produces useful results is far more worth
getting vocal about then a difficult one that gives mixed results
at best.  The amount of labor that goes into something does not directly
correlate to the affect it has on those who use it.  I will get quite
vocal about something as simple as putting the wrappers around malloc(),
or changing the switch() in eval_instruction to a list of pointers.  The
reason for this is that I've tried to compile with smalloc on a NeXT,
and I know people who have been unable to compile the driver under Vax
Unix because of the extreme length of eval_instruction.  On the other
hand, I see things like Amylaar's alists efuns, and I can't get too
terribly excited.  They are confusing, and as such, not terribly useful.
Yet I'm sure that he put quite a lot of time into them, and I respect
him for that effort, but it doesn't go much further.  Likewise, I
respect Shattered Worlds for the things you seem to have done, but it
doesn't really affect anything, so I can't get terribly excited about
it.  Excuse me for my humanistic approach.  ;)

Sulam
Newsgroups: rec.games.mud.lp
From: michael@iastate.edu (Michael M. Huang)
Subject: Re: People, People..
Organization: Iowa State University, Ames IA
Date: Thu, 3 Sep 1992 04:50:37 GMT

In <18374fINNnqn@usenet.INS.CWRU.Edu> ak853@cleveland.Freenet.Edu (Eric Blade) writes:

[Stuff deleted]
>So if someone wants to doante a machine for the cause, I will happily
>volunteer to be the first membver of a driver and/or mudlib committee.
>ANd I will not even use tmy own mudlib that I have take nseveral hourts
>perhaps several days of my time to modify and create, etc, because most
>people would find the things I've done horribly stupid from a coding
>standpoint.

Risking another flame war... But, let me stop laughing first.  Are we
suppose to be impressed by your astronomical time that you've spent 
on your mudlib to take pity on you that you won't even include your
own creations?  Oh my!  Several hours?  Several days?  What am I thinking?
You've spent so much time on it!  And considering that other mudlibs only
cost people several months of work.  What are we thinking?

STOP STANDARDIZATION!  MUDDERS OF THE WORLD!  DIVERSE!

-michael

-- 
Michael Ming-Yang Huang                                michael@iastate.edu
Project Vincent Student Dev. &                         (michaelhg@ids.net)
Carver/Vis. Lab Assist         "A mind is such a terrible thing to waste."
Iowa State Univ, Ames, IA      I speak for myself an' not of my employers.
From: jlw@HEBREW.CC.COLUMBIA.EDU (James Waldrop)
Newsgroups: rec.games.mud.lp
Subject: Re: changing to 3.0 euid/uid's
Date: 27 Aug 92 00:09:55 GMT

Erik writes:
>demon@sequent.com (Dave Richards) said:
>Dave> be done with userids, (2) do they allow me to check for wizard-
>Dave> written players, (3) what is the granularity of checking, and (4) do you
>Dave> have an example of what objects would need to do to conform?  
>      All of the security is based off of the master.c file.  Simply because
> of seteuid().  You will also have to protect shadowing in a few ways(can't
> shadow query_level() among others).  As far as levels, we have changed to no

One other thing you have to worry about (unless you have MudOS), is
references to this_player().  Remember to stick in a this_player(1)
as well, to make sure they agree.

The reason you don't have to worry about this as much in MudOS is because
the object resposible for the call to master.c is passed to it.

Sulam

wheee, ucbvax makes you fill space...
From: genlpc@pip.shsu.edu ()
Subject: Re: Virtual Rooms and Objects (really: Saved sub-objects)
Organization: Sam Houston State University
Date: Fri, 28 Aug 1992 06:11:12 GMT
X-Posted-From: pip.shsu.edu
X-Posted-Through: sol.ctr.columbia.edu


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

> Another way of doing something similar is to use a slightly
> extended syntax for values in savefiles.  We (yes, that's us) can
> save subobjects in savefiles as well as ints, strings,
> and arrays - the syntax for an object value is (currently):
> 
> [ "objectfilename" 
>     ... standard savefile for object ...
> ]

[...full explanation omitted...]

> into.  Thus, players would get back all their items, and could
> even be restored back to the room they were in before the crash
> if we wanted to.
> 
> There are a couple of things to worry about here - only cloned
> subobjects should actually be copied into the player savefile,
> while the rest are stored simply with names; when restoring a
> savefile, there are problems when errors occur loading some of
> the subobjects, etc, and, of course, you need to worry about
> mutually recursive object references (our hack was to only allow
> one level of nesting, and expect the saver to produce a flattened
> contents list; it could be done properly by adding labels to
> savefile elements, but... :)

What did you do about the call_out's and heart_beat's in the objects
that were saved?  Admittedly, it may not be a problem....depending on
how complex the items on your mud are.  But it does prevent the
reloaded state from being a facsimile of the state before shutdown.

Blackthorn@Genocide
From: oakley@contra.enet.dec.com (The Zeeker)
Newsgroups: rec.games.mud.lp
Subject: Examples of shadow() in use?
Date: 25 Aug 92 23:36:35 GMT
Organization: Digital Equipment Corporation, Maynard, MA.
Organisation: Treadstone Seventy-One


 Was wondering if anyone has some examples of shadow() being used
 which I could take a look at?  Any help is greatly appreciated!

-----------------------------------------------------------------
Brought to you by Treadstone Seventy-One Corporation.
--- --- --- | /  "Come not between the dragon and his wroth!"
 /  |-  |-  |(    		- Lear, King of England
--- --- --- | \		oakley@contra.enet.dec.com
_________________________________________________________________
Newsgroups: rec.games.mud.lp
From: eyeq@wpi.WPI.EDU (Brent Alan Burkholder)
Subject: Re: Quests was Re: SW Quests
Organization: Worcester Polytechnic Institute
Date: Thu, 3 Sep 1992 19:07:14 GMT

 Meetch, I'm shocked... what of Torcquest?? (of course, you never actually
had to play it so I suppose it didn't make quite the impact it did on the
others. ;)