Kornman00
August 8th, 2010, 06:22 AM
Today's Open Sauce update is brought to you by the number Eight.
Intro:
Open Sauce. Yelo/Battery. Project Yellow. All of these names are what some, if not all, of you have come to know as the series of Halo engine modifications done by Kornner Studios (formally Kornner Software). A tribute to the countless players who have made multiplayer damn fun and damn funny. A tribute, to the various Halo makers across many platforms for making such a fun game, and fun story. They move on, creating new games. We stick around, get the lay of the land our sandbox is in, and iterate on what they couldn't in their schedule. They're bound by game development deadlines. We're bound by free time, our own sanity and something about copyright...walls or maybe it was calls. Which ever it is, we tip toe across tight ropes making sure the holes in these walls, or the calls we ignore and let ring throughout the day and night, don't harm the original product these copyright holders spent countless man hours to make.
Rules just don't end at the law. There are also rules defined by the engines which power these great games. They have strict standards and formats. Guidelines that we as engine modificationers (why yes, I did make that word up) must learn and respect in order to keep with the feel and mood of the playground which we've been given the privilege to play in. If we don't, that privilege can be quickly revoked. You don't come into a new school and decide to rework the entire playground the very first day. You have to earn your right of passage by those who were there first. The Sandbox of Life in a way.
Details:
Now that we got the formalities out of the way, how about we get down to business?
Officially, Open Sauce has been skitting around as a Release Candidate for a year now. Hard to believe actually. I really didn't want it to go on this long before something solid came out but it's kinda hard to develop for a game when your machine flops and you're stuck waiting until the summer for new hardware to come out for your new development machine.
However, we now see Open Sauce at 2.5. The old features have had time to mature but there are also some new and really awesome features you can now throw on your plate. Really, this should be an entirely new version of OS...but I feel the original OS2's RC was weak and buggy (hey, it was a RC!). Not to say this new version won't have some bugs, but you can rest a little easier knowing that I and a couple others spent many hours pushing the code through tests. Testing is no joke when you're modifying a closed source system. You're confined to how it starts up and the resources it uses. So when it comes to say the game side of things, performing tests can be a major pain as you may find a bug and think it's a simple code change. You exit the game, recompile then start the game back up yet again. There really is no way to perform true unit tests with modifications like OS. Maybe that's something the Kornner should look into changing, hmmm...
So what's new? Well I'm sure most of you will get very happy at the news that we're v1.09 complaint. The upgrade for that took about two solid days (since I had to muck around in both the client and dedi server) but I think it was time well spent in the end. The Halo 1 SDK in OS still includes the v1.08 support but after this release I'm not making as much of an effort on updating the backend memory layouts for that build of the game.
Continuing, I've also spent a long time now working with FireScythe getting his Postprocessing rendering into a solid system that plugs into OS and that also follows most of the standards it goes by. The Postprocessing system can now have its resources stored in some pretty robust tags or even dynamically used by shaders placed in your profile's HaloCE folder (where your game saves are stored). The latter allows you to develop and test your tags in game before you lay them down into tags. You can thank FireScythe for keeping up with systems that work in both tags and dynamically in game!
Another feature we've touched up on: User settings. I wanted this release to be more UAC (I don't know about you guys, but something I actually use) friendly by storing 99% of its data in the HaloCE documents folder. We've also spent time incorporating the use of XML for our settings storage instead of plain-old-text. I was really hesitant of this at first, as it adds yet another library dependency to the SDK. After some initial hiccups and swearing though, we got it working, and it was nice. Really makes things a lot easier for not only us, but the end-users too.
We've also added HEK configuration settings. This is a really awesome new feature to the toolset that I think many people will really enjoy. Are you tired of having to copy 3+ EXEs and countless DLLs to different folders where you have stored countless different tag folders? Don't you wish you could have a single storage location for your executables and then for your various tags folders? Well, now you can! You can setup an XML file which specifies an infinite amount of different "profiles". These profiles define the root directory of your tags folder (ie, "Halo Custom Edition"), plus the tag folder name (ie, "tags" or "tags_h2ce"), the data directory, and maps directory. Basically you can now control where everything gets fed in or shat out.
This doesn't stop at game data folders either, all debug logs are now stored under your HaloCE user profile in the OpenSauce directory along with your OS user settings. All in one place now. Every OS HEK exe will use these file locations no matter where the EXEs themselves actually are. Less clutter on your harddrive! Of course, with the new settings introduced in the OS HEK exes, you should only need one set of HEK exes ;). Debug.txt will no longer bitch at you about the missing beta.map files at start up. This makes it so that the debug log won't be modified unless there is something that actually needs to be written (ie, open edges!).
When it comes to Guerilla/Sapien, you can also specify the profile you want it to use from the settings, via a command line argument much like you use "-console" for the game's exe. This enables you to instead use multiple shortcuts to the same set of EXEs but with different profile names that define what paths to use. So you can have a shortcut to G/S that launches your stock tags environment. Or a shortcut which launches your mod's tags environment. Like the Energizer bunny, it keeps going. Tool however can't specify a profile path since it's a command line application and expects the first argument to be a tool command. So instead, it will use the "default profile" that is specified in your editor settings. If you don't specify a editor profile to use in G/S's command line, then they too will use the "default profile". If no default profile is selected, then no paths are overridden and the EXEs will behave with the same paths as what the stock HEK uses.
Speaking of Sapien, we also know that some of you have multi-processor issues with it (Vista and higher). Well you can stop manually setting the fucking affinity as you can now specify the affinity that it will use in the editor settings! I know, I know, you didn't get us anything. All we expect in return is that you use these new tools and features to make awesome new maps. Or spruce up existing maps :).
'Wait', you ask in a daze, 'I thought OpenSauce was mainly a game extension?'. Fear not citizen, we've also been improving on and adding to the list of things you can do with the game engine too.
People have been doing some pretty neat things with multiplayer maps and scripting over the years. However, many of these neat things have been powered by some sneaky tricks people have thought up. We wanted to introduce some new functionality that would make some of these tricks less tricky and more empowering. We've introduced new functions that let you query various properties of players, units and weapons. You're not just limited to players either, you can work on a team basis too. Querying properties isn't the only thing you can do with players either. There are a few new functions which let you manipulate them as well.
Slap Chop (http://www.youtube.com/watch?v=UWRyj5cHIQA) (You'd really love our nuts)
Of course, not all features can make it off the cutting board. We had to Slap Chop a couple ideas from being finalized or making it into the SDK. One of them was Synapse. Synapse was/is a server tool that was planned for HaloCE that was mostly focused around very detailed stat collection. These stats would be gathered across the entire game. All players who entered and left (and came back again) would have their stats collected along with any shenanigans they performed during the match.
Should be easy right? Well, more or less. You see, before the idea to try Synapse out for HaloCE (it was originally theorized for H2V, back when the game had some hope still left) came about I was working on adding saved films to OpenSauce. It couldn't be done on the scale of Halo3 of course, but it'd at least be something (which is better than nothing). I had a pretty good collection of engine data on how I could go about doing it. Eventually I hinted at the idea to someone, though I forget where. From there, the idea was that an entire HaloCE match could be recorded with all of the events that were fired during the match. From there, the event stream would be compressed and sent to the server for processing. Then, an internal tool would process the entire "film" generating an intermediate file which Cerebrum, the web server to the stat system, could parse and then display to users.
With this system we'd be able to keep records of past games and in the event that we came up with new formulas or more stats, we could go back and re-feed the game data for processing. Other benefits would have come from this, to include detecting cheaters (both in automated form and by manual inspection). In which case the game would then be considered invalid. List goes on, but I'm sure you're getting the idea.
Bringing back the "gravity gun" that was seen back in 2005/2006 was also considered. However it just wasn't possible in the time frame we had left. I was even talking to someone who said that if I could bring this back along with the new ideas I had for it, they'd totally make Forge World for CE (not a remake but a map tailored to CE). Coupled with some of OS's other features (ie, mod-sets), and this Forge World CE would have been pretty powerful and data friendly.
When it's done.
We're just at the tip of the iceberg. By the end of this month you'll get to experience the full monty of the SDK. Doesn't matter if you're an engineer, a modder or a casual player. You'll find something of use in Open Sauce that will greatly enhance how you enjoy your Halo experience.
Note: Yes, I know this is just a wall of text. I'm out of town right now and don't have the ability to take screen captures and/or video. Some things will just need to be experienced in the end anyway. That is what Open Sauce has been about mostly: better user experience.
Intro:
Open Sauce. Yelo/Battery. Project Yellow. All of these names are what some, if not all, of you have come to know as the series of Halo engine modifications done by Kornner Studios (formally Kornner Software). A tribute to the countless players who have made multiplayer damn fun and damn funny. A tribute, to the various Halo makers across many platforms for making such a fun game, and fun story. They move on, creating new games. We stick around, get the lay of the land our sandbox is in, and iterate on what they couldn't in their schedule. They're bound by game development deadlines. We're bound by free time, our own sanity and something about copyright...walls or maybe it was calls. Which ever it is, we tip toe across tight ropes making sure the holes in these walls, or the calls we ignore and let ring throughout the day and night, don't harm the original product these copyright holders spent countless man hours to make.
Rules just don't end at the law. There are also rules defined by the engines which power these great games. They have strict standards and formats. Guidelines that we as engine modificationers (why yes, I did make that word up) must learn and respect in order to keep with the feel and mood of the playground which we've been given the privilege to play in. If we don't, that privilege can be quickly revoked. You don't come into a new school and decide to rework the entire playground the very first day. You have to earn your right of passage by those who were there first. The Sandbox of Life in a way.
Details:
Now that we got the formalities out of the way, how about we get down to business?
Officially, Open Sauce has been skitting around as a Release Candidate for a year now. Hard to believe actually. I really didn't want it to go on this long before something solid came out but it's kinda hard to develop for a game when your machine flops and you're stuck waiting until the summer for new hardware to come out for your new development machine.
However, we now see Open Sauce at 2.5. The old features have had time to mature but there are also some new and really awesome features you can now throw on your plate. Really, this should be an entirely new version of OS...but I feel the original OS2's RC was weak and buggy (hey, it was a RC!). Not to say this new version won't have some bugs, but you can rest a little easier knowing that I and a couple others spent many hours pushing the code through tests. Testing is no joke when you're modifying a closed source system. You're confined to how it starts up and the resources it uses. So when it comes to say the game side of things, performing tests can be a major pain as you may find a bug and think it's a simple code change. You exit the game, recompile then start the game back up yet again. There really is no way to perform true unit tests with modifications like OS. Maybe that's something the Kornner should look into changing, hmmm...
So what's new? Well I'm sure most of you will get very happy at the news that we're v1.09 complaint. The upgrade for that took about two solid days (since I had to muck around in both the client and dedi server) but I think it was time well spent in the end. The Halo 1 SDK in OS still includes the v1.08 support but after this release I'm not making as much of an effort on updating the backend memory layouts for that build of the game.
Continuing, I've also spent a long time now working with FireScythe getting his Postprocessing rendering into a solid system that plugs into OS and that also follows most of the standards it goes by. The Postprocessing system can now have its resources stored in some pretty robust tags or even dynamically used by shaders placed in your profile's HaloCE folder (where your game saves are stored). The latter allows you to develop and test your tags in game before you lay them down into tags. You can thank FireScythe for keeping up with systems that work in both tags and dynamically in game!
Another feature we've touched up on: User settings. I wanted this release to be more UAC (I don't know about you guys, but something I actually use) friendly by storing 99% of its data in the HaloCE documents folder. We've also spent time incorporating the use of XML for our settings storage instead of plain-old-text. I was really hesitant of this at first, as it adds yet another library dependency to the SDK. After some initial hiccups and swearing though, we got it working, and it was nice. Really makes things a lot easier for not only us, but the end-users too.
We've also added HEK configuration settings. This is a really awesome new feature to the toolset that I think many people will really enjoy. Are you tired of having to copy 3+ EXEs and countless DLLs to different folders where you have stored countless different tag folders? Don't you wish you could have a single storage location for your executables and then for your various tags folders? Well, now you can! You can setup an XML file which specifies an infinite amount of different "profiles". These profiles define the root directory of your tags folder (ie, "Halo Custom Edition"), plus the tag folder name (ie, "tags" or "tags_h2ce"), the data directory, and maps directory. Basically you can now control where everything gets fed in or shat out.
This doesn't stop at game data folders either, all debug logs are now stored under your HaloCE user profile in the OpenSauce directory along with your OS user settings. All in one place now. Every OS HEK exe will use these file locations no matter where the EXEs themselves actually are. Less clutter on your harddrive! Of course, with the new settings introduced in the OS HEK exes, you should only need one set of HEK exes ;). Debug.txt will no longer bitch at you about the missing beta.map files at start up. This makes it so that the debug log won't be modified unless there is something that actually needs to be written (ie, open edges!).
When it comes to Guerilla/Sapien, you can also specify the profile you want it to use from the settings, via a command line argument much like you use "-console" for the game's exe. This enables you to instead use multiple shortcuts to the same set of EXEs but with different profile names that define what paths to use. So you can have a shortcut to G/S that launches your stock tags environment. Or a shortcut which launches your mod's tags environment. Like the Energizer bunny, it keeps going. Tool however can't specify a profile path since it's a command line application and expects the first argument to be a tool command. So instead, it will use the "default profile" that is specified in your editor settings. If you don't specify a editor profile to use in G/S's command line, then they too will use the "default profile". If no default profile is selected, then no paths are overridden and the EXEs will behave with the same paths as what the stock HEK uses.
Speaking of Sapien, we also know that some of you have multi-processor issues with it (Vista and higher). Well you can stop manually setting the fucking affinity as you can now specify the affinity that it will use in the editor settings! I know, I know, you didn't get us anything. All we expect in return is that you use these new tools and features to make awesome new maps. Or spruce up existing maps :).
'Wait', you ask in a daze, 'I thought OpenSauce was mainly a game extension?'. Fear not citizen, we've also been improving on and adding to the list of things you can do with the game engine too.
People have been doing some pretty neat things with multiplayer maps and scripting over the years. However, many of these neat things have been powered by some sneaky tricks people have thought up. We wanted to introduce some new functionality that would make some of these tricks less tricky and more empowering. We've introduced new functions that let you query various properties of players, units and weapons. You're not just limited to players either, you can work on a team basis too. Querying properties isn't the only thing you can do with players either. There are a few new functions which let you manipulate them as well.
Slap Chop (http://www.youtube.com/watch?v=UWRyj5cHIQA) (You'd really love our nuts)
Of course, not all features can make it off the cutting board. We had to Slap Chop a couple ideas from being finalized or making it into the SDK. One of them was Synapse. Synapse was/is a server tool that was planned for HaloCE that was mostly focused around very detailed stat collection. These stats would be gathered across the entire game. All players who entered and left (and came back again) would have their stats collected along with any shenanigans they performed during the match.
Should be easy right? Well, more or less. You see, before the idea to try Synapse out for HaloCE (it was originally theorized for H2V, back when the game had some hope still left) came about I was working on adding saved films to OpenSauce. It couldn't be done on the scale of Halo3 of course, but it'd at least be something (which is better than nothing). I had a pretty good collection of engine data on how I could go about doing it. Eventually I hinted at the idea to someone, though I forget where. From there, the idea was that an entire HaloCE match could be recorded with all of the events that were fired during the match. From there, the event stream would be compressed and sent to the server for processing. Then, an internal tool would process the entire "film" generating an intermediate file which Cerebrum, the web server to the stat system, could parse and then display to users.
With this system we'd be able to keep records of past games and in the event that we came up with new formulas or more stats, we could go back and re-feed the game data for processing. Other benefits would have come from this, to include detecting cheaters (both in automated form and by manual inspection). In which case the game would then be considered invalid. List goes on, but I'm sure you're getting the idea.
Bringing back the "gravity gun" that was seen back in 2005/2006 was also considered. However it just wasn't possible in the time frame we had left. I was even talking to someone who said that if I could bring this back along with the new ideas I had for it, they'd totally make Forge World for CE (not a remake but a map tailored to CE). Coupled with some of OS's other features (ie, mod-sets), and this Forge World CE would have been pretty powerful and data friendly.
When it's done.
We're just at the tip of the iceberg. By the end of this month you'll get to experience the full monty of the SDK. Doesn't matter if you're an engineer, a modder or a casual player. You'll find something of use in Open Sauce that will greatly enhance how you enjoy your Halo experience.
Note: Yes, I know this is just a wall of text. I'm out of town right now and don't have the ability to take screen captures and/or video. Some things will just need to be experienced in the end anyway. That is what Open Sauce has been about mostly: better user experience.