[DGD] Hope someone can help

[Par Winzell]

Matt,

Happy to be of assistance. And you really should stop apologizing
for your questions... technical savvy may be useful for precisely
the sort of thing you are trying to do, but it is really a rather
over-specialized skill which in my opinion commands far more real-
world respect than it really deserves, especially in the USA. :-)

I also think trying to write a -game- rather than a MUD operating
system (which half the people on this list have done) is a lovely
change of priorities, and I hereby cheer you on wildly.

First some specifics --

 > The thing is ... I don't know what ticks and stacks are. I know that
 > probably makes me seem like a four year old running for president ;)
 > We are not going to run the standard code/builders thing. We want to have a
 > test mud where we can fully test new code as it comes along. Code will be
 > submitted by other coders and not written from within the mud.

A tick should be considered a unit of time. If a code takes a lot
of ticks, it's taking a lot of time. If there is no restriction on
how many ticks some piece of code can take before it is violently
aborted, then there is no restriction on the amount of time it can
take. If there is no restriction on the amount of time, then that
piece of code can take forever to run. If it takes forever to run,
then nothing else can run. If nothing else runs, you don't have a
functional Mud.

Thus you want to restrict the amount of ticks (time) untrusted code
is allowed to take up. This is done with rlimits.

What stack really is is not very important nor very interesting --
just consider it another finite resource that you want to stop some
random piece of code from using up.

If you do

	rlimits(100, 100) {
		blah;
	}

then the code 'blah' is only allowed to take up 100 ticks and 100
stack before it completes. 100 tick is a silly value, 100,000 may
be more realistic. 100 stack is generous.

 > To be honest with you ... I didn't understand any of the bit about Callout
 > Gateways and the like ... Sorry Par :(

Don't be sorry. It's an extremely specialized, extremely technical
notion that you're not really supposed to have to think about to
make a game. Unfortunately you've chosen not to use the kernel lib,
which is the single piece of software generally available that will
try to do some of these tasks for you. :)

The explanation: callouts are one of the few things that can start
the execution of some code, so if you want to make sure code can't
execute with infinite limits, the very beginning of every callout
is an ideal place to put rlimits.

 > I also wondered what you mean by putting a bunch of r-limits in the 'right
 > places' ... Um ... Where would the right places be? Any advice on where to
 > put r-limits. And how do I do that?
 > Also what is it I need to do about call-outs? Is it preventing call-out's
 > being made when their aren't enough stack/tick thingies which I suppose
 > would be bad for the mud running?

Now instead of answering the specifics I'll answer generally -- you
either need to

 A) not to care about ticks and stack ... this would probably be my
    approach, though I would eventually regret it,
 B) quickly switch to using the kernel library, which is a far from
    trivial an operation, but much easier than building your own, or
 C) either finding somebody who actually -enjoys- this sort of work,
    or prepare to spend many nights staring at code that is 100% tech
    and 0% game...

My suggestion is you do A) now until you are more skilled, then
C) and then finally B)  :-)

 > Last question on that ... Does it matter if we didn't include r-limits any
 > where? Is it something that will prevent our mud from working?

It means any infinite for-loop anywhere in the game would freeze the
game until you reboot it from the last good statedump... and a bunch
of similar risks. Of course, after you rebooted, you would eventually
hunt down this buggy for-loop and fix it... and you'd be fine until
the next buggy for-loop. It's a fragile foundation on which to build
something as complex as a persistent Mud though.

 > > I suggest the only way you can make a large persistent fantasy
 > > Mud is to hook up with a developer who is willing to really dig
 > > into these complex issues -- especially if you're not doing it
 > > with the kernel library.
 > 
 > That sounds ominous :( Do you really think that we can't / shouldn't go
 > further without another developer helping out with these things. Our code
 > and ideas are great ... Haven't seen lots of them in any other muds about.
 > I've introduced ideas from the rl rpg system me and friends have developed
 > over 6 - 7 years. And I'm proud at least that we have got this far ;)

DGD is by design a minimalist driver, which means that there is need
for a chunk of LPC code between DGD itself and the 'game' which is
very technical. If you don't want to write this code yourself, you
need something like the kernel library. Even if you do have the kernel
library, you need somebody to understand it and to interface the rest
of the game with it...

Zell
_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd