We can’t go a few months without another one of these propping up!
Facepunch member Walropodes has unearthed some pretty crazy stuff in the Source Filmmaker files. To be more exact, one file, which can be found under this folder path: “…/SourceFilmmaker/game/sdktools/python/global/lib/sitepackages/filesystem/valve.py”
There are two coding segments here which are of interest to us. Here is one, starting from line 49:
def content():
”’
returns a Path instance representing the %VCONTENT% path – path construction this way is super easy:
somePropPath = content() / ‘ep3/models/characters/alyx/maya/alyx_model.ma’
”’
global _CONTENT
And here is another, starting from line 76:
def tools( engine=’Source 2′ ):
The most important thing to note here is that the engine being used is explicitly and clearly noted as being “Source 2“… which is very interesting. Let’s first understand this: the eighth generation of video game technology is little more than one year away. Source, in its current form, requires a massive overhaul in order to capitalize on new tech opportunities in the next generation, and this is indisputable by this point.
And when you’re giving an engine such an extensive next-gen reworking, why on Earth wouldn’t you give it a separate brand and number to make it stand out? So, yes, I firmly believe that Source 2 does exist, in some form or another. In fact, I’ve thought so for quite some time, but this is the first real confirmation that it might actually be out there, and it’s all pretty exciting.
The EP3 reference from line 49 is also rather interesting. It appears they’re using the Maya model format, which in my opinion lends further credence to the possibility of a new engine (considering the fact that native Maya support on the Source engine is notably painful)… but don’t take my word for it, I’m not much of an expert when it comes to this stuff.
But according to Walropodes, that ain’t the end of any interesting tech-related finds in the SFM files. With regards to better tools and new engine integration, here’s this to chew on:
In \sdktools\python\global\lib\site-packages\vproj, there’s “modoConfig.py” and in vprojUI.py there’s tons of modo-related stuff there. In the ui subfolder, there’s a Qt layout file for a modo plugin install screen of some sort (modotoolsinstalldlg.ui)
It certainly seems as if Valve has some impressive stuff brewing behind the scenes, on the toolset-related front. Better integration and support for an assortment of 3D development programs could only be one side of the whole dealio.
Still, I’ve gotta say – it’s been an interesting couple of months to be a Half-Life fan. New-found revelations towards the franchise’s fate and destiny; colossal concept art leaks; and an assortment of bizarre hints towards Half-Life in some of Valve’s other games.
Not sure what it all means, and only time can tell. But I’ll be keeping my eyes and ears open within the foreseeable future, so stay tuned!
Credit to Gamerman12 for the tip, and to ValveTime for unearthing the other major code segment.
26 Responses to “References To HL2: Episode Three And Source 2 Found Inside Source Filmmaker”
I want tech demo of source 2 now!
Great news, Vic. Thanks.
Valve used Maya for long time. Portal 2 animations are done in Maya. It’s model source file, I’m pretty sure they will still use IDST, because it’s optimized for Source.
or is it just code?
alyx_model.ma
.ma is maya ascii file
that file should be openable in maya. has anyone tried?
Exciting news, to say the least. I’v always thought that like HL2, they’ll unveil a new engine with release. BAM! Confirmation, even if it’s a small one.
I’m probably one of the only people out there who would be wholly content with the next Half-Life game running on the current Source Engine. I know lighting tech has come a long way, Hammer has a steep learning curve, and BSP is a difficult format to work with if you’re not building rectangular rooms (such as in Portal), but even now I play the original Half-Life 2 and its various community mods (many of which are really stunning) and I find myself feeling as though first-person-shooter controls simply do not get any better on PC.
All that having been said, the idea of a true successor to (as opposed to a new iteration of) Source deeply excites me. Even though I would be content with Source 1, the potential room for new-age technology coming straight from Valve is enthralling, to say the least. The one thing I really hope they keep more or less unchanged from past Half-Life games is the control scheme. Of all the Windows-based FPS games out there, I have yet to find a control scheme as comfortable as the one in HL2–which I think is really significant given that there really isn’t much variety to be had in FPS controls.
As for the minuscule glimpse of a new Half-Life game, I am happy we fans have been given such a consistent (albeit very limited) stream of speculation-worthy clues lately. I never doubted the series would continue, but this year has been easy to get excited over–more than nearly every year before it. As was heartily discussed in the first publication of the “Half-Life Dissertation,” there is no shortage of obstacles in making a new Half-Life game–principally the issue of continuing where Episode Two left off while still being new-player-friendly–so I am GLaD it is Valve, of all people, to take on the hurdle.
The bottom line is that I hope we, the community, continue getting these little tidbits of Half-Life “news.” It restores my hope each and every time.
Make a topic with the future of steam in windows 8 because gabe hates it.
If there is going to be a Source 2 I’d expect it to have those features:
-Getting rid of the BSP map format
-Support a wider range of shaders (beyond DX10)
-A redesigned SDK, hopefully with a “what you see is what you get” realtime feature, and some new tools which improve ease of use such as a GUI-based SMD compiler and a soundscript writer.
-Better usage of system resources, such as taking advantage of 64-bit processors (it was removed in the may 25th 2010 update probably because of mac support, or Steam cloud integration as 64 bit saves can not be accessed from 32 bit clients).
Why remove BSP?
Otherwise, yeah those are some of the things.
I think that the BSP map format would be pretty limiting on a map editor with a realtime feature, because it has to be compiled from a VMF file in order to run.
A new map format which can be edited directly would make it much easier to test the map inside the editor and preview lighting and cubemaps, compiling would only be required to build visleafs for the final version of the map.
There are 5 possible outcomes of this:
1) Compiling still exists, but it happens in game rather than external tool; you test your map without visleafs and lighting. In Hammer, you can do it by disabling VVIS and VRAD. Because the editor will be in game, Hammer loading time will be added to game loading time. Bad for developers and players.
2) Every click in the editor takes minutes because of lighting recalculation. Bad for developers.
3) Clicks take short time, but final lighting is dumb. Bad for developers and players.
4) Lighting is processed when the map is loading. Loading a map takes 20-40 minutes. Bad for developers and players.
5) Lighting is processed in runtime. No bouncing light. Bad for developers and players.
You’re exaggerating here, SiPlus, and you’re also speculating very heavily, intentionally tipping the scales towards the worst case scenario. Valve will always choose whatever methods and paradigms work best, and they will always ensure, through continued optimization and development, that everything works just as it should.
Fact of the matter is, the BSP format is outdated, and real-time development tools are starting to come into the light, so to speak. Put two and two together, and it becomes apparent that it’s high time for Valve to ditch it and go for something new.
But if you get a realtime lighting ala CryEngine, you needn’t to compile the map in order to see the final lighting.
I see. Thanks. And to everyone else ^above.
because no-one uses it anymore and generally serves no purpose nowadays since there are much more improved and common methods of culling out there
But BSP is the fastest at runtime.
Portals would be just redundant work.
yeah but next gen stuff doesn’t really need that speed and ditching it would probably make changing stuff much faster and easier
Python? Nice. I didn’t know they use it. But I guess those hints are from a programmer having fun.
I know why the first reference is in line 49. It’s the number of months until ep3 release.
Try “number of years”!
lol!
LOL xD
I was thinking something in those lines, too.
But looks like I’m wrong!
*about the programmers making jokes, not about valve time, of course
New engine for a new Half Life?
Not surprising.
Source 2, I hope that those Direct X 11 features will be included in it if it comes out.
Considering, it’ll more likely embrace OpenGL more.