HDTenEightyP/NetNews huggingface dataset:
From: jwp@chem.ucsd.edu (John Pierce)
Newsgroups: rec.games.mud.admin
Subject: Re: Guru help needed.
Date: 5 Nov 1992 18:03:00 GMT
Organization: Chemistry Dept, UC San Diego
NNTP-Posting-Host: chedccf0.ucsd.edu

 >   The only reason vfork() is faster than a normal fork() is because it
 > only has to copy the parent process's page tables and user structure,
 > and not the whole address space.

One must be careful:  On some machines (e.g. RS6000 AIX), vfork() is,
in essence, implemented as

	#define	vfork()	fork()

That is, the child side of the vfork() will actually get a completely new
address space.

In my opinion, a much better way to handle things that need operating system
resources would be with a separate "operating system resource server" to which
the game driver passes requests and from which it receives responses.  A good
example of this sort of thing is Andrew Molitor's asynchronous action daemon
for ubermud (well, anything actually - ubermud just happens to be where I ran
across it).  In fact, I think that's a good example of the way a lot of things
should be done.  For that matter, barring a few minor problems, I still think
ubermud was a good system, and I still occasionally regret that I let the fact
that there was no equivalent of LP's mudlib push me into using LP for the
Marches of Antan instead.

-- John W Pierce, Chemistry, UC San Diego
   jpierce@ucsd.edu
   Horvendile, The Marches of Antan, chem.ucsd.edu (132.239.68.1) 3000
Newsgroups: rec.games.mud.admin
From: yyrkoon@morris.engin.umich.edu (Jeffrey Jon Kabbe )
Subject: Re: Guru help needed.
Date: Fri, 06 Nov 92 11:29:50 EST
Organization: University of Michigan Engineering, Ann Arbor
Originator: yyrkoon@morris.engin.umich.edu


Actually, the correct term for us is Unix/C God.

Thank you.

:)

Jeff = yyrkoon
Newsgroups: rec.games.mud.admin
From: jdb@jetty.cis.ufl.edu (John Brothers)
Subject: Re: siteban() for DikuMUD
Organization: Univ. of Florida CIS Dept.
Date: Fri, 13 Nov 92 16:48:51 GMT

In article <mah.721553042@radon.sys.uea.ac.uk> mah@sys.uea.ac.uk (Mike Harrold) writes:
>jdb@crane.cis.ufl.edu (John Brothers) writes:
>
>>In article <BxB05u.Ivy@nic.umass.edu> mcrocker@titan.ucc.umass.edu (MATTHEW S CROCKER) writes:
>
>   Blah Blah [stuff deleted]
>
>>You can't.  Not with IP.  You can only get the address.  You can ban machines,
>>domains, or even .edu, .com or .gov, but you can't ban users with straight
>>IP.
>
>   Actually, this is very possible, I know cos I've just coded it on our
>   Diku.  It's not a particularly good way (so I've been told - but *I*
>   think it's quite clever, but then again I would!) but it does the job
>   anyway.
>
>   I'm not one for divulging code which took me hours to write, but I'll
>   give you a hint...
>
>   struct allow_char
>   {
>       char *name;
>       struct allow_char *next;
>   };
>
>   struct banned_sites
>   {
>       char *host;
>       int number;
>       struct allow_char *allow;
>       struct banned_sites *next;
>   };
>
>   Anyone who can program C should be able to recognise what I am doing -
>   well I do anyway :)

You misinterpreted me.  I said username.  Not character name.  Adversary
already does check the character name, in much the same way that you 
do.  (I would imagine).  He wanted to make sure that only his account could
log in as the Implementor.  Not just one host, but only one account.  It can't
be done with the basic IP.

>   Should anyone want more details then feel free to email me.

   char ok = 0;

   for (i = banned_site_list; i; i=i->next) {
	if (i->number == new_number) {
	    for (j = i->allow; j; j=j->next) {
	        if (strcmp(j->name, new_char_name)==0) {
			/* they are ok */
			ok = 1;
			break;
		}
	    }
	    if (!ok) {  
		/* not validated */
	    } else {
		/* let them in */
	    }
        }
   }

>
>   Miko - Implementor on RadonMUD
From: mah@sys.uea.ac.uk (Mike Harrold)
Newsgroups: rec.games.mud.admin
Subject: Re: siteban() for DikuMUD
Date: 12 Nov 92 07:24:02 GMT
Organization: UEA School of Information Systems, Norwich, UK.

jdb@crane.cis.ufl.edu (John Brothers) writes:

>In article <BxB05u.Ivy@nic.umass.edu> mcrocker@titan.ucc.umass.edu (MATTHEW S CROCKER) writes:

   Blah Blah [stuff deleted]

>You can't.  Not with IP.  You can only get the address.  You can ban machines,
>domains, or even .edu, .com or .gov, but you can't ban users with straight
>IP.

   Actually, this is very possible, I know cos I've just coded it on our
   Diku.  It's not a particularly good way (so I've been told - but *I*
   think it's quite clever, but then again I would!) but it does the job
   anyway.

   I'm not one for divulging code which took me hours to write, but I'll
   give you a hint...

   struct allow_char
   {
       char *name;
       struct allow_char *next;
   };

   struct banned_sites
   {
       char *host;
       int number;
       struct allow_char *allow;
       struct banned_sites *next;
   };

   Anyone who can program C should be able to recognise what I am doing -
   well I do anyway :)

   Should anyone want more details then feel free to email me.

   Miko - Implementor on RadonMUD
Newsgroups: rec.games.mud.admin
From: cks@hawkwind.utcs.toronto.edu (Chris Siebenmann)
Subject: Re: siteban() for DikuMUD
Organization: Ziebmef home away from home
Date: 8 Nov 92 12:23:15 GMT

rickert@cco.caltech.edu (Keith Warren Rickert) writes:
| 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.

 Not to mention the question of whether or not you trust the
remote machine at all; if you don't trust it, you can't trust
it to not lie when it tells you who the IP connection belongs
to. Remote machines can also lie (somewhat) about their name,
so be wary of trusting the name gethostbyaddr() gives you
unless you know the traps; you are probably better off using
the raw IP addresses for checks(*).

 Note that current RFC 931 authentification daemons are not
100% reliable either; they manually grub through kernel data
structures and if the kernel happens to shuffle stuff out
from under their examinations, well, strange things can no
doubt happen.

[*: not that the IP address is 100% secure either. See a paper
    by Steve Bellovin, I believe, on attacks on TCP/IP security.]
--
	"zsh has all the useful features of ksh, plus many of
	 the useless ones."		- Paul Falstad		
cks@hawkwind.utcs.toronto.edu	           ...!{utgpu,utzoo,watmath}!utgpu!cks
Newsgroups: rec.games.mud.admin
From: scg@mentor.cc.purdue.edu (Kelly Martin)
Subject: Re: Guru help needed. (More details)
Reply-To: scg@mentor.cc.purdue.edu
Organization: Gender Anarchists United
	<1d9hmdINNsj7@agate.berkeley.edu>
Date: Thu, 5 Nov 1992 15:33:18 GMT

alansz@cogsci.Berkeley.EDU (Alan Schwartz) writes:

>I need to communicate with the process. Specfically, I'm trying to create
>a MUSH-internal spell-checker that players can call, that will pipe the
>text of their object's attrib(s) to Unix 'spell' and notify them of
>unrecognized words. But spell is slow, and doing this with a normal
>popen (my current method) lags the whole MUSH for big objects.
>So, I need to pass the new process the info about what to spellcheck
>and who the player is. It needs to pass back info about what to tell the
>player. This lets out using system() calls, even with & backgrounding.

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.
--
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: yyrkoon@morris.engin.umich.edu (Jeffrey Jon Kabbe )
Subject: Re: Apocolypse's Demise
Date: Fri, 06 Nov 92 11:31:19 EST
Organization: University of Michigan Engineering, Ann Arbor
Distribution: usa
Originator: yyrkoon@morris.engin.umich.edu


That title is kind of redundant isn't it? Apocalypse's demise.....
Newsgroups: rec.games.mud.admin
From: danic@sciborg.uwaterloo.ca (Steve)
Subject: ATTN: skill based muds
Summary: automatic skill point increases
Keywords: skills
Organization: University of Waterloo
Date: Wed, 11 Nov 1992 07:12:24 GMT

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

- Each skill when attempted would have a very small chance of improving.
  - this chance gets smaller still when the skill is high already.
- skills wouldn't be bought with generic experience.
- there would be a maximum on total skill points.
  - this causes players to consider which skills they wish to improve.
  - then players adopt a playing style which uses favorite skills.
- skills not in use deteriorate slowly.
  - actually, all skills drop slowly, but the ones in practice improve
    at a greater rate.

   With a system like this, players could watch their skill points go up as
they play instead of having to go to a guild hall and shop for skills with
experience they earned through without trying those skills.
   Personally, I would prefer a system like i described over the standard
skill systems because it's more realistic, and allows more playing time
instead of running to and from a guild hall.
   Guilds could still exist, but instead of being shopping centers for
skills, all they would provide is a greater rate of learning in certain
skills.  Of course, to belong to a guild you would have to pay a union
type fee as a percent of your profits.
   Races also could affect the rate of learning for skills as well as the
initial skill level of the player.
   Some skills wouldn't be inherent to every player, but must be tought or
found.  Examples of inherent skills are: weapon proficiencies, pick
pocketting.  Examples of non-inherent skills are: spell proficiencies,
smithing, herbalism; these all must be tought to the player initially,
after which they can go up by practice.

How easy would this system be to implement?
If it's not TOO hard, I think it'd be worth it.

...Steve
From: scg@mentor.cc.purdue.edu (Kelly Martin)
Newsgroups: rec.games.mud.admin
Subject: Re: Guru help needed.
Date: 5 Nov 92 15:22:47 GMT
Article-I.D.: mentor.SCG.92Nov5102247
	<1992Nov4.155634.22107@daffy.cs.wisc.edu>
Reply-To: scg@mentor.cc.purdue.edu
Organization: Gender Anarchists United

austin@cs.wisc.edu (Klaas) writes:

>Well, you can fork() or vfork() (non-portable).  You will share the
>same text, but as soon as you write a variable its page will get
>copied.

Actually, copy-on-write is (sadly) not implemented in most UNIX
systems.  fork() on most UNIXes will copy the ENTIRE process at
creation.  This can be expensive.  vfork() doesn't copy; the child
runs in the exact same memory as the parent (and the parent is
suspended until the child exits or execs).  NOTE: no copy-on-write;
changes the child makes to the memory context are preserved in the
parent!

>So shared variables are difficult to have.  In a semi-portable way
>you could shared malloc (shmalloc) the data variables that you want
>the spawned programs to share with the parent, but then all globals
>will have to be in the heap.

Shared memory in UNIX is currently inherently nonportable as there is
no standard (that I know of, at least).

[rest deleted]

I think what the original person is asking for is probably best
handled by vfork() followed by exec().
--
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: spell@spell.demon.co.uk (Martin Glassborow)
Subject: Skill based MUDs
Distribution: world
Organization: <What Work for a Living>
Date: Thu, 12 Nov 1992 19:24:17 +0000

I'm not sure how much this will help, but there is commercial skill-based
MUD in the Uk called Avalon. Skills go up automatically in certain cases,
skills can also be learnt from people and mobiles. Its a while since I
played it and I can't precisely remember how it all worked, however it was
pretty good until things got out of hand, and there were too many skills.

However if you want more info on Avalon, or on any MUG/MUD in the UK, ask.
There are a few about, especially not attached to the 'NET.

Spell
--
You're never alone in the Twiglet Zone
Spell@Spell.Demon.Co.Uk                                    
Newsgroups: rec.games.mud.admin
From: ludwigj@CS.ColoState.EDU (Vilkata (Joe Ludwig))
Subject: Re: ATTN: skill based muds
Date: Fri, 13 Nov 1992 01:25:16 GMT
Organization: Thealir Construction Company
Keywords: skills

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.

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

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

-- 
+--------------------------+-------------------------------------------------+
| Vilkata, the Dark King   | "I'd rather rule in hell, than serve in heaven" |
| ludwigj@cs.colostate.edu | "Priests and cannibals, prehistoric animals,    |
| Vilkata@Most MUCKs       |  everybody happy as the dead come home."        |
From: tfpayn01@ulkyvx.louisville.edu
Newsgroups: rec.games.mud.admin
Subject: Re: ATTN: skill based muds
Date: 13 Nov 92 17:48:07 GMT
Organization: University of Louisville

In article <1992Nov13.063158.20461@leland.Stanford.EDU>, whale@leland.Stanford.EDU (Stephen Schmidt) writes:


Sorry to nuke the previous comments, but they're somewhat irrelevant at this
time...

I do beleive that the gentlemen who bepsoke of using a chance of success method
were on the right track....isn't this the basis for skill points in the first
place?  In other words, if a 10th level character attacks a 1st level monster,
and it's a ridiculously simple task for him, he only gets the minimal amount of
XPs....however, when the first or second level character attacks said monster,
and succedes (sorry, this was the implication!), he gains the maximum or near
maximum of XPs for the task, as it was difficult for him (sorry ladies, I'm too
lazy to put 'it')....

This would seem to be the same for increases in skill levels...

Gents! and Ladies!  Isn't the whole concept here based on the idea of a
DUNGEON?

I would like to refer you to the second edition Dungeons & Dragons Player's
Handbook, or any Palladium game (Believe this or not, check your local library,
you'd be surprised what you'll find there! I found three Teenage Mutant Ninja
Turtles books, one ref guide and two modules! Wow...)...

They explain in detail the methods for increasing skills, XPs, etc...

They also offer details on how to limit progression, based on level, race,
etc...

THIS IS NOT A FLAME, simply advice...IMHO

As a last resort, try out Forgotten Realms, as they use a modified D&D format,
where all skills can be increased by the player based on XPs they gain from
adventuring....I've found the system difficult, thought extremely challenging!
It also allows the player to shape their character to their own concept of the
character...

FORGOTTEN REALMS>  158.36.33.3 2001  <

Thanks!
Newsgroups: rec.games.mud.admin
From: snarflrd@leland.Stanford.EDU (NM156)
Subject: Re: ATTN: skill based muds
Keywords: skills
Organization: DSG, Stanford University, CA 94305, USA
Date: Thu, 12 Nov 92 01:38:53 GMT

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.
>Later versions of the mudlib will probably also include an XP system for
>those traditionalists out there...

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)
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.
-- 
Ingredients: chopped pork shoulder with ham, salt, water, sugar, sodium
             nitrate, snarflrd@leland.stanford.edu
Newsgroups: rec.games.mud.admin
From: urimud@netcom.com (James M. McKenzie)
Subject: Finding a Host for ones Mud
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Wed, 11 Nov 1992 06:44:08 GMT


  It seems that there are always a lot of people looking for a sight, some new,
some old, and some continually.

  It doesn't seem that posting here helps one's cause, but yet some of you,
 the lucky ones perhaps get sites.

 So here's my questions:


   How did you manage to get one?   

  
      Just luck?
      Know the 'right people' ?
      bribe someone (j/k)
      kill off a pre-existing mud perhaps (that's a thought now isn't it ...)

  Feedback would be apreciated, as I'd like to get a sight, but seem to be
  lacking in the success department on this one.


   Man-ing   - Creator of Uri -
Newsgroups: rec.games.mud.admin
From: alcaman@opal.cs.tu-berlin.de (Alexander Weidt)
Subject: Re: Guru help needed.
Followup-To: comp.unix.programmer
Organization: Techn. University of Berlin, Germany
Date: Thu, 5 Nov 1992 18:02:17 GMT

[large reference list deleted]

Hiho..
  I seem to be having the feeling that you folks haven't understood the
question.  James wants to create an asynchronous process *quickly*. 
Furthermore he does *not* require the child process to be initialised
with the same address space as the parent.

Do you think this is going to be faster to:

a)  Use system(3) and thus perform following actions:
	
      parent
	|
	|
	system ("foobar &"); 
	|
	fork();  	Address space is created
	|		involves a lot of copying etc..)
	\
	| \
	|  exec ("/bin/sh foobar &")  <- this is expensive
	|		| 
	wait()		|
	|		fork() <- this is expensive
	|		|\
	|		|  \
	|		|    \
	|		|	exec ("foobar");
	|		exit()		|
	|				| <- foobar is running!
	|		 	
		exec ("/bin/sh foobar &");  - Incur tremendous amounts
		of overhead to load a shell which then does another
		fork for the background process, to create yet another
		address space etc.. the shell will then terminate, at
		which point your parent process will resume.

  So, do you se that you've incurred at incredible expense; created one extra
address space, and invoked an extra program that might even have to be fetched
in via the net...

or simply:

b)
	parent				child
	  |
	  vfork() <- this is is cheap	  |
				  	  execve ("foobar")
	  |<- parent resumes v. soon	  |\
	  |				  |  \ foobar is running
    
    Note that the parent will only be blocked until the child executes
the execve system call.  you can think of it as the child temporarily 
borrowing the parent's address space and thread of control.  be careful
of doing nasties in the child process like returning from the function,
calling _exit(2), or optimising compilers etc.. (read the manual page
on your system)

  In a previous article, I think Lydia mentioned that James wanted this
to hack some kind of spell checker into a mush.  I too consider this an
inappropriate feature in such a driver.  On my LPmud (Tubmud) we use
a bot which keeps a connection to a webster server running on a different
machine to provide spell checking and dictionary services.

  I hope this has cleared matters up on this topic, followups to
comp.unix.programmer.

Happy hacking, Demos.
--
Use the force, read the source.
Newsgroups: rec.games.mud.admin
From: jdb@crane.cis.ufl.edu (John Brothers)
Subject: Re: siteban() for DikuMUD
Organization: Univ. of Florida CIS Dept.
Date: Fri, 6 Nov 92 18:43:21 GMT

In article <BxB05u.Ivy@nic.umass.edu> mcrocker@titan.ucc.umass.edu (MATTHEW S CROCKER) writes:
>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...

   banning sites is rather straightforward.   when you accept() a new 
connection, one of the parameters is filled with a structure containing
the IP address of the connection (i.e., the remote host), among other things.
If you get the part that contains the IP address, you can use the inet_ntoa
function to convert this address to a string in dotted decimal form :

127.228.224.98   

You can then, if you want, take this string, and compare it against any number
of other strings, and see if there is a match.  You can, even, through clever
use of the strncmp function, only compare PART of the net address, to lock 
out entire domains, instead of individual machines.  

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

You can't.  Not with IP.  You can only get the address.  You can ban machines,
domains, or even .edu, .com or .gov, but you can't ban users with straight
IP.

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

again, there is straightforward way to know the username of someone
connecting to the game.  There is a program called 'pidentd', which will
return the username associated with a port on that machine, but of course, it
would have to be running on the machine you were checking to check the 
username.  If you can put this on the machine that you log in from, you might
be able to control who logs in from your machine.

>Anyhelp will be apreciated,
>
>advTHANKSance