[DGD] Letting the players code stuff

[Kurt Nordstrom]

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