Skip to topic | Skip to bottom

Welcome Register

TWiki Web TWiki Web Home Changes Topics Index Search

TWiki Webs DGD Main Sandbox TWiki Welcome Register

TWiki Web TWiki Web Home Changes Topics Index Search

TWiki Webs DGD Main Sandbox TWiki Create personal sidebar porn free porn

DGD.Glossaryr1.3 - 17 Feb 2005 - 22:12 - DworkinBarimentopic end

Start of topic | Skip to actions
Various DGD related terms, abbreviations, and their explanation:

The initial version of this page is based on Noah Gibbs' Glossary.

An Afun, short for "Auto Function", is defined in the Auto object and behaves like an Kfun. It may override an existing Kfun.

Applies are functions in the MUDLib that the DGD driver calls. These are pretty much always in the Driver object, at least in DGD. They're not the same as Hooks because Hooks are called by other code in the MUDLib, not by the DGD driver binary itself.

A relatively new addition (in DGD version 1.2.51). It stands for "arbitrary size number". In LPC, such numbers are represented by big-endian strings. If the highest bit of the first character of the string is set, the number is assumed to be negative, and in two's complement format. If you want to represent a positive number that starts with a byte that would make the string representation negative, simply precede it with a \0 character.

Atomic Functions
Atomic functions are very, very uncommon even in LPMUDs. DGD is really pretty much unique in having them. An Atomic Function is one which, if it gets an error, basically never happened. Any variables, global data and whatnot that it played with will be back in the same state as if the function had never run. Atomic functions may not write to files or use the editor. Otherwise, they can do anything allowable in DGD LPC.

Auto Object
The second LPC object created. All later LPC objects, everything except the Auto object itself and the Driver object, inherit from Auto. Auto is a common place to override the standard DGD [#A_kfun Kfuns] with versions tuned for your particular MUDLib.

In MUDLib that separate Inheritable and Clonable, a Program which may be cloned. It may have variables and other state, its functions may be called and it may be recompiled in place. In MUDLib that don't separate the two, this distinction doesn't matter, but then a reboot may be necessary to upgrade objects. Compare Inheritable.

A clone is basically an "instance", in an object oriented sense, of a master object. Every clone shares its code (called a Program) with the master but each maintains an individual copy of the data.

Dworkin's Game Driver, sometimes called Dworkin's Generic Driver.

Driver Object
The first LPC object created. It field a number of hooked called (see Hooks) from the actual DGD driver, the real C code.

Driver program
The actual binary program in C, not LPC, that starts up the whole LPC environment and begins running the interpreted parts. It may be extended with a variety of packages and extensions, or be normal "vanilla" DGD. The driver implements common functions that programs can't do for themselves and that any big program is likely to need. See also MUDLib.

Short for External Functions. Efuns are functions which are defined or overridden by the MUDLib's auto object. Basically, just like AFuns.

Functions which get called when certain things happen. They're like event handlers in some languages except that, as with Java interfaces, you don't get to pick their names, you just supply an Object with all the right function names defined. You register with another part of the MUDLib for a Hook -- if the driver just does it automatically, it's an Apply instead of a Hook.

In MUDLibs that separate Inheritable and Clonable, a Program from which other programs may inherit. It may not be cloned, none of its functions can be directly called and it may have no variables nor any other kind of state. If it needs to be dynamically upgraded, it will be destroyed rather than recompiled in place, and it will be regenerated on demand from the new source. This is restrictive, but without it you may need to reboot the server to upgrade objects. Compare Clonable.

If you stumble into the thorny territory of writing your own object manager, as you'll need to do in order to upgrade (recompile) objects without rebooting for a Persistent MUD, you'll probably need to know about Issues. An Issue of an object, in particular of an Inheritable object, is a compiled version of that object. Until every object inheriting from a given Issue has been destructed or recompiled, the Issue is still there, lurking. An object manager can be careful to destroy any old Issues when it recompiles a new one, but that's a nontrivial undertaking. It is easiest to keep track of issues by their object index, which will be different for each issue. See the example object manager code on the main page and the mailing list archives.

Kfuns are DGD Kernel Functions, not to be confused with the Kernel MUDLib, a different beast. These are the basic things that DGD lets your MUDLib do. The MUDLib may override them so that the actual objects your wizards create use Kfuns different from the ones DGD supplies. See Auto object.

Lfuns are local functions, functions local to a given object or program.

Lightweight Object
DGD is a disk-based MUD, and swaps out its objects regularly (indeed, constantly) to a swap file. Little things like member variables (including arrays and mappings), get swapped as part of the object they're part of. If they're referenced by another object, then instead of being shared they'll be copied into the other object as well when the current Thead (qv) of execution completes. LWOs have .c files that define them, but act otherwise just like arrays and mappings -- they're part of the object that references them, swap with it and are copied if multiple objects reference them.

Lars Pensjö's C dialect.

A Lightweight Object.

A clone is produced from a master object using the clone_object [#A_kfun Kfun]. In some [#A_mudlib MUDLib], the master must be a Clonable and may not be an Inheritable.

A MUDLib is the layer of LPC on top of the Driver program that runs the actual game or application you want. The MUDLib implements stuff you know your wizards or other users will want to do that not every program built on DGD will necessarily want. This includes things like rooms, mobiles and objects. Remember, not only do different MUDs implement these things in different ways, but DGD can be used for pretty much any kind of network server, not just MUDs.

A chunk of code which may inherit from other objects. It tracks its own data. The same thing as a Program.

Object manager
To have a Persistent MUD, you'll need to keep track of what inherits and clones what so that you can recompile or destroy all the right stuff at all the right times. There's a massive amount of deep, confusing mailing list traffic on this deep, confusing topic. To cut to the chase, you can try installing Geir Harald Hansen's Object Manager from the top page's LPC Code Examples.

Persistent MUD
A Persistent MUD is one that never does the usual save, recompile, reboot routine. Instead it keeps its memory state around and recompiles stuff in-place. This is very, very hard to do in most languages and impossible in pretty much every other MUD server. That's why DGD is so proud of being able to do it well. To do this properly, you'll need a MUDLib that separates Inheritable and Clonable objects -- nothing that's both inherited from and cloned. See Inheritable, Clonable, and Object Manager.

The LPC code of an object. In many MUDLib, it must be either an Inheritable or a Clonable but may not be both.

A thread of execution -- if multiple Threads are occurring, that means multiple things are happening more-or-less at the same time, and maybe really at the same time if you've got multiple processors running DGD. Whenever a thread ends a bunch of stuff happens including swapping objects to disk and send_message and send_datagram actually sending. Shutdown, reboot and state dumps wait for the current thread to end so don't do your post-dump or post-shutdown stuff right after your shutdown call. Wait until the current thread has ended so you're sure shutdown has been called. Note that DGD code always acts exactly as though it's single-threaded, even when it's actually running multithreaded. How it does this is Deep Voodoo, and should be questioned only by those with a profound understanding of Atomic Functions (qv).

A tick is a hardware-independent abstraction of CPU usage. DGD runs on multiple platforms, and you'd like them to have similar behavior with respect to things like CPU quotas. So DGD rates various operations by how processor-intensive they are, and marks off ticks accordingly. Tick usage can be limited by the rlimits() construct, and monitored by status(). The Kernel Library has a quota system for ticks that prevents you using too many at a time, or too many total.

-- ErwinHarte - 20 Jan 2005
to top

You are here: DGD > Glossary

to top

Copyright © 1999-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback