This page is guaranteed to be spoiler free. It is safe for you to read this page even if you have not completed playing The Ur-Quan Masters. Links you follow from this page do not share this guarantee unless they also include this text.
Installing a network-capable version of The Ur-Quan Masters
The Ur-Quan Masters includes Netplay starting with version 0.6.0.
Setting up the network
Network experts can skip to the section "Network Summary". For the others, read on, everything will be explained.
Every computer on the internet has an internet address, consisting of 4 numbers seperated by periods, like
126.96.36.199. Information sent over the internet is split up in packets, each packet labeled with the destination address.
A computer may also have a host name, like
uqm.stack.nl, to make refering to it a bit easier to read for humans. When information needs to be sent to a computer known only by host name, its address will first be looked up.
A computer may run many programs simultaneously which want to receive information from over the network. To direct packets to the correct program, the address will include a number known as the port number or port for short. The Ur-Quan Masters accepts packets sent to port 21837.
The little box which comes with most modern internet subscriptions is a router. A router is a device which passes packets to other computer.
Several computer may be connected to a single router, but usually there's only one internet address for one router (the public address). To be able to address the different computers connected to the router, the router gives them all a local address. Special ranges of address are reserved for use like this (192.168.x.x, 10.x.x.x and 172.16.x.x through 172.31.x.x); these addresses are not accessible directly from the internet.
When a local computer sends a packet over the internet to another computer, the router will replace the return address (which was the local address) with the public address, and send it along. And when a packet arrives from the internet, the router will change the destination address (which was the public address) to the address of the local computer for which it was destined. This relabeling is usually called NAT (for Network Address Translation).
And this is where the problems begin. How is a router to know for which local computer a packet is destined? The packet only comes with the public address and a port number.
When a local computer sends packets first, the router can look at the originating address and port and remember them, so that when a reply comes to the same port, it knows for which computer it is meant.
But if packets arrive from a computer over the internet out of the blue, the router does not know to which local computer it should direct them. (Even when there's only one local computer, most routers will just throw such packets away.) In this case, you need to tell your router explicitely where packets that match a specific pattern need to be sent to. For instance, you could tell it that packets that arrive for port 21837 should go to the computer with local address 192.168.0.2.
A firewall is a program which selectively blocks packets.
Many programs will have some sort of network functionality, more than you're probably aware of, some which are part of Windows itself. When packets arrive these will happily respond to them. But while you may want to share your files with another local computer, you may not want your neighbours to see them. And every program that is accessible could also contain a bug that could compromise your system.
This is where firewalls come in. They have rules which govern which packets are allowed to pass through unhindered, and which are blocked. And because it's better to be safe than sorry, firewalls usually block everything they don't know.
So when you're running a program that needs to access the internet, you'll need to tell your firewall to allow it. A firewall may be running on your local computer (Windows XP has one built in), but your router may also have one. And frequently both will. Both may have to be instructed to allow your packets to get through. You want packets, our else christmas will be boring.
Finding out what your local address is
- from the start menu, select "Run..."
- type "cmd /K ipconfig" (on Windows 2000 and Windows XP), or "command /K ipconfig" (on older Windows versions)
- the line saying "IP address" will contain your local address. You can ignore the rest.
Finding out what your public address is
As your public address is sent as the return address everywhere you go on the internet, you just need to visit a web site that reports it back. http://www.whatsmyip.org/ will do. You'll see your public internet address in big letters on the top of the page.
Note that your ISP may give you a different public internet address each time your router asks for one (after a reboot of the router perhaps). Check, if you aren't sure.
Telling your router to forward UQM packets
There are many different routers, so this section will not contain specific instructions. You will need to find your router's manual, or find information on the internet. A lot of information can be found on www.portforward.com. Typically, you use a web browser to connect to your router's own local internet address. Often http://192.168.0.1/, http://192.168.1.1/, or http://10.0.0.1/. You'll probably need a password too.
When you're logged in, look for a section with a name like "NAT", "IP masquerading" (another word for NAT), or "port forwarding".
You'll need to tell it to forward packets addressed to port 21837 to port 21837 on your local address (see Finding out what your local address is).
If the router configuration doesn't work with single ports, but instead takes a range of addresses to forward, just use the range "21837-21837".
If it wants to know a specific protocol (a class of packets) of packets to forward, use "TCP" (but The Ur-Quan Masters might use "UDP" in the future).
The Ur-Quan Masters will probably also use port 21836 in the future, so you might as well forward it too.
Telling your router's firewall not to block UQM packets
In the router's configuration menu (see above), look for a section named something like "firewall" or "packet filtering".
To allow incoming UQM packets, add a rule to pass packets from any address, from any port, to the public address, to port 21837. If it wants to know the protocol for the packets too, use "TCP" (but "UDP" may be used too in the future).
Your router will likely allow any outgoing packets, so you probably won't have to add a rule for that, but if you do, it would look like this: pass packets from the public address, from port 21837, to any address, to any port.
Telling your computer's firewall not to block UQM packets
This varies per firewall software.
Using Windows XP's own firewall (be sure you have the latest Windows XP service pack installed), you will get a popup dialog when a program first tries to send packets, or begins to listen for incoming packets. Just start UQM, try to establish an incoming or outgoing connection as normal (see below), and when you get the popup, allow the incoming or outgoing connection attempt, and you'll be set.
Ports used by The Ur-Quan Masters:
- TCP port 21837
- (reserved for the future) UDP port 21837 (not currently used)
- (reserved for the future) TCP port 21836 (not currently used; for the meta-server)
Alternative: Using Hamachi
Hamachi is a program which can usually obviate the need to do all the network settings above. It is also the best way to play against someone on another network if your router does not have port forwarding.
The disadvantages are that you can only play against other Hamachi users and the increased network latency (and so the need for a higher netdelay)
When you run hamachi, you will be given a private IP address that you can use as if it was a direct connection. It also comes with a chat feature, so you can chat with other hamachi users. For netplay, use this room:
Network Name: UQMultiplayer1 Network Pass: Fwiffo
If that room is full, use this one:
Network Name: UQMultiplayer2 Network Pass: Fwiffo
Finding someone to play against
The IRC channel #uqm-arena on irc.freenode.net is a good place to find people to eat your flaming plasma death. You can either use a stand-alone IRC client, or use the web-based client. Some web browsers (Firefox, Opera) also have an IRC client built in.
Running the game
Starting a netplay game
Enter SuperMelee as normally, but on the side that you want to be controlled by a remote player, select the "Net..." button. Now one side needs to initiate a connection, and the other one needs to be ready to accept it. The player on the initiating side should enter the IP address or the host name of the remote side in the "Host" field, and then select "Connect to remote host". The player on the incoming side merely needs to select "Wait for incoming connection".
If this doesn't work, then the firewall or router settings of one of the players are incorrect. As someone who is unable to accept incoming connections is usually still able to initiate outgoing connections, you could try to connect again, but with the outgoing and incoming roles swapped.
Every frame, the game sends information to the other side on which keys are pressed, and every frame, it needs the same information from the other side to continue to the next frame. Because it takes time for this information to reach the other side, the game can delay processing of this information for a number of frames. For example, if the net delay is set to 2, information generated in the 99th frame will be processed in the 101st frame.
A higher delay will allow information more time to reach the other side, but at the same time, it will cause the ship to respond more sluggishly. So you'll want the net delay to be as low as possible, but still high enough for the information to reach the other side in time.
If melee seems slow or stuttery, that is a sign that the net delay is too low. You can change the net delay in the network connection dialog you got when you pressed "Net...". The maximum of what both sides have chosen is what will be used. A delay of over 3 is likely to spoil your gameplay.
Multiplayer melee suggestions
The following are some suggestions for getting the most out of multiplayer Melee.
- Have pre-made teams of various sizes (100, 200, and 250 points fleets are often used)
- When using a keyboard, figure out suitable key bindings in advance. Most keyboards don't allow certain combinations of key-presses.
- When playing over a network, find someone geographically close to you, so that you'll have a relatively good network connection.
- Limit the number of ships of one type. This will result in more varied battles. Generally a no-duplicates rule is used, preventing the use of more than one ship of the same type.
- Exclude or limit certain ships:
- Play with random teams. A good random online random team generator can be found here.
- Let each player build the fleet of the opponent. This will result in fleets with ships you don't usually use. You may want to limit the number of ships of one type, to avoid ending up with a fleet of Umgah Drones.
When it's not working
If you cannot establish a connection
This is usually caused by a routing of firewalling problem. See above.
If you are disconnected with a "version mismatch" error immediately after connecting
This will happen when the local and remote versions of The Ur-Quan Masters aren't compatible with eachother. Both players should upgrade to the latest version.
If the game aborts because of "loss of synchronisation"
This can happen if one player has installed some melee-affecting add-on, while the other player has not. Modified graphics can be enough.
If this is not the case, there might be a bug. Please report it with as much details of when the bug occured as possible and include which ships each player had selected.
Also, when 0.6.0 was released there briefly was a version on the download server that had a bug that would cause an immediate loss of synchronisation error under certain conditions. This version was replaced before 0.6.0 was announced, but the sourceforge mirrors carried it for a longer time. If you downloaded 0.6.0 before or soon after the announcement, and you encounter this bug, you may want to redownload and reinstall. You do not have to redownload the content packages.
An error like this will never be caused by network problems.
The game is slowed down/stutters/pauses
If the game is going slowly or stutters, this usually indicates that the information from the other computer isn't received in time. Setting a higher net delay Net Delay when connecting will increase the time in between a keypress (or game controller action) and the moment it is processed. This makes the ships less responsive, but allows for more time for the control information to reach the remote computer.
If the game pauses for a long period of time, this usually means that information got lost on the network. Because UQM is using the TCP protocol, it takes a while for that to get noticed and the information is retransmitted. UQM will switch to using the UDP protocol in the future. Until then, having any packet loss on your connection is unacceptable for UQM netplay.
There can be several reasons for netplay being slow or stuttering:
- the connection between the two computers is slow. This can be because your or your opponents ISP doesn't provide a very good service, or just because there is no high-speed route available (maybe one of you is in the middle of nowhere, or just very far away). Note that a higher bandwidth doesn't help for NetMelee responsiveness, as the limiting factor is the time it takes to deliver information ("latency" or "ping"), not the amount that can be transmitted.
- you or your opponent is filling up his outgoing or incoming connection. Making heavy use of the network while playing NetMelee will slow down the game or even cause packet loss. In particular, running peer-to-peer programs like bittorrent or Kazaa is devastating.
- on of your computers is too busy to give enough attention to UQM. Maybe your virus scanner just activated.
The ships respond sluggishly to my commands
The time in between a keypress (or game controller action) and the processing of that action is determined by the net delay setting used when connecting. A lower delay will result in a more responsive ship, but if the delay is too low, there may not be enough time for the control information to reach the remote computer, resulting in stuttering.
If you've found a bug
Bugs should go to the project's Bugzilla bug database. Be verbose. Or smash it with a paper.