OpenSauce Halo CE SDK Update #2 (RC)

[arbiter901]

Yes i know this is nub but i feel it necessary to announce that i have managed successfully to add my own menu independent of the stock menu... makes me happy because now i understand more key cpp concepts, datatypes, and how enums work. Thats some strong coding there, korn... now i understand why you coded the way you did... kinda lol.

[Dwood]

Yeah korn there is def something wrong in os sapien and tool etc because there is nothing wrong with my xml and it wont accept more than 15 globals.

[Kornman00]

Yeah there is one part of the hs initializing process which I forgot to fix-up it would seem...

but I remember noting that I needed to fix said area. heh, guess it wasn't a good note.

For the time being I guess you'll just have to really ask yourself if each of those globals are really needed. There are the globals f0 to f5 in the engine already after all.

[Dwood]

Lol. :P I can make do for now.

[Kornman00]

Yeah, sorry about that :x. Thankfully this is just a RC right, heh. Then there is that goddamn issue with script functions...

WTF

I really wish I could test new builds :|. Actually, I really wish I didn't have a laptop as a main development machine...

[Dwood]

LOL. yeah there may also be another problem with the globals but i need to confirm it.

[Kornman00]

I've added code to address the limited custom hs globals problem. I'll try to get someone to test it between now and monday


Keep in mind that globals\functions added via CheApe are STUBS. They can't do anything in the tools besides satisfy the compiler. No one should actually be trying to run scripts with their custom globals\functions

[Kornman00]

Oh and I also think I know what's wrong with Halo1_CE's script function shit.

In 'InitializeCreateScriptFunction' I set the function table pointer in the template code to the engine's function table, not OS's upgraded table.

Changing the following code to:

static uint32 hs_function_table_address = //CAST_PTR(uint32, hs_function_table);
                CAST_PTR(uint32, &_upgrade_globals.functions.table[0]);

should possibly make it work finally

e:
and be sure the following code is changed too:

voidInitializeLibrary()
{
//GET_HS_FUNCTION(null).evaluate = (hs_evaluate_proc)GET_FUNC_VPTR(HS_NULL_EVALUTE);
//////////////////////////////////////////////////////////////////////////
MemoryUpgradesInitialize();
InitializeCreateScriptFunction();
//////////////////////////////////////////////////////////////////////////
// Come back later please...under construction

[FireScythe]

Looks like you've hit the nail on the head there . I've had 4 functions playing together nicely. Did notice that when getting arguments the variables are aligned to 4 bytes so some padding is needed after variables that are less than that.

[Kornman00]

Yeah, thinking back now I remember testing the CreateScriptFunction back when I was still replacing existing script functions, not actually upgrading the memory. heh ;x.

Yeah, the way it works is that I pass the arguments list pointer from the hs_thread's stack to the evalution function. It's all 32-bit aligned.

void* example_evalute(void** arguments)
{
    struct s_arguments {
      cstring str;
      int32 i;
      bool b;
      PAD24;
   }* args = CAST_PTR(s_arguments*, arguments);

       return NULL;
}