source-sdk-2013
source-sdk-2013 copied to clipboard
Engine utils (hammer, vtex, studiomdl, etc.) do not work.
StudioMDL does not accept mod projects that use AppID mounting, and the x64 binaries don't even include mdllib.dll:
VTEX also does not accept these projects, although both the win32 and win64 binaries work otherwise:
Because of these issues, the old singleplayer base tools have to be used instead.
This issue also applies to hammer, meaning that even maps cannot be made for mods.
A (hopefully) temporary workaround that I found is replacing |appid_440/|appid_243750| with |all_source_engine_paths| inside of the gameinfo.txt of your mod. The primary issue with this is that, after replacing them, if you want to launch your mod, you need to put them back. I ended up making two diferent gameinfo.txt files & storing them in different areas to have them at hand easily & I just overwrite the gameinfo.txt with the appropriate file as needed. First screenshot is what it should look like when you launch the mod, second is what it should look like when you launch an engine util. That said, as far as engine utils go, I've only tested this with Hammer. Other utils may still be angry for one reason or another.
This is still an issue with all SDK13 tools. I'm unsure why this check is here in the first place because it prevents every TF2 mod (and any mod that decide to use appid mounting) from compiling new assets or maps.
I haven't noticed any issue when launching a HL2MP mod built off the updated SSDK2013 after replacing gameinfo.txt AppId-based search path entries with all_source_engine_paths. @Maertzi not sure if I should check it differently or perhaps the workaround is just an issue on TF2.
See also #1003.
This issue also applies to hammer, meaning that even maps cannot be made for mods.
Hammer++ and HLMV++ was updated to support appid mounting in the meantime
As for StudioMDL, open 32-bit studiomdl.exe in a hex editor, CTRL + F and search for hex bytes 0F 84 1A 05 00 00 and replace these 6 bytes with 90 90 90 90 90 90. It doesn't actually need appid mounting to function
I've come into this issue, although it seems the reason why VALVe disabled this functionality is because they themselves can't get it to work, as neither can I. You can modify public/filesystem_init.cpp to remove this limitation, to learn that the reason it's disabled is because the utils don't actually have a way of communicating with the Steam API. Attempting to load the Steam API dll in the same way the launcher does results in Steam_API failing to init no matter if Steam is running or not.
You can try yourself though, in case I did anything wrong.
To (partially) re-enable AppID mounting, open src/public/filesystem_init.cpp and remove the following #ifdef ENGINE_DLL lines, and their respective #else and #endif lines:
https://github.com/ValveSoftware/source-sdk-2013/blob/0565403b153dfcde602f6f58d8f4d13483696a13/src/public/filesystem_init.cpp#L690-L692 https://github.com/ValveSoftware/source-sdk-2013/blob/0565403b153dfcde602f6f58d8f4d13483696a13/src/public/filesystem_init.cpp#L699-L699 https://github.com/ValveSoftware/source-sdk-2013/blob/0565403b153dfcde602f6f58d8f4d13483696a13/src/public/filesystem_init.cpp#L748-L750