From DoomWiki.org

Zdaemon logo 1.png
Standard Doom, Boom, Heretic
Codebase csDoom
Developer(s) AF-Domains, damo2k, Doom2pro, Kilgore, Krawa, Lyfe, Phenex2, Raider, UberGewei, Venom, Worst-vd-plas
Initial release 0.8 (2001-02-20, 22 years ago)
Latest release 1.10.24 (2023-11-21, 17 days ago)
Development status Active
Written in C++
Target Platform Windows, Cross-Platform (Server Only)
License Doom Source License, 3-point BSD, others
Website zdaemon.org
Screenshot of ZDaemon Launcher

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 1.10.24 (2023-11-21). 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[edit]

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

Supported game modes[edit]

Other features[edit]

  • 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) / Ultrawide (21:9) / Superwide (32:9)
  • Raw Input for Keyboard and Mouse (not currently via WINE)
  • 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 SITREP command variable, short for Situation Report

New lumps[edit]

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:


Main article: 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.


This article is about the exclusive standard used by the ZDaemon source port. For the similarly named more universal standard, see DEHEXTRA.

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

#Include some extra DeHackEd stuff!!!


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)

#Here's another comment.

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

#Include some extra DeHackEd stuff!!!

Thing 1 (Player)

#Here's another comment.

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.

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:


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

To use the EXTRADEH feature in a WAD that contains no DeHackEd, a separate WAD called xdehload.wad 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:

  • zdaemon.exe -file dwango5.wad xdehload.wad pk_weapons_zd_extradeh.wad


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
comment */

<some global patch commands>
<more global patch commands>
<more global patch commands>

<some patch commands for map01>
<more patch commands for map01>
<more patch commands for map01>

<some patch commands for map02>
<more patch commands for map02>
<more patch commands for map02>
Patch commands[edit]

A list of Patch commands are as follows:

  • Thing_Delete (type [, flags [, x [, y [, z] ] ] ] ): 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.
  • Thing_ById_Delete (id): 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.
  • Thing_Change (type, flags, x, y, z, new_angle, new_type, new_flags): 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.
  • Thing_ById_Change (id, new_angle, new_type, new_flags): 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.
  • Thing_Add (type, x, y, angle, flags): 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.
  • Thing_AddZ (type, x, y, z, angle, flags): 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

  • ThingH_Change (type, flags, tag, special, x, y, z, new_angle, new_type, new_flags, new_tag, new_special, new_arg1, ..., new_arg5): 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.
  • ThingH_ById_Change (id, new_angle, new_type, new_flags, new_tag, new_special, new_arg1, ... , new_arg5): 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.
  • ThingH_Add (type, x, y, z, angle, flags, tag, special, arg1, arg2, arg3, arg4, arg5): 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.


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.

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:

  • 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[edit]

The voices used for announcements of most CTF/Deathmatch/Team Deathmatch games were taken from Quake III Arena and Unreal Tournament. 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.


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:

Weekly gaming sessions[edit]

ZDaemon has scheduled gaming sessions each week.

Some are hosted by teams formed by members of the ZDaemon community, others are run independently.

The currently active scheduled gaming sessions are:

  • Wednesday Night Deathmatch ([free-for-all]) - US - This is run independently by the US Quake and Doom Community team. It rotates between ZDaemon and Zandronum every 2 or so weeks.
  • Thursday Night Survival - European - This is run by the TNS team.
  • Friday Night Survival - US - This is run independently by the US Quake and Doom Community team.
  • ZDaemon Sessions (Saturday; varying game modes) - European - This is run by the ZDS team.
  • Wadazine Flag Fest (Sunday; Capture the Flag) - US - This is run independently by the Wadazine team.

Inactive gaming sessions:

  • Tuesday Night Takedown (varying game modes from Capture the Flag, Double Domination and [free-for-all]) - US - This is run independently by the [RAMPAGE] team.
  • Frenchies' Chaotic/Regular Tuesdays (various soft-coded game modes) - European - This was run by the FCT team.
  • Wednesday/Tuesday Night Flags (Capture the Flag) - European/US - Originally run by the WNF/TNF team(s).
  • Friday's Monster Mash (Cooperative) - European/US - This was run by the FMM team.
  • Frag Your Brains Out (Sunday; [free-for-all]) - European/US - This was run by the FYBO team.


In the past (going as far back as December 2003) various community members ran the official ZDaemon Tournaments.

There were three generations of these tournaments:

  • Ancient - December 2003 until September 2008
  • External European - January 2009 until April 2011
  • Legacy - February 2011 until March 2020

The tournaments categorized as "Ancient" have since been recovered and imported onto the official Tournaments site.

Tournaments categorized as "External European" were hosted by both dewww and Gyrossman at the time; aside from three that don't conform to what was available on the official site at the time, the rest are now available (the three cases will eventually be included).

It should be noted that there was some overlap between the start of the now-Legacy tournaments and the end of the External European type.

Thanks to dewww for providing the tournament brackets from the time.

As of August 2022 linkage has been established between the vast majority of participants on those Ancient/Legacy tournaments and their official ZDaemon profile. (Names that no longer exist in their original form but have a known and related alias have been used as the linkage point.)

As of the 28th of February 2023 the import of External European tournaments has been completed with linkage established against the participants' official ZDaemon profiles.

The tournament participation will also now show up on the official ZDaemon player profile page.

New official tournament activity is planned upon the completion of a new system that is being developed.

Clan activity[edit]

Main article: Clans

Other utilities[edit]

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


The ZDaemon Launcher, also known as ZLauncher (ZLauncher.exe) 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[edit]

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

ZDaemon Server Wizard[edit]

The ZDaemon Server Wizard (ZSWizard.exe) is a relatively new utility for creating a ZDaemon server.

ZDaemon Server Monitor[edit]

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

To use it, copy zsmon.exe to your server directory, rename zserv32.exe to zserv32.bin, and then rename zsmon.exe to zserv32.exe.

ZDaemon Server[edit]

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

ZDaemon Multi Server[edit]

The ZDaemon Multi Server (ZSMulti.exe) is a extension to the ZDaemon server application that is currently in development. With ZSMulti.exe, 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[edit]

The ZDaemon Relay Chat client (Zrc.exe) 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. Zrc.exe 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.


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.

As of July 11, 2022, GetWAD supports HTTPS.

Linux and Mac support[edit]

ZDaemon provides server binary builds for Linux and FreeBSD. During the 1.09 beta phase a Mac client 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.


Year Developments
2001 On January the 31th, Sergey Makovkin (Fly) ceased development of his client/server modification of ZDoom 1.22, csDoom.

Nightfang used csDoom 0.7 as a base for his own port named ZDaemon and released ZDaemon 0.8 on February the 20th at www.truelights.com. On March the 11th, March the 12th, June the 2nd, June the 18th and July the 5th, versions 0.9, 0.92, 0.95, 0.96 and 0.99 were released, respectively.

2002 In March, the ZDaemon homepage moved to www.zdaemon.com.

To improve the network code for ZDaemon 1.0, Nightfang rewrote the core netcode, which eliminated the GPLed QuakeWorld networking code that Fly incorporated in csDoom and thus resolved the conflicting licenses that ZDaemon inherited from csDoom (GPLed Quakeworld code and DSLed ZDoom) and allowed the developers to include code from ZDoom 1.23 and later versions without conflict. The ZDaemon core codebase was updated to ZDoom 1.23 beta 33, which, among other things, added support for Heretic and slopes. ZDaemon 1.0 was released in November, followed by ZDaemon 1.02 a few days later and ZDaemon 1.03 in December.

2003 In early 2003, the ZDaemon homepage moved to www.zdaemon.org.

In April, ZDaemon 1.04 was released followed by ZDaemon 1.04c and ZDaemonGL 1.04 in June. Shortly thereafter, Nightfang retired from the ZDaemon project and Raider became the new project leader. In August, Kilgore joined the team and started working on a teamplay mode for ZDaemon. Furthermore, a gradual rewrite of the netcode was carried out over the following major releases. ZDaemon 1.05 was released in October, bundled with GetWAD for automatic WAD downloads.


In March, ZDaemon 1.06 was released and after numerous point releases throughout the year the last version where the source was available, 1.06.08, was released in November.

2005 - Today Starting with the 1.07 release in July 2005, the ZDaemon project ceased to make source code available and has remained closed source from that point forward (see Source Code). In August 2005, ZDaemon 1.07.01 was released and unlagged support was added. In December 2005, ZDaemon 1.08 was released. For more information on subsequent releases including the current version, see the ZDaemon changelog.



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[edit]

The initial ZDaemon release inherited csDoom's conflicting licenses, 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.


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.


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 [1]. More recent versions of ZLauncher and IDE block the automatic download of commercial WAD files.

Fake aimbot trojan[edit]

ZDaemon staff member Doom2pro released a trojan program, 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[edit]

  • Raider: Project Leader
  • AF-Domains: Administration and development
  • damo2k: Development
  • Doom2pro: Development
  • Evolution: ZDaemon Steam group administrator / Tournament administrator
  • Kilgore: Development and support
  • Krawa: Development
  • Lyfe: Development
  • Phenex2: Development and support
  • UberGewei: Development
  • Venom: Development
  • Worst-vd-plas: Development

Notable WADs[edit]

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:


See also[edit]

External links[edit]

Source code genealogy
Based on
ZDaemon 1.06 Merged
Based on
ZDoom 1.22
Base for
Based on
ZDaemon 1.06
ZDaemon Closed source