Closed joeangry closed 7 years ago
oddly enough the sp code was not updated with some updates as the mp code, if i were you i'd try porting AI to mp or literally just copy the project solution files from sp (or edit the vpc files to be like sp's) into mp and hope it works
The singleplayer branch was meant to be a very stable snapshot that only receives absolutely necessary changes, such that one-shot singleplayer experiences did not need to worry about compatibility quirks with SDK updates. Backporting tooling and behavior changes (that themselves rely on other changes) is somewhat antithetical to its purpose.
In the future we may retire the SP variant of the SDK, as its usefulness is suspect. Using the MP SDK, even for single player experiences, should be perfectly fine.
"[...] that only absolutely necessary changes" I'd say fixing the cubemaps is a necessary change as it is and has been annoying everyone and their pet goldfish for a rather long time now, I'm tired of doing workarounds and hacks to just do something as simple as build my cubemaps. And it keeps me away from adding stuff like parallax corrected cubemaps and all that good stuff.
@Nephyrin John, I'll actually pay you to fix the cubemaps in my fork of the SP branch, how much do you want? Give me a price.
Using the MP SDK, even for single player experiences, should be perfectly fine.
We ended up switching to the MP branch for the same reason. Thanks for replying anyway.
Why did you close this? Just because you went that way doesn't mean this case is closed for everyone using the SP branch. We'd very much like an update to SP. And again, @Nephyrin my offer still stands, I'll gladly pay you to fix this and update the SP branch or just my fork of it if there is any hindrances with updating just a small thing such as this.
Because I got the closure I wanted. Valve isn't going to update the singleplayer branch in the near future, if ever. A lot of mods have disappeared so updating the SP branch with mod-breaking changes would kill these mods completely.
So SDK 2013 is over for SP? We must wait for Source Engine 2.0?
Just use the mp sdk.
On Dec 20, 2016, at 12:50 PM, kem008 notifications@github.com wrote:
So SDK 2013 is over for SP? We must wait for Source Engine 2.0?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
I'm curious what the intended workflow for using MP SDK to develop a Singleplayer mod? Should we use both the source code and tools from MP SDK? Or just the Hammer? Or just the VBSP.EXE from MP SDK?
I think the VBSP from MP would be sufficient.
I've tried using the VBSP from the MP branch, and it ups the BSP version, or just causes my mod to crash. Using the MP hammer with the SP code does the same thing
Use the source code, the MP SDK Base, everything. There's no difference between the two other than what updates they receive. They are just poorly named.
SP is just a stable release of the engine that wont be receiving more updates that may break mods in the future.
How do you go with all the networking stuff in MP SDK which makes physics and NPCs laggy. I mean interpolation, lag compensation etc. Can it be disabled for a Singleplayer mod?
They're both the exact same code base. The "sp" one is just a bit of an older version of it.
Building cubemaps in Source SDK Base 2013 has been broken since 2013. It was fixed for multiplayer after almost three years. Any chance we could get this fixed for singleplayer as well? It's a pain in the butt having to work around this!
An updated vbsp with lightmaps on static props would be awesome as well, and something mods could really benefit from.
@Nephyrin @alfred-valve @JoeLudwig
Thanks!
Edit: If you came here hoping for a solution best I can come up with is switching to the multiplayer branch for your game.