[DGD] The kernel library

Tyler Littlefield tyler at tysdomain.com
Thu Sep 23 20:21:37 CEST 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,
this leads me to a question I've asked a couple times, but never gotten
a real answer from.
I really like the looks of DGD, but I'm not skilled enough with both LPC
and DGD to write a base that I can work off of.
Does there exist a mudlib of sorts that I can get going with?
I liked the looks of Gurbalib, but that requires persistents and jumping
through a lot of hoops to get it going with or without.
I'm basically looking for something that will just save the player's
data like skills and load it again when the mud boots up, without
keeping a persistent track of everything, so that I don't need to go
through lots of work to change one variable to do something else with
update functions.
Also, is there a nice complete documentation set on dgd's functions (as
called from LPC)? I'm not sure what all it supports, or what all
functions it includes.

I've been hunting around for a mudlib to use, in whatever language; LPC
is my favorite setup by far, I just haven't managed to find what I want.

Also, I assume Hydra is a multi-threaded or multi-core enabled DGD
driver, correct? Can a mudlib be easily switched to Hydra, as the system
I'm developing on currently runs a quad core.
It won't matter right now, but I'd like to keep my code optomized from
the ground up, so that I won't have to go back and optomize later when
it turns out my combat system could've been 5x faster with some minor
changes; is there some sort of information on some basic things to kepe
in mind when using DGD for cpu/memory performance?
Thanks,

On 9/23/2010 11:13 AM, Felix A. Croes wrote:
> I have decided to stop development of the kernel library in its current
> form.  While it is very usable, powerful and stable, the core design dates
> back to 1996/1997, before I began work on what would eventually become
> Hydra.  Unfortunately, the way it approaches resource management does not
> take Hydra's concurrency into account (data is stored in central objects),
> and this cannot be fixed without violating its original design.  Rather
> than add layers of ugly #ifdefs, I am going to integrate it into a larger
> mudlib that I eventually intend to release into the public domain, rip
> out the parts which I don't want, and see how it evolves.
> 
> I've released version 1.3.4 of the kernel library on github, including
> the full history:
> 
>     http://github.com/dworkin/kernellib
> 
> Unless someone else wants to continue development, I recommend that users
> integrate it into their own mudlibs, as well.
> 
> Regards,
> Felix Croes
> ___________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
> 


- -- 
Thanks,
Tyler Littlefield
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJMm5qxAAoJELDPyrppriJPEPQH/3dMw5Yao7t9igpKTqy+CLGd
nO8vHERDl0CiVsuiMO3wxQNv9XGAlauNEasZT1XfHXS2c4GbFutmCc2JuGuvmcHQ
wJyAIZD12KGrOwdHn2qFOiKUZyIfpocXX+7comIRAhf0h8PBEficf4p5aRmiMvVd
iDK6lCXFrvn8mHtgB6BFdxCoCSo60NVQOlC/F+A8USDLbLjXqnURLDLK6P6rzv43
7vjCAbhrzXsoSj7X9mIAQ6d8BaMrLMTqCnvbk1wENdiIgPaTGEwC8rmZQ/PQzeHk
lfjLu/gLXDYVmYctthxuoZrg99mFnwCQZwqth9LJDHX0XixK2CrD3s5bN26ZqbM=
=ZaIf
-----END PGP SIGNATURE-----



More information about the DGD mailing list