HDTenEightyP/NetNews huggingface dataset:
From: jamie@kauri.vuw.ac.nz (Jamieson Norrish)
Subject: Re: Staging one-shots
Organization: /u/student/jamie/.organization
Date: Mon, 23 Nov 1992 07:24:32 GMT
	<Nov23.021650.86138@yuma.ACNS.ColoState.EDU>

In article <Nov23.021650.86138@yuma.ACNS.ColoState.EDU>
ludwigj@CS.ColoState.EDU (Vilkata (Joe Ludwig)) writes:

     This sounds like fun.  However, it might be a good idea to create
     and assign the characters at least a week before the event so the
     players have plenty of time to familiarize themselves with their
     characters.  (And for any clarifications they might need.)  

Yes; that's certainly what I would do; it would probably be a good
idea to also provide more characters than there are players, so that a
certain amount of choice is given.

     Are you planing to write one?

Well, not specifically. However, the idea is a tempting one. I'm in
the beginning stages of creating a MUCK with a few lp features, and it
would be both a good way to test out a relatively small area, and an
opportunity to let the players have a look around, before opening it
right up. So chances are I'll end up doing something like that at some
stage.

Is there an motive besides pure curiosity for that question? :)

Jamie
Newsgroups: rec.games.mud.admin
From: jgostlin@malloco.Ing.puc.cl (Javier Gostling)
Subject: Re: Arguments in favor of MUDS
Organization: Pontificia Universidad Catolica de Chile
X-Newsreader: Tin 1.1 PL5
Date: Wed, 18 Nov 1992 12:45:57 GMT

Do you want reasons to give to your sysadmin to run a mud or reasons to tell him
why you should be allowed to play them? (I hope this doesn't sound like I'm a
fool).
-Javier Gostling D.
From: mjb@doc.ic.ac.uk (Matthew J Brown)
Newsgroups: rec.games.mud.admin
Subject: Re: ATTN: skill based muds
Date: 19 Nov 92 17:52:16
Organization: Department Of Computing, Imperial College, London.
	<1992Nov17.172434.29119@fy.chalmers.se> <CfF=4_-@engin.umich.edu>
NNTP-Posting-Host: oak23.doc.ic.ac.uk
In-reply-to: guile@engin.umich.edu's message of Tue, 17 Nov 92 15:41:56 EST

In article <CfF=4_-@engin.umich.edu> guile@engin.umich.edu (Kenneth K Lee) writes:
 [ a lot of other stuff ]
>One of the most annoying things about Dikus
>is having to sit, rest and sleep.

Actually I find this is a good thing - it lets me do other things
during my mudding time! While I sleep, I code in another window, or
read news, or something - even play another mud ... it provides natural
breaks in the mudding time.

-Morven
--
| Matthew J. Brown  | Dept. of Computing | If God intended for us to go to   |
| mjb@doc.ic.ac.uk  | Imperial College,  | lectures He wouldn't have created |
| mjb02@cc.ic.ac.uk | 180 Queen's Gate   | double-sided photocopiers.        |
| Morven on Lambda  | LONDON SW7 2AZ     |          -IC RagMag 1991/92       |
Newsgroups: rec.games.mud.admin
From: guile@engin.umich.edu (Kenneth K Lee)
Subject: Re: ATTN: skill based muds
Date: Tue, 17 Nov 92 15:41:56 EST
Organization: University of Michigan Engineering, Ann Arbor

[stuff and babble about skills deleted]

    Ok, so everyone wants to go with a skill based system, and one that 
increases with use.  Great it's realistic, why not?  How about eating and 
sleeping, it's also realistic, lets put it in.  Hey, it doesn't make sense that
you can drink to get healed, lets make it so you have to admit yourself to a
hospital to get healed, and it costs money and you have to have insurance or
you won't get anywhere, and probably end up dead and lying in a gutter
somewhere.  Of course, if you die, that should be it, so lets just rm the
player.o too.  

    Sure, some realism is nice, but lets think about it now, do these things
really add to the fun of the game?  One of the most annoying things about Dikus
is having to sit, rest and sleep.  I don't really care about realism, and I'm
sure most players would be willing to sacrifice some realism for fun, afterall
mudding should be a break from reality..

.i have no sig
From: djohnson@cs.ucsd.edu (Darin Johnson)
Newsgroups: rec.games.mud.admin
Subject: Re: ATTN: skill based muds
Date: 17 Nov 92 19:20:07 GMT
Organization: =CSE Dept., U.C. San Diego

>It
>should be possible, with minimal new coding, to implement a crude
>approximation of the feudal system, and all it's glories. :)

Shhhh...  We've got our peers convinced that we worked hard
and diligently building up a feudal system.  With their lands
and manors, they're already hard to get along with :-)
-- 
Darin Johnson
djohnson@ucsd.edu
    Macintosh - you can buy better, but you can't pay more!
Newsgroups: rec.games.mud.admin
From: baljeual@uther.calvin.edu (Alan Baljeu)
Subject: Re: ATTN: skill based muds
Organization: Calvin College
Date: Mon, 16 Nov 1992 17:36:16 GMT

rossw@ccu1.aukuni.ac.nz (Ross Williamson) writes:



>	At the mud I admin we are just about to upgrade to a new
>driver and with this we are also looking to go to a solely skills based
>system.  
>	We have found that this has it's pros and cons.  One of the
>more interesting ones is how do we now compare players.  With the 
>current xp systems, it's easy the highest xp is tops.  But
>with skills how do we handle it, are some skills better than others
>are they all on the same footing.

>	Any comments?
>Ross

	My question is WHY you would want to compare players.  If you just want 
to see which character is more powerful/skillful, just put their skills
to the test via quests/whatever, and the player that succeeds best is
the best player.  Otherwise the comparison is based on what you think are
good skills rather than what actually are good skills.
From: ludwigj@CS.ColoState.EDU (Vilkata (Joe Ludwig))
Newsgroups: rec.games.mud.admin
Subject: Re: Staging one-shots
Date: 23 Nov 92 02:16:50 GMT
Organization: Thealir Construction Company

In rec.games.mud.admin, jamie@kauri.vuw.ac.nz (Jamieson Norrish) writes:
>If I were to do this sort of thing, I'd like to have, maybe,
>seven-fifteen guaranteed players, who could all play for the entire
>duration. Then, I'd design the "plot" up to where the adventure would
>begin, and then create characters. That is, I'd create the character
>backgrounds, personality quirks etc., appearance, etc. Then all the
>players need to do is read over their character file and go.
  This sounds like fun.  However, it might be a good idea to create and assign
the characters at least a week before the event so the players have plenty of
time to familiarize themselves with their characters.  (And for any 
clarifications they might need.)  

  Are you planing to write one?
-- 
+--------------------------+-------------------------------------------------+
| Vilkata, the Dark King   | "It's better to rule in hell, than serve in     |
| ludwigj@cs.colostate.edu |  Heaven."  -- Paridise Lost??                   |
| Vilkata@Most MUCKs       | "Maybe she sat on something sharp." -- Piper    |
Newsgroups: rec.games.mud.admin
From: sec1@Ra.MsState.Edu (Stephen E. Canfield)
Newsgroups: rec.games.mud.admin
Subject: Diku Help
Date: 16 Nov 92 15:58:12 GMT
Article-I.D.: ra.1992Nov16.155812.8942
Organization: Mississippi State University


I'm running a diku mud, and it has crashed a couple of times in 
the last few days with the following error:

CHECKPOINT shutdown: tics not updated

Any clues as to why this happened, and how to fix it?

Thanks...

--steve
Newsgroups: rec.games.mud.admin
Subject: Re: ATTN: skill based muds
From: rossw@ccu1.aukuni.ac.nz (Ross Williamson)
Date: Sun, 15 Nov 1992 19:48:21 GMT
 <BxLpCM.L6J@watserv1.uwaterloo.ca> 
 <Nov13.012516.33674@yuma.ACNS.ColoState.EDU> <1992Nov13.063158.20461@leland.Stanford.EDU> <1992Nov13.134807.1@ulkyvx.louisville.edu>
Organization: University of Auckland, New Zealand.



	At the mud I admin we are just about to upgrade to a new
driver and with this we are also looking to go to a solely skills based
system.  
	We have found that this has it's pros and cons.  One of the
more interesting ones is how do we now compare players.  With the 
current xp systems, it's easy the highest xp is tops.  But
with skills how do we handle it, are some skills better than others
are they all on the same footing.

	Any comments?

Ross
From: djohnson@cs.ucsd.edu (Darin Johnson)
Newsgroups: rec.games.mud.admin
Subject: Re: Wizardhood on LPMuds.
Date: 22 Nov 92 02:36:59 GMT
Organization: =CSE Dept., U.C. San Diego

>>killing (which in this situation is more common than "monster" killing,
>>and, interestingly enough, VERY rare, as a player who tries to kill lots of
>>other players is inevitably going to have the local lord (a player character)
>>sending out people to bring him or her in)

Well, I don't think just having a local lord solves much.  You're
still going to have the player-killer complain that his/her rights
were violated.  The same situation exists on LPmuds, but that hasn't
solved anything.  The big win in MUSH/etc is that it is much easier to
just call the actions obnoxious and kick the player/site off.

Apparently, even though getting killed in an LPmud is much more
disruptive than on a MUSH, the perpetrators are less willing to
accept that they are being obnoxious, and come up with all sorts
of bizarre justifications...

-- 
Darin Johnson
djohnson@ucsd.edu  --  How come my mind went off for lunch before I did?
Newsgroups: rec.games.mud.admin
From: jort@swi.psy.uva.nl (Jort Okhuijzen)
Subject: Re: help
Organization: Social Science Informatics
Date: Thu, 19 Nov 1992 10:50:50 GMT

s14096jb@UMASSD.EDU writes:

>hello
>I need help.  I'm trying to get on a mud but I have no idea how.
>I would appreciate some detail information.  From anyone such things
>as how to get on mud or even how to get into discussion groups.
>Please e-mail any help to me.  THANK YOU.

You found the answer yourself:
get yourself connected to a mud (most people use telnet) and type help.
et voila!
:-)

Jort (KoBra: telnet mudserver.et.tudelft.nl 8888)
From: un032233@wvnvms.wvnet.edu
Newsgroups: rec.games.mud.admin
Subject: Re: ATTN: skill based muds
Date: 18 Nov 92 17:25:03 GMT
Organization: West Virginia Network for Educational Telecomputing

As fas as it being "impossible" to code a skill based MUD, check out DalMOO -
ahab.eecs.nwu.edu 17971.  We're still in betatest, but we have a
fully-functioning skill system, with NO LEVELS and NO EXP.  Characters are
based on a set of 10 Attributes and a variable number of skills.  Skills go
up ONLY by use - and yes, two players can repeatedly steal from one another
to pump up their Steal skill, but isn't that realistic?  If I want to become
a better pickpocket, I'll get my friend to hold still while I try to lift his
wallet. :)  Anyway, it HAS been done; log in to see exactly how.

Gilmore
Newsgroups: rec.games.mud.admin
Subject: Dragons Dens Mudlib
From: rossw@ccu1.aukuni.ac.nz (Ross Williamson)
Date: Mon, 23 Nov 1992 01:54:49 GMT
Organization: University of Auckland, New Zealand.

	Is it coming or gone ??  I haven't heard anything from
Dragons Den people about it...  we are patiently waiting on it's release
so we can up grade our driver and lib to something new but we are running 
out of time..... can anyone suggest any alternatives??

Ross
Newsgroups: rec.games.mud.admin
Subject: Re: Wizardhood on LPMuds.
From: jamie@kauri.vuw.ac.nz (Jamieson Norrish)
Date: Mon, 23 Nov 1992 07:32:49 GMT
 DU><JAMIE.92Nov23140759@kauri.vuw.ac.nz><Nov23.020052.5024@yuma.ACNS.ColoState.EDU>
Organization: /u/student/jamie/.organization

In article <Nov23.020052.5024@yuma.ACNS.ColoState.EDU>
ludwigj@CS.ColoState.EDU (Vilkata (Joe Ludwig)) writes:

   The problem with giving PCs a history is that at least some of the
   NPCs would need to either know about or be connected with that
   history.

True; a very real and legitimate problem. It would of course be ideal
to not need NPCs - that is, have enough players on at all times so
that they fill all "vacant spots", but that's not realistic. It might
be possible though to relegate most NPCs to a background position.
Then, it might only be necessary to define three modes of behaviour
for them, depending on whether they like, dislike, or are indifferent
to the PC in question.

   This could work, despite the work.  A library of histories could be created,
   and new players could be assigned a role.  (Either at random, or by looking
   through and selecting the one they like the best.)

That's one possibility; however, for characters created after the game
has been running a while, I would prefer a more interactive approach,
whereby the player talks to a god/wizard, and together they work out
the character, with appropriate consultation with players as necessary.

One area in which I would require selection from a list (perhaps with
suggestions considered) is names. Character names have to be one of
the biggest stumbling blocks for anyone trying to get a sense of what
a MU* world is like, since they range from Gandalf to Hotbabe, with
everything in between. Not for me, thanks.

Jamie
From: ralp@db.erau.edu (Ralph E. Bugg)
Newsgroups: rec.games.mud.admin
Subject: Re: Diku Help
Date: 16 Nov 1992 16:34:16 -0500
Organization: Embry-Riddle Aeronautical University, Daytona Beach, FL USA
NNTP-Posting-Host: eta.db.erau.edu

sec1@Ra.MsState.Edu (Stephen E. Canfield) writes:
>I'm running a diku mud, and it has crashed a couple of times in 
>the last few days with the following error:
>
>CHECKPOINT shutdown: tics not updated
>Any clues as to why this happened, and how to fix it?
>--steve

Well the error your getting is coming from signals.c in the 
routine checkpointing()...which gets called when there is a 
SIGVTALRM signal being sent to the process (which should be
every 15 minutes)  the problem is that the variable tics is
somehow not being updated, which should be done in comm.c
a ways down in the game_loop().  This is where I'd check first
to see if there is any reason it's not being updated.
My code around that area looks like:

                if (pulse >= 2400) {
                        pulse = 0;
                        if (lawful)
                                night_watchman();
                        check_reboot();
                }

                tics++;        /* tics since last checkpoint signal */
        }
} /* end of game_loop() */


Well I hope this helps you somewhat, I know it's not much, but
without seeing your code this is about all I can do
-- 
+-------------------------------------------------+------------------------+
|You can get more of what you want with a kind    |   ralp@db.erau.edu     |
|word and a gun than you can with just a kind word|ralp%invalid@db.erau.edu|
+-------------------------------------------------+------------------------+
From: guddt@uniwa.uwa.edu.au (David Bennett)
Newsgroups: rec.games.mud.admin
Subject: Re: ATTN: skill based muds
Date: 16 Nov 1992 02:14:14 +0800
Organization: The University of Western Australia
NNTP-Posting-Host: uniwa.uwa.edu.au

danic@sciborg.uwaterloo.ca (Steve) writes:
>Hi everyone.
>Just a note.  I started this discussion recently because i don't feel
>experience (XPs) should be involved in the development of skills. Experience
>comes from killing stuff.  No thief should learn to pick pockets just
>because he killed a bunch of stuff.

Well...  We thought about implementing the system you just described,
but decieded against it.  We used the xp system as a compromise.  I like
the idea of being able to choose your skills more.  Sure xp is
abstract etc.  But, think of it more as a method of forceing you
to go up levels slowly.  The entire system is abstract anyway.  Gaining
of skills in a guild of some sort is training in the particular skill.

I sort of like the rolemaster system for doing this.  Where you choose
your skills before you go adventuring and then when you get to the
next level you get the actuall skills themselves, where you have been
assumed to be training in them on the way.  This could also be conversely
thought od as a reverse of the chooseing when you get the xp process.
The life of an adventurer in a mud is fairly boring anyway.  One would
hope the poor character gets some time off now and then.  How do you
put the fact that players log off into your secario?  Anyway.  Realism
is one thing.  But, makeing it both flexible and easy to play (Though,
it sounds like I might have failed there :), are higher prioritys.

Shrug, each to his own.  We decied on the skill system used at
Discworld (and forgotten realms ;).

>I like to have numbers to guage my progress too.  That's why i like the
>skill point system where players can see all their skill percentages.  I
>much prefer that to some abstract number (XPs) representing generic
>experience learned from killing stuff.

>On a positive note, I've heard that Dragon's Den (129.25.7.111 2222) and
>DartMud (fermat.dartmouth.edu 2525) have made some progress along this
>theme.  I haven't checked them out yet though.

Shattered Worlds have also done this years and years ago...
:)
It is true though, they did this a year or so ago.

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: linnoise@bigboy (PFTTCZ)
Newsgroups: rec.games.mud.admin
Subject: NEW!! Mud newsletter
Date: 17 Nov 92 10:32:49 GMT
Organization: Temple University

I will be maintaing weekly mud newsletters.  I've selected Diku muds to
to start out with so I've posted a more detailed message in mud.diku.
News letters for other types of muds will follow after the first 4 issues
of DikuNews.

The newsletter will allow people to easily find the type of mud they are
looking for because of the format. New users will like the summaries and
veterans will like the rumors sections provided for each mud because it
will contain changes, upcoming quests, and other info.

Please send me mail with the information I've requested in my mud.diku post
about the mud you are running (it doesn't have to be diku).  I will be
working on non diku newsletters as I send out the first few issues of DikuNews.

---Linenoise
From: whale@leland.Stanford.EDU (Stephen Schmidt)
Subject: Re: Wizardhood on LPMuds.
Organization: DSG, Stanford University, CA 94305, USA
Date: Mon, 23 Nov 92 01:51:30 GMT

In article <ANIPA.92Nov23031459@kaarne.cs.tut.fi> anipa@cs.tut.fi (Niilo Neuvo) writes:
>And everything you mentioned has already been done on the mud I run.

Planning to move to Australia?   :)
-- 
Steve Schmidt			<><		   whale@leland.stanford.edu
I can no longer sit back and allow Communist infiltration, Communist
indoctrination, Communist subversion, and the international Communist
conspiracy to sap and impurify all of our precious bodily fluids!
From: leet@acsu.buffalo.edu (Brian D. Leet)
Newsgroups: rec.games.mud.admin
Subject: Re: Wizardhood on LPMuds.
Date: 22 Nov 92 07:57:10 GMT
Organization: UB

In article <1992Nov22.070928.2078@leland.Stanford.EDU> whale@leland.Stanford.EDU (Stephen Schmidt) writes:
>In article <1992Nov22.050757.6240@midway.uchicago.edu> tuff@midway.uchicago.edu writes:
>>In an environment where combat exists in a
>>vacuum, I'd agree, resetting would be necessary. However, coupled with
>>the ecology, I think that this wouldn't be so much of a problem. Remember
>>that once the ecology system is running, "reproduction" of the beasties
>>should make up for any losses (though I must say that I don't envy
>>E.W.Bright's (Nerine) job of trying to get the ecology into a working
>>balance. ;-) )
>>
>Actually, it shouldn't be that hard. Make sure that the rate at which
>monsters reproduce falls as the number of monsters rises, perhaps by
>requiring them to eat limited food, or by introducing a direct dependency
>of reproduction rate on numbers. Easy to do with the children() efun on 
>LP's, don't know about others.
>The main problem I see is that as more and more monsters reproduce the
>system will slow down making it harder for players to kill them. You
>should probably prevent this by coding an upper bound on the number of
>monsters, and tweaking the parameters of reproduction until you don't hit
>it very often. You'll also need to tweak reproduction rates as player
>activity varies.

I think that is exactly half the problem Moby ( :-) ).  To me a more likely
concern stems indirectly from this but is more likely to occur.  That is the
complete elimination of a species from the mud.  In order to have a large 
enough population on the mud of each species that even when players were on
rampage they wouldn't kill all of a species off would be nearly impossible.
Especially for the larger or more unique species.  Unless you have some 
artificial way of restocking the population the actions of a single character
could easily lead to the extinction of a species.  Especially if you have
species competing against each other (which I hope you would in a real
ecology. 
Artificial restocking are acceleration of birth rates would lead to another
problem:  If as a player I am able to kill off all the goblins on the mud
(for example) except for three or four in a single room I can then stand
at the exit knowing they'll pop out babies at a phenominal rate which I can
kill as the leave the room (assuming everything would have some form of 
mobility).  This should be an easy and relativley risk free way of upping the
xp.  I am not saying balancing the ecology can't be done, just that its not
likely to be so easy as you suggest.

>Mobydick@TMI
					Brian @ UD and even TMI2 sometimes
Newsgroups: rec.games.mud.admin
From: stine@chopin.psu.edu (Jeffrey Stine)
Subject: Re: Diku Help
Organization: Penn State University
Date: Tue, 17 Nov 92 04:15:13 GMT

In article <1e944oINN10e@eta.db.erau.edu> ralp@db.erau.edu (Ralph E. Bugg) writes:
>sec1@Ra.MsState.Edu (Stephen E. Canfield) writes:
>>I'm running a diku mud, and it has crashed a couple of times in 
>>the last few days with the following error:
>>
>>CHECKPOINT shutdown: tics not updated
>>Any clues as to why this happened, and how to fix it?
>>--steve
>
>Well the error your getting is coming from signals.c in the 
>routine checkpointing()...which gets called when there is a 
>SIGVTALRM signal being sent to the process (which should be
>every 15 minutes)  the problem is that the variable tics is
>somehow not being updated, which should be done in comm.c
>a ways down in the game_loop().  This is where I'd check first
>to see if there is any reason it's not being updated.

The code in signals.c that sets the signal alarm is there for
deadlock protection.  Unless you have removed the code in comm.c
where the variable tics is updated (done each game loop) you have a
deadlock or infinite loop somewhere in your code. It is also possible,
albeit unlikely, that for some reason your server is not getting its
timeslice... not spending any time in the run queuea.. which would
probably indicate a problem with select() sleep.
I would look for I/O problems or a faulty loop in newly installed code.
(Though it may also be something older)
Without extensive debugging this problem can be hard to define.