[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