H-Ext (Halo Extension), Support for Trial, PC, and CE! Both client and dedi!

[RadWolfie]

Historical Information

---

Hello everyone, I'll start with brief history and the main goal below.

From the year of 2009 - 2010 with frustration with Termy's SAPP and Rec0 constantly crashing the server along with Ganandur very limited features that doesn't contains the role-play necessary, I decided to find another alternate method to change all that. I have looked into Phasor to see if it actually does have support for Halo Custom Edition, sadly it does not. And the next thing I did...

Is to create DZS OS SAPP (Danger Zone Studio's Open Souce Server Application, 1st generation and is not associated with SAPP revived by Sehe) which is integrated in the halo custom edition dedicated server. However throughout experiencing how the reverse engineering and attempt to hook with halo's function and/or codecave is completely overwhelming for me. DZS OS SAPP was actually started from draft of Abyll's Super App open source which is only supportive on 1.08 I believed. After opening up to public with people willingly to join for tons of testing cause all kinds of crashes which I almost never understand why due to new experiences with C++ software. Then the next thing I decided to do was...

To separate the Halo Custom Edition dedicated server and S-Ext (Server Extension, 2nd generation) as two processes to prevent the crashes on halo dedicated server. We all know that we hate the wait on halo's load every map in the maps folder to verify before the server is fully initialized. Although as throughout new experiencing and gaining skills to resolve what exactly was the cause and better hooks in the Halo CE dedicated server. The big bonus was the S-Ext does the crash while the halo dedicated server remains active. Plus our beta testers were able to re-produce the cause and ability report back to me with reproduction. As I go through with the causes, S-Ext has become more stable and improvises. But this wasn't the only focus I have done, I also do want other developers to create their own plugin with our given hooks to resolve all the conflicts and extend the features in Halo CE dedicated server. As getting better and better with it, the next thing I decided was to include an enhanced GUI feature for the hosts to have ability control better and better stats. After time to time, there was a conflict with communication between Halo CE dedicated server and S-Ext overlapping. I have decided to transfer all of it back into integrated version as the next generation which is...

H-Ext (Halo Extension, 3rd generation and the final generation) to be stripped down as bare-bone application along with some commands to associate with it as a few of the hosting company complaint the memory size is too big. Since the beginning of the development the hooks implement start becoming greater and more accessible. This would be too good to be true as we have found the Trial, PC, and CE aren't that much big difference and decided to make a compatible with all of them. Also, it took us for almost 3-4 months hardworking of re-code to remove the STD library except for one necessary variable (will be replaced) and hopefully the CRT library too as well.

---

End of Historical Information


So what H-Ext (current brand) is for? Well, you can say the main feature is to have plugins for Halo to be compatible instead of incompatible with other third-party applications such as Version Changer and Halo Anti-Cheat (HAC) as for example. Although, the list below will demonstration of what we are trying to do.

• Third-party friendly interface (Is called Add-on for our H-Ext's plugin system)
• Supportive C language expansion (Basically support C, C++, C#, etc Add-ons) NOTICE: At the moment, it only support C++. We are working on this...
• Simple install/uninstall method. (No patching required)
• Advance ban system
• Advance rcon system (Trial does not have this support at the moment.)
• Bare-bone application (Meaning no "extra" stuff and allow the developers to create their own, except for some necessary to be included.)
• Compatible with Halo Trial, PC, and CE (Both client and dedicated server, Open Sauce may subject to be incompatible.)
• Smart signatures for general compatible Halo 1 Windows platform versions.
• Tons of hooks accessible (Not every hooks are accessible due to testing procedure, we will have them available once test stage are done.)
• Customize database accessible (Even MySQL Add-on will work when we have time to update it for H-Ext.)
• GUI features (Both client and dedicated server, currently not supportive yet. Will be in 0.6.0.0 feature.)
• Built-in upgrade from previous versions. (Some are not upgradable; please check the info before upgrading from older version.)
• Communication with client and host/server side (Is not included yet, still in planning to do this)
• Possible GameSpy variables to be include. (i.e. what plugins are currently on the server.)
• + More!

Key:

• Fully Supported
• Some Support
• Not Supported (yet)

Current H-Ext version: 0.5.2.4 (Released, Nov 10th, 2014)
Current Add-on API version: 3.1.2 (Released) and documentation for the standard Add-on API usage.
NOTICE: All downloads, except for latest Add-on API, are required to be login in order to download for safety and accurate stats reasons.

H-Ext is limited source, only Add-on API is open source. And most of our Add-ons are open source too.

Once we have hit the 1.0.0.0 mark, this is where we will say H-Ext is fully featured with nothing missing. We will continue the bug-fixes and/or forgotten feature releases afterward. However, there will not be a 2.0 or later releases.

Here's the official, for DZS's Halo branch, links below.

Official Halo Site
Official Halo Add-ons Site (Including H-Ext)
Official Bug Tracker (for H-Ext & Add-ons)

We have recently added the Licensing agreement in order to maintenance the freedom to use the H-Ext and Add-ons. And the progress can be found at this link.

Got questions or problems? Please do use our "Contact Us" form or use the forum* we have provided.
Want to be part of our beta tester team? (Early access, mainly checks for any crashes, and file the report) Please apply on our forum*.

We worked hard along with other contributes to make this easier on developers creating their own plugin(s) and maintenance the cross-Halo 1 Windows platform.


*Our forum is private, so please login in order to see the forum.
** The link to the Bug Tracker is hidden to public, please login in order to see the actual link to the Bug Tracker. We do not want any of the search engines to index this part of the site.

Keep in reminder, "beta" does not mean it is not stable. It is just defined as the features are not fully implemented yet. Although, if you do see "alpha" it may contain some instability and bugs.

Another reminder, if you keep saying "I need help with sapp!” we then will decline sapp is not one of our production and will not help you. Please do use the proper name in order for us to resolve your problem.


Grammar nazis are welcome.

DZS|All-In-One

Edit: Whoops, I did not actually meant Open Sauce Server Application, I meant Open Source Server Application.
Edit: Grammar corrections so far. A few couldn't be corrected due to "fragment (consider revising)" and can't see what's wrong atm. Been awhile I ever used Microsoft Word...
Edit: Updated to 0.5.2.3
Edit: Big bonus for us, we finally have a budget to have a better server! The websites are officially now running under 1 second! We do not have Halo v2 site ready to go along with new server sadly... Also bug tracker site's link finally open to public.

[Btcc22]

Well, you can say the main feature is to have plugins for Halo to be compatible instead of incompatible

What's to stop two H-Ext plugins from being incompatible if they're both using the same hooks and making changes to the same data structures? You seem to be allowing unfettered access to Halo's memory through the API so there goes any guarantee of plugins playing together nicely or not being able to crash the server.

Also, it took us for almost 3-4 months hardworking of recode to remove the std library except for one nessary variable (will be replaced) and hopefully the crt library too as well.

Why would you do that? The memory footprint of the CRT is negligible, especially when you consider the odds of it already being loaded in another process, allowing it to be shared. You could use static linking to ensure only the functions you need are provided but even then there's a good chance that you're going to be using more memory, not that it matters give that memory is cheap whereas development time is not.

Take a look at the size of the DLLs required for the C runtime and the C++ standard library. They're tiny. Even in the worst case, the memory usage is insignificant.

On another note, I took a look at the current version of the API and I couldn't find a single piece of documentation.

[RadWolfie]

What's to stop two H-Ext plugins from being incompatible if they're both using the same hooks and making changes to the same data structures? You seem to be allowing unfettered access to Halo's memory through the API so there goes any guarantee of plugins playing together nicely or not being able to crash the server.

Phasor does pretty much does the same thing, however I do have additional perimeter that do tells the "next" plugin the request has been changed and will prevent alternating* the return value other than default value. Only within the hooks and a timer system (soon to be feature later) will not be crashing the server. It is recommended to have a command to either disable/enable a functionality inside the plugin or a check with a gametype and/or maps to automatic enable/disable it. The actual point is, we don't really need duplicates which have like version changer, multiple zombie gametypes which are a third-party modification to halo's memory and possible hooks too. It would be nice to keep it standard and popular plugin to be used as one and shared across. Also, there are many programs that is actually using the plugins even though there are "some" duplicates instead of "tons" duplicates that does the same thing which fighting over each other.

P.S. I have perform a Zombie gametype prototype plugin about 2 months ago to verify the hooks are correct and output correctly to the clients as well. It was a success and very amazing to see the result. Although, as I have been updating the Zombie prototype, it starts to get worse on me. I'm not entirely sure why (the hooks I have performed remain the same except for couple tweaks) and is abandon temporary as I do wish to have it become more success plugin and little more "realistic" than other Zombie features.

Why would you do that? The memory footprint of the CRT is negligible, especially when you consider the odds of it already being loaded in another process, allowing it to be shared. You could use static linking to ensure only the functions you need are provided but even then there's a good chance that you're going to be using more memory, not that it matters give that memory is cheap whereas development time is not.

Take a look at the size of the DLLs required for the C runtime and the C++ standard library. They're tiny. Even in the worst case, the memory usage is insignificant.

On another note, I took a look at the current version of the API and I couldn't find a single piece of documentation.

As for load in another process, it was just an experimental with plugins and understanding the halo's asm language for specifically what value did it obtain from and how to properly do the changes where it will not crash, so on. I do understand the situation with DLLs being "required" for the C runtime and C++ standard library. However, you can still remove them. As the current development do have some of them featured and will be continuously adding more. As for your asking for a API documentation, it is on our Bug Tracker** site section under "Add-on API" Project which do contains some documentation. It does will constantly update as the new hooks are included. Plus the file size for including the documentation with the Add-on API are very costy for our server to host (our harddrive isn't that big and is actually a mini computer). Or simplify combine these together to ensure you are human. status dot halo dot dangerzonestudio dot com/wiki/Add-on_api%3AMainPage

Also S-Ext will be discontinue as H-Ext soon to be release on Nov 1st, 2013 and it is likely to be label as Alpha (not because of unstable, because of changes will occurs during the 0.5.x updates to be more better standard and so much hooks into client/dedicated server; compared to around 10 - 15ish hooks in S-Ext while H-Ext has around 122 hooks at the moment).

I hope this will answer to your questions. Bring in more questions and I'll be happy to answer them.

*Aka blacklist/whitelist if you know what I mean.
**hidden from public view, login to see the link from progress page and possible other locations around the site.

P.S.S. I'm tired of typing it all in and made some corrections. So I'll just submit it anyway.

[Btcc22]

Didn't really understand that reply in regards to the CRT.

[sehe]

^

[RadWolfie]

Didn't really understand that reply in regards to the CRT.

One of our contribute demostrate me has a way to completely remove the CRT from the DLL and is used in our loader DLL to load and unload the main H-Ext's DLL which does cut down the file size dramaically. It is little complicated with bunch of errors that willl output on the complier. Although, you will have to "create" your own functions mock up the CRT functions and initialize any of the variables in the entry point that is using the functions globally.

Also, standard library are not compatible with older/current/newer complier as they are very different due to "msvcxx.dll" files. This is not a C native langauge either too. Our inferfaces are C native language which expect almost all complier (that works with C native interface) to work normally.

[sehe]

Also, standard library are not compatible with older/current/newer complier as they are very different due to "msvcxx.dll" files. This is not a C native langauge either too. Our inferfaces are C native language which expect almost all complier (that works with C native interface) to work normally.

What the fuck

+ I still don't get WHY you had to remove these, they adds max 1MB memory.
For example 1 CoD server uses the amount of memory that 20 Halo servers, but also 1 Halo server (without my Sapp :P) using the same amount (or more) CPU, so for them probably the CPU usage will be the cap anyways.
Wonder what hosting company it was tbh.

Edit: Maybe you just had a memory leak? lol

[Btcc22]

Yes, different versions of the compiler will likely use different versions of the runtime but I still don't see your point.

One of our contribute demostrate me has a way to completely remove the CRT from the DLL and is used in our loader DLL to load and unload the main H-Ext's DLL which does cut down the file size dramaically.

Guessing you used static linking but even then, it's insignificant.

[RadWolfie]

+ I still don't get WHY you had to remove these, they adds max 1MB memory.
For example 1 CoD server uses the amount of memory that 20 Halo servers, but also 1 Halo server (without my Sapp :P) using the same amount (or more) CPU, so for them probably the CPU usage will be the cap anyways.
Wonder what hosting company it was tbh.

1MB memory can actually be replace by 3 or 4 plugins. Less useless extra memory = more room for plugins to be loaded. H-Ext isn't focused on just server only. It also support the client as well. So the users can actually use the same plugin for either server or client side and host or for some specific plugins can be only used on client side such as sight jacker.

Edit: Maybe you just had a memory leak? lol

I'm pretty sure the final and few previous S-Ext did covered all of the memory leaks.

Yes, different versions of the compiler will likely use different versions of the runtime but I still don't see your point.

• Supportive C language expanson (Basically support C, C++, C#, etc Add-ons)

Plus allow the developers to use their preferred compilier version instead of "must be" specific compilier version. We are still trying to figure out with C# lanuage to work with our API interfaces. Yes it can read from our H-Ext, but in reverse method, it is just stubborn to export the interfaces that H-Ext's requirement in order to work properly.

Guessing you used static linking but even then, it's insignificant.

For time being, yes it is using static linking (Except for our loader system). However it will be slowly remove and using optimized ulitlity library we have create to replace it. The plugins can use this to reduce the extra functionality and ability to optimize without the standard library and CRT.

[Btcc22]

There's no reason to avoid use of the CRT in order for other languages to make use of your API. Sure, there are things you have to watch out for when it comes to sharing memory/data structures across modules but still.

The memory usage argument still makes no sense to me, especially after mentioning C#, but nevermind.