At 1:26 there used to be an explanation of why null pointers cause crashes, but it was greatly oversimplified. Cutting that out means the joke at the end no longer makes sense lol. FAQ Q: Where code? A: github.com/ValveSoftware/source-sdk-2013/ Q: UH ACTUALLY you can check if a pointer is null before dereferencing it! A: I know. Corrections 1:23 It's not the game that no longer has the data, just the vortigaunt that no longer has it. This is clarified later but perhaps I should've done it right then and there instead.
@@Pinsplash well I guess i need todo better research I just remember needing to play what amounted to visual studio musical chairs where I had to uninstall all versions of visual studio and install them oldest first at the time. you basicly had to install 2013 then 2014 then 2016 etc
It also happens in portal 1, if you get to glados chamber, every entity that is not on the glados chamber will be removed, so if you die out of glados test chamber, the game will delete you and i the gane will crash
I really enjoy this more technical style of video that includes debugging. Not enough channels that cover glitches and trivia are able or willing to dive in to code.
TheZZAZZGlitch does some super interesting technical content like this about pokemon (mainly gen 1 and 2), would recommend, they make some of the best content on youtube imo
You sneaky bastard! You commented about not being able to find technical breakdowns of glitches so that you could get recommendations for channels where they do technical breakdowns of glitches!
Speaking of, shounic is a good channel for this kind of content. He makes videos on TF2, the other, other source spaghetti game made by valve. Given the nature of the game, he tends to put a little bit of humor into his videos, even if the joke is relegated to the thumbnail.
1:40 I have looked into this, and it turns out what happens is when the metrocop fires his bullet, for some reason the end position of the bullet becomes infinity on all 3 axes, causing the tracing code to be stuck in an infinite loop due to how it internally uses voxels to find objects along a ray. I am not too familiar with how the trace system works internally with the voxels, but I think it tries to find a voxel using a hash of a 3D position (in this case infinity) and fails every time.
4:10 Haha! I realized the player got removed as soon as I saw the camera do that. I'm sure you know of the command impulse 203, which removes the object you're looking at, well, in TF2, another player can remove you without a crash with the command, which causes you to be put in a limbo state of being in the server and not, brings me back to when I used to hang out on empty private TF2 servers with my friends years back. Sorry for the slightly off topic anecdote, it was just fascinating seeing the same visual occur, fantastic and educational video.
oh, that explains this one time when a server admin was pissed at me because my voice was high pitched because I was still a kid and the same thing happened.
Valve don't clean up their code very well, HL2 included. The Sniper has an unfinished and unused penetration mechanic lying around and the Strider is still waiting on a proper right leg stomp animation with commented out bits for stomping with the right foot sometimes. (The Strider model does have a right stomp anim, but it's more of a placeholder. It does not mesh with their inverse kinematics and does not return into the idle position, ending immediately on hit.)
@@MolkoKillStyle The whole Strider stomp mechanic is executed on an impressive level. It uses a smooth animation in conjunction with continuosly running inverse kinematics, temporarily takes over the left foot IK to manually designate it a new target so the Strider aims directly at the victim and then uses ragdoll trickery with an attacment point on the model to do the impaled corpse. The only caveat is that the Strider can only do this with the left foot, despite being originally intended to be able to use either front foot for it. I guess Valve just decided it wasn't worth the hassle, making a right stomp anim and revisiting the code to fully implement the choice of attack, seeing how Striders rarely engage multiple humanoids up close at once in HL2. The Strider as a whole is a technological marvel of Source capabilities and ingenuous spaghetti code. I mean, they aren't even a ground unit - they're technically a flying NPC using a lot of physics and animation trickery to convincingly sell the illusion of being a hulking stomper.
There are so many useless unnecessary assert(0)'s in the code. I saw one issue on github related to vehicles code and removing assert would prevent crash with no bad side effects.
4:09 regarding the hallway that deletes you, there is a similar phenomenon in HL1. In the map c2a5b (Surface Tension, right after the cliffside walk), if you climb on top of the smaller tank without destroying it beforehand you will get teleported to the previous area, half-stuck inside the concrete floor, and not even the "noclip" command can get you out of there. I wonder if climbing on top of the smaller tank deletes you just like in this case because if you use "impulse 101" in this state the game will type "Got a NaN origin on [weapon/ammo name]" in the console for each weapon/ammo unit, but you still get the weapons. Interestingly enough, shooting the Hivehand types the same console message but with "hornet" as the entity name. P.S: as a Team Fortress 2 veteran, seeing you survive for so long in that situation was honestly jaw-dropping even for a jaded player like myself...
Hmm, I can't seem to replicate what you're saying, but I think what you describe is actually a result of a level transition happening without the player being "visible" to a certain entity related to level transitions. As a result, the player entity is not "saved" through the transition, which locks your view to some default position (likely 0,0,0).
Damn! The glitch with the tank has always bugged me, since no one knows what I mean or why it happens! Glad someone else has noticed it. I need to press my interact key when on top of the Bradley for it to happen to me though. On my first playthrough I thought it was just some not implemented system for taking control of the turret or something, but that seems unlikely, especially since we later just find a tank with an open hatch you can control.
When scout mains reach 10000 hours in the game, they gain the ability to become impervious to death just so long as they are within über stuffing distance of a medic with more than 70% über.
Left 4 Dead 2 has a similar bug on the Dark Carnival finale. When the finale is triggered, it shuts a door behind you and deletes any players and NPCs stuck behind it rather than using a kill plane. Speedrunners use this to kick bots from the server forever by incapacitating them at the start then triggering the finale. And on the (peer to peer network) Xbox 360 version, you can crash the entire server if the host gets deleted.
I'm pretty sure that the issue there is some iffy physics calculation resulting in the player's position being set to NaN. In "floating point numbers" (the way computers usually handle numbers that can have a fraction) you have three main kinds of values: real values (+7.0, -11.5, +2678.027891), the infinities (+infinity and -infinity), and NaN (standing for "not a number"). Any invalid math operation (like 0.0 / 0.0 or infinity - infinity) will return NaN, and any math operation involving NaN will also return NaN. You can think of it as "poisoning" any expression it appears in, to signal that the whole thing is invalid. So if your position ever gets set to NaN, there is almost no movement option (short of a straight-up teleport) that can move you away from that "position". When forcibly converting NaN to an integer or some other system that doesn't support weird float values, it will usually be treated as zero, so that's probably why your viewpoint appears to be 0,0,0 (the map origin).
I like how - in the very moment of the crash - you have blackwhited the frame. it's a nice touch. the explanations are gold as you have attached the source code parts with the scenarios as well... great job and good video! very educational and entertaining in the same time
This reminds me of how in GTA San Andreas (on the PC version) if you have something like a rocket launcher before doing the mission for Zero where you shoot down planes on the roof with the minigun, you'll lose that weapon at the end of the mission. It'll still be in your inventory, but it'll be missing an icon and won't fire. Trying to aim with it crashes the game. I'm guessing it was another null pointer situation?
Its likely, the minigun and rocket launcher occupy the same slot I think, so maybe the game tries to restore your weapon inventory after the mission is over, but it wasn't implemented properly.
Okay am I crazy if I said that I would love to hear this guy break down crashes in a bunch of other video games. I just love how he gets so technical with it.
3:14 this kind of optimization may not be for speed, but for memory usage instead. it may even be a memory _leak_ which could eventually lead the game to a crash. its possible it may be a memory leak because _maybe_ what happens is whenever the gun ends up as a phys object again, such as when the rebel drops it to pick up another gun, it creates a new phys object for it, and replaces all the pointers of the old one. if the old one was never deleted, then, well, it's leaked.
@@ВластелинКриперов potentially yes, but you have to remember this is the source spaghetti monster we're dealing with here if reusing the same physobj was a possibility, why would they need to delete them at all? even if they wanted to stop using that particular physobj for that particular object, and just recycle that physobj instead of remaking a new one later, surely they still wouldnt even need to delete it then either?
@@Templarfreak you could be right though. However, I also figured it might be a measure to reduce overall memory used, as destroying physobj most likely deallocates it
@@ВластелинКриперов right, that's what i was suggesting in OP. i was also just pointing out a potential reason why it _has_ to be done for stability reasons and not just memory usage reasons, tho
ok so what you can do to a crash your game, which is prob my favorite way. You can take a prop, rub it against the edge of a combine car tire to make it fly (yes it will just fly lol), and if you crouch jump into it, you will magically acquire its property, then if you just save and load, then load again, you will crash. Also doing stuff with props in the weird state after loading once will also crash at times.
3:58 Halo also has triggers that delete the player, when they clip out of the map into certain spots, get too far away from the map, or part of the level spawns on top of their location. On the Halo 3 level The Covenant, if you jump into the path of the light bridge after fighting two Scarabs, and the bridge activates with you right in the way, you will despawn, the camera will lock up, the HUD will disappear, and a moment later you will respawn
I feel like you could become the Decino of Half Life games if you continue making analysis videos like this. This in-depth breakdown of what is causing the crashes is really interesting.
A guess at the helicopter/speed crash cause - designer wants to run a script "on-spawn" for the helicopter, but can't do it the same frame it spawns because initialization hasn't happened. So they delayed it "at least one frame" at 0.06s. If the player gets targeted by the uninitialized helicopter, it's game over.
My thought was that it was supposed to move to an initial waypoint somewhere around the trigger (via the input mentioned at 6:05), but if you move too fast, that waypoint gets unloaded. Since the helicopter cannot access that unloaded waypoint, it doesn't know where to go, and it crashes. This seems like a very far-fetched explanation, though, and I don't think that's what's actually happening here. Seems more like something that would happen in Mario 64 than in Source.
1:42 Unity engines alternative is to just report the issue as a NullReferenceException and continue running as if nothing happened. it wont get any incorrect data or crash, it just "stops" the code where the error comes and doesnt run anything after it. if you had a custom console attached to the game instance and you built the game you would see a mile long list of NullReferenceException errors or just a single one, depending on where the error comes from and how often that section of code was called
This can be both good and bad. It's convenient for the player and seems like a good idea initially to let the game continue, but if the code stopping there results in other code malfunctioning as well, it can lead to even more instability. As I was working on UI code in my Unity game, one of the null reference exceptions caused some initialization code to be skipped, which then resulted in an infinite loop somewhere else in the code, which then propagated to the C++ side of Unity and caused Windows to first (seemingly) run out of GDI handles, making the taskbar and other parts of the system flicker, then all windows' flags to reset, making otherwise hidden internal windows appear (much like how you can make them visible using tools like Process Hacker). It was very funny to realize this after looking at the logs.
Please Please Please do more of these. Your dead-pan delivery and the subject matter itself work so well together. Plus there are so many videos about glitches in games that you rarely see videos just about crashing the game. It's fascinating to be reminded of the fragility of game code.
I think if you go into that part of the Citadel where you get the physics gun but you already have a physics gun (via the command "physcannon_mega_enable 1") it will crash.
In portal 1, it is possible to fizzle yourself. All you have to do is spawn an airboat (ch_createairboat) and drive into a fizzler. And unlike the trigger that removes you at 4:00, the game actually does crash. I didn't check if it crashes on steam pipe, i know for sure it crashes on the 3420 build.
I remember finding a crash with the can cop where if you put the can in the trash then throw it at the cop it will just exit to desktop. Very interesting video though, nice to finally have somewhat of an idea as to why the helicopter crashes. I'm not exactly a speedrunner but I am still very annoyed by it.
This crash on d1_trainstation_02 map does indeed happen. The timing on this is very tight, though as metrocop has to be hit after the trigger in the trashcan is triggered by the held can, but before the cop says "Alright, you can go."
Great video! As a C++ devleoper, I can relate. Disappointed by the amount of unsafe coding in the source engine. I guess it was done for speed - remember, HL2 came out in 2004 (or 2003?), and it ran very well on old hardware.
Do you know how he managed to run HL2 through VSCode? I'd like to debug Civilization IV in the same manner so I can mod it. I have the source code, too.
These videos are literally my favorite types of videos. Monotone analysis of the game's innerworkings. For some reason I just can't get enough of them.
I realized that valve really are trying to hide the number three you got gold source, source, and then source two technically, it would be called source one from half-life one source two as half-life two then source three as half-life Alex. I really think they don’t know how to count to three.
Almost 20 years old game and still alive, thats awesome. Gonna play again HL2 when i buy PC.
3 месяца назад
i love how you explain why it crash showing the problem, that helped me fix most of those bugs in the mod i'm working on, i love the other videos too, perfect channel and i love it
I've only done some serious programming lately. before starting this channel, i spent about 3 years basically rewriting source engine documentation which involved a lot of in-game testing and looking at code. before that i took two programming classes in high school and knew the bare basics of html css python and java.
That TF2 clips was fucking nasty, WTH? How did you get away with that? Also, really cool content, of course. I don't really understand how you got access to the source code (and especially comments) without getting the leaked build, but I love getting a look at the code and seeing why things work the way they do. btw, I didn't think that the object being removed being the cause of the crash is surprising at all. I think the reason for the physics object being removed is probably to save RAM, unless I'm misunderstanding something about the nature of the physics object. But I do agree that it is unnecessary. The amount of RAM saved should be negligible, and shouldn't be able to result in a memory leak. Or maybe it's just kind-of muscle memory to delete an object when it should no longer be possible to access it.
Code archeology is always fun. Best thing is when you're tracing a particularly nasty bug for hours and hours, only to find a comment on a function that you think is causing it: "this doesn't work"
I love these types of videos because you get an insight into the code of the game and interesting oversights/bugs the developers had missed and why they actually happen.
Bravo, I require more! I MUST know these obscure yet interesting facts. The hidden dev comments are also extremely interesting and, IMO, worthy of their own video if there’s enough of them.
On gosh, I read the thumbnail as "crashies" and for a split second thought this video would be about a furry parallel parking incident. "Oops! X3 I made crashies again!!! uwu"
Please do another video like this soon! For whatever reason this was really entertaining! I don’t understand code but I love listening to people explain it!
I remember in gmod I was messing with func_physboxes, those entities have a specific flag called Break on Touch, which does exactly as it said, so if u have said physbox at hp 10 or 1000 - it will always break. But if u set its hp to 0 ( which even says that it wont break ) and attempt to break it - the game still operates, but is in a weird softlock state
Dig the incredible technical and deep analysis done on these glitches. It’s a subtle reminder that a glitch isn’t always meaning something is “broke”, rather that it operates in an unintended and interruptive manner. These glitches are the engine working exactly as it was coded, it just that it should have been made different to produce the desired results.
I love the dev comment "Don't finish that sentence" like they knew it was a bad idea to set "m_hTargetEnt" to null. Or I could be entirely wrong and it's talking about "SentenceStop()"
I actually have a good theory for the Helicopter crash; since the event tells the Heli to move to a specific pathing node, it's possible that when the Helicopter's initialized, it's pointer to 'what node are we located at' is set to NULL by default, and the event's there to give it somewhere to go at the start of the fight (set on a delay so the helicopter has time to set up first). Hence why if you get the heli to run the "saw the player approaching" code before that path variable's been initialized through the I/O event, when it tries to figure out where it should move to engage the player, the failsafe check passes since the helicopter doesn't have any node set, thusly setting off the false assert crash. I imagine a crude fix to not make it apparent to the player that it doesn't know what it's supposed to be doing would be to run a basic distance-check to find the nearest node to the heli's position, then assume 'that's where we're supposed to be' and return it while setting the variable to that same node...
These are some incredibly easy null pointer fixes. The second one for throw, just have a check for the phys object to only do what it does when "Phys object not null" have it take the object and throw. If "Phys Object null" then just cancel throw and revert to regular play like it would normally. The only reason a lot of these are not fixed is they were missed for long enough and effect the game very rarely so the discovery and then priority were later and lower. Love half life 2.
I want more of these videos tbh, after watching another youtubers videos on his analysis of different aspects of the og doom engine, I was searching for the same thing for the source engine as well and now I have it
Interesting... What about the crash at citadel_03 when you grab your weapons back? I assume that also has some null stuff, but then I wonder why it sometimes doens't crash.
There is another way to crash the game: 1) Put the game disc into a rocket 2) Make the rocket run out of fuel before it reaches escape trajectory 3) Wait 3-10 minutes 4) Crash
So basically, if you throw a painting bucket on a pigeon while on the roof of buildings in City-17 (the chase sequence with the metrocops) you also crash too. Edit: I also made a video on it months or a year ago.
The first one is similar to if you delete the actors from the opening scenes (alyx, barney, kleiner, however, lamar is probably the only actor ive deleted through console commands and the game went through the opening scenes no problem, just lamar wasnt there. I think this is because lamar's script events occur regardless, while barney, alyx, and kleiner need to walk over and press buttons n whatnot to keep the scene going)
Another crash: when I tried to take rollermine(ball that dog gives) with me, every single time if I submerge it slightly and pull it out, the game crashes. I bypassed that crash by quickly saving and loading before crash after pulling out that rollermine.
In Xbox original, I broke this game by killing alyx with a suitcase right before she opens the soda machine, once I entered Dr Cliners lab, the game would freeze since the files couldn’t continue without the model of Alyx
there is also this one crash that happens at the mines in ravenholm. I don't remember how I did it but it could have involved me bringing dog's ball over there.
another way to crash: If you skip Alyx encounter in the chapter A Red Letter Day, and go to kleiner's lab after he said his starting dialogue. After this dialogue ends, alyx is supposed to say another dialogue but if it doesn't exist, it will crash when the alyx dialogue thing triggers
another easy one can be done in the citadel, if you throw a grenade before the confiscation field ejects your weapons and the grenade manages to knock one of the weapons down the hallway outside the field's reach, the game crashes
I believe the reason that the PhysicsObject for the weapon is deleted is to avoid leaking memory in the program. I don't know much about Half-Life and it's Source Engine, but I do know that softwares need to free up some of their memory if they allocated it somewhere, or else the memory is allocated but can't be reached because the pointer to that location is missing. Many programming languages have automatic fixes for this such as Java, but other languages like C or C++ forces the programmer to implement the program in such a way that the memory is freed when it is no longer being used, which I think is the case for the weapon's PhysicsObject.
I mean, the Airboat 'crash' could be any number of things, knowing the Source engine's usual code hijinks. It getting stuck in a bullet-tracing function's pretty odd though, since the other suspects I might have for an infinite-loop error (kinematics code for keeping the feet on whatever the cop's standing on accidentally gets a NaN position, entity pathing having zero clue where to move from that position, etc.) aren't really included... considering that 'enginetrace' function call, one might presume that the cause is in that function, by the name it might be something that could get stuck infinitely iterating over the entity list; but it's likely to be in the raw engine source code, not the HL2 source, hence why tracing it would be difficult...
you can crash the xbox version by placing a barrel between alyx and the secret vending machine door in red letter day, the barrel will kill her and when you enter the next room the game gets confused and crashes
the game deletes the physics object because its just good practice, the physics object isnt going to be used anymore so its removed to free up whatever memory its using
