(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.)
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.
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.
The player number of the local session. This value will logically be different for every node, as each node controls a different player.
The current frame ZDoom is running. This value can never advance past the last complete set of nettics, and can never decrease.
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.
The lowest nettic an individual node has out of all nodes. The gametic cannot go any faster than the lowtic.
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.
(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
Code: Select all
zdoom.exe -join study-pc
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 188.8.131.52 -file udmx.wad
Code: Select all
zdoom.exe -host 2 -deathmatch -file udmx.wad +dmflags 545796 +map map02
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.)
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 (184.108.40.206:5029, for example). Guests automatically use a random port assigned by their socket manager, regardless of the port setting.
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.
Various things (actions, occurrences and messages) can occur in game. These are either player controlled or otherwise.
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 cannot currently be done in game, and must be done as a launch command. See above in "Multiplayer launch settings".
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).
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).
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 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.
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.
- 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.
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” 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.
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.