Daemon
From LSWiki
| Revision as of 11:46, 10 March 2007 (edit) Arafelis (Talk | contribs) (changed from redirect page) ← Previous diff |
Revision as of 11:46, 10 March 2007 (edit) Arafelis (Talk | contribs) Next diff → |
||
| Line 1: | Line 1: | ||
| - | Twilight writes: This is where daemons are. What are daemons you ask? Good question. Basically I think they are objects that control, handle, and store data. Right? | + | ''Twilight writes'': This is where daemons are. What are daemons you ask? Good question. Basically I think they are objects that control, handle, and store data. Right? |
| - | Chaos responds: Something like that. Our daemons are probably best understood by reference to Unix system daemons, which are programs that run continuously (usually) and handle some particular task; the most popular daemon is the HTTP daemon, or web server. Our daemons are similar: they're objects that hang out and handle some particular function. /daemon/armour manages the armour subsystem, tracking the armour type and armour style definitions; /daemon/weapons manages the weapon subsystem, tracking weapon types, weapon sizes, and ammunition types. These are examples of a class of daemon called broker daemons because their main function is handling definition objects and brokering requests for them; they're mainly found in /daemon. Control daemons are another major class; these live in the ~Project/dmn directories of individual projects, each serving as a central manager for its project. Other daemons just package up some similar functionality, such as /daemon/time; some manage ongoing or specific-purpose processes of the game, such as /daemon/cron, /daemon/autoheal, and /daemon/shutdown. | + | ''Chaos responds'': Something like that. Our daemons are probably best understood by reference to Unix system daemons, which are programs that run continuously (usually) and handle some particular task; the most popular daemon is the HTTP daemon, or web server. Our daemons are similar: they're objects that hang out and handle some particular function. /daemon/armour manages the armour subsystem, tracking the armour type and armour style definitions; /daemon/weapons manages the weapon subsystem, tracking weapon types, weapon sizes, and ammunition types. These are examples of a class of daemon called broker daemons because their main function is handling definition objects and brokering requests for them; they're mainly found in /daemon. Control daemons are another major class; these live in the ~Project/dmn directories of individual projects, each serving as a central manager for its project. Other daemons just package up some similar functionality, such as /daemon/time; some manage ongoing or specific-purpose processes of the game, such as /daemon/cron, /daemon/autoheal, and /daemon/shutdown. |
| Two of the universal characteristics of daemons is that they are never cloned and they are never in-game objects. I can conceive of circumstances that could create an exception to the former, but not the latter. | Two of the universal characteristics of daemons is that they are never cloned and they are never in-game objects. I can conceive of circumstances that could create an exception to the former, but not the latter. | ||
| If you need to refer to a daemon that lives in /daemon in code, you will almost always be using the "service" macros for them, defined in /lib/services.h, which look like Daemon_Time, Daemon_Autoheal, Daemon_Shutdown, and so on. Another daemon, /daemon/services, manages these. Besides being prettier than string pathnames, these use a special mechanism to make them faster than other methods you might use for referring to daemons. | If you need to refer to a daemon that lives in /daemon in code, you will almost always be using the "service" macros for them, defined in /lib/services.h, which look like Daemon_Time, Daemon_Autoheal, Daemon_Shutdown, and so on. Another daemon, /daemon/services, manages these. Besides being prettier than string pathnames, these use a special mechanism to make them faster than other methods you might use for referring to daemons. | ||
Revision as of 11:46, 10 March 2007
Twilight writes: This is where daemons are. What are daemons you ask? Good question. Basically I think they are objects that control, handle, and store data. Right?
Chaos responds: Something like that. Our daemons are probably best understood by reference to Unix system daemons, which are programs that run continuously (usually) and handle some particular task; the most popular daemon is the HTTP daemon, or web server. Our daemons are similar: they're objects that hang out and handle some particular function. /daemon/armour manages the armour subsystem, tracking the armour type and armour style definitions; /daemon/weapons manages the weapon subsystem, tracking weapon types, weapon sizes, and ammunition types. These are examples of a class of daemon called broker daemons because their main function is handling definition objects and brokering requests for them; they're mainly found in /daemon. Control daemons are another major class; these live in the ~Project/dmn directories of individual projects, each serving as a central manager for its project. Other daemons just package up some similar functionality, such as /daemon/time; some manage ongoing or specific-purpose processes of the game, such as /daemon/cron, /daemon/autoheal, and /daemon/shutdown.
Two of the universal characteristics of daemons is that they are never cloned and they are never in-game objects. I can conceive of circumstances that could create an exception to the former, but not the latter.
If you need to refer to a daemon that lives in /daemon in code, you will almost always be using the "service" macros for them, defined in /lib/services.h, which look like Daemon_Time, Daemon_Autoheal, Daemon_Shutdown, and so on. Another daemon, /daemon/services, manages these. Besides being prettier than string pathnames, these use a special mechanism to make them faster than other methods you might use for referring to daemons.
