Open Sauce Ideas thread

[Dwood]

What the hell are you talking about? You don't understand what you are talking about. The HEK does not, nor has it ever had the ability to create .bik files. What you described was recorded animations, Bink Video files are not the same as recorded animations in any way whatsoever. Bink Video is a file format created by RAD Game Tools. There are only 3 Bink Video files played by the Halo 1 game, one for the Bungie logo, one for the Gearbox logo, and one for Guilty Spark flying off at the end of the game (I'm pretty sure that last one is right, haven't played the game in a while).

Sorry I used the wrong file type name.

[ShadowSpartan]

Sorry I used the wrong file type name.

Recorded animations don't even have their own file type, they are stored in the scenario tag.

[Dwood]

Recorded animations don't even have their own file type, they are stored in the scenario tag.

Oh, interesting. Didn't know that. (Obviously)

[MissingSpartan7]

.....that's it!
we could have load points within campaign levels, so from the menu you can load from a major section of the level
(the equivalent of the "rally point" in halo 3)

[Rhydgaled]

There are only 3 Bink Video files played by the Halo 1 game, one for the Bungie logo, one for the Gearbox logo, and one for Guilty Spark flying off at the end of the game (I'm pretty sure that last one is right, haven't played the game in a while).

Yeah, that's right, except I think there are 4 bink files. The 4th .bik is the Microsoft Game Studios logo, it plays along with the Bungie and Gearbox logos at start-up.

Now, if somebody makes a script command that runs that play .bik function in OS we might not have to worry about recorded animations anymore. We could render .avi files from 3ds Max, use a video converter to make them into .bik files, and then use said .bik files as cutscenes. Of course right now we can use animated scenery for cutscenes instead, not sure how difficult that is though because I haven't got around to trying it. I would have a shot at making the script command but I've only been taught very basic Java and very basic Delphi (going to be doing Visual Basic this year, very basic Visual Basic probablly).

Um, what?! Not sure what you mean with this. Only one map file is loaded at a time - the one you are playing. The maps aren't all loaded when you start the game, only UI.

I'm pretty sure he's referring to the checksum (I may have the term wrong) before the UI appears, where CE takes forever to load.

Yeah, not sure about the term checksum either but CE does take longer to load the more maps you have, I was suggesting making some maps be ignored by the game until you click certain buttons. Not possible without getting a look at CE's source code you say?

[Dwood]

Here's an idea. Use Open Sauce to do the interfacing for this (probably a stretch) but have OS_Tags that are like 3d ui options.

To explain this best it would be like using a biped, once that biped were "killed" OS would take that certain one and commence commands based on what biped has died.

The player would be put into a fixed position where they cannot move, only shoot, and are viewing the 'biped' menu screen in such a manner that they can see all of the menu options. I would go into more detail but I am struggling to stay awake right now.

From what I've heard, this could possibly be used with the now in development Forge as well.

[Rambo]

There's a problem with the BIK idea. What if your start-up involves someone flying in on a vehicle or you have cutscenes where you get transported somewhere and get out?

Recorded animations FTW! :P

[CodeBrain]

Heres something that everybody would love.

Right now I am in a predicament with one of my Phantom's, an AI-controlled one that drives around. I changed some of the settings around, and everything works in sapien. No crashes, no problems. Used run_game_scripts and it works like a charm. Perfectly avoids walls and whatnot.

The problem is, when the level loads, and I get to the point where the ai-controlled phantom is spawned, the game crashes with Gathering Exception Data...

My suggestion is to copy that exception data, and put it in a .txt file, like how the chat is copied to a txt file with the use of Yelo from Open Sauce. Unless it's not as easy as it sounds, shouldn't it be just looking WHERE the exception data goes, copy it, and put it in a txt file, and place it in the directory where the other Yelo stuff goes? (Your HaloCE profile in Documents)

[Dwood]

How about a script command that allows for arrays to be used?

I'm not sure what it would take to do, myself... but what if we had a new global called 'array' that holds a string which is the name of each global you want to store?

And then there's another idea of doing a more updated version of scripting... here's what it would look like-

(script static "void" variables (var1 var2 var3)
(sleep_until (= var1 1)
(set (= var2 var3)
))

In any case, I hope you get the idea. This way we can seriously cut down on the repetitious coding.

[Kornman00]

Adding support for generic arrays would require reworking of not only the hs runtime, but also the hs parser and compiler. Even then I don't really see how it can be helpful overall for HS's scripting purpose.

You don't need to put quotes on the return type of a script.

Script arguments can be hacked in, but if the tools are to support them the parser would have to be reworked. You'd be better off just writing a higher level language for HS as you can hide some repetitive implementation facts, but you'd still be having to write your own parser and translator which would have to be ran before the tools.


Halo 3 supports script arguments though. You should upgrade to it