ZDaemon

ZDaemon is a multiplayer-focused source port based on ZDoom for both Windows and Linux/Unix (server only at this time). The current stable release is. ZDaemon was originally derived from ZDoom v1.23, which was one of the last major versions of ZDoom before moving to its current 2.xx codebase. It includes some of ZDoom's advanced features such as the majority of line types, sloped lines, and deep water, but lacks some later implementations such as DECORATE, flat and texture mixing, and other similar features. ZDaemon features an enhanced network code suitable for client/server games, stats and experience collection, teamplay support, and a Capture the Flag mode.

Supported games

 * Doom and Doom shareware
 * Doom II
 * The Ultimate Doom
 * Final Doom
 * Freedoom
 * Heretic and Heretic shareware
 * Hacx

Hexen is now mostly supported. Getting the rest completed is on the project road-map.

Supported game modes

 * Cooperative
 * Survival
 * Deathmatch
 * Team Deathmatch
 * Capture the Flag
 * Double Domination
 * King of the Hill
 * Duel

Other features

 * Partial support of ACS scripting
 * Dozens of new ACS and DeHackEd extensions. They can be found at the External Links section of this article
 * Advanced netcode for smoother movement
 * Demo recording (Client and Server side)
 * DVD-like demo playback (skip forward/backward, pause, playback speed, etc.)
 * In-game voice chat
 * Super-Sampling Anti-Aliasing
 * Uncapped (with or without vsync enabled)
 * Borderless Fullscreen
 * Widescreen (16:9)
 * Vampire mode
 * InstaGib
 * Dynamic bots
 * Killingspree announcer
 * In-game voice announcements
 * Unlagged
 * Extended nodes: ZDBSP Compressed and Uncompressed types
 * Detailed information about location, health, armor and active voice chat on the player screen. This is done using the command variable, short for Situation Report

New lumps
Throughout the years ZDaemon, along with several new ACS and DeHackEd extensions and enhancements, introduced several new lumps unique to the port, designed to enhance and improve the existing ZDoom v1.23 codebase with new features otherwise seen in different implementations in other source ports. These new lumps include:

DEHSUPP
DEHSUPP is a lump introduced by ZDoom that is used to add things to the list of actors and weapons that can be modified by DeHackEd. By compiling a DEHSUPP lump using the associated utility and inserting it into a WAD file, DeHackEd patches can reference things from Heretic, Hexen, and even Strife. It should be noted that DEHSUPP does not do anything by itself, and must be used in conjunction with either an internal or external DeHackEd patch that takes advantage of the new references. ZDaemon predates the introduction of DECORATE, leading to DEHSUPP being embraced by the community as a means to extend the moddability of the engine.

EXTRADEH
This lump allows DeHackEd patches to be stackable, utilizing the include directive.

Here is an example of a patch inside a WAD: Patch File for DeHackEd v3.0 Doom version = 21 Patch format = 6


 * 1) Include some extra DeHackEd stuff!!!

Include EXTRADEH The "include" makes it so that the above DEHACKED lump will look for any additional lumps named "EXTRADEH", whether the lumps are inside the main WAD along with the DEHACKED lump, or loaded separately as another WAD or patch, and will insert their contents into the DEHACKED lump above.

Here's an example EXTRADEH lump: Thing 1 (Player) Bits = SOLID + SHOOTABLE + DROPOFF + PICKUP + NOBLOOD + NOTDMATCH + TRANSLUCENT

Note how you must not include the header in the lump, because this lump will essentially get included into the main DeHackEd patch, forming the following patch file: Patch File for DeHackEd v3.0 Doom version = 21 Patch format = 6
 * 1) Here's another comment.


 * 1) Include some extra DeHackEd stuff!!!

Thing 1 (Player) Bits = SOLID + SHOOTABLE + DROPOFF + PICKUP + NOBLOOD + NOTDMATCH + TRANSLUCENT

Any lump names can be used as long at the base patch references the same lump. This requires a bit of planning on your part, and you must ensure you "include" all of these lump names in your DeHackEd WAD.
 * 1) Here's another comment.

So if you're making a 10-map WAD with a little bit of DeHackEd, to make your WAD EXTRADEH compatible, all you have to do is add the following lines to your DeHackEd patch: Include EXTRADEH Include EXTRAWEP Include EXTRAMON Include EXTRAMSC The placement of the include directives inside the base patch file will determine whether or not any subsequent patches can overwrite the base patch information. For example, if you use include an EXTRAWEP lump before your main DeHackEd weapon stuff, any weapon mods that use EXTRAWEP will not replace stuff already defined. If you include a patch at the end of the file, any patch WADS can completely overwrite anything you have done. It can also be placed in the middle of the patch file, with sensitive stuff defined before the include directive, and non-sensitive stuff defined afterwards. This gives you control over what can be modified. But only do this if you have good cause to (e.g. the WAD might break if your weapons are modified).

If you are creating a EXTRADEH patch, whether it be a monster or weapons mod, make sure you rename your DeHackEd patch to the correct lump name, and remove the header that WhackEd/DeHackEd adds to it. A WAD doesn't have to just include one EXTRADEH patch, you could have, for example, both "EXTRADEH" and "EXTRAWEP" in the same WAD file. The following lump names can be included:
 * EXTRADEH - Used for the main general purpose modifications
 * EXTRAWEP - Used for weapon modifications
 * EXTRAMON - Used for monster modifications
 * EXTRAMSC - Used for miscellaneous modifications

XDEHLOAD
To use the EXTRADEH feature in a WAD that contains no DeHackEd, a separate WAD called was made to aid in this which needs to be included, so that you don't have to keep separate EXTRADEH versions. XDEHLOAD loads an EXTRADEH WAD with a WAD that does not already have a DeHackEd patch included.

Here is an example how to load XDEHLOAD:



PATCHINFO
This is a text lump that specifies small changes (patches) on maps. The lump consists of one or more sections pertaining to a map; each section is introduced by the map name enclosed in square brackets (i.e., same as in SECTINFO or Windows ini files).

The mapname may be equal to "*" which means that the patch commands in there will apply to all maps; this is called a "global section". If such a section exists, as well as other "map-specific" sections, then the global section will be combined with the map-specific sections with the latter being executed after (i.e., overriding) the global section.

One could have multiple PATCHINFO lumps; they're read in WAD-loading order and their contents "added up"; if there is more than one section with the same map name (e.g., [map01] from WAD A and [map01] from WAD B), then all but the last one are discarded.

Patch commands follow a "function-like" syntax; you don't need semi-colons or other terminators/separators. Commands can span more than one line. The command parameters can consist of 'filters' and 'new values'. Delete commands only consist of 'filter' parameters, Add commands consist of only 'new value' parameters, Change commands consist of both 'filter' and 'new value' parameters. Filter parameters are used for narrowing down which things the command will match with. Using a * for a filter parameter means that the attribute of the filter will be ignored for the matching.

New values are simply new values for the attributes of the thing affected by the command. For add commands these are the values of the attributes of the new thing. For change commands these are the values that the attributes of affected things will be changed to. Using a * for a new value parameter in change commands means that the given attribute should be kept as is.

Here is an example of PATCHINFO syntax: -- Sample Syntax --

// Some comment

/* Multiple line comment */

[*]   

[map01]   

[map02]   

Patch commands
A list of Patch commands are as follows:
 * : Deletes things with a given type (i.e., of a given edit_id).  If you specify flags (in doom format) or x/y/z you can narrow down the thing matching. If for example you specify only the type, then all things having that type will be deleted. If you specify type and flags, then only things with the given type and flags will be deleted. If you specify type, flags, x and y, then you need a match on all 4 for the thing to get deleted. And if you specify all 5 parameters, then you need a match on all 5 for the thing to be deleted. If you need to specify a later value (z for example) and you don't want to specify previous values (x, y for example), you can use * for the unspecified values.
 * NOTE: if this command is used in the global section, it should NOT specify x/y/z. It will get rejected if it does.
 * : Deletes a specific thing in the map, this is specified by then given unique id number.
 * NOTE: this command cannot be used in the global section: it will get rejected.
 * : Changes things matched by the first five 'filter' parameters. You can use * to ignore some of the filters. The last 3 parameters are the new values for the angle, type (edit_id) and flags (doom format) attributes of the matched things. To keep an attribute as-is, you can use a * for the 'new value'.
 * NOTE: if this command is used in the global section, it should NOT specify x/y/z. It will get rejected if it does.
 * : Changes a specific thing in the map, which is specified by its unique id number. The last 3 parameters specify the new angle, type (edit_id) and flags (doom format) that will be set. To keep the old value, you can use * for any of the new values.
 * NOTE: this command cannot be used in the global section: it will get rejected.
 * : Adds a thing of the given type (edit_id) at position x/y and with the given angle and flags (doom format options).
 * NOTE: this command cannot be used in the global section: it will get rejected.
 * : Adds a thing of the given type (edit_id) at position x/y/z and with the given angle and flags (doom format options).
 * NOTE: this command cannot be used in the global section: it will get rejected.

Hexen format commands
 * : Changes things matched by the first seven 'filter' parameters. You can use * to ignore some of the filters. The rest of the parameters are the new values for the attributes of the matched things. To keep an attribute as-is, you can use a * for the 'new value'. The flags are in Hexen format. The parameters after new_flags are optional, if left out, the old values will be kept for them.
 * NOTE: if this command is used in the global section, it should NOT specify x/y/z. It will get rejected if it does.
 * : Changes a specific thing in the map, which is specified by its unique id number. The new flags are in Hexen format. You can use * to keep the old value instead of specifying a new value. The parameters after new_flags are optional, if left out, the old values will be kept for them.
 * NOTE: this command cannot be used in the global section: it will get rejected.
 * : Adds a thing of the given type (edit_id) at position x/y/z and with the given angle, flags (hexen format), tag, special, and arguments. The parameters after flags are optional, if left out, 0 will be used for them.
 * NOTE: this command cannot be used in the global section: it will get rejected.

SECTINFO
This is a text format lump to be added in any wad that allows to define a name for each and every sector in any level. Additionally, for team play game modes, SECTINFO allows to define the boundaries of each team, allowing for ZDaemon's scoring system to determine whether kills occur offensively or defensively.

Sector definitions use sector numbers, instead of sector tags. This makes tracking extremely easy and less taxing on the author's end. Any lump should follow the standard formatting as shown below. [map01] names = { "Area name #01" = { sectors, numbers, go, here }, "Area name #02" = { some, more, numbers, there }, }	Should many sector numbers follow up each others, you can use hyphens to link them together. This prevents you from having to write down every single number individually, and allows for mass production. See this example: "Laboratory" = { 17-28, 35-43 }, Should the level be a team play oriented one, you will find it useful to be able to define the boundaries of each base. To do so, start the lump in a similar approach to sector definition, except you are not using quotation marks this time around. Base definitions follow the same order that the client variable "team" does, which means:

[map09]
 * Base0 is the Red team
 * Base1 is the Blue team
 * Base2 is the Green team
 * Base3 is the White team

base0 = { 0-136 } base1 = { 137-292 }

In case a sector is defined twice in the same level, instead of crashing, ZDaemon will ignore the rest of the lump, allowing the author to easily fix the error. Once the author is done writing, simply import the file into your wad and name it SECTINFO. ZDaemon will automatically read it on start, no further action is required.

Game adaptations
The voices used for announcements of most CTF/Deathmatch/Team Deathmatch games were taken from and. They were compiled together by the creator of the WADs zvox.wad and zvox2.wad, and are subject to change with time. There are also some custom sound packs which are made and maintained by individual authors, and also subject to change at any time as they are independent of the main development team.

Community
The ZDaemon user community, while not formally part of the ZDaemon development program, plays a huge role in the experience of playing ZDaemon online. It features many discussion forums and many avenues to begin contributing content, and the ZDaemon team itself hosts and maintains many related resources to ensure cohesion and interoperability.

The community's discussion and gaming services include:


 * ZDaemon Chat / #zdplayers on ZDirc.
 * #zdaemon on Libera.
 * The ZDaemon Forums.
 * ZDaemon Tournaments.
 * ZDaemon Leagues.
 * ZDReview.
 * ZD Discord

Weekly gaming sessions
ZDaemon has scheduled gaming sessions each week, such as "Tuesday Night Flags," which is a weekly Capture the Flag game; "Thursday Night Survival," a weekly cooperative game where each player has a limited number of lives per round; "Friday's Monster Mash", a weekly cooperative game where players have an unlimited number of lives/respawns; "ZDaemon Sessions," which is where the staff and/or community chooses a wad/map to play each Saturday; and "Frag Your Brains Out," which is a weekly free-for-all deathmatch run every Sunday.

Other utilities
ZDaemon incorporates several custom utilities to improve the multiplayer experience for both players and server hosters. These include:

ZLauncher
The ZDaemon Launcher, also known as ZLauncher is a specialized launcher created specifically for ZDaemon. It provides an official list of currently available servers for people to play on. It also features a buddy list, GetWAD (automatic wad downloading), a quick link to ZSW (the server wizard) from the menu, a WAD file setup utility, demo recording, playback utilities, a built in chat lobby (based on IRC), and embedded forum access. It is maintained by team member Kilgore.

ZDaemon Demo Tool
The ZDaemon Demo Tool ( is a utility to edit demos from either client or server. Both the old and new  formats are supported. It is maintained by team member Kilgore.

ZDaemon Server Wizard
The ZDaemon Server Wizard is a relatively new utility for.

ZDaemon Server Monitor
The ZDaemon Server Monitor is a small utility by team member Kilgore to automatically restart the GUI version of the ZDaemon Server  in case of a crash.

To use it, copy to your server directory, rename  to, and then rename  to.

ZDaemon Server
The ZDaemon Server is the official server application for ZDaemon, allowing players to start their own servers.

ZDaemon Multi Server
The ZDaemon Multi Server is a extension to the ZDaemon server application that is currently in development. With, up to 100 instances can be created.

To use the Multi Server, it needs to be placed in the same directory as the ZDaemon Server Wizard.

ZDaemon Relay Chat
The ZDaemon Relay Chat client is a modular IRC client created by team member Kilgore which was designed for use with the ZDaemon IRC chat server. It can still act as a general-purpose IRC client. When used within ZLauncher, it automatically joins ZDaemon's IRC server, enabling users to chat other players who are logged in to ZDaemon. is a standalone version of the client which can also be used to access ZDaemon's IRC server, however the user must provide their master server account password on the connect line as the IRC server's password in order to connect.

GetWAD
This is a modular utility created by team member Kilgore that searches various repositories for third-party (WADs or .pk3 files for example), which it then downloads and extracts to the user's specified directory automatically.

Linux and Mac support
ZDaemon provides server binary builds for Linux and FreeBSD. During the 1.09 beta phase a was available for testing. An official Linux and Mac client release is planned for 1.10 or later. There is however a supported version of Lyfe's ZDaemon MacOS project that you can use. Until the arrival of a native client, users may play using emulation software such as WINE, Cedega or CrossOver. Playing using this software is allowed.

Cheating
For the most part the ZDaemon team has managed to keep cheating relatively under control through closing the source, regular security updates, and surveillance (for instance, demo recordings are often demanded during competitive tournaments to combat cheats like aimbots or wallhacks). ZDaemon contains also some kind of cheating detection system which detects third party cheat applications.

Public accusations of cheating (whether founded or not) are frowned upon as unnecessary public disturbance, with Raider once calling it a form of harassment. For this reason, it is usually requested that such reports be relegated to a private dialog with a member of the staff. The administrators maintain that they ban only when given clear evidence by their cheat detection system and stand by their policy.

Source code
The initial ZDaemon release inherited csDoom's, which made it impossible to legally assign either the GPL or DSL to the codebase. This conflict was resolved in ZDaemon 1.0 when the GPLed parts of the source code were rewritten and the project was again under the DSL, which it inherited from the ZDoom 1.22 codebase. This change allowed ZDaemon 1.0 to to include BUILD licensed code from ZDoom 1.23.

Starting with the ZDaemon 1.07 release in July 2005, the development team stopped releasing the source code due to numerous exploits and cheating incidents. Unlike the GPL, the DSL does not forbid closing the source code. This action caused some free software friendly people to distance themselves from the ZDaemon community, criticizing the move as a form of security through obscurity, though it makes development of cheats more difficult through the implementation of anti-cheating methods. The move also makes development of alternate ZDaemon clients and servers impossible, which is uncommon in the Doom community given that most ports make their source code publicly available. Skulltag, a formerly closed-source multiplayer-oriented source port, faced the same criticism until it was opened in February 2012.

The developers have stated that anyone wishing to develop a new feature or bugfix may do so using the older ZDaemon 1.06 codebase and submit it to the core development team for inclusion. The source code is for ZDaemon version 1.06.11, the binary is version 1.06.

Bans
The ZDaemon master server will only advertise servers that enforce a ban list controlled by the ZDaemon staff. Servers that do not enforce this ban list are not shown to users. The effective result of this is that the ZDaemon staff have the ability to ban anyone they choose from all ZDaemon servers advertised on the master. No ban list (or other) restrictions apply to servers not advertised on the master. While this allows the removal of cheaters, the mechanism used can occasionally block innocent players as well due to matching dynamic IP ranges. Nevertheless, it is a common banning method used by other multiplayer Doom ports and many online games in general.

Ban appeals, especially those of bystanders caught in the range bans of others, often end up as over-dramatized forum posts. For this reason, it is usually requested that such appeals be relegated to a private dialog with a member of the staff.

GetWAD
Doom source ports require a Doom IWAD file which contains the graphics, levels and other media that are used in the game. These IWAD files are still copyrighted. This means that although source ports can be freely downloaded, users must still buy a copy of Doom in order to play. ZLauncher, IDE and IDEse (Internet Doom Explorer, Skulltag Edition) allowed GetWAD to automatically locate and download any WAD files, including IWAD files, without restrictions. ZDaemon never officially condoned any form of piracy, yet some people took issue with the downloading of IWADs. More recent versions of ZLauncher and IDE block the automatic download of commercial WAD files.

Fake aimbot trojan
ZDaemon staff member Doom2pro released a, purporting to be a ZDaemon cheat, in a global cheat development forum to trick regular cheaters to download it. When run, the program would inform Doom2pro and delete the ZDaemon folder from the user's computer. Although Doom2pro acted independently of the rest of the ZDaemon staff, ZDaemon has nonetheless been criticised for his methods.

The ZDaemon team

 * Raider: Project Leader
 * AF-Domains: Administration and development
 * damo2k: Development
 * Doom2pro: Development
 * Evolution: ZDaemon Steam group administrator / Tournament administrator
 * Flambeau: Channel Operator / Forum Moderator
 * Kilgore: Development and support
 * Krawa: Development
 * Lyfe: Development
 * Phenex2: Development and support
 * Rhinoduck: Development
 * UberGewei: Development
 * Venom: Development
 * Worst-vd-plas: Development

Notable WADs
Because of the various unique enhancements offered by ZDaemon, the port has its own notable mapsets. Some of these are unique, such as ZDaemon City, while others are a conversion, originally designed for a different port, such as Valiant or Ancient Aliens. They take advantage of the new features offered by ZDaemon or to make them compatible for multiplayer play. A list of notable WADs include:
 * Ancient Aliens (Conversion by Rhinoduck)
 * Batman Doom (Conversion by Ubergewei)
 * Doom 64 for Doom II (MAPINFO fixes by damo2k)
 * Epic 2 (Conversion/enhancements for multiplayer by Krawa)
 * Eviternity (Conversion by damo2k)
 * Obituary (Conversion/fixes/merging by Ubergewei)
 * Valiant (Conversion by Aeyesi)
 * ZDaemon City
 * ZDMegaCTF