My specs: Dell Vostro 3750; Core i5 2410M
Windows 7 Professional
NVIDIA Geforce GT 525M 1GB
4GB DDR3 Memory
I can’t imagine that it could be my specs because I’m able to play games like Crysis 3 smoothly. But I’ll tell you where the crashes occurred:
1st: I killed the now-killable guard zombie (that stands behind the glass) and when I wanted to move on to H it gave me the “lump 53” error! It happened on the loading between G and H.
2nd: It happens all the time, even if I console command to H. The moment I open the hatch and jump down the pipe on the roof (after killing the sniper) the game freezes when I’m mid air down the jump and I receive a beautiful “HL2.exe not responding” error.
3rd: I was playing around in map H and even before I got to the marine that is is thrown through the wall I tried to go back to G through the new office door you placed there (where the guard zombie is) and it gave me the “lump 53” error. So it happens when the levels load from G to H and visa versa.
4th: I was playing G and explored the whole map a little bit and then the game crashed (HL2.exe not responding error) randomly when I was standing on the roof.
I haven’t had time to check the errors and behaviors myself but I will let you know if anything turn up.
Transition from G/H - possibly a problem with that area itself as it seems to happen to some people when consoling to H.
The hole that get blown in the wall at the start of the Abrams fight.
Dropping down into the water tank by the Satpipe scene.
I’ve possibly rectified a problem which might have been occurring by the Satpipe scene, so we’ll have to see if it’s helped that one. The trigger_multiple which closes the areaportals and triggers the satpipe scene to set up was right next to the trigger_autosave. It’s possible that having the game save while that stuff was happening might result in a crash. That’s all I can think of.
I’m currently tinkering the Abrams scene to make sure the game knows that all inputs can only be fired once. That’s the only reason I can think that scene might be crashing. There are no serious flaws in the I/O for that section that I can find.
As for the transitional area, I might just remove the Zombie, which is a shame because I like him.
I tested these problem areas myself a total of 10 times each (30 total), and didn’t crash once. Which is strange. It’s problematic. If I can’t reproduce the crash, I can’t figure out how to fix it.
EDIT: On the Abrams scene, I found a few outputs from the logic_relays leading to non-existent entities (outputs which were used for a previous setup but I’d never deleted). I don’t THINK these nonfunction I/O chains can cause crashes, but I’ve deleted them just to be safe. Maybe it will help.
I doubt it. I doubt EVERYONE has bad setups which are their own fault. It seems to be happening to everybody except me, which is very weird.
The BLAST DOOR IS THE PROBLEM. No really. It’s the blast door. Not the zombie. Transfer to the next map before the blast door closes and you get the error.
As for transitioning back to G from H, you may want to consider some area portals inside of the office space to increase performance.
Some people get the problem with the normal door as well. I think it’s the Zombie, but I’m gonna look at everything.
One thing I noticed that lots of these crashing areas have in common is that they contain broken I/O chains, from things I might have had before but then changed/removed, without deleting the I/O chains. I have a theory that this could cause people crashes, but I just don’t know for sure, because it doesn’t explain why I don’t get them. They’re called broken I/O chains, but I never really thought they could cause problems so I never deleted them. I’ll go through Hammer’s error checker very systematically and delete them all, just to be on the safe side. This may very well eliminate the crashing for people, though I don’t know for certain.
I’m just going to point out to everyone that I’m basically ready for the final release of v2. I’ve fixed everything that I wanted to, it’s just the crashing which has me in a bit of a pickle. So what I’ll probably do is actually have a Release Candidate for v2, before the final release. This is probably going to be released tomorrow or even this evening, depending on how it goes.
The purpose of the Release Candidate IS NOT for detailed bug reports as everyone’s been so kindly giving me. It’s not. It’s just to make sure the crashing has been eliminated before I go for the wide release. Please bear this in mind. My main focus now is stability.
Intel Core I7 2630QM @2Ghz
8.00GB DDR3 (PC3-10700 (667Mhz)
AMD Radeon HD 6800M 1GB GDDR5
Windows 8 Pro 64-bit
Transition from G to H when killing zombie cop (ran out of memory error)
TOW Yard when killing the Grunts from closeby (HL2.exe error)
When Osprey destroyed tank in H (crash to desktop without error code)
Windows 7 64-Bit
AMD Phenom II X6 1090T @ 3.2GHZ
Radeon HD 7770 Crossfire (Both cards hold on to 1GB of VRam)
16GB RAM
I don’t think the zombie is the source of the error. Let me explain.
Whenever I start the game from an auto save (when you watch the fight between aliens and HECU marines), at some point while I’m in the office block, the game’s performance starts to decline from 60 FPS to below 50FPS. The game would later crash when I tried to get into H after killing the zombie.
When I loaded a quick save in the middle of the office block (near houndeye room), performance is about 60FPS and killing the zombie and opening the door to H doesn’t lead to a crash at all. It could be those broken I/O chains you were mentioning about.
Personally I think that alt stairwell to the zombie office should be scraped because if you go that way, it destroys the regret vort’s animation scene, and I always loved just leaving that zombie to his own demise. But as long as c2a5h’s tank doesn’t attack you at the start of the battle ill be happy.
Edit: did a quick playthrough was clearing out the new offices on c2a5g. Cleared it from the vort side to the Alien grunt side, went down the stairs killed the security guard zombie, went back up the stairs and headed to the houndeye office when I crashed to my desktop.
Windows 8 64-bit
Intel® QuadCore™ i5-3570k CPU 3.40 GHz
NVIDIA GeForce GT 610
8.00GB RAM
I agree that we’re not supposed to go to the guard zombie area but maybe to make him possible to be killed, just have a small hole which a grenade could fit in to kill the zombie.
I think Text did a good job here with those accessable zombie guard area just before transition…
Now u actually see the world behind the area…
Always loved to see the full Black Mesa base and not just some parts of it… (just a dream…I know!)
So every room is accessable, when u enter Black Mesa with the tram, u see wonderful parts u never access (not using noclip) and when u use noclip u loose all the magic!
Not exactly. Text is going to release a Release Candidate version of ST Uncut either tonight or tomorrow for us to see if the crashing issues that were reported in the beta have been fixed or not before the final version is out.
Very nice, hopefully the crashes are fixed. The only 2 areas where I consistently got them was at the level transition, and dropping into the drain pipe. Those were before the new version, I haven’t experienced any with the new STU as of yet. The zombie one in particular may be related to the old crash though.
Btw is it still too late to recommend a change in the HECU’s AI behavior? I’d imagine it is, I just don’t like how their main tactic is to suicide charge into the enemies, who already vastly outnumber them. That and maybe the removal of this wall, which seems redundant now that we can see the place behind it anyway.
Of course if it is too late, I suppose you could just ignore this post.
I had no problems. And considering I not only have less memory than most people here (both RAM and VRAM), but multitask extensively, I doubt memory has much to do with it, despite what the error messages imply. Oh, and I always play in windowed mode, but I wouldn’t think that matters much either.
Founded in 2004, Leakfree.org became one of the first online communities dedicated to Valve’s Source engine development. It is more famously known for the formation of Black Mesa: Source under the 'Leakfree Modification Team' handle in September 2004.