Might be related to the game crashing on fullbright compiles. I found a workaround (at least for fullbright) in that if the game is open and you load the map with dynamic lights turned off, it doesn’t crash, but if you launch straight into the map from hammer, it crashes. Can’t say for sure whether I tried it with LDR, but I believe LDR maps work using that method as well.
Probably something to do with initializing the lighting system, and it not reacting well to fullbright (or LDR) in such a state.
Yeah, don’t go there :3 Nice to see you around tho Vic.
Steam forums are still important as alot of the people who buy the game don’t know about the official forums, I just wish that before they posted there they would read through our developer posts which contain the facts, and not just randomly spout opinion as fact. Most of the responses Chon and I have given so far are clearing up misinformation, although there are a few dedicated individuals there pushing it. In short, if you read something that states “the team is doing this, the game is this” etc, if its not from a developer or quoted from one of us, take it with a grain of salt, it’s likely to be false information.
About HDR - no you wont be able to disable HDR, in fact LDR is disabled from our engine, it just doesnt use it. Along with alot of the dx8 shaders now. To put it simply, our engine has evolved alot over time, and LDR lighting added a fair bit to compile times, not to mention issues with compiling LDR as well as HDR cubemaps. DX8 shaders added DAYS onto compile times for shader code as well. So with some discussion, I made the decision to request LDR be removed, and our coders made the decision to cut out the old legacy shaders.
When we update you with the full Xen setup, I’ll likely add a specific post to the modding areas with some information on how to do some of the more advanced level design tech in there, as there isnt any documentation on valves site for it (we’re beyond the CSGO engine as far as tech is concerned now). The hybrid Black Mesa engine is currently the most advanced version of Source 1 out there (afaik), and has some complex compile options too.
Titanfall’s engine isnt really source, they ripped it up and rewrote the entire thing, iirc Respawn refer to it as teh Titanfall Engine now. Ours is a hybrid of the tf2 2009 engine (mod is on 2013 engine). I’m sure Chetan can give even more details, as i think we had a discussion about Titanfalls engine some time back. I should really catch up with some of the people who worked on Titan Fall 2, a few old BM devs went to work on it.
With branch engines you can go back a long way - I could say that Black Mesa is one of the most advanced versions of the Quake engine too, as we still have nuggets of code from waaay back then.
I remember that TF1 basically was them adapting Source to use their Radiant tech from CoD 4/MW2 since both were derived from Quake engines, but I didn’t realize they’d rewritten SO MUCH.
I think I actually decompiled a Titanfall map once to load it into Hammer, just to see how the logic worked. It was borderline impossible to figure out anything about how the map worked, since all of the entities and logic were done from scratch. I was always salty Respawn never released mod tools for the game, I would have killed for the chance to make a Titanfall MP map.
Just to let you know, this might be the cause of crashing when loading directly into maps without lighting data. If you load an HDR map first, then load the map it’s fine, but if you go straight to a fullbright map in game, Black Mesa crashes.
Off topic, I vote to unoffically name Black Mesa’s modified branch of the Source engine the Black Mesa Source engine.
If you guys release an updated hammer editor with better compiles and less of hammer… You’ll be loved forever in the source community.
While you’re at it, maybe hide carve and radius culling somewhere it’s not found easily or used.
And add ability to change hotkeys and you’re gold.
Weirdly, iirc when we went through the code base selection process - we didnt have access to the 2013 engine, and other engine versions we were offered (and had access to) were less stable. So as odd as it sounds, we used the most advanced engine available for the mod (orange box), which was updated by Valve after launch of the mod to 2013 which is essentially Orange Box with further support for other OS’s the code for which was made public, whereas we selected the 2009 engine for retail as it was the most stable. It’s possible this changed later, but the one we moved to for retail was 2009 - there’s actually not a vast amount of differences between them and it gets confusing as there are many variants, of which we can’t go into more etc. This was all decided a very long time ago now, and whilst we’ve not done anything as much as Respawn in redoing bits of the engine, its definitely changed a fair bit, including changes to vrads lighting to get that fully up to date with alot more features.
As for hammer being updated - there have been some updates to it and we haven’t forgotten future support for modding and custom maps, the tools will all be updated along with the game - some of the new features will require at least some input from a coder and level designer on the team to go through their use, as we have alot of custom entities now that are idiosyncratic in their usage vs old style valve entities, and those arent covered in the valve wiki either. We had a conversation today about the complexity of our compiles and setup in fact, so we’re giving that thought as well. :3
i wouldn’t expect to see a modified hammer (no matter how much the carve tool deserves death), but I would expect to see further modified compilers. I mean, the release branch Black Mesa VRAD already has some nifty little compile options that don’t exist in any other versions of the tool; -ambientocclusion is the first one that comes to mind. From the sounds of it, the Xen branch VRAD will have even more options, such as the colored skybox lighting, and there might be changes to VBSP and VVIS as well.
It’s possible (though certainly not guaranteed) that some features of the Black Mesa compilers will actually work on other source branches. As far as I’m aware, the current Black Mesa Source engine is for the most part, a modified version of Source 2013. Theoretically, you could compile a map for a compatible branch using the BM compilers, then load it up in a different game. I believe skybox lighting and ambient occlusion could both work with other versions of source, seeing as how static lighting data is baked into the map file itself and isn’t reliant on the engine. If that’s true, than ultimately the limiting factor would be the bsp structure and version the engine’s expecting, vs what it actually gets.
Of course, this is all speculation, and I don’t know the exact details of how Black Mesa implements these new features, nor if the Black Mesa retail bsp structure and bsp version is even compatible with other branches of the engine. All my experience in the area comes from porting mod edition bsp files to other source games such as Half-Life 2 and Garry’s Mod, which was a much easier task seeing as how they both ran on the same or newer branches of the mainline Source engine. This would be porting a map made for a newer, modified version of the source engine to an unmodified or slightly older version of it, which is much less likely to work.
Will the December update bring any improvements to the enemy AI ? (vortigaunts and bullsquids - they need to be more aggressive / be able to run and hunt you down, just like in the original HL)
Needs more RAM!
I remembered my 2005 Horror Project for CS:Source. Big map with a graveyard, forest, haunted house, barn and underground passage.
Ended up ditching it cause the PC couldn’t handle creating the map at a certain point. If only…
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.
