HDTenEightyP/NetNews huggingface dataset:
Newsgroups: rec.games.mud.admin
Subject: Main Diffs Between MudOS and -DR -CD etc
From: rossw@ccu1.aukuni.ac.nz (Ross Williamson)
Date: Wed, 11 Nov 1992 19:00:51 GMT
Organization: University of Auckland, New Zealand.


I have read all the posts in rec.games.mud.* about the praises and 
worries over all the different sorts of mud drivers that are around
But what I would really like to know is
	" What are the *main* differences between the drivers, with
	MudOS on one hand and the other modified -DR -DD -CD 
	distributions of Lars' driver?"

	Please ***Don't*** flame me about lumping all the special 
-DR -DD -CD 's together I really just want the hard facts about the
differences.  I am planning to upgrade from a 2.4.5 mudlib with a -DR
distribution driver and was going to just move straight to native mode
but if MudOS is better for us then I will move to that.

	Could someone please light the candle of understanding when it 
comes to the drivers for me.

TIA
Ross ( Belarion @ around here somewhere )
+-----------------------------------+---------------------------+
| Name   : Ross Williamson          | Do you remember when sex  |
| E-Mail : rossw@ccu1.aukuni.ac.nz  |  was safe and skydiving   |
| Auckland University, New Zealand  |      was dangerous?       |
+-----------------------------------+---------------------------+
|   Of course these opinions are my own and thank !! for that   |
+---------------------------------------------------------------+
Newsgroups: rec.games.mud.admin
From: danic@sciborg.uwaterloo.ca (Steve)
Subject: Re: ATTN: skill based muds
Keywords: skills
Organization: University of Waterloo
Date: Thu, 12 Nov 1992 11:31:34 GMT

With regard to skills which increase based on usage instead of exp:
To prevent cheating from guys with clients, you can take a few easy steps.

Set up a maximum total number of skill points any player can have.
Where there may be 50 skills, the total number of skill points may be 250.
Then anyone who sets up a client to give them a high number in climbing is
not being very productive.

Implement a penalty for suckers.  Anyone who gets pickpocketed without
noticing should lose some skill points from their awareness or something.
This prevents players from cheating with the help of friends.

Make the chance of skill improvement dependant on the difficulty of the
task, or level of the victim.  A player who repeatedly kills squirrels,
won't improve his combat skill very much.

...Steve.

Newsgroups: rec.games.mud.admin
From: donaldc@ug.cs.dal.ca (Donald Chisholm)
Subject: GateWay LPmud
Organization: Math, Stats & CS, Dalhousie University, Halifax, NS, Canada
Date: Sun, 8 Nov 1992 18:48:12 GMT

	After reading Cynic's (Walt's) posting I thought I should get off my 
butt and post something for you folks who have been looking for GateWay
(129.173.4.4 6969) the past few months.

	Needless to say GW is down.  I havn't actually lost the Dalhousie 
site, but can't quite justify putting the mud back and risk running into the
resources problems the existed before I shut it down.

	None of the source (i.e. wizard files, mudlib source) is in danger of
being lost.  I can't say this is the end of GW, as I'm sure it won't be, but
if there are any wizards out there who wish to remove their source from the
archives mail me and I'll do with it whatever you like.  This does not apply
to whole domain source directories.  Any Lords who wish the source to their
entire domain must somehow get the permission of the wizards belonging to
that domain.  An e-mail message from each would be sufficient.

	If anyone has any questions, comments, complaints or concerns don't
hesitate to e-mail me at donaldc@ug.cs.dal.ca.

Don Chisholm
(a.k.a BaDaXe - GateWay Admistration)
From: beeman@cats.ucsc.edu (Adam Beeman)
Newsgroups: rec.games.mud.admin
Subject: Re: ATTN: skill based muds
Date: 12 Nov 1992 08:44:32 GMT
Organization: University of California; Santa Cruz
NNTP-Posting-Host: am.ucsc.edu
Keywords: skills


In article <1992Nov12.013853.16076@leland.Stanford.EDU> snarflrd@leland.Stanford.EDU (NM156) writes:
>In article <1992Nov11.173945.1299@leland.Stanford.EDU> whale@leland.Stanford.EDU (Stephen Schmidt) writes:
>>In article <BxJIoo.3D8@watserv1.uwaterloo.ca> danic@sciborg.uwaterloo.ca (Steve) writes:
>>>Has there ever been any thought amongst mud admin toward changing a skill
>>>system so they go up automatically?

>>MudOS mudlib 0.9 will implement this. Not exactly as you describe it, but
>>pretty darn close.

>in a straight use = increase system, there will always be too many twits who
>just set up their client to perform the action over and over, then go out for
>tea  (or do it manually ... just to increase)

Rest assured, this HAS been thought of.  My personal preference is to have 
your skills in combat go up as you get hurt, for example, which means if you 
get hurt repeatedly, you DIE.  In an ideal system, if you focus on one thing
for too long you begin to suffer from not paying attention to the other things.

>i remember, this was how it worked on the old computer game, Wasteland.  there
>was a sand-pile that you could climb over and over until your 'climb' skill
>maxed out for all players... silly and pointless, but so are most players
>in a given MUD.

Yeah, this is a good point you bring up here, and it's an important one.
I'll be sure we try to come up with ways of preventing people from abusing
it.  Note that a lot of muds you gain skill just by mindlessly banging against
monsters anyhow... 

Adam (Buddha@tmi-2)

>-- 
>Ingredients: chopped pork shoulder with ham, salt, water, sugar, sodium
>             nitrate, snarflrd@leland.stanford.edu


-- 
-------------------------------------------------------------------------------
 From the Mind of Adam Beeman       || Flames:      root@localhost
 #include <std/disclaimer.h>        || other stuff: beeman@cats.ucsc.edu
-------------------------------------------------------------------------------
 Yeah, I'm into MUDs, UNIX, philosophy, art, networking, and saving the earth,
         the Information Age is here and my head is too small...
-------------------------------------------------------------------------------
Newsgroups: rec.games.mud.admin
From: fsjjp@acad3.alaska.edu (James Pietan)
Subject: Need
News-Software: VAX/VMS VNEWS 1.41.UAC
Organization: P.A.R.A.N.O.I.A
Date: Fri, 13 Nov 1992 15:51:00 GMT

        Need basic 2.4.5 adv_guild.c
        I would also like to know where I can pick up an advanced
        soul.c .. one with greater capabilities than that offered      
        by the 2.4.5 mudlib.

Stuart_Hall
aka Corwin
#include BITNET <FSJJP@ALASKA.BITNET>
#include EMAIL <FSJJP@ACAD3.ALASKA.EDU>
Newsgroups: rec.games.mud.admin
From: austin@cs.wisc.edu (Klaas)
Subject: Re: Guru help needed. (More details)
Organization: U of Wisconsin CS Dept
Date: Thu, 5 Nov 1992 19:09:08 GMT

In article <SCG.92Nov5103318@mentor.cc.purdue.edu>, scg@mentor.cc.purdue.edu (Kelly Martin) writes:
|> 
|> the following sequence might be roughly what you need:
|> 
|> pipe(p1);
|> pipe(p2);
|> if (!vfork()) {
|> 	dup2(p1[0],0);
|> 	dup2(p2[1],1);
|> 	close(p1[1]);
|> 	close(p2[0]);
|> 	exec(/*spell program*/);
|> }
|> close(p1[0]);
|> close(p2[1]);
|> /* write request to p1[1] */
|> /* read response from p2[0] */
|> 
|> you can use select() on p2[0] to do appropriate nonblockingness.

This does seem like the only portable way to accomplish your task.  I grabbed
PennMUSH 1.50pl4 and looked at the dispatch mechanism.  It seems (I could
certainly be wrong here, as I have not fully studied the code) that the
socket commands are parsed and placed on a central queue.  This queue is then
serviced at fixed time intervals.  It appears that a command is executed
completely before moving on to other commands or select()'s, in other words,
commands are a single transaction.  To prevent mush slowdown, you need to also
support split transactions (start command transaction, and end command
transaction.)  I did not see this in the code, and if added, it should be
done in a generally useful manner.  There are a lot of ways to do it --
here's one suggestion...  Add the following fields to the per-player/socket
structure (some i'm sure are already there):

	enum { Complete, Waiting } state;
	int socketFd;
	int waitFd;
	void (*tailFn)();

To create a split transaction internal function, like '@spell'...

	1) dispatch as usual to the spell_fn() internal implementation
	2) send whatever out the spellFd file descriptor
	3) change the player struct var state to Waiting
	4) plug the spellFd into the tailFd
	5) plug spell_finish_fn() into tailFn
	6) return to the dispatcher
	.
	.
	7) on all dispatches match socket data as follows

	    if (player->state == Waiting) {
		if (player->waitFd == socketFd) {
		    (*player->tailFn)(); /* finish the transaction */
		    empty_socket_buffer(); /* may have missed events here */
		}
	    }
	    else if (player->state == Complete && player->socketFd == socketFd)
		queue_commands()

	   where socketFd is the socket with new data, returned from select().
	   Note that the order of the two checks are important, as the waitFd
	   must be serviced before socketFd, also, the socketFd for the player
	   executing the split transaction must be processed after return of the
	   waitFd data, as we may have ignored earlier select events to ensure
	   serial semantics of the mush code.
	.
	.
	8) reset the state to Complete at the end of tailFn (do this when you
	   have gotten enough data to satisfy the @spell, this may take several
	   trips into spell_finish_fn())

Although I haven't the time to completely think this through, it does seem that
with proper packaging, it would be easy to integrate any external program.

Todd Austin, Klaas @ { nowhere currently ;) }
Newsgroups: rec.games.mud.admin
From: whale@leland.Stanford.EDU (Stephen Schmidt)
Subject: Re: ATTN: skill based muds
Keywords: skills
Organization: DSG, Stanford University, CA 94305, USA
Date: Wed, 11 Nov 92 17:39:45 GMT

In article <BxJIoo.3D8@watserv1.uwaterloo.ca> danic@sciborg.uwaterloo.ca (Steve) writes:
>Has there ever been any thought amongst mud admin toward changing a skill
>system so they go up automatically?
>
MudOS mudlib 0.9 will implement this. Not exactly as you describe it, but
pretty darn close.
Later versions of the mudlib will probably also include an XP system for
those traditionalists out there...
-- 
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: behrenss@Informatik.TU-Muenchen.DE (Soenke Behrens)
Newsgroups: rec.games.mud.admin
Subject: Re: Guru help needed.
Date: 5 Nov 92 10:42:57 GMT
Organization: Technische Universitaet Muenchen, Germany
Originator: behrenss@hphalle7i.informatik.tu-muenchen.de


In article <1992Nov4.075817.24657@netcom.com>, urimud@netcom.com (James M. McKenzie) writes:
|> alansz@cogsci.Berkeley.EDU (Alan Schwartz) writes:
|> : I have need of advice from a Unix/C guru, and I prefer to turn to the
|> : community of MUSHfolk, particularly given the nature of my problem.
|> : I'd like to have my MUSH (which happend to be PennMUSH 1.50pl4, but
|> : that's not important) spawn off a simultaneous child process which
|> : will (1) not suspend the parent process, and (2) not create a whole
|> : copy of the parent process, like fork(), since that's hard on the CPU.
|>   I think system() will give you what you are looking for.   Anyone wish
|>   to correct me on this?

Yup. system() halts the calling process and passes a command to the shell.
If you want a subroutine as your child process, I have to admit I have no
idea on how to do that (portably). If you don't care about cluttering your
disk ;), you could execve (or similar) the routine, using pipes or such to
pass information.

Hope that helped.
Soenke

-- 
===========================================================================
More than silver, more than gold, I need   !    behrenss@informatik.
electricity. I need it for my dreams.      !    tu-muenchen.de
(RACTER)                                   !  FIDO: 2:246/13 Soenke Behrens
From: trsnyder@mcs.Drexel.edu (Bob Snyder)
Newsgroups: rec.games.mud.admin
Subject: Re: ATTN: skill based muds
Date: 12 Nov 92 23:50:45 GMT
Organization: Drexel University, Dept. of Math. and Comp. Sci.

>>>>> In article <BxJIoo.3D8@watserv1.uwaterloo.ca>,
>>>>> danic@sciborg.uwaterloo.ca (Steve) writes:

Steve> Has there ever been any thought amongst mud admin toward
Steve> changing a skill system so they go up automatically?

Dragon's Den does this.  There are no experience points, only skill
points, which increase with use.  Levels are determined by your skills
proficency.  The more you use a weapon or spell, the better you get at
it. 

Steve>    Guilds could still exist, but instead of being shopping
Steve> centers for skills, all they would provide is a greater rate of
Steve> learning in certain skills.  Of course, to belong to a guild
Steve> you would have to pay a union type fee as a percent of your
Steve> profits.  Races also could affect the rate of learning for

This is what we have in mind for guilds, once we get a chance to
actually write them.  :-)  Guilds would offer better training, or
skills that aren't availble to be learned elsewhere.  The player
would, of course, have to give something up to join the guilds, and it
would be up to the different guilds to determine if they will let
members be parts of different guilds....

Fordan, god, Dragon's Den LPmud (129.25.7.111 2222)
Newsgroups: rec.games.mud.admin
From: jort@swi.psy.uva.nl (Jort Okhuijzen)
Subject: KoBra arches
Summary: Change of power on KoBra lp-mud
Keywords: KoBra Kobra kobra arches
Organization: Social Science Informatics
Date: Fri, 13 Nov 1992 09:25:37 GMT


On behalf of the former archgroup of KoBra mud I hereby officially announce
the event that took place at 2 november 1992: all arches were demoted.
Delay for this announcement, for those I couldn't reach by e-mail, has to
do with the fact that this change took place while I was on short leave.
As I write this the new arch group has been installed, among that group
one of the old group, Exodor, remained arch.

Jort, ex arch of Law, KoBra mud
From: rickert@cco.caltech.edu (Keith Warren Rickert)
Newsgroups: rec.games.mud.admin
Subject: Re: siteban() for DikuMUD
Date: 7 Nov 1992 00:30:00 GMT
Organization: California Institute of Technology, Pasadena
NNTP-Posting-Host: sandman.caltech.edu

Getting the host ip of the foreign site should
be easy, although I have never looked at Diku internals,
so they may have managed to obfuscate it in some way.
However, getting a username is not really possible unless
the other site is running an RFC 931 (?) style authentication
server, which not common enough that you will be able to rely
on it.
Keith
Newsgroups: rec.games.mud.admin
From: scg@mentor.cc.purdue.edu (Kelly Martin)
Subject: Re: Apocolypse's Demise
Reply-To: scg@mentor.cc.purdue.edu
Organization: Gender Anarchists United
	<SCG.92Oct27120825@mentor.cc.purdue.edu> <9111@blue.cis.pitt.edu.UUCP>
Distribution: usa
Date: Thu, 5 Nov 1992 16:07:32 GMT

astinus+@pitt.edu (Mark E Porterfield) writes:

>While no real criminal act occured there was a serious breech of
>ethics here.

I have no doubt of that.

>Files belong to users.  This is personal property as long as they are
>not directly related to the work the person is being payed to do by
>an organization.

This claim is dubious.  The company I used to work for claimed that
any intellectual property (which would possibly include files) created
using its facilities belonged to it, not the creator.  That was part
of the patent agreement I had to sign in order to work there.  Many
universities do the same for their faculty and staff involved in
research work.

>The User accounts are property of the institution the person works
>for or school he attends.  It is ok for person D to disable
>Terminator's acount but it is NOT ok to in ANY way manipulate his
>files without his consent.

Ethically, probably.  Legally, there's no grounds for this position
(unless person D is an agent of the GOVERNMENT).

>It IS illegal for any PRIVILAGED user to access another users files
>without due cause.  Here we have not estabished due cause for person
>D.

Again, only if person D is an agent for the GOVERNMENT.  Probable
cause only applies to the government.  Private-sector employers have
no such concern.

>Therefore, we might have a possible criminal act.  I admit it is very
>grey but very possible.  No it is not computer trespass but it is non
>the less very administratively very unethical at the very very least!
>If this where to occure with anyone I employed...They would be out of
>work very fast.

Again, I have no doubt that this represents a breach of ETHICS, but
not of law (except possibly contract, if person D acted in ways which
exceed his contract of employment).
--
You're damn right we need a rational code of morality and ethics.  But not
much progress can be made in that direction while we've still got a majority
ranting about gods, devils, souls, and absolute morality, and using an ancient
book written by ignorant nomads as a guide.  -- Doug Graham (dgraham@bnr.ca)
Newsgroups: rec.games.mud.admin
From: mcrocker@titan.ucc.umass.edu (MATTHEW S CROCKER)
Subject: siteban() for DikuMUD
Organization: University of Massachusetts, Amherst
Date: Fri, 6 Nov 1992 16:51:29 GMT

Hello,

 Lanewood and I are trying to set up our MUD on the school machine
we currently have the site-admins permission to run the MUD, but he
would like to have it be an on-cmapus MUD for now.  I'm looking
for the siteban code.  Anybody got it hanging around...

I looked in comm.c and saw where the new connection is created
but I cannot for some reason get the connecting clients name

I would like to be able to get the username@host.name.IP.number
so we could ban one user of a whole system..

I'm currently thinking about adding a security check with the player login
that checks to make sure you are logging in from the same location
(useful for implementor's)  My plan is to only allow a login for
Gandaff  from my account (mcrocker@titan.ucc.umass.edu) I know
that this can be done.. Is anybody doing it?

Anyhelp will be apreciated,

advTHANKSance

-Matthew S. Crocker
aka (Gandaff of Titania)
mcrocker@titan.ucc.umass.edu

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
- Matthew Crocker
s1949782@titan.ucc.umass.edu <-  Til 1/1/93
mcrocker@titan.ucc.umass.edu <-  Til I Graduate  LOOOOOOOONNG TIME
Newsgroups: rec.games.mud.admin
From: whale@leland.Stanford.EDU (Stephen Schmidt)
Subject: Re: ATTN: skill based muds
Keywords: skills
Organization: DSG, Stanford University, CA 94305, USA
Date: Fri, 13 Nov 92 06:31:58 GMT

In article <Nov13.012516.33674@yuma.ACNS.ColoState.EDU> ludwigj@CS.ColoState.EDU (Vilkata (Joe Ludwig)) writes:
>In rec.games.mud.admin, danic@sciborg.uwaterloo.ca (Steve) writes:
>>Set up a maximum total number of skill points any player can have.
>>Where there may be 50 skills, the total number of skill points may be 250.
>>Then anyone who sets up a client to give them a high number in climbing is
>>not being very productive.
>  This works for weak players, but some guy who plays a fairly well-rounded
>character will legitimately run out of skill points.

You can handle this by making the constraint non-linear. Place a restriction
on the sum of the squares of the skills, or something like that.
>>
>>Implement a penalty for suckers.  Anyone who gets pickpocketed without
>>noticing should lose some skill points from their awareness or something.
>>This prevents players from cheating with the help of friends.
>  I don't like this so much.  How about automatic retaliation? ;)

I kinda like it... The current system is set so that if you steal an item
there is a chance of a fight starting, whether you succeed or not. Of course,
two players can always just break off the fight so this isn't a real
deterrent to abuse, but it does make things harder to automate. I hadn't
thought about the possibility of ducking the victim's skill but it is
a clever one.
>>
>>Make the chance of skill improvement dependant on the difficulty of the
>>task, or level of the victim.  A player who repeatedly kills squirrels,
>>won't improve his combat skill very much.
>  Absolutely.  Base the amount of increase or the chance of increase on the
>chance they had to perform the feat.  If they had a guarantee, or a very
>high chance, they should get almost nothing.

We discussed several methods of doing this. We ended up with the following:
the chance of a combat skill improving is equal to 4*p*(1-p) where p is
the hit chance. Thus, if your hit chance is either 0 or 1 your skill does
not improve. At p=0.5 you always get increase, and the probability of an
increase is quite high for p between .2 and .8.
The main drawback of this is cpu use; this all has to be done in heart_beat.

>  It is also  good idea to give small increases for failure.  If you shoot
>your bow at that rock enough times, you will eventually get better.

We're planning to have training facilities to represent this kind of thing.
Not so much that time will be the limiting factor, but gold will, and it
takes time to go get more gold...

Mobydick@TMI
-- 
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!
Newsgroups: rec.games.mud.admin
From: mcrocker@titan.ucc.umass.edu (MATTHEW S CROCKER)
Subject: JudyMUD  sources,
Organization: University of Massachusetts, Amherst
Date: Thu, 12 Nov 1992 14:04:47 GMT


Where can I get the sources for Judy??/ we currently have a MUD
running but it would be nice if we didn't have to re-invent the wheel.
please e-mail replies to mcrocker@titan.ucc.umass.edu  If you want to
uuencode it and email it to me (yeeech) then send it to :
macon@titan.ucc.umass.edu

Thanks

-Matt
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
- Matthew Crocker
s1949782@titan.ucc.umass.edu <-  Til 1/1/93
mcrocker@titan.ucc.umass.edu <-  Til I Graduate  LOOOOOOOONNG TIME