[DGD] The future of muds

Shentino shentino at gmail.com
Sun Sep 26 06:34:29 CEST 2010


My main reason for relying so heavily upon the klib was security,
inheritable segregation enforcement, as well as a basic "just works" bottom
layer that I could log into and if nothing else chit chat with everyone
else, as well as having a solid way to fix things if everything else went
bonkers.

If I were to redesign the klib (which I actually have semi serious
intentions of doing), I would make resource management optional.  Have a way
to turn it off completely when needed, but have a way to reenable it later
as an auditing mechanism if trouble happens later.  Done intermittently, it
is useful for debugging.

Objregd is also useful as basic insurance against bad tracking/garbage
collection of clones.  If your object manager goes tits up, you can always
reset your clone records based on its lists.

Though in a commercial environment, using Skotos's
find_object("/path/to/object#iterated") might work better.  This method does
however require tracking blueprints.



More information about the DGD mailing list