Start here

Your e1m1 for QHvH.

Bending software is and always was fun. But before you can start you need to know its ups and downs to leverage them. For that I host these pages where I try my best to explain how Quake works. At the very bottom I list the jargon file if needed.

Game clients

In general all Quake clients do the same; Read your input, build a usercmd, send it over UDP, decode the snapshot form server and predict&draw your position. Two main one are ezQuake and FTEQW (which is also a server). There is more of course, but unless you can read C like English, you better pick one and stick with it. Both are well written and documented, which is all you can ask for from 10+ y.o. projects.

Other popular clients include OG 1999 client which is unusable for modern servers unless built from source and nQuake which is preconfigured ezQuake. Thats fine, but not really usable for hacking the client.

Servers

On contrary to clients, in server field you have only two options. mvdsv+KTX is the classic competitive QuakeWorld stack. mvdsv is the physics engine and KTX (Kombat Teams eXtreme) is where the game rules (voting, dmg tables, statistics). The KTX is developed so closely with mvdsv that it's practicaly its extension.

FTEQW (server) is a modern engine that speaks both QuakeWorld and older NetQuake protocol. Game rules are written in QuakeC (scripting language), so every mod is a bytecode file interpreted by the engine.

If you wish to run your own QuakeWorld server, you can checkout this guide which covers both options.

Game overview

The server is the only judge. Your game client never sends hit confirmation nor the player possition. It only says I pressed these keys while looking this way. Consider the gameloop in four steps:

  1. Your client builds a usercmd many times a second and blasts it to the server using UDP. That's which way you look, which way you strafe, which buttons are held, an optional impulse number (e.g. switch weapon) and how many milliseconds this command covers (msec).

  2. The server runs physics with that usercmd, then runs the game logic (QuakeC on FTEQW server and KTX on mvdsv server). This is where damage, item pickups and scores happen.

  3. The visibility filter uses the map's PVS (Potentially Visible Set) to choose which players you could possibly see from where you stand and packs them into your snapshot.

  4. Your client predicts your own movement so it feels instant, then corrects itself when the snapshot arrives and the renderer draws the result with whatever models, skins and settings you have locally.

"Zones"

There are three zones where the game code and your code can live. Client hacks, are done by modifying the clients source code and compiling it. This is how most hacks are done but you may also add custom models, textures and HUD modification without building the client.

A wire hack is a separate program which sits in path between server and client and edits the packets as they pass. It usually runs on your own computer, but you may run it on VPS too. Currently, the only free software tool available is Cheapo.

A server hack is either game mod or benevolent server config. However, you may encounter CTF servers (like yours trully) which give players the rcon password as reward. The rcon stands for remote console, and player which knows it, can command the server from game client. Then the player may load config they desire.

Some hacks need more than one zone to run. The see what needs which access check out the Hack gallery.

Weak spots

Original Quake code was never really ment to be open source, meaning lot of game logic was coded with "security by obscurity" method. Therefore weakspots exists which enable(d) hacking.

The entity list is fully trusting. The client receives exact positions, angles and velocities of every player in your PVS, and stores them so it can draw them. It has no notion that this data is “for drawing only.” Any code with access to that list can use it for aiming, dots on a radar, or names above heads. Rendering is only clients job which together is the biggest weak spot.

To feel responsive, client runs the physics itself ahead of the server. That means the movement math lives in the client, where it can be read and exploited for perfect strafing or bunnyhop timing. The weak spot is that the client must understand the rules to predict them, and understanding is half of optimizing them.

These are basis for making aimbots, triggerbots, wallhacks, autostrafe and any other hack. Of course, for detailed picture you need to read the code / documentation I listed higher in this page. I also recommend consulting QuakeWiki engine dev.

Jargon file

Here is list of some lingo you might hear for first time and will hear a often. The title of the sections is link (like every other section is too) so you can bookmark it if needed.

Gameplay related