HDTenEightyP/NetNews huggingface dataset:
From: escott@csuvax1.csu.murdoch.edu.au (Evan Scott)
Subject: Re: sub-objects and MudOS virtual objects
Organization: Murdoch University
Date: 28 Aug 92 16:15:51 GMT

beeman@cats.ucsc.edu (Adam Beeman) writes:
>MudOS is *years* ahead of its time, surely.

Whether or not this was supposed to amuse us Buddha, you _have_
been claiming this far and wide from the lofty heights of your ivory
tower.  Thanx for in one statement demonstrating the ultimate
in oxymoronical self-aggrandizing foolishness.

There are two reasons people would wish to develop and discuss new
ideas and methods for doing things -
a) As an ego boost, an attempt to be able to lord over others by forever
   claiming "such & such an idea was mine".
b) As a genuine attempt to further the refinement, sophistication and
   general niftiness of something through an honest, open and 
   egoless forum of discussion.

I know which of these I most wish for, and I know which we have seen in 
rec.games.mud.lp over recent days.

The second is _difficult_ (and I think impossible) to achieve in a pure
state because it requires a discipline and an emotional development
which seems far beyond most people.  However, it is something worth
striving for.  Certainly I am not blaming you (Buddha) for any but
a small part of the poisonous debate we have seen.

If such a forum _can_ be maintained, great gains can be achieved.  
_Everyone_ has interesting and potentially useful ideas that can
enhance any project that is embarked upon ... if the people doing
the actual implementation stop and listen and discuss.  Surprisingly
Buddha, you and the select group of people who work on your
love-child are not the only ones with good ideas in the world ... and
this goes for all the other cliquey groups on r.g.m.lp as well.

In NO way am I trying to suggest that there is "one true way" ...
and I think the development of separate drivers is a good thing
because it promotes varying and interesting ways of looking at
problems.  I think I AM trying to say that each driver project
should look deeper to find out what _overall_ trends they are trying
to promote ... and then listen to peoples ideas, and look at what
the other groups are willing to openly share, and pick and choose
those things which they think will fit in well with their ideologies.

Sorry to rant guys, but this flame war is achieving nothing but
greater intolerance and less sharing of ideas which would 
improve _everyones'_ lot.

Bing on,
Ember.

Newsgroups: rec.games.mud.lp
From: rickert@cco.caltech.edu (Keith Warren Rickert)
Subject: Re: Hack'n'slash not for me
Organization: California Institute of Technology, Pasadena
Date: Sun, 23 Aug 1992 18:01:15 GMT

In <1992Aug23.160013.15754@uniwa.uwa.edu.au> guddt@uniwa.uwa.edu.au (David Bennett) writes:

>anipa@cs.tut.fi (Niilo Neuvo) writes:
>>One of the best uses I could think of for exec() is a cyberspace. Or a
>>mud within a mud in other words (one could think of our gridwar as a
>>mud within a mud).

>You can do a lot of this with shadows and clever thingy handleing on the
>playter object.  ONe good reason for keeping everything on the player
>object is that all the stuff for handling player stuff is in the one
>spot.  You do not need to change it in a bunch of files.

One solution is to have a lot of common player stuff in separate modules,
all of which are inherited by the various execable modules
Only the sections that really need to be different are in the separable
player objects.  
Depending on what you are trying to do, of course....

ObFlame: You are entirely deceitful.  I have it on good
authority that you are not pink, but rather a pale mauve.  Furthermore,
there have been some unsupported rumors that you are half amphibian,
and not a fish, but a frog.  And, I think that the grammar errors werent
on purpose, but by accident. And spelling errors are due to the machine.
Nyahh.

Keith
Kringled@ TMI, MudDog
From: jlw@HEBREW.CC.COLUMBIA.EDU (James Waldrop)
Newsgroups: rec.games.mud.lp
Subject: Re: "external" efuns
Date: 27 Aug 92 00:16:54 GMT

djohnson@cs.ucsd.edu (Darin Johnson) writes:
>One of my old ideas to Lars was a way to encapsulate ALL non-standard
>efuns into files separate from the standard distribution.  For
>example, if you wanted to add printf, you would add printf to
>func_spec.c, get a printf.c file, and perhaps update an
>external_efuns.c switch table...  It would have made adding new things
>simple to do, while still being able to apply patch files.

MudOS has done something like this in 0.9.0 (very soon to be released).
The huge switch in eval_instruction has been replaced with a list of
pointers to functions.  This lets you put new efuns in different files,
or even group efuns by class.

Sulam

jlw@hebrew.cc.columbia.edu (if you were smart, you'd realize this is filler)

This isn't, though.
Newsgroups: rec.games.mud.lp
From: rdubbs@cs.tamu.edu (Roger B. Dubbs III)
Newsgroups: rec.games.mud.lp
Subject: Re: spellbook code in lpmud..
Date: 25 Aug 92 23:48:26 GMT
Article-I.D.: tamsun.1992Aug25.234826.19733
Organization: Computer Science Department, Texas A&M University

In article <1992Aug25.114733.8575@corax.udac.uu.se> flax@mizar.docs.uu.se writes:
>
>I'm using cdlib 00.25 and gamedriver 01.57.
>I'd like an example on how to code so that when a user with too low
>xp or wizlevel picks up a spellbook (or spellobject) the high level
>spells never show up with the 'spells' command.
>I was thinking of overloading list_spells but that method
>is nomask'ed. Any ideas?

Standard LPC solutions won't work because of the exact problem Jonas is
trying to solve.  (Remember, this is CD mudlib.)  I think what you want
to do is use add_spell() and remove_spell() creatively in order to
achieve your effect.  So, in the enter_inv() function, you could just add the
appropriate spells using add_spell() and in the leave_inv() function,
you can remove all spells.

The biggest problem with this solution is, what happens if the player
increases experience sufficiently to gain a new spell?  Perhaps you
could have a "learn spell" command, and the spellbook can show you
(using the long desc) what the next spell is.  If the learning is
successful, you simply call add_spell().

We do use "nomask" a lot in the CD mudlib.  What ends up happening,
inevitably, is that someone's creativity is hampered.  This is traded
off for the extra security we get.

I hope this helps.
/Roger
From: rson@rhi.hi.is (Reynir Hugason)
Newsgroups: rec.games.mud.lp
Subject: Re: Driver additions
Date: 26 Aug 92 12:08:46 GMT

What is of course needed is to eliminate all but the basic efuns and
write a driver that compile the standard objects into itself. THat way
things would run a lot faster and the concept of muds hoging a machine
would be eliminated.

Lpc is not really very different from standard C is it? It is fairly
easy to write a preprocessor for it that translates to C and viola
standard objects inside the driver :-)

It would of course be preferable if the compiled versions didnt have to
use value structures but could instead use primitive data types...

Just a thought..
Newsgroups: rec.games.mud.lp
From: oakley@contra.enet.dec.com (The Zeeker)
Subject: Re: **** TOP 10 LPMUDs ****
Organisation: Treadstone Seventy-One
Organization: Digital Equipment Corporation, Maynard, MA.
Date: Wed, 26 Aug 1992 11:50:11 GMT


In article <1992Aug26.070914.29762@msuinfo.cl.msu.edu>, chena@crs.cl.msu.edu (Antony Chen) writes...
> 
>oakley@contra.enet.dec.com (The Zeeker) writes:
> 
>>	Well, I installed the TMI game driver and `mudlib' a month or
>>	so ago, tried it for a week or so and was not impressed a great
>>	deal.  Stick with the 3.1.2 game driver.  I have yet to experience
>>	any problems with it
>>	
>>	Zeek
> 
>Um....no problems?  I don't really know if I'll be able to crash the
>mud as a player, but as a wiz, I could do several things that would really
>futz up the mud.  TMI's new game driver allows for socket efuns and other
>things like a standard message efun instead of having all the rest of 'em.
>I know that whenever I post on here, I always defend TMI, but what the hell?
>They deserve it for coming out with such a GD.

	What things are you talking about?  

init() { add_action("exit","exit"); }

exit() { this_player()->move_player("X#room/church");  return 1; }

*snicker*  That can cause serious problems.  Or slowing the mud to a
halt by cloning thousands of objects that have working player heartbeats.

-----------------------------------------------------------------
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
From: pariah@tartarus.uwa.edu.au (Michael Malone)
Subject: Re: Driver additions
Organization: University of Western Australia
Date: Wed, 26 Aug 1992 06:28:39 GMT

> Why not have one driver as standard ?

I believe we had this discussion before, and it was
largely a philisophical question. Take the case of
the DM environment versus the Discworld mud. Both
originated from UWA, with some influence from the
Borderline mudlib. Each used a 3.x driver as a starting
point. That was where the similarities stopped.

Pinkfish and co attempt to produce beautiful, easy to
learn code:

    set_short("A room");
    set_long(
        "Line 1\n" +
        "Line 2\n" +
        "Line 3\n"
        );
    add_item("clock", "It is broken\n");

We have three things in mind: speed, memory constraints
and functionality (especially as regards the language
parsing). Thus we get:

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

Now the Discworld model is far easier to read, but each
of those function headers takes about 48 bytes. The item
can only be addressed as "clock", whereas 
"look at the broken wall clock" will work fine for us.
Our average room size if < 600 bytes, but the cost is
readability and ease of learning. After being open for
5 months with > 12 wizards, we have maybe two that I would
describe as good coders.

Other problems become apparent as well. We cut efuns from
the driver that pinkfish may describe as "essential". He
adds efuns that we would describe as "useless". In my view
a movement towards a single driver would be a huge step
backwards, and politically, it would be an impossibility.

Have fun
From: djohnson@cs.ucsd.edu (Darin Johnson)
Newsgroups: rec.games.mud.lp
Subject: Re: Driver additions (was Re: **** TOP 10 LPMUDs ****)
Date: 1 Sep 92 18:45:10 GMT
Organization: =CSE Dept., U.C. San Diego

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

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

-- 
Darin Johnson
djohnson@ucsd.edu
    Strange things are afoot at the circle-K...
Newsgroups: rec.games.mud.lp
From: mmcg@cs.monash.edu.au (Mike  Mc Gaughey)
Subject: Re: Consider the following...
Organization: Computer Science, Monash University, Australia
Date: Fri, 28 Aug 1992 04:46:48 GMT

dbn@rti.rti.org writes:

>Consider the following situations:

>1->5) Someone who prefers hermitage to champagne

>Which of these situations would you prefer as a common man?

It depends whether the hermit enjoys kicking heads :)

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

"Head stompin', ass kickin', finger licking nastiness"
From: chena@crs.cl.msu.edu (Antony Chen)
Newsgroups: rec.games.mud.lp
Subject: Re: Driver additions
Date: 29 Aug 92 06:02:56 GMT
Organization: Michigan State University

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

>I don't think the idea was to just sit around and talk.  I think
>the idea was to actually go and do something.  Most of the modified
>drivers out there have only a few bug changes (we're not talking about
>TMI, CD, or Shattered).  So why not try to merge that back in.  That's
>the way things were working prior to 3.1, and it worked pretty well.
>And I can't see any serious objections to putting in bug fixes.

>I agree that TMI won't be interested in using the resulting product.
>The argument that "TMI won't use it, so it's a waste of time" is
>rather silly.  It would be nice if they allowed some of their code to
>be used though.  This of course assumes that not everyone there is of
>the mindset "if you won't use our driver, you must be morons".

Go for it.  Make this committee....if it didn't work, it would be at least
an interesting experiment
From: craig@ec.uwa.oz.au (Craig Richmond - division)
Subject: Re: Driver additions
Organization: University of Western Australia
Date: Thu, 27 Aug 1992 10:00:30 GMT

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

>>One of my
>>favorite features in MudOS is the system of mappings, to duplicate this in
>>3.1.2 requires you to use two arrays, and even this doesn't come close to the
>>effect of a mapping.

>Aren't mappings just the same thing as associative arrays with a better
>syntax?  (and aren't there two incompatible versions of mappings? :-)
>Ie, assoc(), insert_alist(), etc.  Why would anyone want to do the
>two-array method?  yeesh

Mappings are a classic example of bad language design.  Pascal had mappings
of sorts ages ago.  They were called sets.  A friend of mine took his
mudlib and converted huge large chunks of it to use mappings.  This was
good.  They made lots of it easier and mean that at a later date he can
implement mappings as a hash table in the driver and it will really rush.
Only problem was that his typing aint so hot (not to mention his spelling)
and he suffered lots of bugs which were the result of mistyping a name when
using it as an index to a mapping.  This of course wasn't noticed as an
error.  Then he went and started #defining just about everything that he
was using as indexes on mappings.  Bit stupid really.  While they have
their uses, defining sets would have been useful too!

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: dbn@rti.rti.org
Newsgroups: rec.games.mud.lp
Subject: Consider the following...
Date: 27 Aug 92 18:25:57 GMT
Organization: Research Triangle Institute, RTP, NC

Consider the following situations:

1)  A hermit scientist working in an ivory tower on the top of some mountain
finds a cure for cancer.  The man is brilliant.  He also doesn't like to
communicate with the outside world.  No one ever finds out about it.

2) The same hermit scientist realizes that he must inform the world of his
discovery, but realizes that he has lost all capacity for communication from
his years of isolation.  People see his effort, but don't understand it
because of the scientist's inability to communicate clearly and effectively.
The man is written off as a fool and a charlatan.

3) The same scientist finds the cure to cancer, except that cancer is an
extremely rare disease.  The knowledge of the cure is lost, and the scientist
loses interest and moves on to something else, thinking of the cure as an
intellectual exercise.  Many years later, cancer is much more common and an
independent researcher comes up with an equivalent cure.

4) At the same time that the scientist described in situations 1) and 2) finds
the cure, someone else does, too.  But the someone else is expert at clear
and effective communication.  The someone is heralded, the hermit scientist is
not.

5) Again like situation 4) but the someone doesn't find a complete cure, but
is able to inform the public about the underpinnings which will eventually
lead to the whole cure.  The someone, again, will be heralded.  The scientist
will be forgotten in short order.

Which of these situations would you prefer as a common man?
Do these situations look like a picture of a debate going on now?
If you see what I'm driving at, good for you.  Now get back to work. :)

-Daniel
(Florentino@Overdrive)
From: jlw@hebrew.cc.columbia.edu (James Waldrop)
Newsgroups: rec.games.mud.lp
Subject: Re: Subobjects
Date: 29 Aug 92 05:29:28 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
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 06:40:12 GMT

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

>In article <geoff.714882644@bruce.cs.monash.edu.au> geoff@cs.monash.edu.au (Geoff Wong) writes:
>>jlw@HEBREW.CC.COLUMBIA.EDU (James Waldrop) writes:
>>

>Good for you. Did you release it? I have not seen it.

Yeah - in fact we did; you probably hadn't made it out of high school
then. Undergrads are all the same.

>"Simply makes the code easier to work on"...simply. Can't have that, can
>we? Ho Hum.

No one was interested 18 months ago - why is it such a big deal now?

>I notice you say nothing about the virtual objects. But, perhaps they are
>not even worth your comment. Ho Hum after all.

You're correct - they're not.

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

Newsgroups: rec.games.mud.lp
From: ins448c@lindblat.cc.monash.edu.au (Andrew Mills)
Subject: Re: MudOS a ripoff?
Organization: Monash University
X-Newsreader: Tin 1.1 PL5
Date: Sat, 29 Aug 1992 00:22:06 GMT

Dwayne Jacques Fontenot (fontenot@ravl.rice.edu) wrote:
: In article <geoff.714897612@bruce.cs.monash.edu.au> geoff@cs.monash.edu.au (Geoff Wong) writes:
: >fontenot@ravl.rice.edu (Dwayne Jacques Fontenot) writes:
: >
: >>In article <geoff.714882644@bruce.cs.monash.edu.au> geoff@cs.monash.edu.au (Geoff Wong) writes:
: >>>jlw@HEBREW.CC.COLUMBIA.EDU (James Waldrop) writes:
: >>>
: >
: >>Good for you. Did you release it? I have not seen it.
: >
: >Yeah - in fact we did; you probably hadn't made it out of high school
: >then. Undergrads are all the same.
: 
: well...actually, I had. See, for all your intelligence, how could you know
: that I have been reading your's and Mike's postings from the very beginning?
: And I contest the above statement. You and Mike are constantly posting
: teasers -- "yeh..I did that a million years before your great grandfather
: was born..and even then I did it a googleplex times better than you".

They did and it most likely was done better.

: Sure, you may have posted many buzzword-filled articles with things like
: "implementation is trivial, so I won't bother to tell you how I did it",
: but the only thing helped by that is your egos.
: 
: And before you come screaming back with "proof" that you released your code,
: perhaps we should define "release". Do you mean you gave it to a few
: priveleged friends? See, if you actually released it, where is it?
: And if it's so great (and released), why is nobody but you using it?

Why give stuff out to someone who doesn't appreciate the effort and ingenuity
put into it ?  Much better to build a system and know they've done a good job
and have an admiring audience who appreciates that.

: And, yeh...a couple times you posted some stuff that vaguely looked like
: code but...see above.

Ditto.

: >>"Simply makes the code easier to work on"...simply. Can't have that, can
: >>we? Ho Hum.
: >
: >No one was interested 18 months ago - why is it such a big deal now?
: 
: People *were* interested. And the only one making a big deal out of it now
: is you.

Funny, I didn't notice anyone beating down their doors to get at their code.
There should have been.
 ___________________________________ _________________________________________
<                                   |                                         >
<                big                |  Young Crone : "How did you know that?" >
<         (aka Andrew Mills)        |                                         >
<                                   |  Black Adder : "Just a wild stab in     >
<         can be found at :         |    the dark.  Which, incidentally, is   >
<                                   |    what you'll be getting if you're     > 
<     big@yoyo.cc.monash.edu.au     |    not a bit more helpful !"            >
<___________________________________|_________________________________________>
Newsgroups: rec.games.mud.lp
From: mmcg@cs.monash.edu.au (Mike  Mc Gaughey)
Subject: Re: sub-objects and MudOS virtual objects
Organization: Computer Science, Monash University, Australia
Date: Fri, 28 Aug 1992 10:41:45 GMT

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

>In article <9208280657.AA01597@hebrew.cc.columbia.edu> jlw@HEBREW.CC.COLUMBIA.EDU (James Waldrop) writes:
>>
> [ stuff deleted ]
>>Even worse, how do you handle object pointers to things that haven't
>>logged back in yet?  Or another problem, you say only cloned objects
>>can be saved, so you have a pointer to /std/sword#345, but when you
>>come back it's gonna be /std/sword#22 or somesuch confusion.  Possibly
>>if you logged all the players back in, but linkdead, and you had some
>>way of stamping objects, but then you're getting dangerously close to
>>recreating the conditions that probably caused the crash in the first
>>place.

You're talking shit.

>	My guess is that each object gets a lifelong identity 
>-- not file_name -- but related to it, and there can be only one such 
>object with that identity, ever.

And so are you.

Why the hell would I want to make new names of objects after a crash
consistent with those from before the crash?

Look, guys, the situation is simple.  If you rely on string names of
cloned objects, your code will be fucked on a reload from a savefile.

What do you think object pointers are FOR?

The ONLY reason the file_name() efun still actually returns the
"#nnnnn" suffix for cloned objects is because it's occasionally useful
for wiztoys.  And that's gonna disappear soon anyway - in my opinion,
clones shouldn't _have_ unique ascii names.  There should be different
ways of getting hold of them.

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

"Head stompin', ass kickin', finger licking nastiness"
From: lipscomb@lonestar.utsa.edu (David S. Lipscomb)
Newsgroups: rec.games.mud.lp
Subject: ?
Date: 1 Sep 92 13:57:54 GMT
Distribution: na
Organization: University of Texas at San Antonio


Does any of the Muddog wizards know when Muddog will be back up?
If you do please email me at lipscomb@lonestar.utsa.edu.
Newsgroups: rec.games.mud.lp