HDTenEightyP/NetNews huggingface dataset:
From: anipa@cs.tut.fi (Niilo Neuvo)
Subject: Re: Hack'n'slash not for me
Organization: Tampere U of Technology, Finland
	<1546@lysator.liu.se> <ANIPA.92Aug23161702@sotka.cs.tut.fi>
	<1992Aug23.160013.15754@uniwa.uwa.edu.au>
Date: Sun, 23 Aug 1992 19:19:48 GMT

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.

You obviously haven't thought of this enough, let us take an example:

Ghosts don't need a score command. You either put a check in the
player.c (if(ghost)return), or you just don't inherit the score
command. The check is fine as long as the mud is simple, what happens
when a player is something else (dragon, frog, gas-cloud, bug, stone
statue), do I need to write n+1 if()'s into the score command?

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

Ever heard of inheriting? Beginning of bug.c (gridwars bug, comments
added while writing article):

inherit "/obj/player_dir/who"; who-command is nice
inherit "/obj/player_dir/channel"; channels are needed
inherit "/obj/player_dir/ignore"; I should be able to ignore players
inherit "/obj/player_dir/communicate"; Tell/say/shout is needed
inherit "/obj/player_dir/uptime"; You guessed
inherit "/obj/player_dir/termcap"; Boldface exits and other features
inherit "/obj/player_dir/inform"; Inform entry/leaving the game
inherit "/obj/player_dir/look"; Look command
inherit "/obj/player_dir/preparser"; 'quicktyper'

create()
...

> Shadows are just as much fun and just as powerful...  We use a shadow
> for death amongst other things.  In fact I use a lot of shadows.

Shadows are good for what they were designed to do. How do you do the
following things with shadows:
	- Turn a player into anything with a limited/different command set,
	  without writing hundreds of lines of code masking all unneeded
	  commands (yes you can use add_action, but what happens when you
	  decide that 'eq' is much nicer than typing 'equipment').
	- Make a player control another player/monster, command() will
	  not do as we want to see what is going on.
	- Make a mud within a mud, that really feels like something
	  different (cyberspace is a good example of that).

Yes you can code all this into the player object, only ending up with
a huge player.c, but what is the point?

Shadow is good for things that modify the player during the game, like
armours, spell effects and such (as it is used on BatMUD). You can do
all sorts of nice things with shadow, but it simply is intended for
things you can 'wear'.

++Anipa, they think they think
--
      NN   NN  NN   NN  NNNNNNNN
    NNNN    N  NN    N  NNNNNN
  NNNNNN  N    NN  N    NNNN
NNNNNNNN  NN   NN  NN   NN
-- 
Newsgroups: rec.games.mud.lp
From: guile@engin.umich.edu (Kenneth K Lee)
Subject: Re: * PEACE PLEASE! *
Date: Fri, 28 Aug 92 23:30:03 EDT
Organization: University of Michigan Engineering, Ann Arbor

In article <17mqh4INN73q@darkstar.UCSC.EDU> beeman@cats.ucsc.edu (Adam Beeman) writes:
>
>In article <michael.715052408@pv0237.vincent.iastate.edu> michael@iastate.edu (Michael M. Huang) writes:
>>
>>-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.
>
>
>What a dicky .sig.
>
>
>-- 
>#include <std/disclaimer.h>
>#define NAME	"Adam Beeman"
>#define EMAIL	"beeman@{cats, ucscb}.ucsc.edu"
>inherit SIGNATURE; // enhanced .sig virus

*laugh!*  hmm... where did we hear that before??

[no sig!]

Xref: sparky rec.games.mud.lp:3079 rec.games.mud:8555
From: rson@rhi.hi.is (Reynir Hugason)
Newsgroups: rec.games.mud.lp,rec.games.mud
Subject: Re: How should object handles work??
Date: 1 Sep 92 07:48:44 GMT
Followup-To: rec.games.mud.lp

How many servers do you expect to have? Maybe it's enough just to
have a list of servers and send the message only to them instead of
broadcasting it to everybody? Maybe if there are not a zillion
objects servers can keep track of what others servers have?

Maybe you should read about Distributed Databases they have the
same problem.

And remember in REAL computer terms a handle refers to a pointer to
a pointer. If that isnt what you mean by handle please pick another
term since it can confuse the hell out of people. Oh nevermind I'll
go and sit in my corner and rust or perhaps fall apart where I am
standing...
From: chena@crs.cl.msu.edu (Antony Chen)
Newsgroups: rec.games.mud.lp
Subject: Re: **** TOP 10 LPMUDs ****
Date: 26 Aug 92 07:09:14 GMT
Organization: Michigan State University


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.
Newsgroups: rec.games.mud.lp
From: michael@iastate.edu (Michael M. Huang)
Subject: Re: * PEACE PLEASE! *
Organization: Iowa State University, Ames IA
Date: Sat, 29 Aug 1992 05:10:53 GMT

In <17mqh4INN73q@darkstar.UCSC.EDU> beeman@cats.ucsc.edu (Adam Beeman) writes:

>What a dicky .sig.

>-- 
>#include <std/disclaimer.h>
>#define NAME	"Adam Beeman"
>#define EMAIL	"beeman@{cats, ucscb}.ucsc.edu"
>inherit SIGNATURE; // enhanced .sig virus

Look at the dick who's talking.  

-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: rson@rhi.hi.is (Reynir Hugason)
Newsgroups: rec.games.mud.lp
Subject: Re: Driver additions
Date: 30 Aug 92 14:20:13 GMT

You'll have to bear one thing in mind, what some people consider
features others consider bugs.

Like for example:

1) this_player() defined in a call out, doubtful design philosophy.
2) input_to() and EVAL_COST are one of the things people have REAL
trouble to understand.
3) why have write(), say(), and why let the game driver keep track of whre
objects are located (in which rooms they are).

In anycase the greatest advantage of having the whole source code to the lpmud
game driver is that you CAN modify it. The only real use for a commit is in
areas where you do NOT have the possibility to make your own additions.
Also most muds do NOT encourage usage of code from other muds.

Just my 0.02 guilders ...
Newsgroups: rec.games.mud.lp
From: michael@iastate.edu (Michael M. Huang)
Subject: Re: * PEACE PLEASE! *
Organization: Iowa State University, Ames IA
Date: Sun, 30 Aug 1992 16:54:44 GMT

In <mmcg.715150785@bruce.cs.monash.edu.au> mmcg@cs.monash.edu.au (Mike  Mc Gaughey) writes:

[Some strange logical(?) argument deleted].

Mike!  You've lost it!

Sanity!  Sanity!  Sanity!  My kingdom for some sanity around here.

(What am I talking about....  sanity and RGM.LP?  What a moronic
contradiction... :)

LET ME OUT!  LET ME OUT!

-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.
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: Mon, 31 Aug 1992 00:17:22 GMT

jlw@gestalt.austin.tx.us (James Waldrop) writes:

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

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

Nope :)

Attack_ob is static.  And, in our case, livings don't save - in
living.c, there's an lfun 'query_external_save_ok()' which returns 1 if
the object shouldn't be able to be saved as part of another object.  So
we still rely on reset, etc, to set most things up - this is not a way
of taking a snapshot of a whole situation, and expecting it to run
flawlessly when restored.  It's a way of storing cloned object values
in savefiles.  It's used, primarily, for player savefiles, and things
like house and pub backrooms (which save items), and shop storerooms
(which need to keep their long term stock or the economic model here
collapses).  There's also a hack in save_object which only allows one
level of save_object nesting; this accounts for all other (poorly
coded) cases, but means that things which save items need to explicitly
flatten out their contents lists.

If you program anything significant here, you just have to know about
this stuff and program for it - this means static variables where
appropriate.

In any case, I'm getting rather jacked off with the problems and
inflexibility of save_object, and will be scrapping it completely
soon.

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

"Head stompin', ass kickin', finger licking nastiness"
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 04:29:56 GMT

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

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

That's precisely the point.  INTERNAL CHANGES.

'nawk' is still 'awk'...

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

What, you mean a few extra pointers?  A few less?  A hashed object
name chain perhaps?  So have we.  Big fucking deal.

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

Oh, yeah.  Done here over a year ago.  We install them as opcodes
on driver startup.

>Our own version of mappings, mainly snagged from Perl

But still mappings.

>Wrappers around malloc(), realloc(), and free() which allow keeping
>  track of memory (for a small overhead)

*snort*
Maybe you should just install one of them debugging malloc packages
so you can change the name of your mud...

>A change in the way objects compile to allow 'true' virtual objects

Uhh huh.  Like an object name mapping table?  Big deal...

>A file is read in to set certain parameters that used to be #defined

*yawn*

>Several more calls to master.c at various points

Big deal... we have new lfuns in general objects (called from the
parser) as well.  Hell, we had master.c (and /secure) when 3.0 was a
mote in Lars's eye.  AND real security, which (I might add) was and is
better than the primitive uid/euid system you people are lumbered with
now...

>Many many changes to efuns...

And again...

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

If this is all you need to do for a name change, I should have changed
the name of the Shattered game driver approximately a month after I
started rewriting it - about 2 years or so ago.  Hell, Geoff alone has
made more hacks to Shattered's parser than you mention here - and he's
been primarily concerned with LPC!

To be a truly different mud, one should start by having truly different
features.  Despite all the speed hacks, bug fixes, extra efuns, extra
operators and operator overloadings in our language, despite the
extended syntax and type definitions, etc, Shattered will remain an
LPmud until its source language and object and event management
systems - the fundamental features of LPmud - only vaguely resemble
those of LPmud.  That is, while there may still be many similarities
(as MOO resembles COOL), by the time the name gets changed, a lot of
the way things work will have to be very, very different.  Different
enough that you have to think differently to program with them.
Otherwise it's still just LPC, and it's yet another LPmud.

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: Virtual Rooms and Objects (was: Re: MudOS a ripoff?)
Date: 4 Sep 92 00:30:20 GMT
Organization: =CSE Dept., U.C. San Diego

>room1.c:  add_exit("east","some_room:42"); 
>This results in the creation of some_room#23122
>
>room2.c:  add_exit("east","some_room:42");
>How does this room2 know which clone of some_room is the some_room:42.

Well, it does whatever you put into the function :-)  Actually though,
the "standard" controller checks an array to see if element 42 is
already there or not.  The code is very small to do it all.

>This system is nowhere near the flexibility of virtual rooms though, 

True, but I have more important things to do than muck with the
driver when it isn't broken.

-- 
Darin Johnson
djohnson@ucsd.edu
    "I wonder what's taking Guybrush so long..."
Newsgroups: rec.games.mud.lp
From: amylaar@opal.cs.tu-berlin.de (J"orn Rennecke)
Subject: GD update
Organization: Techn. University of Berlin, Germany
Date: Fri, 4 Sep 1992 02:45:40 GMT

host: ftp.cs.tu-berlin.de alias quepasa.cs.tu-berlin.de
filename: /pub/mud/incoming/driver3.1.2.j.zoo
Newsgroups: rec.games.mud.lp
From: meetch@DIALix.oz.au (Mitchell Brandsma)
Subject: Re: Quests was Re: SW Quests
Organization: DIALix Services, Perth, Western Australia
Date: Fri, 04 Sep 92 02:44:34 GMT

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

>Mitchell Brandsma (meetch@DIALix.oz.au) wrote:
>: The quest that sticks out in my mind most of all was slapquest on Hero.  What
>: fun, running around like a madman, saying "SLAP ME!".  After fifty slaps your
>: quest was complete. :)  A real challenge to this would be if it was impossible
>: to say it in any form, thus forcing you to insult others or do something to
>: make them slap you.  :)
>Okay - point to watch out for:
>	you don't want the same person to be able to slap the questor
>	multiple times, ie, 50 different people will need to slap the 
>	person.

That was taken into account. :)  The slapper autoloaded with the list of
everyone who'd already slapped you.  In the later GD versions 1 or 2 lines
of code will do the appropriate checking.

>Apart from that - I like the idea :-)
>Imagine a quest - a player is turned into a toad, and needs to be kissed
>by a player of the opposite gender who has not done the quest yet. When the
>questor is kissed, the kisser is turned into the toad :-)
>(this quest could be easily abused, but would be interesting :)

*chuckle* That's a lot like the old frog curse on vanilla muds.  Hero's
variation was the **IT** curse.  The idea was to run around tagging other
players, thus transferring the curse.  Of course, should you happen to be
**IT** and run into the boogeyman, he'd pound you into a pulp unless you
ran like hell. :)

Another quest they had was for Villains - being simply to kill 50 police and
cut their heads off, give 'em to the dude at headquarters and voila!

Anybody else out there got a player interaction specific quest as opposed to
a "get this, do that and fly off into the sunset" quest ?

>The Wigs of Oz,
>Aaron Wigley	- just another Figment of your Imagination :)

- Meetch - must have dreamt I was on SW last year (meetch@DIALix.oz.au :)
Newsgroups: rec.games.mud.lp
From: meetch@DIALix.oz.au (Mitchell Brandsma)
Subject: wizlist in native 3.1.2.
Organization: DIALix Services, Perth, Western Australia
Date: Fri, 04 Sep 92 03:07:50 GMT
Summary: It works, but how do I exclude player's actions ?

G'day all,

It's not of vital importance, but when a player moves, they have their name
added to the wizlist and the number of actions incremented.  I'm running a
vanilla 3.1.2 in native mode and have had a quick look at wiz_list.c.
Naturally, I only want the wizard who wrote the area to be accredited with
a point for a player doing something, not the player who actually called the
command.  It'd also be nice if wizards executing commands wouldn't effect
the wizlist at all.

Could some kind soul please tell me what I have to do to fix it?  My C isn't
exactly up to scratch (though I reckon my LPC is :).

Thanx in advance,
		  - Meetch (meetch@DIALix.oz.au :)
Newsgroups: rec.games.mud.lp
From: njal@engin.umich.edu (David Schairer)
Subject: Overdrive (and a valuable offer!)
Date: Sat, 29 Aug 92 01:33:46 EDT
Organization: Campus Computing Sites, University of Michigan


As some of you have noticed, Overdrive has been down for the last two days.
This is because it very suddenly lost its site.  The files are all safe
and all we need is a new site to get up and running again.
Now, those of you who know us know what a nice mud we run, and how
agreeable we are as people, and those that don't know that should
be all means take my word for it. :)  Anyway, we're currently using
MudOS 0.8.14 (top of the line stuff), and have a very sophisticated
mudlib and a group of very dedicated players and wizards, so if you
have a machine that's just begging to run a mud, please let me know
at njal@aal.itd.umich.edu or david_schairer@um.cc.umich.edu, or preferably
both, since they seem to die at random times :).

--Talyessin@Overdrive
From: beeman@cats.ucsc.edu (Adam Beeman)
Newsgroups: rec.games.mud.lp
Subject: Re: * PEACE PLEASE! *
Date: 30 Aug 1992 04:21:25 GMT
Organization: University of California; Santa Cruz
NNTP-Posting-Host: am.ucsc.edu


In article <mmcg.715147474@bruce.cs.monash.edu.au> mmcg@cs.monash.edu.au (Mike  Mc Gaughey) writes:
>ins894r@aurora.cc.monash.edu.au (Aaron Wigley [Wigs]) writes:
>>Adam Beeman (beeman@cats.ucsc.edu) wrote:
>>: Ah, aren't you from Shattered Worlds?
>>: 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"...


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

>Mike.
>--
>Mike McGaughey			AARNET:	mmcg@bruce.cs.monash.edu.au
>
>"Head stompin', ass kickin', finger licking nastiness"

Adam, unfortunately also Buddha@TMI

-- 
#include <std/disclaimer.h>
#define NAME	"Adam Beeman"
#define EMAIL	"beeman@{cats, ucscb}.ucsc.edu"
inherit SIGNATURE; // enhanced .sig virus
From: trsnyder@mcs.Drexel.edu (Bob Snyder)
Newsgroups: rec.games.mud.lp
Subject: Re: Driver additions
Date: 1 Sep 92 17:36:02 GMT
	<1992Aug26.005902.829@engage.pko.dec.com>
	<17h567INNs0r@darkstar.UCSC.EDU>
	<UEKLEINF.92Aug27174119@queen.mcs.Drexel.edu>
Organization: GE Aerospace, Advanced Technology Labs, Moorestown, NJ

>>>>> In article <UEKLEINF.92Aug27174119@queen.mcs.Drexel.edu>,
>>>>> uekleinf@mcs.Drexel.edu (Erik Kleinfelder) writes:

Adam> I'm also not telling when I'm releasing it
Adam> because then I'll kick back until right before then, and either release
Adam> a *terrible* hack or have to apologize for it taking extra time (hi 
Adam> Fordan and Gunther! ;-)

Erik>      *smirk* I swear it will be released soon, just let me add
Erik> this feature.  *grin* *kick buddha* *smile*

Erik> Erik (Gunther God@Dragon's Den -- 129.25.7.111 2222)

Erik> P.S.
Erik>      I am sorry, but *IT* will be released soon. *wave buddha*

Sure it will.  :-)  Actually, it should be coming out quite shortly, as we
have been officially open to players for about a month, and we know where
the final big bugs lie.  Bouncing levels, anyone? :-)

Fordan, god, Dragon's Den LPmud (129.25.7.111 2222)
Newsgroups: rec.games.mud.lp
From: guddt@uniwa.uwa.edu.au (David Bennett)
Subject: Re: Driver additions
Organization: University of Western Australia
Date: Wed, 26 Aug 1992 03:26:19 GMT

uekleinf@mcs.Drexel.edu (Erik Kleinfelder) writes:

>     Ok, fine.  But when is a MudOS mudlib still an LPmud, or isn't it.  Can
>it really be claimed that this mudlib which only works with MudOS is an
>LP mudlib or this one that only works with CD.  I do not want anyone to
>ask ANSI to make a standard for LPC, but it would be nice to have a standard,
>like 2.4.5 once was.  Everyone has these great ideas, but no one is willing
>to go for giving them and their code out.  I mean should we benefit the
>mudding community or benifit ourselves and not get known for the great work
>that was done here and there.

You just talked yourself into a corner.  You complain about there being
no standard, then say that CD is a standard and MudOS is a standard.
They are both stanards...  Don't you know the saying?  The great thing
about standards is there are so many to choose from.

If some code is written for the CD driver is will work on all CD based
mudlibs...  If code is written for a MudOS driver it will run on all
MudOS mudlibs...  Sounds like a definition for a standard to me.

MudOS and CD (correct me if I am wrong) both appear to be giving thier
code out.  What do you mean?

This is not like Pascal or C (even though quite often they are not quite
ansi compatible...) there is no standards convention.  I think you would
have troubles forming and enforcing such a thing.  Driver bashing will
go on, mostly because it is fun :)

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.
From: jacob@fy.chalmers.se (Jacob Hallen)
Newsgroups: rec.games.mud.lp
Subject: Re: Darker Realms - The Mudlib
Date: 27 Aug 92 03:45:40 GMT
Organization: Chalmers University of Technology, Physics Departement, Gothenburg

In article <1992Aug20.041547.1704@mcshh.Hanse.DE> amylaar@mcshh.Hanse.DE (Joern Rennecke) writes:
>djohnson@cs.ucsd.edu (Darin Johnson) writes:
>
>>Er, not to get in the way of your wonderful fight, but this reminded
>>me of something that seemed inefficient to me.  Namely, the way
>>swapping works.  What happens (in standard 3.1.2) is that after
>>swapping in some code, the portion it occupied in the swap file
>>can never be used again.  Not really a big deal, but over time,
>>the swap file can get *huge*.  Especially when time to swap is
>>low in order to save memory...
>
>That's one of the gaping holes in the gamedriver...
>About a dozen FIT_STYLES to choose from, and there will be probably one of
>these that makes all other useless...

This sounds unnecessarily complicated. Can't we just from time to time
copy the relevant stuff to an other file and scrap the old one?
I don't think this is a speed critical part of the game. Please
correct me if I'm wrong.

Jacob Hallen