Qizmo lag fix
This page was stolen from Dirtbox's tutorial How to use Qizmo to fix lag at QuakeWorld.nu
Introduction
If you have been playing Quakeworld for a long time then you know that Qizmo was an absolute must for online competitive gameplay. It contains a massive suite of features such as... route improvement, FPS enhancements, QW over TCP, teamplay and voice enhancements, demo viewing, demo compression, large scale spectating games online and, quite uniquely, manipulation of the QW Netcode.
Most of these features have now been replicated and replaced within the clients we use (ezQuake, FTE, Fod) or with QTV and QWfwd however there are still a few important features in Qizmo that have never been replaced and keep Qizmo as something that people should know how to use.
How does it work?
When using Qizmo, if you connect via 2 Qizmos, one locally on your PC and the other remotely hosted server on the internet it allows you to manipulate the QW traffic going between the 2 Qizmo's without the client or the server knowing about it. Here is a basic picture of how your connection would look:
Client > Local Qizmo > Remote Qizmo > Server.
What are the basics?
First the basic setup. 1. Download Qizmo for Windows or Linux. 2. Run Qizmo.exe 3. Connect via your Local Qizmo to a Remote Qizmo (Full list on quakeservers.net ) using the following commands:
say proxy:menu bindstd //to bind arrow keys and pgup pgdn, enter... to control the qizmo menu cl_useproxy 1 //ezQuake server browser will work via Qizmo connect 127.0.0.1 //This connects you to your Local Qizmo .connect nl.besmella.com //This connects from your Local Qizmo to Remote Qizmo
Now you need to connect to a server and you can either use the ezQuake server browser or you can manually do this:
,connect qw.foppa.dk:28501 //Manually connect Remote Qizmo to a server
Everyone should know by now that to send a command to a proxy you need to put a "." (dot, period, fullstop) at the beginning of the command, for example .connect however this poses a problem when you are using more than one proxy because it will always be the proxy closest to you that receives the command. If you send a .connect command it will make your Local Qizmo connect to an IP instead of the Remote Qizmo. To get around this you instead use a "," (comma) which will send the command to the last proxy in the chain (in your case, the Remote Qizmo).
A shortcut to automatically connect to your own Qizmo is to add +connect 127.0.0.1 to your command-line. Also you can create an alias to connect from your Local Qizmo to a specific Remote Qizmo...
ezquake-gl.exe +connect 127.0.0.1 alias qizmo_nl "say ,connect nl.besmella.com"
Ok, now what?
Now we have you connected, I am going to cover just 3 important features which have not been replicated in modern clients or servers.... They are the Nail Filter, Data Compression and Sending multiple packets
Nail Filter:
As anyone who plays 4on4 knows, especially on e1m2, that when you get a lot of super nailgun action it can create not only FPS lag but network lag because every single nail that is fired is its own unique projectile and 3 dimensional element being rendered by the client and having its telemetry transmitted from client to server and vice versa. Qizmo allow you to help this buy setting the Remote Qizmo to only send half or three quarters of this information to you. You will see less of the nails but you will lag less too. Remember to use a comma when you configure it so it is the Remote Qizmo that filters the nails otherwise you will only get the FPS Benefit and not the network lag benefit:
,fps 0 0 0 0 0 0 2 0 0 0 //Filter 1/2 Nails (one half) ,fps 0 0 0 0 0 0 3 0 0 0 //Filter 2/3 Nails (two thirds) ,fps 0 0 0 0 0 0 4 0 0 0 //Filter 3/4 Nails (three quarters) ,fps 0 0 0 0 0 0 0 0 0 0 //Disable Nail Filter
There is 10 numbers and the 7th number controls the Nail Filter.
Data Compression
Most people have fast connections these days and trying to squeeze more data through your connection in order to be able to use a higher rate is a thing of the past but if you still have a low bandwidth connection then this may interest you. By enabling data compression any QW traffic between the 2 Qizmo's is compressed and decompressed by the Local and Remote Qizmo's and therefore uses less traffic. Once connected to both Qizmo's this is as simple as typing the following commands which Qizmo automatically creates aliases for (experiment with which works best for you):
ezcomp //Compression in both directions ezcomp2 //Compression with Quality Line Mode* ezcomp2 //Compression with Quality Line & Lossy Compression Modes*
The results are quite impressive. From my testing I have found that the basic compression in both directions (ezcomp) achieves the following results:
Client-to-Server data - 64% reduction in size
Server-to-Client data - 80% reduction in size
Sending Multiple Packets
Of the 3 features that I am covering, this is the least known and definitely the most beneficial because you can lower your packetloss. Packetloss can be caused for many reasons such as a poor quality internet connection or an ISP who is oversubscribed... but for whatever the reason it sucks for Quakeworld. Qizmo has the ability to send each packet more than once which greatly lowers the chance of that packet being lost. From the Remote Qizmo you can receive each packet up to 5 times and from your Local Qizmo you can send each packet up to 3 times. This means that if you have a high bandwidth connection, you can just send more data and get less chance of packetloss.
I previously had a connection that would get a constant 10% PL any time it reached 21:00 at night. When this happened I would connect via 2 Qizmo's and set my Local Qizmo to send each packet twice and the Remote Qizmo to send each packet 3 times and I could effectively lower my 10% PL down to 1% or 2% (or low enough that I didn't notice it at all). If sending more traffic is a problem for you then you can also combine this feature with the Data Compression I mentioned above. In really extreme PL cases you should use the maximum setting of sending each packet 3 times and receiving each packet 5 times.
Cool! How do I configure it?
Sending packets Client-to-Server (c2s)
.repeatc2s 1 //Default setting (send once) .repeatc2s 2 //Send each packet twice .repeatc2s 3 //Send each packet three times
Receiving packets Server-to-Client (s2c)
,repeats2c 1 //Default setting (send once) ,repeats2c 2 //Send each packet twice ,repeats2c 3 //Send each packet three times ,repeats2c 4 //Send each packet three times ,repeats2c 5 //Send each packet three times
Basically you just need to increase the amount of packets you send until your PL starts going down. To make it easier you can even create a couple of aliases which will do this for you:
alias pl_none "say .repeatc2s 1;say ,repeats2c 1" alias pl_medium "say .repeatc2s 2;say ,repeats2c 3" alias pl_big "say .repeatc2s 3;say ,repeats2c 5"