ZDoom multiplayer setup, troubleshooting and FAQ

[edward850]

ZDoom multiplayer setup, troubleshooting and FAQ
(This guide assumes you are using the latest possible ZDoom version. You can find these at http://devbuilds.drdteam.org/zdoom/. GZDoom also applies to this FAQ.)

Word Index
Some words are mentioned in this thread that may need explanation. It’s a safe idea to learn what these words mean, even if you think you know, as these descriptions are ZDoom specific:

• Arbitrator (net_arbitrator)
  The initial game controller. Typically the initiator of the game, this player controls settings and flags.
• Node
  A unique session connected to a ZDoom netgame. While a node is not necessarily a player, there is presently no scenario where a node has no player attached, and thus presently all nodes will have an active player regardless. A node number does not need to match a player number, and node 0 will always be the local session.
• ConsolePlayer
  The player number of the local session. This value will logically be different for every node, as each node controls a different player.
• Gametic
  The current frame ZDoom is running. This value can never advance past the last complete set of nettics, and can never decrease.
• Nettic
  An input frame of a player. Each node shares nettics with each other node to complete a frame. All nodes share the same nettics as this is what the game uses to complete frames.
• Lowtic
  The lowest nettic an individual node has out of all nodes. The gametic cannot go any faster than the lowtic.
• UDP
  Stands for User Datagram Protocol. ZDoom uses this to communicate due to the smaller header size and overall faster response. ZDoom uses Reverse Acknowledgement (the act of only acknowledging data that is absent, rather than data that turns up) to make sure all data is received, and re-requests anything that happens to be missing.

Setting up a ZDoom netgame

(For the purposes of this FAQ, this thread implies you have an understanding of the Windows Command Prompt or Linux/Unix terminal for launching programs. While there is nothing stopping you from using a launcher like ZDL, said launchers tend to make up their own rules, usually due to a lack of understanding of the commands, and not match or include relevant features, thus tend to be inaccurate.)

By popular demand, I have created this thread explaining the basic ins and outs of setting up and running ZDoom multiplayer games. Refer to the FAQ at the end and feel free to ask any questions not answered by this mega-post/FAQ.
ZDoom netgames use UDP with IPv4, regardless of how you set them up. Using port 5029 UDP (by default), and requiring all nodes to have their NAT properly configured depending on net framework. If you have no idea what any of those words meant, this is the guide for you.

To start off, you want to host a game (initiate and control a netgame), you need to properly configure your network to be properly contactable. If you are playing a LAN game, this step can be ignored (as your LAN should already be fully traversable).

First, you need to know what to do with your router. Assuming you have at least a broadband connection, your router will need to be configured to allow remote nodes to send traffic to your computer, and thus ZDoom. As there is many different kinds of router manufacturers and network configurations, this guide can’t cover this specifically, only with the basic information. There are a lot of websites that will guide you with the setup specific to your router (namely http://portforward.com/).
By default, ZDoom uses port 5029 UDP to communicate, so as long as you can configure that to be routed to your PC, you're all set. Only the arbitrator needs to configure this for all nodes to connect. However, hole punching is used to establish all other connections with 3 or more players.

In ZDoom Peer-to-Peer, with just 2 players, the joining player doesn't need to receive anything from any other connection, thus the router usually already knows where the traffic needs to go.
With 3 or more players, all nodes use the aforementioned hole punching as noted above. This normally works out absolutely fine, but some routers (and even ISPs) block multiple incoming connections to a single socket from unrouted ports. And in incredibly rare cases, even routed connections (like Xaser's, seen in this thread).
Packet-Server games don't need to follow the above behaviour for 3+ player games, as they use the same networking behaviour for 2 player games for every remote node. However, be advised that if the host leaves, the game has a chance of locking up as the next node won't be able to maintain the connection.

So, hopefully your network is now setup to run a multiplayer game. Now we can start launching ZDoom. This is where the command line comes into play.

To host a simple ZDoom game, we can do the following:

Code: Select all

zdoom.exe -host 2

That’s it. This will run a ZDoom game in multiplayer co-op with 2 players (yourself and 1 other). Want more players? Just bump up the number specified by the -host command (maximum is currently 8). Joining the game is just a simple, although it does require the IP address or hostname of the host to connect to. In a LAN game, this will typically be an address starting with 192.168 or 10.0, or the hostname of the PC (such as “user-desktop” or “study-pc”). So to connect to “study-pc”, we would use the following:

Code: Select all

zdoom.exe -join study-pc

When hosting the game, you will be presented with a screen that will look like this (post IWAD selection screen):

Host.png

This will be presented while the host actively waits for all player slots to be filled up. This does also mean that the exact number of slots you used must also be filled; as you cannot launch the game early. So make sure you know this in advance (players cannot join while the game is already running).

As each player joins, the player count indicated will increase, and once that reaches the total, the game will start. You will see the usual ZDoom gobbledygook as it sets up the game, plus some additional information about which players are present and there player/node number. Joining players will actively see the player count increase once they join and wait for other players to also join, presented the same as above.

Multiplayer launch settings
So now your ZDoom game is running. You have killed some imps and wonder how else you can play multiplayer. Like Deathmatch or custom wads. Depending on what the setting is, only the arbitrator will need to specify these commands.
(A full list of launch commands and server variables is available on the ZDoom wiki)

Custom wads are set as per usual, with the -file parameter. All players will need to have the exact same mods loaded to keep the game consistent, as the arbitrator does not dictate this.
So, for example, if you wanted to load everyone's favourite deathmatch wad, UDMX, all players will need to append udmx.wad to their -file commands:

Code: Select all

zdoom.exe -host 2 -deathmatch -file udmx.wad

Code: Select all

zdoom.exe -join 123.45.67.89 -file udmx.wad

You will also notice the -deathmatch command. This sets the gamemode for the current game to deathmatch (as expected), but you will also notice that the remote player joining doesn't specify this. While files loaded aren't shared in the netgame, the game settings are, such as deathmatch, dmflags and various other gameplay specific commands. Although there is no harm redefining this when joining, as anything that the joining player is already informed about is ignored, so there’s no risk in, say, accidentally changing the skill level if you a joining a game. Gameplay options, like DMFLags, can be added as launch commands by the host, but a defined slightly differently:

Code: Select all

zdoom.exe -host 2 -deathmatch -file udmx.wad +dmflags 545796 +map map02

This will start a ZDoom game with the additional DMFLags defined, as well as set the starting map to map02. Like before, any joining players do not these additional commands.

There are some specific settings to multiplayer, however, which control how the netgame functions. These settings can radically improve performance in various cases, but also note they can also reduce the responsiveness of the game. As before, only the host needs to set these:

• -dup # (1-5)
  Reduces the packet load by dividing the number of player input frames sent per second. The default value is 1, which means 35 nettics a second. setting it to 2 will logically reduce this to 17 nettics a second. ZDoom will still run at 35Hz a second, and skipped frames are averaged out between inputs. “-dup 2” is usually unnoticeable to most players. (5 is pretty much considered borderline unplayable, as this limits input to 7 tics a second. Hence why anything higher is unavailable.)
• -extratic
  Duplicates every packet sent. In connections where packets are dropped periodically, this can improve performance, but logically will also double the bandwidth cost (although it isn't that much to begin with). Usually helpful with wireless connections therefore.
• -netmode # (0 or 1)
  Changes the netmode. This will greatly change the performance and complexity of network traffic depending on the setting. 0 is peer-to-peer where all nodes are treated as (and required to be) hosts. 1 is Packet-server which is easier to setup at the cost of performance, as the arbitrator will always send out its currently active lowtic, which means the slowest possible packet. Usually fine on LAN, but Internet games can be greatly affected by this in responsiveness. It should also be important to note that while the netmode is reported as a netgame starts, only the arbitrator's matters. Netmode reported by all other nodes has no effect.
• -port # (default 5029)
  Changes the port this local session communicates on. This is only useful if the network needs a different port due to configuration. Do note that this also changes the port ZDoom expects to connect to, so if the host is still using port 5029, you will need to append their port to the end of the address (123.45.67.89:5029, for example). Guests automatically use a random port assigned by their socket manager, regardless of the port setting.

Loading saved games
Loading games must be done by all players (otherwise the game will desync on the first frame), and must all use the loadgame launch command. -loadgame <filename.zds> covers this. All players must also have a proper copy of the saved game, either their own or one provided by another player. The player order is maintained via player names. Additional players can be introduced when loading games. If new players are detected, they either replace the slots of players that are missing, or spawn in as if they were a new player entirely.

In game
Various things (actions, occurrences and messages) can occur in game. These are either player controlled or otherwise.

Saving
You can save the game at any time, and any player can do this. When a game saves, it will save on all sessions as well. Like vanilla, be careful with save-slots, as you can accidentally replace a save on somebody elses end (this can be avoided completely by defining a custom name for the save using the “save” console command.) Unlike vanilla, save sessions have their description maintained over the network, so you have something more informative than “netgame” as the description.

Loading
Loading cannot currently be done in game, and must be done as a launch command. See above in "Multiplayer launch settings".

Pausing
You cannot pause the game by opening the menu, but the pause button still works. Any and all players can pause the game at any time (and likewise, unpause the game regardless of who paused it).

Chat
Players can chat at any time by pressing the T key (by default). Does the same thing as vanilla, although you can no longer chat to specific players (however there is a team chat command for team games).

Disconnecting
Any player can disconnect at anytime. Unlike vanilla, this player will simply vanish from the game when this happens. At this point in time, demo recordings are ended the moment any player leaves, however.

“Waiting for” message

waiting.png

This message occurs if a node is taking too long to send their next nettic. During this time, ZDoom will attempt to request a resend for the missing nettic. The number is the player number you are waiting for (1 based). The game is still functional during this time, so the menu can still be accessed if needed.

Troubleshooting
This section is useful if you are having troubles starting a game.

When joining a game, it just sits there saying “contacting host”

• The host may not have actually started the game yet. ZDoom will keep contacting the host until heat-death, so there is no harm waiting in this screen.
• Make sure the host’s network is properly configured, and that port 5029 UDP (if left at the default) is properly forwarded to their local machine if playing an internet game.
• Make sure the IP address handed to you is valid for the type of network being played. A LAN address (typically 10.*.*.* or 192.168.*.*) is useless over the internet, as this will never match the remote host you’re trying to contact.
• Like wise, WAN addresses are useless for LAN games, as routers are typically not designed to loopback this information to the relevant host (if you know this should work on your network, you wouldn’t need to be looking at this guide, by the way.)
• If the host has already started the game, it cannot be connected to. It can only be contacted during startup.
• 5.*.*.* addresses, that old VPNs use, weren't actually reserved for VPN use, so having a VPN installed like hamachi may conflict with this address if it’s actually a WAN address.

The game appears to be shaky or keeps stuttering

• Make sure the connection is clear, and that no bandwidth intensive processes are running, like torrents. This counts for anybody in the game, not just yourself.
• Somebody's network may not designed or struggling to keep up with a 35Hz packet load. This shouldn’t be a modern problem but poorly configured or crowded wireless connections tend to exhibit this behaviour. Try running the game with a higher dup value (-dup 2, for example) to improve this.
• Also with wireless connections, -extratic may improve issues with packetloss.
• If you are playing on Packet-Server, try using Peer-to-Peer instead (-netmode 0). Take note of the setup guide above to be sure this is properly configured.

The game seems to be rather slow (i.e a long response time to actions like shooting)
Like with above, try peer-to-peer rather than packet-server. Packet server can only route information at the speed of the slowest player, at-least doubling response times of a standard game. This tends to be rather unplayable over the internet.

My game stopped on the very first frame in peer-to-peer with the "waiting for" message, and some players sometimes just have a black screen
In peer-to-peer, if a node cannot be contacted properly, the game will appear to lock up as nettics fail to get delivered. Make sure all players have properly configured their network and try again. Do note that peer-to-peer requires hole-punching with 3 or more nodes over an internet connection. Some networks (such as business networks) forbid this, which will cause the game to lock at startup, producing the above symptom.
In rare cases, this may be a router blocking traffic as it can trigger security measures such as DDos protection, as the traffic is coming from unexpected sources.

Also note: Hybrid LAN/WAN games (games between both LAN nodes and Internet nodes) are currently impossible in Peer-to-peer, as socket addresses won’t match their expected destinations (and thus will match the presented symptoms). As the old command -net has long since disappeared, there is currently no way to resolve this, outside of playing with Packet-server or on a VPN.

I get a message at the top of the screen saying “out of sync”

sync.png

The game’s consistency has failed. The usual culprit is a player loading a different set of mods (this includes autoloads) from the rest of the players. Consistency is tested using a combination of RNG information and player positioning, and if any of these offset differently from other players, the check will fail.
Do note that it is possible for a player to see this message on their own end but not another. This usually indicates that something about the player has shifted (like their position). Make sure that all players are running the exact same version of ZDoom, the same mods and loading the same saves, wherever applicable.
A mod itself can also cause this behaviour by using an indeterminate feature.

FAQ
Have another question? Feel free to ask it. This section will be updated as needed.

What causes the message “Net decompression failed”?
This message can show up time to time on malformed packets. ZDoom will discard these and wait for a proper packet. The message itself is rare, nowadays.

What causes the message “Dropped packet: Unknown host (‘address’)”?
This shows up if a remote connection attempts to contact you that isn't part of the game. This will either be garbage data from an old connection on the same port (it doesn't have to be from ZDoom), or a player trying to connect while the game is already running.

What is the most intensive map ZDoom can play?
Everything. No really. Map complexity has no effect on network performance. All the data transmitted is player input (which is delta encoded and compressed). You could play NUTS.wad which will have no change on network performance (other than individual computers slowing down by all the object processing).

Can latency cause consistency issues?
Not under normal conditions, no. It would require a difference of ~64 tics (at least 2 seconds) at the least to confuse ZDoom with which packet is the next one, which isn't remotely achievable on even cross-country Internet connections. Due to the way ZDoom handles all traffic data, it will always wait for nettics it doesn't have at a threshold of 16 tics (half of the input cycle buffer), and will never continue past that or process a gametic without a complete message from all nodes.

[Xaser]

I managed to get my system to that I can join games (i.e. ports forwarded), but I can't host -- nobody can connect to my game. What would cause this?

[EDIT] I should clarify that I'm able to join a 3+ player game (netmode 0), so my system should allegedly work just fine with hosting as well as joining. It's not. D:

[Skrell]

I recently found out that it was possibly to play multiplayer with ZDOOM, whereas before i thought this was ONLY possible with Zandronum, my question is does this guide apply equally to GZDOOM ?

[edward850]

Considering ZDoom's networking is A, older than Skulltag (and thus Zandro) and B, technically older than ZDoom itself because C, It's inherited from the Linux Doom 1.10 source release (and thus Vanilla Doom), such a comment is rather surprising to say the least.

And yes, everything here applies to GZDoom equally as such. Nothing changes, however just as a note they shouldn't be mixed. All the network instructions are the same, however there's some components as part of how the GL renderer does things that make their playsim code subtly different.
The same should be said about ZDoom 64bit, just as a note, however only as a precautionary. 32 and 64bit should be compatible with each other, but it's not immediately obvious if all the float math will do the same thing between the two build types. Although myself and edward-san do track down such issues between the two from time to time.

[Matt]

How do you set fraglimit (or other cvars) in the command line? +(set) fraglimit never seems to work for me.

[edward850]

Code: Select all

+fraglimit 69

[Matt]

So why do these not work? (no error message or anything, just always return fraglimit 0):

Code: Select all

gzdoom -file hd/hd.pk7 downloads/bauhaus.wad -warp 02 -nomonsters -host 1 +fraglimit 1
gzdoom -file hd/hd.pk7 -warp 02 -nomonsters -deathmatch -host 1 +fraglimit 1

[edward850]

Both of those commands exactly as typed work for me? Fraglimit in the console returns 1.

[Matt]

Latest version of GZDoom fails when -file is used, latest ZDoom is fine - seems like a bug that should be fixed once GZDoom updates.

EDIT because this really isn't worthy of a bump:

Changed my "gzdoom" script from

Code: Select all

~/doom/./gzdoom $1 $2 $3 $4 $5 $6 $7 $8 $9

to

Code: Select all

~/doom/./gzdoom $*

and everything runs fine.

[Edward-san]

Not sure to know what are you talking about. If I run:

Code: Select all

gzdoom -iwad DOOM2.WAD -file ICARUS.WAD -warp 02 -nomonsters -deathmatch -host 1 +fraglimit 1

it works fine.

[Beast Node]

Hey what am i suppost to do with this i am very confused
zdoom.exe -host 2

[edward850]

That's correct. The remote player will the use:

Code: Select all

zdoom -join <your IP/HOSTNAME>

Generally, it's more helpful to read the FAQ first, because the very first section explains this and it saves repeating information.

[Zeke]

How do you get rid of the "Waiting for ..." message?

Currently when I load a co-op game of Hexen, this message shows up ("Waiting for 1 2") on both machines yet we are still able to move around and play. I've tried waiting it out, killing both players and changing areas in game. Out of game I've tried changing the netmode from 1 to 0 but that didn't do anything either...

Command parameters for host
-host 2 -warp 01 -skill 4 -netmode 1 +set sv_cheats 1 +set sv_weapondrop 1 +set sv_noweaponspawn 1 +set sv_cooploseinventory 1 -loadgame save13

Command parameters for others
-join 192.168.0.8 -loadgame save13

We're basically sitting right next to each other directly connected to the modem (so not over wireless). We're both using the exact same files (GZDoom, no mods, hexen.wad).

[edward850]

I'm going to rewrite that message. There is no reason for network status messages to be stored and serialized in player_t.
You could coax its removal by toggling prediction off and on.
Also:

-host 2 -netmode 1

With two players especially, netmode 1 is actually useless. If not detrimental.

[Agitatio]

Code: Select all

start gzdoom -iwad doom2.wad -host 2 -netmode 0 -extratic -skill 4 -file MM.WAD MMMUS.WAD brutalv20.pk3 smivhudwidescreen.wad +net_ticbalance true +sv_noweaponspawn true +sv_weaponstay true +sv_samespawnspot true +sv_allowjump true +sv_doubleammo true +cl_noprediction false +cl_predict_specials true

Code: Select all

start gzdoom -iwad doom2.wad -join -netmode 0 -extratic -skill 4 -file MM.WAD MMMUS.WAD brutalv20.pk3 smivhudwidescreen.wad +net_ticbalance true +sv_noweaponspawn true +sv_weaponstay true +sv_samespawnspot true +sv_allowjump true +sv_doubleammo true +cl_noprediction false +cl_predict_specials true

Have a very minor shaking/stuttering. It's barely noticeable. Still, would really appreciate any advice. Using -dup 2 didn't help.