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

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 :eek:
• 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.

Quote:

---

Originally Posted by coolest2guy

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.

Quote:

---

Originally Posted by coolest2guy

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. :(

Quote:

---

Originally Posted by Btcc22

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.

Quote:

---

Originally Posted by Btcc22

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.

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

^

Quote:

---

Originally Posted by Btcc22

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.

Quote:

---

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

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

Quote:

---

Originally Posted by coolest2guy

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.

Quote:

---

Originally Posted by sehe

+ 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.

Quote:

---

Originally Posted by sehe

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.

Quote:

---

Originally Posted by Btcc22

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.

Quote:

---

Originally Posted by Btcc22

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.

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.

So these plugins you speak of...you force them to not use CRT as well? What about the common runtime libraries used by other languages? There's a reason why they're called 'common' and are shared libraries.

Also, 32-bit processes generally have 2GB of addressable memory (user mode), with the game having been designed originally for a machine with only 64MB of RAM. Yet you're worried about 1MB? Have you even performed any useful profiling/measurements to prove all this effort is actually worth the time?

Quote:

---

Originally Posted by Kornman00

So these plugins you speak of...you force them to not use CRT as well? What about the common runtime libraries used by other languages? There's a reason why they're called 'common' and are shared libraries.

---

No, they can still able to use the CRT. It's still being used by LoadLibrary function, I'm hoping I can actually replace it as well. Once it has, I'll make sure the CRT to be check and run support as well. I just need to verify the requirements for H-Ext to have ability load the plugins before it can actually be load as active plugin. However this isn't the main focus at the moment. As for 'common' and 'shared', there are two different version which is Multi-Threaded (/MT) and Multi-Threaded DLL (/MD). We are using the Multi-Threaded (/MT) which doesn't share the libraries of common runtime just like Halo does to another DLLs. If we do use Multi-Threaded DLL (/MD), then we get a lot of reports it couldn't startup due to msvcr__.dll missing. So this is not an optional for us and don't really needed the std library to go with it.

Quote:

---

Originally Posted by Kornman00

Also, 32-bit processes generally have 2GB of addressable memory (user mode), with the game having been designed originally for a machine with only 64MB of RAM. Yet you're worried about 1MB?

---

We aren't worry about the 1MB, however one of the hosting company does. Although, it will give more room for the user to add another plugin if they want to.

Quote:

---

Originally Posted by Kornman00

Have you even performed any useful profiling/measurements to prove all this effort is actually worth the time?

---

One of the old blog post long time ago from micorsoft's staff demostration the file reader by using with and without standard library to trim down the load, processing, and unload time. That is one of the proof and I have seens some improvement in our CiniFile in Add-on API 3.0 . The other proof was our contribute whose has been helping out along the way when I was having some issues and remove extra useless functions that aren't in used. The point was our contibrute made his own analysis with his third-party comparsion of with and without either of CRT (C runtime) and STD (Standard) Libraries. He showed me the improvements without them with less delay on startup.



From 3 years ago, I made my stand to say it's time to change the incompatiable third-parties on Halo to be compatible and be friendly to each other. The question is... are you?

E: Can't find the strike format on this editor. Using bold letters to correct my spelling.

LOL

If you let other plugins use CRT, then you could just compile your code whit /MD and SHARING libraries whit the plugins etc. Basically now if you have at least 1 plugin that uses CRT, then it will actually using MORE memory because you static linked everything into your app.

Quote:

---

We aren't worry about the 1MB, however one of the hosting company does.

---

I'm pretty sure they were worried about your memory leaks and not of that +1 MB.

And CRT initialization takes about <10ms I guess and that includes the stuff you have to do anyways like initialing the global variables/classes etc..

What hosting company was this? I have never heard of any issues from the usual hosting providers used by CE players. If it's only one company, I question their ability to provide quality server hosting and thus someone's choice to use them (you get what you pay for).

I have to question the experience and abilities of someone with desires of replacing LoadLibrary. Also, there's a little thing called the VC++ redistributable. It's what you install with your release builds of your product. This is how you fix your "msvcr__.dll missing" problem. Treat the cause, not the symptoms.

What the hell is "contibrute"? I'd be more concerned about speed during runtime, not startup which is just a one-time thing. I would also rather develop with modern code and libraries, than reinvent the wheel.

Open Sauce's major releases are open source, and has a very specific development mentality (we deal with the entire engine, not just the game releases). We don't have to the time or patience to worry about how OS works with other people's shit. I'd rather we integrate the desired functionality into the codebase (making it open source too, unlike most of the other projects out there).

About replacing LoadLibrary: http://www.joachim-bauch.de/tutorial...l-from-memory/
It works fine, it's not as a big magic as it seems.
Not like LoadLibrary has anything to do with CRT btw.

Quote:

---

Originally Posted by sehe

And CRT initialization takes about <10ms I guess and that includes the stuff you have to do anyways like initialing the global variables/classes etc..

---

I am not entirely sure, however it has to do with the functions next to the global variable preventing it to be complie. I had experenced with this issue and moved them into the dllMain as a global initializing for any of the variables to be initialize. The rest of the global variables are pretty much as it is as define in the value.


Sehe, it wasn't even about the memory leaks. Also claims your SAPP is using too much memory. So I wasn't the only one, just fyi. As for the post about the replacing the LoadLibrary, we have seen it before and have seen other replacment too. Although, still are taking precaution and is not a high priorty. Thanks for sharing. :)


Kornman00, which is reason why we are taking precaution steps with replacement on LoadLibrary. Using the modern code and libraries are what we asked for. However, it take more processing time with them. This new recode which basically remove every part of standard library and run better, even on the older computer as well.


I never asked you to take your time to worry about other people's "shit" and please do mind your manner. I am not against you or anyone else involving with third-party creations. Also what if some users don't even want any of the extra integration features that has nothing to do with game engine? And we will have a finished crash report that will determine the actual cause by a third-party or not. We also deal with game engine and the game releases. From what I remembered the Open Sauce's dedicated server executable is still using the patched from Termy's Patcher, that also need to be fix. What I heard form our users says SAPP isn't compatible with Open Sauce. Although, our project do able to run with Open Sauce just fine. We did perform some tests relative to player's coordination, vehicles and cloning objects. No conflict so far.

Well yeah ofc, if they whine about 1MB RAM then obviously they don't like SAPP which adds 1MB + some more if they use No-Lead mode.
In the other hand, I reduced CPU usage by 80% or more.

Anyways, no one ever complained about memory usage of SAPP to me, because proper hosting companies like GameServers.com not running PCs with 64MB RAM but at least 8GB.

I would not pay anyways for hosting company that whines about +1MB of ram when DDR3 RAMs are cheaper than ever, and you can buy 8GB for irrelevant amount of money for a company.

Also, you saying that your code is better than the std library which made by skilled coders who have at least a master degree and 20 year of coding experience? I doubt that.

Edit: Oh and looks like you ignored our comments about the shared libraries...

Lol, didn't talk about a 1MB RAM limitation and Halo can't even run on 1MB RAM either too.

Didn't say our code is better than the std library, just doesn't need all of extra functions from a std library which we do reduce to only what is needed. Also we have done some profiling with std libraries at run time which took more processing than our code. Also we are not using the Intel's complier too, only Microsoft Visual Studio.

Hmm... Ah found what I left out, thanks for pointing out about the shared libraries.

CRT isn't shared across the msvcr__.dll, only the std library does. So basically the CRT are built-in, if you're saying I'm wrong about this. Please do and I will make little more research about it. Plus by using the /MD forcing us to include the msvcr__.dll file for every release builds is not even important for us to do. The only option for us to do is use the /MT instead. We used to provide an installer binaries with our older builds. However, we no longer doing that due to time consuming, constant updates, maintaining the website, etc. So we do not actually include the VC++ redistributable as there's no reason to constantly include it for every releases.

P.S. If any of you feel like I left out the response to your question/comment, then let me know and I will response it.

WTF? No one talked about 1MB limitation, don't even think there is such small RAM existed for PCs with x86 CPU.

If you use the /MT switch then compiler obviously cuts out the functions you never call (in release build), otherwise it would generate a 5MB+ dll, or if you use the /MD switch everything will be in the shared dll, and yours will be even smaller.

And no, CRT is shared too.
http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx

Quote:

---

Originally Posted by Kornman00

What the hell is "contibrute"?

---

He means contributor. There is an obvious language difference here. I'm surprised you didn't get it.

I really cannot understand why you didn't want to use the CRT. What are you using as a memory manager, Windows' HeapAlloc? Also, why would you ever want to replace LoadLibrary? There is absolutely no benefit in doing that for your use case - you're loading kernel32.dll anyway, and as btcc22 mentioned, most system dlls don't physically get loaded into memory just for you (other processes are already using them).

By the way if you don't want to install the redistributable that Kornman linked to, and you're using msvc10+, then you can simply include the dlls along with your code.

Quote:

---

Originally Posted by sehe

Well yeah ofc, if they whine about 1MB RAM then obviously they don't like SAPP which adds 1MB + some more if they use No-Lead mode.

---

Just pointing out your grammar isn't define of what you are trying to say. Also, yes I am aware of difference between /MT and /MD due to separate dlls and /MD make my dll smaller. And I do preferred to be in one dll instead of separate dlls due to big difference in Visual Studio's complier. It won't be compatible for other plugins that's using a different complier including new/old version of the complier as well.

I looked into CRT and it is a system dll which is acceptable. Although, it doesn't seems to be using the CRT's dll version as if it is using the integrated. I'll need to check into this. If it is integrated, then I'll have to find out a work-around to remove the integrated CRT into shared CRT dll which Windows' system have.

Yes Amit, contributor is the word I'm looking for. Thanks for correcting my grammar. :)

urbanyoung, assuming Oxide, I was actually taught not to use the CRT from one of our contributor. Although, we are considering to use the CRT's dll usable shared library. No, we are using the new/delete as the memory manager and we have corrected our memory leaks in H-Ext. The reason we want to replace the LoadLibrary is to verify the dll do contains the functions requirement in order to be a "valid" plugin. If not, it doesn't get to be actual load as active plugin. LoadLibrary just plain add the module and activate it directly without our verification check requirement. That is a big nono for us. We do want to protect our users from using the older plugin that is not compatible. Including potential scammed modules which is not specifically for H-Ext. So that's a big benefit for us and our users, and we know we're loading the kernel32.dll since there are some functions being used from it.

We can, as stated before in this post, 1st paragraph, 3rd and last sentences are our general reason.

What's this compatibility problem you keep talking about? The main thing you have to avoid doing is freeing memory across module boundaries (potentially using one version of the runtime to allocate and another to free) and that's an easy problem to solve without resorting to ditching the CRT. Either export a couple of wrapper functions for memory that's going to be allocated/freed across boundaries or use an external allocator like LocalAlloc.

Additionally, the CRT is versioned, hence names like msvcr100.dll. If somebody compiles a plugin using a different version, you just get another DLL loaded in. If you've got msvcrt.dll in mind, you're not supposed to be using that even if plenty of older applications do so. It's supposed to be strictly for system use.

msvcr___.dll; Again I already explained our vision for the plugin system to be expected to work with. Some rather work with C++, C# (working on this), F# (not tested), VB (not tested), or any of the languages that are supportive for C native language interface. I won't enforce them to expect use C++ and must be specific complier version in order for it to work with our H-Ext.

After creating a plugin in Visual Studio 2008 (not the same version as H-Ext), I experenced with new/delete issues with our header. We have included the new/delete in the header which are exported to be used either from directly or one of our header that do required it in order to transfer the data between the plugin and H-Ext.

Hmm... so you're saying we're not allow to use kernel32.dll, ole32.dll, user32.dll, or any of the system dlls? Pretty sure they're not "only system use" since Microsoft provide them for us, developers, to use since it is integrated with Window's operating system. Must have read it wrong on the document specific for CRT's. So CRT is out of question now and isn't needed at all.



Everyone, please do not discuss anymore about "why we excluded the CRT and standard library" which is self-explained again in first paragraph of this post. We already made the final decision about this before the development on H-Ext, 3rd generation., has started. If the developer of the plugin wished to use the CRT and/or standard library, they can do so. We do not protest this at all.

Since we have plenty of time before the release date, we will go ahead and remove the final std library variables. Also, we have updated the Add-on API 3.0's events documentation on our Bug Tracker section.

Quote:

---

Just pointing out your grammar isn't define of what you are trying to say.

---

Funny that someone who speak English even worse than me points out my grammar (which was NOT ambiguous at all [just asked Btcc to be sure and he's from UK] lol).

I don't understand why you have to "point it out" anyways, I didn't point out either that 80% of your posts that makes no sense at all or contradicts each other cuz of your bad english or simply because it's just moronic.

Quote:

---

Everyone, please do not discuss anymore about "why we excluded the CRT and standard library" which is self-explained again in first paragraph of this post. We already made the final decision about this before the development on H-Ext, 3rd generation., has started. If the developer of the plugin wished to use the CRT and/or standard library, they can do so. We do not protest this at all.

---

Not sure if I should cry or laugh.

Hmm, that's completely off topic so this is what I will say.

Well, spoken english isn't going great with big words and which I don't actually use spoken english. My actual primary language is American Sign Language, try learn that since it is hard for hearing people to learn or some are successful whom are motivated to learn ASL.


80% of my posts are programmer talk, if you don't understand programmer talk, then you're not caught up yet. Or you just don't have experence enough with slightly advanced plugin which is competely different from single standalone executable and modules. In order to have better experence with plugin interface, you will have to create your own plugin interface in different complier versions, optimizations, and possible other different language that is able to use the same plugin interface. Oh by the way, you failed english due to 2-3 sentences in one single sentence. So, learn your mistake and improve it. That's all you have to do.


Cry, as you do understand as you have the similar experenced as I do. Laugh, as you are completely clueless of what I have experenced in past 2 years and what I am trying to achieve.


Any more of off topic will be competely ignored. Now, back on topic.

Yes we are laughing at how far you reached despite you have no clue what are you actually doing LOL.

Quote:

---

80% of my posts are programmer talk, if you don't understand programmer talk, then you're not caught up yet.

---

You ignored everything we said and ended up asking not to discuss about it anymore.
Most of your sentences simply doesn't make sense AT ALL but we blamed your bad english and acted like we do not think you are a retard.

Basically (from what I understood of your posts, [and no, not because it's "programmer talk", but because it's simply makes no sense]) you removed CRT and STD since some hosting company you still did not named figured out that extra 1MB is too much that CRT and STD (?) adds to your extension. Oh and because they do "useless things that no-one wants" that slows down loading by 10ms LMAO. We still did not see actual numbers/benchmarks tho.
So instead, you decided to write everything from the scratch adding shitload of memory leaks and exploits to your extension and decided to use custom load (but why?) even tho LoadLibrary is in the kernel32.dll which is loaded into every application and has nothing to do with the CRT or STD.
Edit: Right, to protect your users. Then tell them to don't use your extension perhaps.

Although I know its totally useless, let me explain the difference between /MT and /MD one more time.
If you use the /MT switch, compiler will static link the CRT library into your extension, while whit the /MD switch it uses dynamic linking, that means you will have to include the msvcrxxx.dll and the msvcpxxx.dll to your extension or put a link to the readme.txt that they have to download the C++ redistributable package if they don't have it already. However, these dlls only loaded into the memory ONCE, because they are SHARED. This means if ANY application in the PC uses these, they will be loaded into the memory, ONCE. So basically if only one of your plugins use these (which is very likely) your work removing the CRT was ABSOLUTELY TOTALLY USELESS since it will be loaded into the memory anyways. Actually with static linking your "own CRT", your extension will probably consume even more memory, not even talking about the memory leaks and the unstable code. Also you have no proper documentation either since "it's using too many space on the HDD".

Quote:

---

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).

---

I'm still trying to interpret your following sentence:

Quote:

---

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.

---

???

Also:

Quote:

---

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.

---

Do you know that C# has nothing to do with C++ apart the actual "style" because it's a managed language and it needs CLR to run? Better not mentioning the memory usage of that.

In conclusion: You are either a complete moron or a troll.
It's quite obvious for everyone here that you are the one who does not understand of what we are trying to explain to you.
Ignorance is a bliss huh...

PS. My English is still better than your's, tho my native language is Hungarian which is one of the hardest language on the earth. :P

Quote:

---

Originally Posted by coolest2guy

The reason we want to replace the LoadLibrary is to verify the dll do contains the functions requirement in order to be a "valid" plugin. If not, it doesn't get to be actual load as active plugin. LoadLibrary just plain add the module and activate it directly without our verification check requirement. That is a big nono for us. We do want to protect our users from using the older plugin that is not compatible. Including potential scammed modules which is not specifically for H-Ext. So that's a big benefit for us and our users, and we know we're loading the kernel32.dll since there are some functions being used from it.

---

You want to replace LoadLibrary in order to perform the function of yet another preexisting win32 function, GetProcAddress?

Frankly, you sound like Windows store with all this 'control/verify all the things!'. If you want to be open, link to approved plugins. Require the plugins to be open source. Assuming anyone even writes plugins for a framework which is only partially open. You're worried about someone potentially scamming modules, when the system itself can be scammed as well.

API versioning can be easily handled by exporting a proc which returns the version the plugin was built with. Think smarter, not harder.

Someone could create a kernel32.dll hook which forwards the calls you need, just as people create DX hooks.

Sehe, you and Btcc22 chose to ignored my posts and questioning my skills repeatly. Be sure to re-read again because we are talking about same thing except you're just adding to what I'm saying.

I'll re-interpret the sentence into a text picture for you to undersand. Not saying you're an idiot, just a helper example.

For example:

Type	Name	Complier	requirement	is sharing the requirement?
General	H-Ext.dll	VS C++ 2005	None	No
Plugin	RP Mod.eao	VS C++ 2008	mvscr90.dll	Nothing to share with other plugin
Plugin	Remote Control.eao	VS C++ 2012	mvscr100.dll	Yes, sharing with Teleportation.eao
Plugin	Teleportation.eao	VS C++ 2012	mvscr100.dll	Yes, sharing with Remote Control.eao
Plugin	MySQL DB.eao	VS C# 2012	.Net Framework 4.5	Nothing to share with other plugin

NOTICE: This is not accure information above.

So H-Ext has no reason to use mvscr__.dll at all of which all Add-on API interfaces are C language. So you do understand something like GetProcAddress, LoadLibrary, CreateWindow, etc ARE C language interfaces? Since C#, Visual Basic, F#, etc can even use this interfaces as well.



Yes, and we again, again, are being careful not to lose the expectation of what developers wants with GetProcAddress, GetModuleHandle, and so on. We may will have to get the Windows to read the memory directly instead of read from the module's file and register it as a module. This will be done after checking the export names. Although, later will be change into a structure variable in order to maintaince any API hook name changes including remove almost all of the GetProcAddress for each hook names. All of the plugin developers don't even need to be concerned about this.

And yes we are trying to determine where to make a verify version check on specific API sections even though there hasn't been any changes on minor updates from S-Ext releases. Such as Native MDB 1.0 support from 0.3.0.0 to 0.3.2.3's API while 2.0 do support 0.4.0.0 to 0.4.2.2's API. The only differences were the standard for command function parameters has been changed. And some other additions in the process.


As for kernel32.dll, it is very small chances the AntiVirus, in-game messenger (such as xfire and steam), etc will call for kernel32.dll in a working directory instead of directly from the system32's directory. I have verified this with version.dll which is a system module on this computer and the virtual machine with original operating system (no extra third-party installed) and halo.

I am assuming DX is DirectX, yes it is very possible with any Windows OS. I'm not exactly sure why it check the working directory instead of system directory and gave me a big confusion. :confused: Although, it doesn't get to load on executable startup either.

Even with your table, I still can't see why you're so determined not to use the CRT. Your logic appears to be, "because other modules use the CRT, we won't".

Here's the key question that you haven't really answered: Why would you reimplement all of the functionality provided by the CRT instead of just using it like you claim the add-ons will be able to?

You original cited speed and memory usage as the reasons but now you've gone back on those, what's left?

Quote:

---

Originally Posted by coolest2guy

I'm not exactly sure why it check the working directory instead of system directory and gave me a big confusion. :confused: Although, it doesn't get to load on executable startup either.

---

This will explain.

On another note, you really need to look for another host for your website. Nobody wants to dig around on a site with 30 second+ page load times just to find the documentation, assuming they can find it at all.

Quote:

---

Originally Posted by Btcc22

Why would you reimplement all of the functionality provided by the CRT instead of just using it like you claim the add-ons will be able to?

---

The main H-Ext doesn't even need those CRT's functionality as we have made our own better optimized code to serve specific things instead of generally. I think I might not answer to this question right, so just say it doesn't.

Quote:

---

Originally Posted by Btcc22

On another note, you really need to look for another host for your website. Nobody wants to dig around on a site with 30 second+ page load times just to find the documentation, assuming they can find it at all.

---

It's a non-profit organization which doesn't originally focus on Halo, so hence the reason of using the mini-computer. And I do agree with not wanting to dig around 30 second+ page load time, it's due to many plugins on WordPress + the Bug Tracker take little less longer to load. We have been working on site v2 to remove the WordPress and its plugins and possibility the Bug Tracker section too. The site v2's result about 300-500% more faster load page time than what we have now. We did have plan to custom build our server, yet it kept on postponing a lot. To be honest, it's a lot of work on our free time.

Quote:

---

Originally Posted by coolest2guy

The main H-Ext doesn't even need those CRT's functionality as we have made our own better optimized code to serve specific things instead of generally. I think I might not answer to this question right, so just say it doesn't.

---

A cardinal rule of programming is not to reinvent the wheel, especially when it comes to something like the CRT and you don't have any evidence to justify the decision. At best, you'll gain a performance boost that nobody's going to notice and at worst, a bunch of security holes and stability problems.

Quote:

---

Originally Posted by coolest2guy

It's a non-profit organization

---

Fair enough but so is every other mod project. If you can't get the site working, you could think about posting the code and documentation on some source-control site like GitHub, Google Code, BitBucket or any other service that looks suitable.

So, security holes as in modules that is hacking the functions than it should be? Since we have experenced with reverse engineering (I do know you have more experence than me), I don't see how that would fix the security holes. And we do perform some tests with our custom coding to meet our expectation as it should be than leaving the functionality to constant crash as we're done with coding it.


GitHub is pretty much limited and not really satisfied with their features. Google Code may be likely better to use. BitBucket is a lot less featured and required to be paid in order to host the code. In summary, we only perferred free service similar to Google Code has to offer.

P.S. We really need to finish our site v2 and replace our old site due big performance improvement on reduce page load time. (Still working on the forum section.)

Quote from his PM to me:

Quote:

---

My friends has read the posts you made and gave me advice not to response back to you due to your judging me and very ignorant troll as well.

---

By now it's pretty clear for everyone here that you are an ignorant retard and it's useless to tell you anything because you don't even try to think about that maybe we are right, since your pathetic arrogance would not allow you to admit that what you have done is just completely useless.

Quote:

---

Sehe, you and Btcc22 chose to ignored my posts and questioning my skills repeatly.

---

Yes, we are questioning your skills because so far you only proved that you are a complete moron and lack of knowledge in every field you are working in.
Funny that you still think that we do not understand what we are talking about. But then, what did you achieve in the past 2 years? I was working on SAPP for example, and more than 300 servers are running on SAPP atm.

Well, just go on ignoring our posts, it's your problem, not ours, I stop wasting my time replying here anyways.

Quote:

---

Originally Posted by coolest2guy

GitHub is pretty much limited and not really satisfied with their features. Google Code may be likely better to use. BitBucket is a lot less featured and required to be paid in order to host the code. In summary, we only perferred free service similar to Google Code has to offer.

---

How is GitHub limited? Google Code is doing away with their downloads system, while GitHub is making a first-class releases system.

BitBucket doesn't require you to pay anything unless you are hosting private repos, and even then you don't pay anything until you go over 5 developers (upgradeable to 8 if you invite more people to BB). GitHub, on the other hand, doesn't offer -any- sort of limited private repo hosting.

GitHub, Google Code, BitBucket, they're all free (the first two only for 'open' repos) and offer the same set of features at varying levels of integration (though, again, Google Code is doing away with the downloads system).

Looks like GitHub has changed. And the first-class releases system you have reference is pretty much what we need. Since our Add-on API is open source and doesn't even need to be complie at all. So, this is a big benefit for all of us without the need to go through the svn in order to obtain every files. Google Code's separate download system and the source code isn't what we like for Add-on API's releases including some minor fixes.


Meaning we will be likely go with GitHub for Add-on API's code and the documentations. Thanks to Kornman00's questioning about our old research on the GitHub limitation.

Btcc22, I just realized the documentation link isn't on the Add-on API's FAQ and it's own page. I will have that fixed by tomorrow or until I have the GitHub for it to be ready and make the link to there instead. Can't believe I had overlooked that.

We have added the Add-on API repository to the GitHub including the documentation from our Bug Tracker section. The library and header interfaces will be posted on Nov 1st, 2013. All of the export hooks for plugin to be used in H-Ext 0.4.0.0 and above are available to be view in our documentation too. Any feedbacks are welcome. :)

Also, I have updated the Add-on API's main and FAQ pages to be link for our documentation either on GitHub or Bug Tracker section.

We have released H-Ext 0.5.0.0 and Add-on API 3.0 and ready for public usage. (We noticed a few are missing from the S-Ext transfer and will be updated in the next release.)

Bitbucket Limited? Ha yeah right. You realise its built by Atlassian? And therefore has direct compatability (and features) for JIRA, Confluence and other tools?

GitHub has no limited to contributors per application code whilst BitBucket do have limitation of 5 users (aka contributors) for each application's source code. Therefore give a GitHub +1 reason to have. However GitHub's private service demand to be paid per monthly. But we do not need any of private service since our H-Ext is close source and easy to maintaince ourselves. GitHub do have similarilty to Atlassian's Confluence, even Google Code has this too. Also GitHub do have direct compatability and feature (similar with JIRA) with many third-party supports.

Our decision summarize into this expectation. First, the Add-on API's source code is need to be public. Secondly, in case of having more than 5 contributors (if any) to continously update the halo structure and other purposes would be better than 5 or less contributors. Third, we do not need any private service even if it's optional feature for free. Finally, H-Ext is basically provide the interface for the plugins to use whilst staying as barebone system*. So the conclusion would be GitHub.

We have Bug Genie software installed which is pretty much identical to JIRA. Although, the software is quite slower than our Halo's site. The plan is to migrate everything into our site v2 without the necessary to create different accounts for each software we have, more secure security, use only necessary resources to load a page, etc.

Remember, not every provider has your every needs can be hard to find and each do have limitation for free.



*this mean the plugins will be required to be loaded to serve your propose expectation such as role-play commands, extend gametypes, remote access, and so on.

Quote:

---

Originally Posted by coolest2guy

GitHub has no limited to contributors per application code whilst BitBucket do have limitation of 5 users (aka contributors) for each application's source code. Therefore give a GitHub +1 reason to have. However GitHub's private service demand to be paid per monthly. But we do not need any of private service since our H-Ext is close source and easy to maintaince ourselves. GitHub do have similarilty to Atlassian's Confluence, even Google Code has this too. Also GitHub do have direct compatability and feature (similar with JIRA) with many third-party supports.

Our decision summarize into this expectation. First, the Add-on API's source code is need to be public. Secondly, in case of having more than 5 contributors (if any) to continously update the halo structure and other purposes would be better than 5 or less contributors. Third, we do not need any private service even if it's optional feature for free. Finally, H-Ext is basically provide the interface for the plugins to use whilst staying as barebone system*. So the conclusion would be GitHub.

We have Bug Genie software installed which is pretty much identical to JIRA. Although, the software is quite slower than our Halo's site. The plan is to migrate everything into our site v2 without the necessary to create different accounts for each software we have, more secure security, use only necessary resources to load a page, etc.

Remember, not every provider has your every needs can be hard to find and each do have limitation for free.



*this mean the plugins will be required to be loaded to serve your propose expectation such as role-play commands, extend gametypes, remote access, and so on.

---

Oh for what you intend to use it for GitHub will do a marvelous job, it seems the key feature you want is easy access to outsiders who can contribute, which would be GitHub as it houses a lot more users and is more open.

I just felt you were saying that Bitbucket wasnt on par, so thought I'd defend it :)

And you have the right to defend it. ;)

(off topic)
We are aware of Atlassian offered Minecraft dev team to use their product for specifically JIRA's ticket system. This does help the team to summarize how many users are reporting actual issue instead of inaccurate issue(s).

Out of curiosity, are you still developing this?
I am wanting to develop with C# but that is made very difficult because of the lack of managed code, but you claim to support C# (or are going to in the future). I basically have to rewrite the whole add-on API in C# to use any of it. I assume this would be the case with any other .NET language as well.

Yes it is still under development, right now it's not compatiable with C#'s import/export interfaces and still looking for a fix. I will need to create the .cs files for it able to use C# instead of other developers required to make their own add-on API transition (if this is the right word for it...) from C header to C#. The problem is... it will require to be unmanaged C# instead of managed C#. Eventually some time later, the interfaces of requirement will be readjusted to accept the unmanaged exports from C#'s DLL.

Wondering what's going on with the current development? Well the following listed is already implement for 0.5.2.2:

• Added Timer system
• Major changes to the command function (readjusted for general timer system supportive).
• Will be updated to Add-on API 3.2
• Fixed the IObject's Create function
• Fixed the red/blue team from obtaining the player list prefix
• And some other things I can't remember...

Edit: My apology, I meant what's ALREADY included in the future release of 0.5.2.2. What we're not sure about... what should be included in 0.5.2.2's features. If C# fully support is a must, then we may have the time to research what is possible and not possible with "Unmanaged Exports (DllExport for .Net)" which do required NuGet installed for Visual Studio 2012 or higher.

Halo is entirely 32bit, so you would be better off creating a C++/clr wrapper library instead creating even more overhead with Interop and increasing code complexity with duplicating structures in pure C#.

I am not sure what you mean by "increasing code complexity with duplicating structures", Kornman00. Could you possible explain slightly more deep about this?

I am still having issues with DllExport (unofficial third-party plugin for C#, created by Robert Giesecke) to export the variable (not exporting a function) for verify a variable's structure before proceed to load an (read-only) add-on into functional add-on to use with the compatible H-Ext. I thought about the DllImport and how exactly it suppose to work with. So I tried this method:

Code:

---

[DllImport("Test.dll")]
public bool testInt;

---

It returns exactly the same message from DllExport's error: "Attribute 'DllImport' is not valid on this declaration type. It is only valid on 'method' declarations." I have googled up any solution for this and only found suggestive to use the functions which I cannot use at all if I'm going to use a read-only exported variable to make verification before load the compatible add-on. If there is no chance at all to have import/export variable to be supportive in C#, then it's likely C# add-on type will be out of the picture.

One part of the reason I would like to have C# supportive is MySQL Database. So it can be build in C# to use without additional installion requirement while C++ version does. However, C++ can be used as an optional build instead.

If no one is able to suggest a fix, including the working sample code, for the C#'s import/export a variable, then I will substitute more general compatible C native to experimental client-server network communication into H-Ext 0.5.2.2. However the experimental client-server network communication will take slightly longer than making a C# supportive with H-Ext's interfaces including a variable structure requirement.

His DllExport is just like DllImport, in that it only supports methods. You can't use it on anything other than a method, which is why it fails to compile. So what you're trying to do isn't possible. You would have to use an exported method for get/set.

And by increased code complexity, I'm talking about writing a C# wrapper for your native C++ extension. Eg, any structures used in the C++ APIs would have to be redefined in C# and appropriately annotated with interop attributes. And C++/cli tends to have better performance than doing P/Invoke via DllImport and marshaling, unless you use SuppressUnmanagedCodeSecurityAttribute, but that too shouldn't be used willy nilly.

"You would have to use an exported method for get/set." By this you mean:

Code:

---

public bool testBool { get; set; }

---

either above or below,

Code:

---

private int testBoolA;
public int testBoolB
{
  get
    {
      return testBoolA;
  }
    set
    {
      testBoolA = value;
  }
}

---

or you actually meant this below? (Can't really use this method as I explained in previous post, just informing.)

Code:

---

private int testBool;
public int getTestBool()
{
  return testBool;
}
public int setTestBool(int setValue){
  testBool = setValue;
}

---

H-Ext is mostly written in C native along with some C++ template needs without needing to write individual classes per se. And yes, it required SuppressUnmanagedCodeSecurityAttribute since C# doesn't like the structures I provided.

The first thing you posted is a property, which is an amalgamation of two specialized methods for get/setting. Behind the scenes a property really translates into two methods: "get_testBoolB" and "set_testBoolB".

The DllImport concept can only be applied to literal methods, not properties. So yes, you would have to use the individual methods like in the last code block of your post.

That's what I was concerned about... I have thought of another solution for this problem, the two options I could think of are..

• Create a eaoVersion file to be included in a project (aka embedded into the add-on dll file, also will need to rename the dll to eao as file extension).
• Our executable file to append the eaoVersion into the add-on dll file, then convert to eao, file extension.

If anyone have any suggestions other than listed above, please do reply here. March 7th, 2014 will be the deadline decision of which method will be used as replacement. We will keep the deprecated of dllexport version of the EXTOnPluginInfo function until 0.6.0.0 is in development, then we will recommend to replace the dllexport version to the options we have determined to use. This also include the community's suggestions which may be seems more suitable than our options idea.

After March 7th, 2014, we will start working on this compatible issue with C Sharp (C#) and Visual Basic (VB) to be supportive. Have other programming language(s) suggestion which does support complied as module (dll) and support C base interfaces? Please do let us know. We may try the basic interfaces with the programming languages other than C++, C#, and VB to see if it works correctly. If needed, we will do our best to make the necessary script files to support it. Such as C# required .cs files, C++ requires .h and/or .hpp header files, and so on.

The experamental network communication is delayed until this issue is resolve.

Why are you wanting to use compiled languages in the first place?

Excellent question Oxide! ;)

By using the complied languages, the following list offer big advantages over non-complied languages.

• Encoded into machine language, compiled language, offer stronger privacy and is unreadable to users. Reverse engineer users will take longer time to translate it back into specific language it was compiled from, in most cases they just give up.
• Shorter load time and ready to use. (Also depends on what kind of purpose you're using it for.)
• Offers variety of code optimization of your preference.
• Uses less memory. (Depends on your preference, like /MT if want to bundle everything in one dll file which do increase more memory.)
• No restriction of how you use it. (Example, PHP doesn't have support for DirectX interfaces and strictly limited excluding some additional require installation to use, like Perl.)
• At least ability to tell you the errors before it complied instead of crash often, usually due to incorrect standard rule and/or misspelled variables/functions.
• Compatible C native interfaces which expected to work with almost any C base language instead of limiting to one language only.
• Ability to create a extended interface for specific language required separate management in case if C native interfaces is not supported. (Such as Lua, PHP, JavaScript, etc.)

Quote:

---

Encoded into machine language, compiled language, offer stronger privacy and is unreadable to users. Reverse engineer users will take longer time to translate it back into specific language it was compiled from, in most cases they just give up.

---

Do you realise that half of the mods on this forum (or Halo), such as HAC2, OpenSauce, Phasor, Gandanur, SAPP, etc. is all about reverse engineering Halo's machine code and adding new features or fixing bugs? How can you even make such extensions without basic knowledge of reverse engineering?

Edit: Also, perhaps we should have told this to you some months/years ago, but C# has nothing to do with C/C++, and it's using managed code which is compiled into machine code at runtime.

More likely will be leaning to second option which is

• Our executable file to append the eaoVersion into the add-on dll file, then convert to eao, file extension.

Reason?

• Less headache with individual complier compatibility and remove limited support of possible of each complier is able to do.
• At least ability to focus on one central executable file without need to check individually issues.

What is likely required to for it work?

• Add-on Converter executable file must be inside the root directory which contains the Add-on API folder. (The library and every header files must be in this directory).
• Must be macro defined within one header or a main file (if not using a header file).
• Check the structure from Add-on API's eaoVersion against the macro defined within an add-on's header or main file. (The add-on does not require to include the eaoVersion during compile process.)
• Convert valid add-on dll into add-on eao file extension with eaoVersion header info. (Most likely in same folder where the add-on dll file was compiled in.)
• If there is a compatible support for a language which isn't listed, then please do post name of the language, attach the header and/or main file for it. We will append this check into the Add-on Converter's search list.

If any of you have complaint about this, please do calmly post your complaint. I will account the complaint ratio of this idea.

EDIT:

The conclusion of the discussion will be a custom executable add-on file we will supply to support the converting module (dll) into compatible add-on. The development for it will begin tomorrow.

During the spring break, there was a conflict with other surprised planning. So, it had been delayed for another week (after spring break). After doing some researching and find out the method to have the potential way to have both converted add-on plugin and verification of the add-on as well. There is a way... Except it will required much more time to make some of functions & verifications as required base on the research in order have it to work properly. The eta for next release will be TBA since the load method development will take minimal 1-2 months and another month worth of testing.

Cheers,
DZS|All-In-One

EDIT:

We are only halfway completed the load system which may will need slight modification once we have start working on converting the compiled plugin into compatible add-on for H-Ext to load it. And of course... had some setbacks to re-fix the issues for different type of dlls that is supported by Windows' OS. Will create a new post once we have completed the load system plus finish the converter for it too. Hoping to have testing process be ready at beginning of June or the end of June.

Updated to 0.5.2.2 contains bunch of fixes and support Halo 1.0.10!

Updated to 0.5.2.3

I'll post the changelog there and here. Unless any of you have a complaint about this. Feel free to inform me via pm please.

• Added: isfloatA/W, isdoubleA/W functions added to util namespace. NOTICE: This require an updated Add-on API.lib file for H-Ext 0.5.2.3 and newer.
• Added: EXTOnPlayerUpdate hook
• Added: EXTOnMapReset hook, only supported for Halo PC & CE version. Halo Trial does not have this. NOTICE: This does not hook to a "successfully reset" section, it only tells sv_map_reset has been executed.
• Changed: EXTOnPlayerAttemptDropObject hook, was EXTOnPlayerDropObject
• Fixed: Rcon message for client console does not appear. (Added another detection if player is local or remote.)
• Changed: Timer ticks changed 60 ticks to 30 ticks per second (using map ticks instead of game ticks) and excluded the requirement of needed to include map ticks.
• Previous checking for halo, and Open Sauce, commands were not 100% accurately due to limitation on commands matched. Now it fully include every commands.
  
  • NOTICE: You will need to manually re-fix your commands.ini file! Please remove ANY of the non-characters such as +, -, <, =, etc under "[Halo]" section!
• Fixed: Halo's alias commands aren't 100% successful due to executing the alias instead of full command name.
• Fixed: Any non-characters excluding underline, dot, and numeric cause issue for iniFile class to insert fake section wrongful.
• Changed: Since noticeable for some hosting company could not restart due to quietly crash internally. By default it will not quietly crash. However, you can use a command to force quietly crash enable.
• Fixed: Login command through rcon cause crash.
• Fixed: First login success then cause second and on not to work due to overwriting other variables. NOTICE: This is a serious affect of how H-Ext handle the players!
• Fixed: Login through chat displayed the sensitive login info.
• Fixed: dynamicStack class of copying has one minor misused variable. NOTICE: This has a serious affect of how H-Ext and addons operate the ICIniFile class!

As for additional news, we have moved the Halo branch onto another server which is able to serve average 3 seconds per page. No more average 10 seconds or more per page! Although, the bug tracker's issue page did take about 20 - 30 seconds to load... Now it only takes 5 seconds!

I was under the impression that Halo PC, CE, and Trial's master server browsers all went offline when Gamespy cut off support for them. I'm totally out of the loop on where Halo is in all that though. Have you guys (or somebody) come up with a fix for that?

Quote:

---

Originally Posted by Donut

I was under the impression that Halo PC, CE, and Trial's master server browsers all went offline when Gamespy cut off support for them. I'm totally out of the loop on where Halo is in all that though. Have you guys (or somebody) come up with a fix for that?

---

Bungie is hosting the master server in house now.

The fix is to patch your Halo to 1.10, it is a official patch by the way. What it has is some bugfixes and change the master server from GameSpy to Bungie's base on Btcc22's master server code provided. Here's the link since it is hiding from dark corner of the Internet.

Updated to 0.5.2.4

• Fixed: UAC Virtualization cause issues with forced redirect directory without telling the application where it's really stored at.
• Changed: Changed the fresh setup method at load.

Just a reminder, the UAC Virtualization fix required a patch to your halo application. If you do not want your halo patched by H-Ext, just click no when requested (it will repeat every time you start up halo).

I'm informing everyone here the website containing downloads for H-Ext & Add-ons are currently down up. Aka http://addon.halo.dangerzonestudio.com due to my mistakenly corrupted the database when attempt to fix strange characters not being converted correctly. FIXED! Also, mysqldump executable isn't dumping every single piece of data from an old database. So, it's gonna take awhile to get this thing fix... Even my computer's http and https protocol aren't functional whilst other protocols are working fine which is strange, can't find source of the cause too (this is how I accidentally corrupted the database when attempt to fix the strange characters).

EDIT: Fixed http://addon.halo.dangerzonestudio.com site, no issue(s) so far.