Re: OpenSauce and Halo CE Crashing *PLEASE TEST FOR FEEDBACK*
Other than critize current methodologies, you can present a working alternative. I know how to fix the sapien issues while keeping the dll, but never had the problem during development since my installations are split.
I've already tried modifying the v1.08 exe but it still verifys it's integrity as with all previous versions (except v1.00). I made automations for modifying the various exes (hek, haloce, dedi) to execute custom code and load a Yelo module. The automations are internal though, so thats just more things I have to include in the OS codebase (and the hek poritions are closed anyway).
With a dll hook you maintain the abstraction from the code of which is being modified. If I didn't use a dll hook, then I would have to also release a modified EXE. Great, now a app plus a dll bullet on Arteen's list. For haloce *and* dedi. This also makes it somewhat more of a hassel with version targeting. Its just more modifications to keep track of and update.
Re: OpenSauce and Halo CE Crashing *PLEASE TEST FOR FEEDBACK*
I'll try the server version out of you need people to test stability on that as well... ;)
Re: OpenSauce and Halo CE Crashing *PLEASE TEST FOR FEEDBACK*
Re: OpenSauce and Halo CE Crashing *PLEASE TEST FOR FEEDBACK*
It would be cool if OS would work with Sapien, since Sapien only compiles the default script functions.
You could have like a space map. Where you start inside a base, then you move to the airlocks. And a trigger point is there, so when you exit the airlocks to the outside, you jump around as though you were in space and had less gravity.
Re: OpenSauce and Halo CE Crashing *PLEASE TEST FOR FEEDBACK*
Hehe, I would love to, but I am only throwing this on your table as a good alternative. As picky as you are with your code, please keep an open mind and just think about it.
The method I want you to float your mind around is dll injection. Not only can you inject the dll whenever you want, but you can also eject it whenever you want without having risk of crashing Halo because it would no longer have a loaded d3d9 module to use. This will also make it easier to debug and test code, without having to keep opening and closing Halo to load the dll over and over. External injection can also be very noob friendly, just like a proxy would. It can be as simple as opening an executable that has no interface controls and loads it automatically when it finds the game. Building your own custom dll injector sounds awesome anyway, to me. You brought up the point of modifying Halos executable code to load your dll, but this is not necessary since injection from an external source is possible without needing to touch Halo's code. Therefor there would be no need to lug around patched executables, only an injector and your dll.
As far as changes to your own dll code, it would be significantly small and very little work. There are many different ways to hook Direct3D, but I will propose what I think is the most logical method in this situation, which would have to be VMT pointer modifications. Instead of detouring or creating an old fashioned jmp hook, you just replace Halo's VMT pointers with the addresses of your own functions. This has some advantages. The return can be a call to the original d3d9 function, so programs like xfire, gamecam, fraps, gcc can all still be hooked and running properly. Also, unhooking is just as easy as hooking and you don't have to unwrap the entire interface, only hook and unhook individual functions freely. There is a lot more flexibility here and the only thing you will need to keep track of is Halo's device pointer, which is global and static, but I'm not sure if it changes between CE versions or not. I bet you already have the version checking code, so you would just need to add this variable under that check. You could also pattern scan for the CreateDevice call, which returns the device pointer and grab the address from a relative offset, so a version check is not even needed. Alternately a less viable method is to inject immediately when Halo starts and hijack Direct3dCreate9 and then CreateDevice, but that shouldn't be necessary.
There are some downsides to this method, just like any method, but I think it's more reasonable than the current one. You will have to lug an injector around, but this is not a bad thing. It can be used universally to inject any dll into any process and only needs to be downloaded once. Injectors are all over the place, so if one does not work, there is one that will, they all have the same basic method of entry. So, like I said, keep an open mind as will I. I didn't bash your method to break your heart, but as constructive criticism to think about other possibilities. There seems to be many problems hovering around this proxy method and I am just offering my advice and will help where I can.
Re: OpenSauce and Halo CE Crashing *PLEASE TEST FOR FEEDBACK*
Would modified content files affect how it runs? I'm sure many people here use that old CMT chat box or one of the many variants on Halomaps.org
Re: OpenSauce and Halo CE Crashing *PLEASE TEST FOR FEEDBACK*
Depends on the "modified content." For the most part, no. Custom UIs, custom chatbox, and the version changer should not (and appear not to) crash the game. They're completely separate.
However, a modified exe will more than likely crash the game (if you can even get the game to start without OS). Strings.dll I'm not entirely sure about, but I wouldn't chance any foreign ones anyway. Besides, altering the code of those and redistributing them violates the DMCA.
Re: OpenSauce and Halo CE Crashing *PLEASE TEST FOR FEEDBACK*
Poll is inaccurate because so many "no" are becoming "yes"
Re: OpenSauce and Halo CE Crashing *PLEASE TEST FOR FEEDBACK*
I have been slowly modifying the poll as the cases are resolved. I believe where it stands now is fairly accurate, unless you can refer me to a post I missed where someone who answered "no" got it working.
Re: OpenSauce and Halo CE Crashing *PLEASE TEST FOR FEEDBACK*
FAILED. Game exceptions on load!
Time of this report: 5/28/2009, 15:42:21
Operating System: Windows XP Professional (5.1, Build 2600) Service Pack 3 (2600.xpsp_sp3_gdr.090206-1234)
Language: English (Regional Setting: English)
Processor: AMD Athlon(tm) 64 X2 Dual Core Processor 5000+, MMX, 3DNow (2 CPUs), ~2.6GHz
Memory: 2048MB RAM
Page File: 718MB used, 4244MB available
Windows Dir: C:\WINDOWS
DirectX Version: DirectX 10.0 (4.10.0000.5512)
DX Setup Parameters: Not found
DxDiag Version: 5.03.2600.5512 32bit Unicode
DxDiag Previously: Crashed in system information (stage 4)