Shooting Through Walls: Unraveling the Code Behind Quake's Lightning Gun Bug 

Watch Quake Speedruns Explained's counterpart video which covers the backstory of this technique here! ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-zfY96tAqmdI.html

The main takeaway is: if you're developing a game it's a good idea to make invisible entities that can interact with other entities actually visible while debugging. It would be obvious that something is wrong if the two invisible rays were shown

Surely even with both of the fixes demonstrated, there is still a bug here with how the vector is normalised before it is projected onto the XY plane. Shouldn't the vector be projected first to ensure that the normalized vector is actually length 1 on the XY plane.

There's actually a third bug in that function (albeit not abusable): we should normalize _after_ setting Z to 0, otherwise the sidebeams get closer when looking up or down

I really love your in-engine visualizations.

I came here from quakespeedrunsexplained. There is actually one more bug in the code, although it's irrelevant because of the other ones. Let's say the assignment of the normalization and the swap bugs were corrected, the offset would still be wrong, because the vector is first normalized and then the z-component is subtracted. That means that the xy-components do not form a unit vector. The higher or lower you aim, the closer the beams will come together. Correct would be to first eliminate the z-component and then normalize.

There is a somewhat similar bug with Team Fortress (1, for Quake) sentry guns - it also doesn't normalize properly, but the difference with this bug is that the vector p2 that is passed to the traceline() ends up having really giant magnitude instead (magnitude squared IIRC). Thus sentry rounds have no scatter, despite authors trying to make it like a super-fast single barrel shutgun. An another bug is that a sentry shoots from the top of its head, and, when its target is on the same height level, it shoots at the enemy's top of the head (height 56 from floor level). Thus when both bugs combined, a shot's outcome depends on a sentry and its target absolute positions, by the means of floating point accuracy and rounding errors, rather than PRNG.

The rays either side of the main beam may have been an attempt to make long distance shots more likely to connect. Most players were in 320x240 with ball mice - at that resolution and with a low mouse DPI, an apparent hit could easily be a miss even if one tick of the mouse were small enough to hit the mark - especially given the 'lightning' closer to the gun can overlap the stream in the distance. I played a lot of deathmatch - consensus was lighting was a mid-range corridor weapon, bad long range given you're mostly missing the target and just 'scanning' across it - maybe the 'fixed' code would have elevated it above the nailgun!

Its crazy how theres not one but TWO bugs in the small snippet of code!

I'm a terrible programmer who has never stuck to any one language long enough to be proficient and recently I've been playing around in Quake as a hobby, I found this video very funny as I also have misused normalize and had brief moments of forgetting to set temporary variables haha cool video, love the visualizations! Learning programming would be so much easier if there were teachers like you with visuals prepared.

As a game designer my guess is that they wanted to use three beams instead of one to make it easier and more rewarding to hit enemies. The electric beam also does visually not appear like just a thin line, it's more like a tube, but a tube collision detection is much more resource heavy than collision detection with three lines.

Judging by the model of the weapon, I would guess that the original plan was to have three beams firing out from the start (not as a fix for shooting multiple, but just intended from the start to make it more effective/require less precision back when people couldn't aim or used keyboards only). And I can imagine they scrapped the three beams idea for performance or to reduce the visual clutter, but didn't want to make it feel less accurate. I would bet that the level they set up to test it also happened to have the enemies aligned on the Y axis (so the player was facing down X), hiding the issue to some degree. Seems like it would be difficult for this to slip by testing otherwise, or perhaps they just didn't test this in isolation and never noticed it wasn't working.

Modifying weapon behaviour was probably the main thing people did to try and learn some QuakeC. I remember changing the nailgun to a hitscan machine gun. Lot's of people in the 90s (including me) probably looked at the code and did not notice the bug.

This explains why I miss the toilet with my own beams sometimes. What a relief it isn’t my fault.

Would love a tiny comment by John Carmack on this *feature*

Even though ive been coding for years with vectors and 3d graphics, vectors are sometimes the most painful god damn thing in the world. I swear the first thing i do with vectors in every program i use is make a proper vector arrow display function (like the one in the vid) because without it its just tooth pullingley tedious

I mean, what are we to believe, that this is some sort of a magic lightning gun or something? Boy, I really hope somebody at id got fired for that blunder!

If QuakeC compiler had some warnings ("builtin-function normalize return value not used") this would have been catched. Why this was not found during deathmatch (especially 1on1) puzzles me.

I love this! Do you mind if I show it in my game programming class?

Great video again! Please keep going! This is better than Netflix :)

What a bug!

It's good to see two Quake themed RU-vid channels supporting each other. Carry on such great work!

New video and as always excellent, you disassemble the code bit by bit. Thank you and you and Connor found a great topic! 😊

Huh so rumors about the lightning guns creation for the remote viewers division had a kernal of truth to them neat.

This video is #2 on hacker news at time of writing. Congrats, and awesome concise video!

I've been wondering if this exists in NetQuake. I think of it were it would be noticed more, but I feel like it should have been noticed a lot earlier in online competitions than it was in speedrunning.

I'm very surprised the programmer did a bad swap, I can't remember ever making a mistake like that (I probably have, just forgot), I understand it was probably just a late night mistake or something of the sort, very interesting. There's a popular interview question that asks the programmer to swap 2 variables without a temp one. My favorite answer is using XOR x = 2 y = 3 x = x ^ y; y = x ^ y; x = x ^ y; // x = 3, y = 2 this, however, is horrifying and shouldn't be used. Also I'm not the most familiar with C, isn't ignoring a return value like that a warning? I just always assumed you would need to assign cast it to void? or even just assign it to a value and let it be optimized out by the compiler?

Stunning as always.

I was wondering if the side beams can potentially triple the damage, and may explain why the gun has such high DPS (300), but looking at the quake c it seems like subsequent traces only deal damage if the previous didn't hit, and it just deals 30 damage per cycle. There also seems to be some PvP specific funky Z velocity push that only happens on the primary beam, but the bug should work in deathmatch too.

Cool collaboration!

I don't want to sound smart - we all do stupid mistakes (me especially), but I'm puzzled how this could happen: using temporary variable to swap two others is like an example shown to beginner coders (usually show along with XOR swap trick) and knowing that for function to change the value passed as an argument you need to provide a pointer to it is like C 101. Well, what can I say: write your unit tests*, kids 😇 *) except for the games, without bugs we wouldn't have fun bugs like this or even bunny hopping 😅

That normalize() mistake is so easy to make in GLSL as well, hate it. Would be so much clearer if it were normalized() instead

Imagine being a shalrath (vore) living your life normally when you suddenly feel an unfathomable pain then you die XD

Does this 'bug' also work in QuakeWorld against other players? I have never heard of it and I played QW for 10+ years on the European scene.

It's nice to see that even in a groundbreaking game like Quake, developers make the same mistakes I do in JS front-end development - we're not as different as I thought

You make great content!

Why is it 0 - f_y rather than just - f_y ?

Has anyone made a "no LG bug" mod to let you play with the intended mechanics? I know it would be kind of... not huge, but I'm just curious.

I insta-click your videos. Thank you, Matt.

How did I know you used vim

Awesome explanation! I'm kinda sad that this video doesn't show off the tool you developed. It was mentioned around the 14-minute mark in QSE's counterpart video.

So if you line it up right you can do 3x damage if all 3 lightning beams hit the same enemy?

Great video. I can't believe it took so long to notice this bug.

According to Michael Abrash early in Quake's development, he discovered a bug in the Pentium chip's hardware, the infamous "f div" bug, which caused completely random snaps to totally different parts of the map for a split second.

Quake 1 code was open sourced?

Wow, what a bug.

How long was this known about before someone dug into the code?? Wouldn't that be the first place you look? .-.

Parkinson's LG

I've always wondered what that code was intended to do. I think your theory makes the most sense since it can be chalked up to two simple programming mistakes.

This seems like such a weird and somewhat hacky implementation to me. If I were to program this, I would grab the player’s right directional vector (pretty sure Quake already pre-calculated that somewhere) which is already normalized, scale it by 16 units and then use that to offset the beam’s start and end positions. Since the player rarely has any roll applied, there’s not much need to flatten the vector either. Someone must have programmed this in a hurry and then didn’t thoroughly test if it works.

If I follow you correctly though, shooting at enemies without moving the mouse at all should deal 3 times the damage to an enemy in front of you though right?

OMG, Broken!!! It's like this code was written by Chat-GPT or something