HDTenEightyP/NetNews huggingface dataset:
From: guddt@uniwa.uwa.edu.au (David Bennett)
Subject: Re: Driver additions
Organization: University of Western Australia
Date: Thu, 27 Aug 1992 16:32:41 GMT

oakley@contra.enet.dec.com (The Zeeker) writes:

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

They did.  Thats how the tmi driver started.  A bunch of people got
organised and started a driver.  However most of the original people
wandered or gave up.  The cd and shattered people were never involved in
at, as at that point tmi was a tin pot little mud with an uncertain
future.  The TMI driver was also almost completely taken over by one
person.  They had a mailing list and only one thing that I remmeber was
posted to it.  The only people who posted ideas for adding before adding
them was sean and I and none of our ideas ever got added :)

People are often to egocentric.  I am sure I fall into this trap and I
doubt anyone is immune.  Programing is a very personal task and with a
thing such as a mud ideas are very strong.  The best way to discuss
things in face to face in this cicumstance.  I bet  the ansi committee
didnt meet over the net.  I wouldnt want to design a language with
someone I couldnt shout at :)

David.
[DDT] Pink fish forever.  WHos that?
-- 
  David Bennett,  guddt@uniwa.uwa.oz.au | University Computer Club
     Where Pink fish swim backwards.    | c/o Guild of Undergraduates
These words I am singing now mean nothing more than meow to an animal - TMBG
Disclaimer: Any spelling mistakes in this article are all entirly my fault.  Any grammer errors spotted in this article were put there because I could.
Newsgroups: rec.games.mud.lp
From: pn88384@cs.tut.fi (Petri Nurminen)
Subject: Re: **** TOP 10 LPMUDs ****
Organization: Lets waste him. No offense.
	<alfred.713896642@dutepp3>
	<Bt2ztt.9IB@wpi.WPI.EDU>,<mmcg.714010591@bruce.cs.monash.edu.au>
	<1992Aug25.235838.13734@ctr.columbia.edu>
Date: Wed, 26 Aug 1992 12:09:24 GMT

uIn article <1992Aug25.235838.13734@ctr.columbia.edu> ucs_rjd@SHSU.EDU writes:
> You are not a player killer until you've beaten the best on Genocide.

You are not a playerkiller aunless you've won Blood Bath in BatMUD.

	Pet
--
	************************************
	* Peace through superior firepower *
	************************************
--
From: jlw@HEBREW.CC.COLUMBIA.EDU (James Waldrop)
Newsgroups: rec.games.mud.lp
Subject: Re: MudOS a ripoff?
Date: 26 Aug 92 23:54:42 GMT

Subject: Re: MudOS a ripoff?

	[ note: Pnews has decided it doesn't like me anymore,
	  so I'm using ucbvax to post.  Boo hoo.  As a result
	  of the probs, however, I have an extreme backlog of
	  things to post about.  I'll try and not repeat
	  myself too often... --Sulam ]

Petri.Virkkula@hut.fi (Petri Virkkula) writes:
>On 22 Aug 92 05:31:46 GMT, mmcg@cs.monash.edu.au (Mike  Mc Gaughey) said:
>> Even though they can talk MudOS as another version of LpMUD
>> why they had to make totally different name? A postfix to
>> LpMUD would have been enough.
>Mike> In TMI's case, I agree.  But, in your opinion, how far does a mud have
>
>	That is difficult question but I can tell my opinion about it:
>
>	As long the game driver is internally same as the LPMUD it 
>	should have name similar than LPMud. And with "internally
>	the same" that it contains same compiler, same interpreter
>	or its data structures are same. The problem when they
>	aren't anymore same.
>
>	In case of MudOS above means that it is still an LPMUD.

Exactly what do you know about MudOS?  Internal changes at this point
include:

Several changes to the object struct, and a few to the sval struct
A completely rewritten eval_instruction (it uses pointers to functions
  instead of the large switch())
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)
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...

  People have spent many hours profiling memory under MallocDebug
(on NeXT's), and under Ultrix to find places where the CPU can be
usefully conserved. 

Other people have spent a lot of their time to make MudOS run on
more platforms than any other 3.0 version out there.  Currently
we compile on almost any machine that has gcc.

Still more people worked very hard to change certain efuns to make
them more useful (for example Shadowhawk's mods to input_to() to
allow passing arguments with it).

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 that CD has as many internal
changes as MudOS.  Do you consider them to be a ripoff as well?

Sulam
From: uekleinf@mcs.Drexel.edu (Erik Kleinfelder)
Newsgroups: rec.games.mud.lp
Subject: Re: Driver additions
Date: 26 Aug 92 04:18:33 GMT
	<UEKLEINF.92Aug25152135@queen.mcs.Drexel.edu> <R1h-h##@engin.umich.edu>
Organization: Drexel University


>       As long as MudOS is an LPmud game driver, the MudOS mudlib is a LPmud
> mudlib.  As for having 2.4.5 as a standard, WHY?  Why go back to something as
> inefficient as 2.4.5 and it's 2000+ lines of player.c?  There are enough 
> 2.4.5 mudlib-based Lp's to go around, how about seeing something different
> than the humpbacked bridge?

> [.sig]                           		Guile@engin.umich.edu

     *ack* No way.  What I was wondering is, can everyone come together and
agree on one "driver", not go back to how 2.4.5 was(*scream* No way).  I was
actually wondering if those driver's that are out there can come together to
form the best and most efficient driver in existence.  So one does not have to
say, I want this TMI specialty that is this efficient and this CD piece of
code that is real fast compared to TMI's, and then have to build the driver
they want.  How about one driver at peak performance?????

Erik (Gunther God@Dragon's Den -- 129.25.7.111 2222)
From: jlw@HEBREW.CC.COLUMBIA.EDU (James Waldrop)
Newsgroups: rec.games.mud.lp
Subject: Re: security holes in 2.4.5
Date: 27 Aug 92 00:03:12 GMT

guddt@uniwa.uwa.edu.au (David Bennett) writes...
>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!
> 
>Bug free, so long as you removed the money bug...  The quicktyper bug...
>etc.
	We had more minor technical problems with living.c, soul.c,
	player.c and master.c..  No bugs with quicktypers or money
	to my knowledge...

Hmm, what was your address again?  :-)

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.

Sulam
Newsgroups: rec.games.mud.lp
From: mmcg@cs.monash.edu.au (Mike  Mc Gaughey)
Subject: Re: MudOS a ripoff?
Organization: Computer Science, Monash University, Australia
Date: Thu, 27 Aug 1992 11:12:35 GMT

fontenot@ravl.rice.edu (Dwayne Jacques Fontenot) writes:

>>You mean you CHANGED its NAME but you are still using the SAME BASE CODE?

>well...one of the entries in the changelog is:
>        * added in major changes to the driver: comm1.c was almost entirely
>          rewritten (again), including add_message() which is now varargs.
>          The driver now implements an event queue -- this is a major change
>          to the way the driver handles events/interrupts.

Most unimpressive.  I did this before you were born.  It was so simple,
I didn't even bother to log it in the changelog.

You've got it all wrong anyway.  You'll never be able to justify
yourself in terms of a few speed hacks or cleaner handling of internal
structures.

The only correct response has been from Sulam: "Fuck you".

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

"Head stompin', ass kickin', finger licking nastiness"
Newsgroups: rec.games.mud.lp
From: havardhk@dhhalden.no (HAVARD HOYAAS KRISTOFFERSEN)
Subject: New MUD
Organization: Ostfold College
Date: Sat, 29 Aug 1992 11:34:51 GMT

Hiya all. I'm starting a new MUD called the Forgotten Realms MUD.
I will need some new play-testers before I let it loose however.
There are some players already, but they're not very experienced
in mudding, so they just can't point out all kind of errors and
inconsistencies to me.

If you're familiar with the DiscWorld (DW) standard you'll find my 
mud is very similar to it. Hope to see a few bugseekers today or
tomorrow. The address is:

fenris.dhhalden.no 2001   or 158.36.33.3 2001

Ducky              havardhk@dhhalden.no
From: jacob@fy.chalmers.se (Jacob Hallen)
Newsgroups: rec.games.mud.lp
Subject: Re: Darker Realms - The Mudlib
Date: 27 Aug 92 04:06:48 GMT
Organization: Chalmers University of Technology, Physics Departement, Gothenburg

In article <1992Aug20.040039.1426@mcshh.Hanse.DE> amylaar@mcshh.Hanse.DE (Joern Rennecke) writes:
>Hmm, no wonder the code won't work like it should when you never care to
>incorporate it correctly.

But we haven't incorporated it, Lars has, and I think you have had the chance
of testing what he has done, and correcting any of his mistakes. And I hardly
expect him to find obscure leaks in the middle of your code.

>b) Documenting code is extremely inefficient when the basic design is
>unfinished. Because The comments will vanish with the code when you realise
>that a piece of code needs replacement. And i haven't seen a bug-free
>and complete LPmud gamedriver yet.

This is the lamest excuse I have ever heard. If you make your code available
for FTP, you must expect other people to use it, and unless you have
delusions of grandeur, you must expect your code to contain bugs. How do
you expect the poor people you lure into using your stuff to be able to find 
and repot your bugs? Do you expect them to be able to fix them themselves?
What you do is that you load the inefficiency onto your victims, who have
to understand your cryptic and undocumented code.
>
>>So instead of arguing why your code should be hard to read, why don't you
>>change your coding habits. You will do yourself a favour and we can start
>>using your code again.
>
>Readability without functionality is useless. And there is still a great deal
>of unimplemented stuff in the gamedriver, some even pointed out by gaping
>holes in the code...
>
Functionality without readability is useless, especially in a changing
environment. You must expect that someone else takes your code and modifies
it for some other use, or reimplements it with an other algorithm that
turns out to be more suitable under the given circumstances. If you don't heed
this, your code will be useless to all people apart from yourself.

Jacob Hallen
Newsgroups: rec.games.mud.lp
From: mmcg@cs.monash.edu.au (Mike  Mc Gaughey)
Subject: Re: Virtual Rooms and Objects (really: Saved sub-objects)
Organization: Computer Science, Monash University, Australia
Date: Fri, 28 Aug 1992 04:49:36 GMT

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

>>Actually, what are virtual objects?  I've got virtual rooms on my

>The other thing the virtual object daemon might do is see if there's a file
>without a .c extension in that place, that contains object description code
>of some sort.  This allows us to write an object description language that
>is far easier to use than LPC and much more memory efficient.  There is,

>--- cut here ---

>short: A glowing golden orb.
>value: 300
>weight: 2
>id: "orb" "glowing orb"
>long:
>This is the great orb of utter simplicity.
>It appears to be pretty useless, but you could probably sell it.
>**

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

This was originally to make it difficult for players to distinguish
game driver crashes from link death (because reboots took a few seconds) -
for instance, when autosaving, the player savefile had the following
entries:

name "drokk"
....
contents { [ "obj/torch" ... savefile for a torch ... ]
	   [ "obj/weapon" ... weapon savefile ... ]
	   ...
	}

When a restore_object was done, an object would be cloned up
for each of the subobject values in the file, and restored
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... :)

So, _another_ virtual object possibility, somewhat more limited than
Buddha's (but with a few nice bonuses) is to treat a name for which
a .o file exists, but no .c file exists, as an object description,
and simply clone up the appropriate object and restore_object into it,
(extend your savefile syntax to optionally allow an object name).

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

"Head stompin', ass kickin', finger licking nastiness"
From: djohnson@cs.ucsd.edu (Darin Johnson)
Newsgroups: rec.games.mud.lp
Subject: Re: driver bugfixes (was: Re: **** TOP 10 LPMUDs ****)
Date: 28 Aug 92 23:55:18 GMT
Organization: =CSE Dept., U.C. San Diego

>Watch the mud go >down<.

Hmm, you're right.  I remember this from before version 3, I just
assumed it got fixed by now :-)

>and so it *misses* this check for the maximum evaluations, and the game
>hangs until someone comes along to kill the processes.

I can't find anything relevant in the (huge) diffs.  Or is this something
fixed in 0.9?

-- 
Darin Johnson
djohnson@ucsd.edu
  - Grad school - just say no.
From: jlw@hebrew.cc.columbia.edu (James Waldrop)
Newsgroups: rec.games.mud.lp
Subject: Re: Subobjects
Date: 29 Aug 92 03:09:05 GMT

mmcg@cs.monash.edu.au (Mike  Mc Gaughey) writes:
> When a restore_object was done, an object would be cloned up
> for each of the subobject values in the file, and restored
> 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.

Just to make sure I have this right, let me give you an example.

Let's say I have player A, who is attacking an orc, so he has
his attack_ob pointing to Mr. Orc.  The room he's in also
has a global variable pointing to Mr. Orc, which it uses to
check whether or not he's been slaughtered.  If the game
crashes and comes back up, will there not be 2 orcs, one for
the player's copy, and one for the room's copy?

I'm not criticizing your work, I'm just trying to figure out
how you deal with certain problems that I and some friends of
mine banged our heads up against for a while.

Sulam
From: uekleinf@mcs.Drexel.edu (Erik Kleinfelder)
Newsgroups: rec.games.mud.lp
Subject: Re: Virtual Rooms and Objects (was: Re: MudOS a ripoff?)
Date: 1 Sep 92 00:56:26 GMT
	<37330@sdcc12.ucsd.edu> <17jcmeINN21m@darkstar.UCSC.EDU>
Organization: Drexel University

>>>>> On 27 Aug 92 20:07:42 GMT, beeman@cats.ucsc.edu (Adam Beeman) said:
Adam> NNTP-Posting-Host: am.ucsc.edu

> If, however, the daemon detects that this is a virtual object's filename,
> then any object it returns will now have the filename identifier of
> "/d/Sahara/desert_52,30"... so even file_name(ob) will return that.  What
> this is useful for is a number of things.  In the case of the desert, rather 
> than write a hundred rooms that all say, "This is barren, dry desert with
> exits in all directions", I can just write a program that clones rooms and
> sets their descriptions, then returns the rooms... and they get more useful
> filenames than "/std/room#435".

     Actually Buddha, Fordan and Cyberleader on Dragon's Den have this for
SPACE, and let me add that this is a great space saver, considering you have
3 dimensions to worry about instead of two.

> The other thing the virtual object daemon might do is see if there's a file
> without a .c extension in that place, that contains object description code
> of some sort.  This allows us to write an object description language that
> is far easier to use than LPC and much more memory efficient.  There is,
> admittedly, a small CPU time tradeoff here.  However, cloning a generic
> object is about 5 times as efficient as inheriting it, in many cases.

> And presto, there's your basic stupid object.  Useful for things that
> don't need associated code.  And, the object description languages (ODLs)
> have a long ways to go.  

     This sounds great, but I have a few questions.  Is this something to be
planned to be added to A "driver"(or MudOS)??  And couldn't something like
this be added to any mud to use "restore_object()"??  I can imagine the
efficiency would drop greatly, but how advanced could this get??

> Anyhow, I hope this helps explain something to someone.

     Very much, but now you got me wanting to develop ODLs with you.  One last
thing, aren't we moving from LP to the MUSH type idea where objects are just
stored variables(Granted they are saved, but you get the idea)???

> -Adam Beeman
> Buddha@TMI

Erik Kleinfelder (Gunther God@Dragon's Den -- 129.25.7.111 2222)
From: sgreen@neumann.une.edu.au (Stephen Green)
Newsgroups: rec.games.mud.lp
Subject: Saving Scores
Date: 25 Aug 92 02:02:02 GMT

The following relates to code on an lp386Mud (3.1.2 driver, 2.4.5 lib)

Some background:
 One area I have contains 3 rooms with locked safes.
 Each players goal is to find the clues that belong to each level,
 ( which represent the combination for each level to open the safe ),
 in the quickest time possible, find the safe room, enter the combination,
 ( giving them the 'start clue' for the next level's safe ), and continue
 in this fashion ( in the quickest time ) to solve 3 levels.

 I added set_ lines to player.c that set ,for each player, the time taken 
 to solve ( and if a personal best set this too ) for each of the 3 levels.

 Then the next time they solve the level i had query_ 's to check to see
 if their time was a personal best, a level_best or ( if the room I am 
 querying in was the 3rd safe room ),  the game_record.
  ( a level_best occurred if time was the best by any player for that level ).
  ( the game_record was the best total time taken to solve all 3 levels )

Now where I ran into trouble was in 'storing' the level_best and game_record
so that after resets or crashes the first player to solve levels would not
be creditted with a level_best ( which would happen if the level_best etc
were not saved through resets/crashes).

What I ended up doing was using write_file to write files in my dir the
"length" ( in heart_beats ) of the various times, then setting a variable
equal to 'file_size() -1' to be the lengths which represent times!

Does anyone know of a better way of "storing" number values ( eg 1045 would
be the time in heart_beats for the game_record ) so they are always
accessiblle and can be modified whenever need be?

Thanx.

/* .sig */

Stephen Green,
University of New England,
Armidale, N.S.W. Australia
--------------------------
sgreen@neumann.une.edu.au
From: mmcg@cs.monash.edu.au (Mike  Mc Gaughey)
Newsgroups: rec.games.mud.lp
Subject: Re: * PEACE PLEASE! *
Date: 30 Aug 92 04:04:34 GMT
Organization: Computer Science, Monash University, Australia

ins894r@aurora.cc.monash.edu.au (Aaron Wigley [Wigs]) writes:

>Adam Beeman (beeman@cats.ucsc.edu) wrote:
>: >-michael
>: 
>: Ah, aren't you from Shattered Worlds?
>: Hey, can you tell me if they *really* exist anymore?

Oh, no!  Our dreddful decret is out!

>I can. We exist. Here's our player motd:
[...]

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

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

"Head stompin', ass kickin', finger licking nastiness"
Newsgroups: rec.games.mud.lp
From: guddt@uniwa.uwa.edu.au (David Bennett)
Subject: Re: security holes in 2.4.5
Organization: University of Western Australia
Date: Thu, 27 Aug 1992 07:42:26 GMT

djohnson@cs.ucsd.edu (Darin Johnson) writes:

>Here's something I always wondered about with some of the native mode
>mudlibs:

>  init() {  this_player()->command("trust this_objects_name"); }

I have always wondered about this one too...

Make an object auto-loading then put a
seteuid(getuid()); in the create function....

David.
[DDT] Pink fish forever.
-- 
  David Bennett,  guddt@uniwa.uwa.oz.au | University Computer Club
     Where Pink fish swim backwards.    | c/o Guild of Undergraduates
These words I am singing now mean nothing more than meow to an animal - TMBG
Disclaimer: Any spelling mistakes in this article are all entirly my fault.  Any grammer errors spotted in this article were put there because I could.
Newsgroups: rec.games.mud.lp