[DGD] Letting the players code stuff

[Noah Gibbs]

  Fair enough.  DGD is actually quite well protected against accidental idiocy
as long as you do well by your rlimits(), don't make the maximum array size too
big and impose reasonable builder quotas.

  For the latter, you should also make it reasonable to find all current
objects belonging to a builder.  An "oops" with a script that makes lots of
objects and doesn't free them can leave behind a lot of garbage.  The Kernel
Library has some good but primitive tools for this, which Phantasmal cheerfully
exposes intact.

--- Kurt Nordstrom <kurt at blar.net> wrote:

> Noah,
> 
> I can see what you mean.  In this case, though, I have the feeling that
> I will more have to deal with "accidental idiocy" as opposed to
> "intentional destructiveness".  I am envisioning a policy where you
> would not receive "player builder" rights until you have been well
> established on the mud for a while, and the admins know you're not out
> to cause problems.  If this seems overly optimistic, I'd say that it is
> not much worse than policy for making people actual wizards.
> 
> The interpreted mini-language idea is great.  However, that's also
> requiring of a lot of work.  In this case, I'm willing to go with a
> "good enough" solution, and cross my fingers.
> 
> And make regular backups. ;)
> 
> -Kurt
> 
> Noah Gibbs wrote:
> >   You are correct that all of that is a good idea.  Unfortunately, it will
> only
> > solve some of your problems.  You can prevent an infinite recursion that
> way,
> > or an infinite iteration, but remember that objects can be created in many
> > different ways.  Assigning a new hash table to an existing table or array,
> > entering a new scope and creating new objects can all create more storage
> space
> > within a DGD object.  You *cannot* limit the size of a single DGD object,
> even
> > though you can limit how they are created.
> >
> >   So a malevolent player will always be able to create a table containing
> 100
> > tables, each containing 100 tables (and so on) and foil what you're doing. 
> If
> > he only creates, say, 20 thousand table entries on each iteration then he
> won't
> > run out of cycles.  But your MUD will still run out of space very, very
> > quickly.  There are many related little tricks which DGD's LPC simply
> cannot
> > address as-is.  However, by creating an interpreted language *within* DGD
> you
> > can fix this problem because then *you* control how player code allocates
> all
> > memory, not just some of it.
> >
> >
> >   
> >
> 
> ___________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
> 





       
____________________________________________________________________________________
Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase.
http://farechase.yahoo.com/