OpenSauce SDK for Halo CE 1.08

Yeah, uploading a version without the statistics compiled in is fine. Be sure to include a note of that change to the source to fix those issues.

Also, I was referencing a the internal Main.cpp by mistake. I run a tool over the source and project files to perform any changes to the source needed for public releases (making some source files have more or less code). This helps with removing code which hasn't been fully tested and\or implemented.
Obviously statistics wasn't meant for AI, so a check needs to be put into place to tell if the killer or killee unit has a player index and if not, ignore the statistics record event, thus once again enabling statistics. That or have a special branch which details AI related killings.

Kornman00, I was ecstatic when I looked through your sauce. I had been working hard last summer on reversing the dynamic object structures, I'm sure you seen my documentation. I had posted my findings and have written smaller SDK's after you posted this, but I didn't know about this until a week ago. You are a really great coder and an even better reverse engineer! This has given me a great push towards better development.

Would I be able to use some of your data structures? I would use your complete source to expand on, but I really am not use to your coding style and it bugs me in some ways. Mainly your abundant use of macro functions, seems a bit overboard, especially when you wrote out every static address. I know in-lining functions are more efficient, but was all that necessary? Between the lowercase notation and awkward struct/func names, it's really quite the task to understand, especially when there is a huge lack of comments. Without a manual or documentation/wiki, most of this will not make sense to the casual Halo programmer, unless they are familiar with the engine. :( You may also want to look a bit more into making the d3d wrapper xfire compatible. Xfire also hooks Reset, possibly other functions and will be a major cause of crashing when it's called. I think xfire only hooks the first 5 or 6 bytes, so maybe hook deeper into the functions?

So I guess what my real question is, how do I go about using these reversed engine structures in my projects without breaking your license agreement? All my work has been GPL open sourced since I started programming, so do I need to include your entire source or just include copies of the used files or use your GPL or my GPL? What do I need to do on my end so I'm legal?

Hope we can collab one of these days, unless you are more on the independent side? I can send you some of my stuff.

Great thanks for this :dance:

Skarma:

Not all macros declared were meant to be used in place of a function. The macros used for defining engine-build dependent symbol addresses are one of these. In order to use the addresses in both the assembly and C++ code, a constant was needed which is what I used, an enumeration value.
Also, some data structures needed some rather nasty initialization schemes like declaring custom packets in MessageDefinitions.cpp or in the scripting code. Other uses can be exampled in TStruct which was more of a kludge to accessing engine objects which I didn't have the entire layout of. The fact of the matter is macros aren't just the old C way of declaring "inline" functions, they also help ease the pain of repeated code\data declarations and hiding away rather ugly implementations which you have to use since the code itself is interfacing with an alien system you can't change.

The underscore naming convention was used in the Halo engine so I decided to keep with that when it came down to engine related code. However in my own code I perfer CamelCase. I can't stand java's convention and never understood the point of lowercasing the first letter of the word while uppercasing the rest. IDK, maybe its just my OCD.

Yelo doesn't "hook" into the DX system, it acts as an inceptor with its own definition of the IDirect3DDevice9 interface. From there it forwards calls to the respected DX implementations, while performing any custom code. If Xfire hooks the DX system, it should be retaining the code it replaces. I don't think they would just assume the DX functions they hook into have the same bytes in each version that comes out, so they would have to have a dynamic way of handling the code they overwrite (so that its still executed when they return the IP back to the original code).

If you're not intending to use the source in the projects you make, then I ask that you just note in the code where you referred to OS and include a note in any releases that some of the code is based off OS code. Since you already open source your stuff I have no other qualms with how you use the code.

Coding style seems to be a never ending battle lol. Personally I don't care what style other people use, I also have my own OCD about my style haha. I was just pointing out that since you released this as an open source sdk for developers like me, it just makes it that much more difficult without the documentation.

I thought you were actually hooking the entire d3d device, my mistake. So from what I see in your initialization, you're just grabbing the device pointer and assigning it to your own device interface? This looks a lot like Azorbix starter kit wrapper. He never copyrighted it so I'm not saying you ripped it, but that would be a ton of work if you wrote out all 119 functions by hand! :confused2:

I had started on a few projects, but right now I have started from scratch so I can focus on writing out my own SDK for Halo engine. When I'm near done, I will undoubtedly create some applications with it. All of which will be open source, of course. I will gladly credit you for the information I rip out. I wouldn't be posting here if I did respect your work! Just wanted the OK from you. Thanks :)

No problem at all, I appreciate the consulting.

Bitterbanana was originally the one who brought up the idea to using a dll proxy for DX instead of hooking the game's code (note: we still weren't hooking dx, just the game's rendering code). Using a proxy dll isn't some closely guarded secret though, and it doesn't just stop at DX. It was orignally the method I had in mind for loading the dedi version of Yelo when we first started, by having a proxy Strings.dll.

Cool cool!
Just out of curiosity, why did you guys decide to go the proxy route and not hook some engine draw functions for your app? I only seen a video, so I'm unaware of how far you went with drawing. Was it just the fact that it's an easy route to get your dll injected? I'm currently going the VMT route, by grabbing Halo static device pointer, which I think is triple pointer deep:

Code:

---

IDirect3DDevice9*** pHaloDevice = (IDirect3DDevice9***)0x0071D09C; //halopc
vTable_D3D9* vD3D9 = (vTable_D3D9*)**pHaloDevice;

---

I only have console output hooked and haven't yet reversed any other drawing functions, which is why I'm still playing with EndScene lol.

As for a modified Strings DLL, did you guys have to reverse and rewrite it? Is it a possibility to add in a LoadLibrary call to Strings DllMain to load your own DLL?

Just trying to chisel info outta ya, a great cure for my boredom! :p

Using the proxy method we ensure compatibility with potential future game releases; we won't have to see if we need to re-find the addresses we patch (or if we did anything hpc, but I told banana that I would give hpc no attention, I'm CE only). It also gives us more control and stability in some aspects. It also kills a third bird and that is making the game load our code extensions. Originally this wasn't a problem in CE v1.0 days, but afterwords we couldn't just modify the exe's code with no strings attached.
Banana made a Textbox and Menu system but I left implementation of stuff with that up to him while I worked on other core stuff.

For the strings.dll route, I was actually just going to have Yelo load the real strings.dll and patch the game to have that dll's runtime handle so everything is all savvy again. Simple setup, as we don't have to rewrite anything or add extra resources (like string data) to our dedi builds.

I read many walls of text but from what I understand you're getting "Yelo" for 1.08?

Quote:

---

Originally Posted by Kornman00

will build for v1.08 of the game

---

.

Quote:

---

Originally Posted by Rook

I read many walls of text but from what I understand you're getting "Yelo" for 1.08?

---

More like Make-Your-Own-Yelo for 1.08.