Difference between revisions of "ZDaemon"

From DoomWiki.org

[checked revision][checked revision]
m (It is spelt Freedoom, not FreeDoom.)
(Revision: Radical overhaul of the page. Included descriptions of utilties, new lumps based on ZDaemon posts, and various other info. It should now be more clear what ZDaemon's capabilities are.)
Line 42: Line 42:
 
===Other features===
 
===Other features===
 
* Partial support of [[ACS|ACS scripting]]
 
* Partial support of [[ACS|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
 
* Advanced netcode for smoother movement
 
* [[Demo]] recording (Client and Server side)
 
* [[Demo]] recording (Client and Server side)
Line 54: Line 55:
 
* Unlagged
 
* Unlagged
 
* Extended nodes: ZDBSP Compressed and Uncompressed types
 
* 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 {{c|SITREP}} 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 [[lump]]s 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====
 +
{{main|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====
 +
{{About|the exclusive standard used by the ZDaemon [[source port]]|the similarly named more universal standard|DEHEXTRA}}
 +
This lump allows DeHacked patches to be ''stackable'', utilizing the ''include'' directive.
 +
 +
Here is an example of a patch inside a WAD:
 +
<pre>
 +
Patch File for DeHackEd v3.0
 +
Doom version = 21
 +
Patch format = 6
 +
 +
#Include some extra DeHackEd stuff!!!
 +
 +
Include EXTRADEH
 +
</pre>
 +
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:
 +
<pre>
 +
Thing 1 (Player)
 +
Bits = SOLID + SHOOTABLE + DROPOFF + PICKUP + NOBLOOD + NOTDMATCH + TRANSLUCENT
 +
 +
#Here's another comment.
 +
</pre>
 +
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:
 +
<pre>
 +
Patch File for DeHackEd v3.0
 +
Doom version = 21
 +
Patch format = 6
 +
 +
#Include some extra DeHackEd stuff!!!
 +
 +
Thing 1 (Player)
 +
Bits = SOLID + SHOOTABLE + DROPOFF + PICKUP + NOBLOOD + NOTDMATCH + TRANSLUCENT
 +
 +
#Here's another comment.
 +
</pre>
 +
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:
 +
<pre>
 +
Include EXTRADEH
 +
Include EXTRAWEP
 +
Include EXTRAMON
 +
Include EXTRAMSC
 +
</pre>
 +
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 {{c|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'':
 +
 +
* {{c|zdaemon.exe -file dwango5.wad xdehload.wad pk_weapons_zd_extradeh.wad}}
 +
 +
====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 (ie., 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 (ie., 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 (eg., [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:
 +
<pre>
 +
------------------------------------------------------------------
 +
Sample Syntax
 +
------------------------------------------------------------------
 +
 +
// Some comment
 +
 +
/* Multiple
 +
    line
 +
comment */
 +
 +
[*]
 +
<some global patch commands>
 +
<more global patch commands>
 +
<more global patch commands>
 +
 +
[map01]
 +
<some patch commands for map01>
 +
<more patch commands for map01>
 +
<more patch commands for map01>
 +
 +
[map02]
 +
<some patch commands for map02>
 +
<more patch commands for map02>
 +
<more patch commands for map02>
 +
</pre>
 +
 +
=====Patch commands=====
 +
A list of Patch commands are as follows:
 +
* {{c|Thing_Delete (type [, flags [, x [, y [, z] ] ] ] )}}: Deletes things with a given type (ie., 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.
 +
* {{c|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.
 +
* {{c|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.
 +
* {{c|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.
 +
* {{c|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.
 +
* {{c|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'''
 +
* {{c|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.
 +
* {{c|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.
 +
* {{c|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.
 +
 +
====SECTINFO====
 +
This 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 weither 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.
 +
<pre>
 +
[map01]
 +
names = {
 +
  "Area name #01" = { sectors, numbers, go, here },
 +
  "Area name #02" = { some, more, numbers, there },
 +
}
 +
</pre>
 +
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:
 +
<pre>
 +
  "Laboratory" = { 17-28, 35-43 },
 +
</pre>
 +
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 your 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
 +
<pre>
 +
[map09]
 +
 +
base0 = { 0-136 }
 +
base1 = { 137-292 }
 +
</pre>
 +
 +
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===
 
===Game adaptations===
Line 59: Line 222:
  
 
== Community ==
 
== 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 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.
  
Line 79: Line 241:
  
 
== Other utilities ==
 
== Other utilities ==
 +
ZDaemon incorporates several custom utilities to improve the multiplayer experience for both players and server hosters. These include:
 +
 
====ZLauncher====
 
====ZLauncher====
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.
+
The ZDaemon Launcher, also known as ''ZLauncher'' ({{c|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====
 +
The ZDaemon Demo Tool ({{c|ZDdemotool.exe}} is a utility to record [[demo]]s from either client or server. Both the old {{c|.zdo}} and new {{c|.zdd}} formats are supported. It is maintained by team member Kilgore.
  
 
====ZDaemon Server Wizard====
 
====ZDaemon Server Wizard====
This is a relatively new utility for {{ZDaemonforums|t=17335|creating a ZDaemon server}}.
+
The ZDaemon Server Wizard ({{c|ZSWizard.exe}}) is a relatively new utility for {{ZDaemonforums|t=17335|creating a ZDaemon server}}.
 +
 
 +
====ZDaemon Server Monitor====
 +
The ZDaemon Server Monitor ({{c|ZSMon.exe}}) is a small utility by team member Kilgore to automatically restart the GUI version of the ZDaemon Server (c|{{ZServ32.exe}}) in case of a crash.
 +
 
 +
To use it, copy {{c|zsmon.exe}} to your server directory, rename {{c|zserv32.exe}} to {{c|zserv32.bin}}, and then rename {{c|zsmon.exe}} to {{c|zserv32.exe}}.
 +
 
 +
====ZDaemon Server====
 +
The ZDaemon Server ({{c|ZServ32.exe}}) is the official server application for ZDaemon, allowing players to start their own servers.
 +
 
 +
====ZDaemon Multi Server====
 +
The ZDaemon Multi Server ({{c|ZSMulti.exe}}) is a extension to the ZDaemon server application that is currently in development. With {{c|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====
 
====ZDaemon Relay Chat====
This 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.
+
The ZDaemon Relay Chat client ({{c|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. {{c|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.
  
 
====GetWAD====
 
====GetWAD====
Line 158: Line 338:
 
* '''Venom''': Development
 
* '''Venom''': Development
 
* '''Worst-vd-plas''': 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 are wholly unique, such as ZDaemon City, others are a conversion, originally designed for a different port, such as Valliant: Vaccinated Edition. A list of notable WADs include:
 +
* Valliant: Vaccinated Edition
 +
* ZDaemon City
  
 
== Sources ==
 
== Sources ==
Line 167: Line 352:
 
== External links ==
 
== External links ==
 
* [https://www.zdaemon.org/ ZDaemon.org]
 
* [https://www.zdaemon.org/ ZDaemon.org]
 +
* [https://www.zdaemon.org/index.php?CMD=info&NAME=acs ZDaemon ACS Extensions list and descriptions]
 +
* [https://www.zdaemon.org/index.php?CMD=info&NAME=deh ZDaemon DeHacked Extensions list and descriptions]
 +
* {{ZDaemonforums|t=17109|DEHSUPP desciption}} at the ZDaemon forums
 +
* {{ZDaemonforums|t=15968|DEHSUPP Documentation Generator (DDG)}} at the ZDaemon forums
 +
* {{ZDaemonforums|t=12466|EXTRADEH desciption}} at the ZDaemon forums
 +
* [http://master.zdaemon.org/patchinfo.txt PATCHINFO description], at ZDaemon.org
 +
* {{ZDaemonforums|t=17328|SECTINFO desciption}} at the ZDaemon forums
 +
* {{ZDaemonforums|t=17329|SITREP desciption}} at the ZDaemon forums
 +
* [http://hs.keystone.gr/zdmaps/ ZDaemon MAP browser] for screenshots and info on various maps played on ZDaemon
  
 
{{featured article}}
 
{{featured article}}

Revision as of 09:55, 21 June 2021

ZDaemon
ZDaemon 109 Logo.png
Standard Doom, Boom, Heretic
Codebase csDoom
Developer(s) AF-Domains, damo2k, Doom2pro, Kilgore, Krawa, Lyfe, Phenex2, Raider, Rhinoduck, UberGewei, Venom, Worst-vd-plas
Initial release 0.8 (2001-02-20, 20 years ago)
Latest release 1.10.19 (2021-05-17, 2 months 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.19 (2021-05-17). 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.

Features

Supported games

Hexen is now mostly supported. Getting the rest completed is on the project roadmap.

Supported game modes

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.)
  • Ingame voice chat
  • Super-Sampling Anti-Aliasing
  • Vampire mode
  • InstaGib
  • Dynamic bots
  • Killingspree announcer
  • Ingame 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

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

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.

EXTRADEH

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!!!

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

#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)
Bits = SOLID + SHOOTABLE + DROPOFF + PICKUP + NOBLOOD + NOTDMATCH + TRANSLUCENT

#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:

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 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

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 (ie., 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 (ie., 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 (eg., [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 */

[*]
<some global patch commands>
<more global patch commands>
<more global patch commands>

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

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

A list of Patch commands are as follows:

  • Thing_Delete (type [, flags [, x [, y [, z] ] ] ] ): Deletes things with a given type (ie., 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.

SECTINFO

This 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 weither 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 your 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
[map09]

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 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 soundpacks 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:

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.

Clan activity

Main article: Clans

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 (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

The ZDaemon Demo Tool (ZDdemotool.exe is a utility to record 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

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

ZDaemon Server Monitor

The ZDaemon Server Monitor (ZSMon.exe) is a small utility by team member Kilgore to automatically restart the GUI version of the ZDaemon Server (c|Template: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

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

ZDaemon Multi Server

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

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.

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 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.

History

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.

2004

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.

Criticism

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 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.

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

Fake aimbot trojan

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

  • 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 are wholly unique, such as ZDaemon City, others are a conversion, originally designed for a different port, such as Valliant: Vaccinated Edition. A list of notable WADs include:

  • Valliant: Vaccinated Edition
  • ZDaemon City

Sources

See also

External links

Source code genealogy
Based on
csDoom
ZDaemon 1.06 Merged
Based on
ZDoom 1.22
Base for
X-Doom
Based on
ZDaemon 1.06
ZDaemon Closed source