Except the basis of OpenSauce is extending what's already there, not completely changing or replacing (thus breaking stock-compatibility). Some of the enhancements that OS does makes it so that it has to be loaded before the majority of program has started initialization. Using a loader would only complicate the runtime chain and add yet another level of detail to deployments. I'd rather have simple drag&drop support in OS which anyone can muster than maintaining a loader along with the DLL which then end users have to go out of their way to use.
OS can target both servers and clients. There is very little dedicated server specific code so I don't run tests for it unless it's for a major release, but the support is there in the codebase.
OS uses non-intrusive XML configurations. It wouldn't make sense to put OS specific config info into init.txt when that file is for stock Halo. Also with XML, the library doesn't have to worry about using custom parsing or writing code, it can use a third party library.
The server list operates by displaying all servers that have a matching version number as the client who is performing the query. If I cared about only showing OS specific servers, all that would need to be done is change the version number to one that would never be used by an offical game update (eg, "2.00.01.16").
The only network packet changes that I was ever going to support in OS was adding new message deltas. I had no interest in changing the lower level data packets that are communicated. When clients get unknown or invalid data from the server, their connection is automatically refused anyway. Nor do I have any interest in using custom networking solutions (a la MultiTheftAuto) that are specific to OS as that would only further complicate the codebase and go against "extending" present game features.
The networking changes I came up with for theoretically increasing online performance are done by changing what's already there in the game, nothing is added. It's a mix of what Delagginator did plus a few other configuration changes.
HaloCE is already plagued by too many versions. The point with OS was building on top of existing game features that wouldn't completely break stock games so there wouldn't need to be yet another level of versioning in CE. This enables people to continue to use OS-enabled games in stock game servers. It also keeps the codebase less complicated.
E @ Codebrain: the stuff in the initial post of this thread is pretty outdated compared to what is in the source repo now. I no longer use pre-built EXEs, but use OpenSauceIDE to "apply" OS HEK changes. This enables users to perform whatever changes they want to whichever HEK EXE (eg, sapien) then "apply" the OS features to a copy of that EXE and also completely removes the issues of those DLL errors seen in past versions of the modified Guerilla.
Bookmarks