August 2007:
This document was written in the mid 90s, much of it is still valid,
but the DGD kernel library will provide you with a shell and a starting point
for building your own lib.
Aidil
dgd.eval by Soermo for Dawn Of Empire mudlib.
D G D E v a l u a t i o n
by Soermo
I have had a look at the DGD driver and thought that many would like to
know what we are up against here. DGD is a very no-nonsense driver, which
means that it does not do anything it can leave to the mudlib. That makes it
increadibly fast, memory efficient and versatilie, BUT it require a hell of a
mudlib :-).
Since the driver leaves alot to the mudlib, the low level code of the
mudlib need to have very high quality for the speed and memory gain to really
work, and this is where our consideration in how to use DGD should really go.
After that, we can more or less use any mudlib.
What does DGD need that other drivers do not?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DGD does not have a file security system in the driver. We need to make
one ourself. This is done in DGD by adding the security system to an "auto
inherit". This inherit is automatically inheritted by ALL objects.
DGD lack the add_action() and related efuns. The player object receives
all input from the player via the DGD driver directly, and DGD need you to
code a shell on your own. This makes DGD extremly well fit to use with a good
parser and a good command daemon. If done properly we can save enormous
amounts of resources here. This also means that DGD does not really know the
difference between living and inanimate objects like other drivers do with the
help of the enable_commands() efun. This is the job of the shell and the parser.
DGD have no concept of "rooms". The environment(), present(),
all_inventory() etc. functions does not exist in DGD. That is all right,
because keeping track of "rooms" is really none of the driver's business.
These functions can be implemented with the help of lfuns in the auto object
without any trouble. Another side of this is that DGD does not understand
"movement". This can also be handled nicely by lfuns in the auto object
however. Of course, DGD does not handle light in the driver either.
DGD does not have a heart beat function, but that can be simiulated if we
wish in the auto object with the help of call_outs.
DGD does not support shadowing of objects.
I do not think DGD supports function pointers yet, but I think it will in
the future. That is really not as bad as you may think as a mudlib
implementation of function pointers using arrays will not be much worse than
the MudOS implementation (the functions pointers in MudOS are really handled
as arrays in the driver, I am told).
How do we solve this?
~~~~~~~~~~~~~~~~~~~~
All of the points mentioned briefly above are very complicated pieces of
code. It will probably be more complicated than any piece of code in an
ordinary mudlib. The shell, parser and security system all need to be
execelent to use DGD's potenital fully. I suggest to use large parts of
Vikings command daemon, possibly supplied with Kobra's. I think Kobra and
Viking have some of the most state-of-the-art command daemons out there (I
believe in Tenser@Kobra and Auronthas@Viking :-) ). Also, I have code for a
parser. I have no idea if it is good, since it is the only one I have ever
seen, but Drevreck@Viking assures me it is execelent. I will have him explain
it briefly to me, and try to port it. The command daemon and the parser will
togeather be more or less equal the shell.
I have heard rumors that DGD will bundle a good parser soon. If that is
the case, we should probably be able to use it for even greater speed soon.
The file security system is more complex. Here we must decide what
security system to use. The general feel in MUD's is that the user ID security
system is not an execelent one, and I have seen some other suggestions for a
file security system. In my opionion we can start off with a fairly simple one
(maybe just use Viking's), and complicate matters when we have the time ;-).
What does DGD feature?
~~~~~~~~~~~~~~~~~~~~~~
DGD is very versatile because so much is done by the mudlib. It can
support almost any file security system, it can support fast command daemons
and parsers. I belive DGD have a working array and mapping system (as opposed
to MudOS - believe me :-) ), although I think DGD will not be extremly fast
with mappings.
DGD will support virtual object compilers if we want to.
DGD supports floats.
DGD have the option to force strict typing. This is something I think we
should turn on :-).
DGD supports state dumps. That means that the state of the MUD will be
dumped to a file when the MUD reboots, so it can continue where it left off
before. This is good for players, but the mudlib must make sure that there
will not be an object inflation etc.
Below are a list of the kfuns supported by DGD:
allocate fabs map_values save_object
call_other find_object modf send_message
call_out floor object_name shutdown
call_trace fmod [parse_string] sizeof
catch frexp previous_object sscanf
ceil function_object query_editor status
clone_object get_dir query_ip_number strlen
crypt get_exec_cost random swapout
ctime implode read_file this_object
destruct_object ldexp remove_call_out this_user
dump_state lock remove_dir time
editor make_dir remove_file typeof
error map_indices rename_file users
explode map_sizeof restore_object write_file
Conclusion
~~~~~~~~~~
Until Camelot get DGD fairly stable, and until we can make very crude
shell and mudlib for DGD, we will not be able to use it. We can simulate DGD
under MudOS by using only the same efuns as DGD have, and to inherit the auto
object in all objects. In this way we can make a crude mudlib that will work
on DGD, and hopefully get it started. I believe I am starting to get a grip on
how DGD works by using the 2.4.5 simulation and source, so if Whoever Decides
want me to, I can give it a shot :-). Hiering Tenser@Kobra, Abigail@Viking and
Auronthas@Viking as consultants may pay off as well, but we can not expect
them to CODE anything ;-).
Be aware that this has NEVER been done before (as far as I know). There
are only two mudlibs existing for DGD (both are excelent I am told) - the
2.4.5 simulation, and a simulation for some strange MUD type never before ran
on an LPMud-like driver. In my knowledge, _NO_ LP-MUD 3.x-like MUD use DGD
now, and especially not with advanced parsers and command daemons. The reason
for this is that it require some complicated core code, and because it is not
compatible with other drivers. If we use the DGD, it will make the MUD unique
and original codewise, but it also means that we can not seek out help in
other mudlibs and on other MUD's. I personally think we should give it a shot.
This document was written in the mid 90s, much of it is still valid,
but the DGD kernel library will provide you with a shell and a starting point
for building your own lib.
Aidil
dgd.eval by Soermo for Dawn Of Empire mudlib.
D G D E v a l u a t i o n
by Soermo
I have had a look at the DGD driver and thought that many would like to
know what we are up against here. DGD is a very no-nonsense driver, which
means that it does not do anything it can leave to the mudlib. That makes it
increadibly fast, memory efficient and versatilie, BUT it require a hell of a
mudlib :-).
Since the driver leaves alot to the mudlib, the low level code of the
mudlib need to have very high quality for the speed and memory gain to really
work, and this is where our consideration in how to use DGD should really go.
After that, we can more or less use any mudlib.
What does DGD need that other drivers do not?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DGD does not have a file security system in the driver. We need to make
one ourself. This is done in DGD by adding the security system to an "auto
inherit". This inherit is automatically inheritted by ALL objects.
DGD lack the add_action() and related efuns. The player object receives
all input from the player via the DGD driver directly, and DGD need you to
code a shell on your own. This makes DGD extremly well fit to use with a good
parser and a good command daemon. If done properly we can save enormous
amounts of resources here. This also means that DGD does not really know the
difference between living and inanimate objects like other drivers do with the
help of the enable_commands() efun. This is the job of the shell and the parser.
DGD have no concept of "rooms". The environment(), present(),
all_inventory() etc. functions does not exist in DGD. That is all right,
because keeping track of "rooms" is really none of the driver's business.
These functions can be implemented with the help of lfuns in the auto object
without any trouble. Another side of this is that DGD does not understand
"movement". This can also be handled nicely by lfuns in the auto object
however. Of course, DGD does not handle light in the driver either.
DGD does not have a heart beat function, but that can be simiulated if we
wish in the auto object with the help of call_outs.
DGD does not support shadowing of objects.
I do not think DGD supports function pointers yet, but I think it will in
the future. That is really not as bad as you may think as a mudlib
implementation of function pointers using arrays will not be much worse than
the MudOS implementation (the functions pointers in MudOS are really handled
as arrays in the driver, I am told).
How do we solve this?
~~~~~~~~~~~~~~~~~~~~
All of the points mentioned briefly above are very complicated pieces of
code. It will probably be more complicated than any piece of code in an
ordinary mudlib. The shell, parser and security system all need to be
execelent to use DGD's potenital fully. I suggest to use large parts of
Vikings command daemon, possibly supplied with Kobra's. I think Kobra and
Viking have some of the most state-of-the-art command daemons out there (I
believe in Tenser@Kobra and Auronthas@Viking :-) ). Also, I have code for a
parser. I have no idea if it is good, since it is the only one I have ever
seen, but Drevreck@Viking assures me it is execelent. I will have him explain
it briefly to me, and try to port it. The command daemon and the parser will
togeather be more or less equal the shell.
I have heard rumors that DGD will bundle a good parser soon. If that is
the case, we should probably be able to use it for even greater speed soon.
The file security system is more complex. Here we must decide what
security system to use. The general feel in MUD's is that the user ID security
system is not an execelent one, and I have seen some other suggestions for a
file security system. In my opionion we can start off with a fairly simple one
(maybe just use Viking's), and complicate matters when we have the time ;-).
What does DGD feature?
~~~~~~~~~~~~~~~~~~~~~~
DGD is very versatile because so much is done by the mudlib. It can
support almost any file security system, it can support fast command daemons
and parsers. I belive DGD have a working array and mapping system (as opposed
to MudOS - believe me :-) ), although I think DGD will not be extremly fast
with mappings.
DGD will support virtual object compilers if we want to.
DGD supports floats.
DGD have the option to force strict typing. This is something I think we
should turn on :-).
DGD supports state dumps. That means that the state of the MUD will be
dumped to a file when the MUD reboots, so it can continue where it left off
before. This is good for players, but the mudlib must make sure that there
will not be an object inflation etc.
Below are a list of the kfuns supported by DGD:
allocate fabs map_values save_object
call_other find_object modf send_message
call_out floor object_name shutdown
call_trace fmod [parse_string] sizeof
catch frexp previous_object sscanf
ceil function_object query_editor status
clone_object get_dir query_ip_number strlen
crypt get_exec_cost random swapout
ctime implode read_file this_object
destruct_object ldexp remove_call_out this_user
dump_state lock remove_dir time
editor make_dir remove_file typeof
error map_indices rename_file users
explode map_sizeof restore_object write_file
Conclusion
~~~~~~~~~~
Until Camelot get DGD fairly stable, and until we can make very crude
shell and mudlib for DGD, we will not be able to use it. We can simulate DGD
under MudOS by using only the same efuns as DGD have, and to inherit the auto
object in all objects. In this way we can make a crude mudlib that will work
on DGD, and hopefully get it started. I believe I am starting to get a grip on
how DGD works by using the 2.4.5 simulation and source, so if Whoever Decides
want me to, I can give it a shot :-). Hiering Tenser@Kobra, Abigail@Viking and
Auronthas@Viking as consultants may pay off as well, but we can not expect
them to CODE anything ;-).
Be aware that this has NEVER been done before (as far as I know). There
are only two mudlibs existing for DGD (both are excelent I am told) - the
2.4.5 simulation, and a simulation for some strange MUD type never before ran
on an LPMud-like driver. In my knowledge, _NO_ LP-MUD 3.x-like MUD use DGD
now, and especially not with advanced parsers and command daemons. The reason
for this is that it require some complicated core code, and because it is not
compatible with other drivers. If we use the DGD, it will make the MUD unique
and original codewise, but it also means that we can not seek out help in
other mudlibs and on other MUD's. I personally think we should give it a shot.