The "Everything in SDK 2013 is Broken" Thread

General Development Source 1
#1

It seems like Half Life 2’s overall engine is suddenly totally borked. All the player physics are completely messed up. Jumping feels like a Halo game now because it’s floaty, and player movement is substantially slower despite the enemies moving at normal pace.

All of my custom maps are having cubemap problems and skybox errors up the wazoo, even when not using SDK base 2013. This happens in Episode Two now, too. The vanilla maps look okay, but still have the strange new movement physics. Anyone else having these problems? Or have you all made the sensible move to not update until Valve un-fucks everything?

EDIT: Episode One is also borked the same way with regards to player physics.

#2

I haven’t really been experiencing these in games problems, but I suppose that’s probably because I’ve been working with extremely simple maps since just a little bit before the update.

Having to use hammer now though is suddenly a bit more annoying though.

#3

I think I’ve updated (I don’t know, I don’t really pay attention often), but my HL2, Ep1 and Ep 2 both seem to work perfectly. Physics are fine, movements, speeds, etc are fine.

On another note: I am getting a stutter-y thing every few minutes which is annoying, and I haven’t gotten it before.
I turned everything down to lowest to try and see if it was my computer not coping with the graphics (which wouldn’t make sense anyway because running BM on medium to high and it runs perfectly), but still happens, so no idea if that’s just random crap or if its 2013 SDK.

#4

The new engine seems more hardware intensive, I’m getting crashes trying to run my games now.

(no, my hardware isn’t that bad, it’s just summer and my vents are dusty as shit but I have nothing to clean them with)

#5

Great. So as of today, I’ve been hit by the lovely “floaty jump and slippery floor run” issue. Sigh.

#6

that’s why I have all source games (including BM) steamless on my laptop (I do own them on Steam)

no surprise updates

#7

July 9th steam update is causing source engine games to freeze on startup for a lot of people, the steam ingame overlay is also broken although it appears(often multiple times) in the processes in taskmanager.

#8

Assuredly the BM devs have planned for this contingency. Besides, the mod still runs on Source '07, so BM should still be playable.

#9

Yeah, BM seems to work fine, which is great.

Still sucks, wanted to finish playing Ep 1 and 2 again with developer commentary. :’(

#10

HL2 based games freeze up on me after ~2 - 25 minutes of gameplay (generally around 10). This started after the Steampipe update.

#11

I wonder if they’re gonna fix it this time. IIRC last time they broke a bunch of stuff it never got fixed.

#12

This seems to be affecting even Half-Life: Source. Puzzling.

#13

Well, received updates voor Source SDK 2013 SP and MP

So I guess fixes are added…

#14

I already uninstalled the thing. They still have to fix the vanilla games.

#15

Still broken for me in general.

On the new Hammer Editor with Source SDK 2013, custom mods cannot use the VGUI Model Browser, as it causes Hammer to close, which is a total pain in the ass!

Apparently Cubemaps are also screwed too.

Just when you thought Mapping on the Source Engine wasn’t faffy enough!

#16

I guess we should retrograde. I had some un-Steam Pipe’d backups, but they might have gotten the update fuck.

EDIT: Wait a minute- why are my movement things back to normal now? Running Ep2 off my external SSD might have done the trick. The tools are on my laptop, so I’d probably have to manually copy over the files. I guess I could build/compile on my laptop, send the map to my desktop, and test there, but this is going to be a royal pain in the ass.

#17

Are those new bugs in this new version forwarded to Valve?

#18

I guess we just wait until Valve unfucks every bug…

#19

The problem with the odd movement is actually a console variable that somehow keeps getting set to 1. The convar is sv_alternateticks, and typing “sv_alternateticks 0” in the console fixes the problem. I honestly don’t know what exactly it’s for, but I put a little work in to figuring out why it’s getting set to true. According to baseentity_shared.cpp (where it was defined), it is in fact supposed to be set to 0 by default, which most likely means that something like a config file is messing it up. I searched through the config files, and the only instance of “sv_alternateticks” is in a file that seems to set default graphics settings based on the name of the graphics chip and DirectX version. It only seems to have it set to “1” on DirectX 8.0 and below. I remember there being an issue with Source SDK 2013 defaulting to the wrong version of DirectX, and I don’t know if it’s related.

TL;DR/Conclusion: Making an autoexec.cfg with “sv_alternateticks 0” in it seems to be a good hold-me-over for the funky movement issue.

#20

Thanks! I’ll give this a try.

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.