What do Kornman and Firescythe have in mind for you, the individual user, the one who already pushes the last unlocked HEKs to their limits? Many things... many things indeed: http://www.youtube.com/watch?v=M_nmHD-8LUk



Many commands and engine globals have been unlocked for in-game use, and many screen effects have been added as the video clearly shows. There is one for heavy fog, one for water (or I guess it could represent heat waves even) over the camera, one for distortion as you see in Reach when stepping out of bounds.

Yelo is what makes all of this possible, a .dll that is added to your HCE directory. The extra features require, of course, a new version of tool and a new map compilation method to implement them.
Edited by The Cereal Killer on Jul 14, 2011 at 01:16 PM

where get?
and how do you even use this?

It's still in progress. You use the screen effects through script, they are added through the Yelo .dll.

I've been messing around with Open Sauce RC2 ( Bloodcreek RC3 Build ) recently and I've come up with some stuff.
Edited by 032 Mendicant Bias on Jul 14, 2011 at 01:37 PM

That's right, I forgot there were some really old versions out: http://www.modacity.net/forums/showthread.php?17758-OpenSauce-Halo-CE-SDK-Update-2-%28RC%29&p=452567&viewfull=1#post452567

will this let us have normals/bump maps on dynamic objects?

Seriously, someone should make a tutorial on how to use it, I would have been using Open Sauce long ago, just don't know how.

Its programming, like C++

just reading the word programming gives me shivers, cause programming usually requires typing a bunch of codes *shivers and gets goosebumps*

make a version of guerilla that lets me do stuff like having more than two grenades and I'll be happy.

I haven't been working on the Halo1_CE side (ie, the subprojects which directly modify the Halo1 engine) of OS as of much lately, mostly due to underwhelming responses, even with the release of the new effects (which can be defined in tags and also scripted) and detail map demo vid.

For the most part, things seem to be in working order, but we haven't done true stress testing. Nor have I really got around to testing the dedi build (for the most part, as long as the client build works, the dedi should as well).

There's no real coding involved for end-users, unless you're wanting to add additional functionality that OS doesn't already have.

We've made improvements over this past year, such as creating an installer program to handle pretty much all actions that need to be done. Maps which are dependent on OS features now also use .yelo extensions, instead of .map, to avoid the stock game from ever touching them.

However, like say, since there wasn't hardly any talk when that demo vid was released (it only shows the stuff which can actually be demoed visually), I just put it on the backburner and went on to work on more interesting subprojects in the OpenSauce codebase, like BlamLib and some Xbox related stuff.


As for your grenades idea, it's not realistically possible since a unit's gamestate memory only has enough space for two grenades.

Well I was very much looking forward to it, along with the other handful of people with enough skill to utilize it thoroughly. You said it was basically in working order but not stress-tested, would you be interested in just releasing what you've already done if you don't want to work on it more?

Oh God thank you. I tried making OS work a while back and it was just torture.

Say what!?!

Edited by The Cereal Killer on Jul 15, 2011 at 01:08 AM

It's on the backburner, but it's not abandonware.

If anything previous test releases have shown is that unstructured/supervised releases are more work than they're worth. I end up with people who download or continue to use old versions, then complain about problems, and it just propagates bad rep about the software (and people use that as an excuse to not use it). There's also the issue of versioning: I've changed some of the group definitions this past year. If a test build been released between that time, I'd have people complaining about tags not opening because they're old versions. FS and I have pretty much locked down any new features or tag group changes now, but it's still not official, until it's official (ie, gold, released)

I told Masters that I would work with him and the team if they wanted to use OS for their next release(s), but I haven't heard the verdict yet about what the team thinks about that. That's the only way I would do a stress test right now, is with a team who is savvy with both the HEK and game already. Not only would they not be complete idiots (not calling you one, just the average joe), but they would provide me with the feedback needed to fill a FAQ and such since I'm working along side them. Even with a FAQ though, I'm sure I'll still have to ignore stupid people who IM with stupid questions (if I have to spoon feed you/drag you to water, it's a stupid question, people need to pull their own weight at least).

After all, OS for Halo 1 isn't just a tool mod but a engine mod as well. We have to target both modders and gamers in general (on top of making sure the codebase is suitable for other programmers) in our development.

Goodness. I was actually almost completely unaware of OS. I feel incredibly daft. Do you guys have a blog or some sort of information compendium where I can read more?

Edit
Derp derp, thanks google.
Edited by Diaboy on Jul 15, 2011 at 07:51 AM

I was expecting this post,after I watched the vid LOL

I like that ability to use bump maps on gbxmodels, it would finally stop people from ruining otherwise good models with fakebumping.

Instead of fake bumping you could just use a multi-purpose map. It looks alot better without fake bumps.

I just thought of an idea... would it be possible for open sauce to make games to have 32 v 32? or even 16 v 16.

imagine blood gulch with thirty people, ctf, all the map's vehicles and weapons spawned. IT'D BE AN EPIC GROUND WARRR!!!

Well imagine coldsnap or extinction with 50 people. EPIC VEHICLE WARRR!!!

that would be so sick.

You can do that with an external program but there's still the bandwidth limit unfortunately.
-Zekilk

Yeah but that's an external program. I think having just one huge package with all the stuff inside would be easier, and a lot more organized for other people to have the same programs and stuff you do.

No, and

No, you can't

The 16 max players is a hard limit. There are structures within other memory (eg, server state) where it is fixed at 16 players. Most of that memory isn't even dynamically allocated, but statically allocated in the PE's .data section. An external program isn't going to magically make it work. It'd be more than just changing a few numbers in the memory to be '32' or whatever. It'd require changing entire code to use new structure offsets, or references to entirely different memory addresses.

It'd require far more work than it's worth. You'd be better off breaking into MS and stealing the source and just changing the value of MULTIPLAYER_MAXIMUM_PLAYERS (and probably a few other constants) and recompiling.

I guess the problem I see with open sauce is that new users already have a hard tiem creating maps. This is just gonna bog down new users with more crap to learn.

I see it as more of an add-on for users who are experienced enough to utilize it correctly.

Yea but the average newbie sees one of these cool maps with post p and other cool effects so they feel like they are supposed to learn this stuff from the get go.

A friend and I also are looking forward this release, the video seemed appealing enough. Obviously the issue will be propagating it to mass users, although there barely Is any mass user on Halo anymore. Perhaps Dennis can be of some help there by suggesting the use of OS or simply linking the installer to any ''OS map''.

I am proud enough to say that I'm not stupid, but OS still completely baffles me, so I hate to imagine what a newbie might think. Then again, I haven't even tried making lightmaps yet, so there we go.

BUT. I will learn, and the possibilities are sweet.

Well then, we could have a split community. One for the newbies without OS that learn the basics, and then one for the experts with OS who like to soar beyond limits.

I guess it's safe to say I'm a noobxpert then.

I'm in the talks phase right now with a couple people to help test the tools and such in a production environment, so we'll see how that goes.

There will always be a learning curve to everything. OS just builds on what is already there. If you don't know how to work with the HEK, then you should either take the time to develop such a skill or just stick with enjoying what other people create. There will always be noobies. Some of them will actually put forth the effort and learn the trades, and the rest will continue to be noobs. Not everyone was born to model, or program, or design, or do anything related to game development.

I wouldn't re-approach Dennis until I knew I had all my ducks in a row and ready to follow his guidelines. This is his site, and he has rules which he has setup to keep him out of legal troubles and also ensure there is some sort of QA.

I also own halomods.com, and have hosting support on google code, so it's not like this place is the last stand for everything modding related, there are more sites out there.

This sparked my interest a while back. does anyone have links to all the OS files already released? I mean I have the one where enemy's can sit in your vehicle together. but I've seen more.

Bump,

A Question: For shaders, especially shader models and shader environments, is it possible to allow full alpha testing? Because what happens with normal shader models and shader environments is that if you tick the Alpha Tested box, it allows opacity. The only problem with that is either you get 100% transparency in one place and then 100% opaqueness in other places. This means that in the alpha bitmap, greyscale colors from 0-127 = Opaque, and 128-255 = Transparent. So yeah, In OS, is it possible to have full alpha opacity instead of either 100% transparent or 100% opaque?

We've only extended the shader_model to support a new tag block which defines the new detail/bump mapping. We haven't touched any other part of the tag or other shader tags. Someone else (ie, someone other than FS or me) would have to implement if you're talking about a fix/change to existing tag fields.