Game dll's

[NachtPiloten]

What language are the dll's compiled in .net, visual basic, C++ or ? Why, well I beleive that through the use of custom dll files the functionality of CFS3 can be altered and enhanced. As stated elsewhere WOFF does this. I am not talking about stealing but knowing how they are/were made and moving forward if possible.

[grover1]

DLL's are predominantly in C++ and Visual Basic.

[MajorMagee]

The original dll files appear to be for C.

[gecko]

How do these actually work? Apparently it's possible to make new ones that are somehow recognized by CFS3, rather than just being limited to the existing ones. OBD has done it, Ankor did it as well, both with stunning results. It would be great if we could build our own, if there is anyone here with the requisite skills.

[AnKor]

I don't have exact knowledge, but I believe OBD's way of using additional dlls relies on (W)OFF frontend starting cfs3.exe and then immediately patching its memory to load OFF.dll somehow. This means simply placing that dll in the game's folder won't do anything.

My d3d8.dll is loaded differently. Windows normally uses a version from System32 folder, but if the dll is present in the game's folder then "local" version takes priority. This trick has been used for ages, even officially. For example, 3dfx provided a special version of OpenGL32.dll to be placed in GL Quake's folder because the game wasn't natively compatible with Voodoo cards.

Once a custom dll is "injected" into the game you can do anything you want, original language doesn't really matter. gecko has managed to program some amazing things with AutoHotKey scripting language. AHK technique is similar to what WOFF does.

So while I won't call it trivial, it is a solved problem.

The actual issue is to find memory locations for things you want to alter.

My guess is that OBD has found locations of AI functions in the original executable, created their own versions of those functions, and redirected calls to use new versions.
This is difficult, because not only you need to find those (I haven't, though I wasn't really looking), but then you need to find out what inputs and outputs these functions have. And there are barely any tools that can help, you just poke blindly for hours until you get anything meaningful.

[NachtPiloten]

Ankor, so when you say executable, are you suggesting that in the main exe file one could search to find places in the code that reference game elements and then design dll's to replace the existing code or extend the code to allow you to incorporate new or revised features? I know this is a basic statement but is it essentially correct?

[AnKor]

NachtPiloten, yes, this is exactly how it is done - find the code in the original exe/dll, then replace it as needed (all modifications are made in memory while the game is running, instead of patching files on the disk).
But again, the problem is that the game code is not human-readable. C++ is compiled into machine code which has almost no hints about its sources.
Here is a nice example from my unfinished DX11 renderer that modifies an existing cfs3 function to enhance object visibility checks:

        const BYTE proc[] = {
            // ... test eax, eax ...
            // can safely use eax
            0x75, 0x04,                        // jnz +0x04 
            // didn't take the jump, thus eax is zero, cmp will NE => setne al will set 1
            0x83, 0x65, 0x00, 0xFD,            // and dword ptr[ebp + 0], 0FFFFFFFDh
            0xE8, 0x00, 0x00, 0x00, 0x00,   // call ...
            0xEB, 0x04,                        // jmp +4
            0x90, 0x90, 0x90, 0x90            // nop
            // then eax is immediately overwritten
            // ... mov eax, ...
        };

            memcpy(addrProc, proc, sizeof(proc));
            *(DWORD*)(addrProc + 7) = callOffset;
            // also replace jump from 0x564a76+2 to 0x00564A8B+6 = 91h-78h = 0x19
            // test eax,eax and then doing JZ to cmp eax, 0FFFF...
            // thus if eax is zero, cmp will NE, so setne al will set 1
            addrJump[1] = 0x19;

[gecko]

Is a dll a little less "invasive", for lack of a better word, than what I am doing with Autohotkey? My code is an entirely separate process that is reading and writing memory values in the CFS3 process. Dlls seem to be integrated into the actual sim process, and as such are they potentially less prone to reading/writing to a bad address and possibly have greater control over what the exe process does instead of just reacting to it? Or is it pretty much the same at the end of the day?

[NachtPiloten]

Ok, I used an exe/dll reader (exeinfope) to look at the main cfs.exe file. It takes the machine code and displays it as hexidecimal. Great right? Not so much since the code is really not human friendly at all. Read an analogy today "....like baking a cake. We know there are eggs in there and we could maybe find traces of the eggs in an analysis but to reconstruct the eggs from the baked cake... " Well it seems that the exe is like the cake the original code the eggs. So, unless we can decipher bits of the hexidecimal code to find the right pieces of code to work with, not sure this can be done. Well at least not by me at this point. There seems to be some machine code that converts to letters but much of it is in some symbolic language. Knowing this I am in awe of the WOFF folks how could find segments of the code to work with via a dll. But I guess a dll is smaller and might be accessible... Maybe Tom with his ins with MS could get us somewhere, but we have not heard from him for several months since his last set of comments. I wonder if the WOFF folks would even talk to us, anyone know some of these fine folks? I just started this so I am not giving up yet but seems a momentous task but if understood the potential is intriguing.

Off to something I know I can do build a plane....Hey anyone up to or knows someone who can write a complier for CFS3 using a newer version of max? We have the orignal script just don't know if possible.

[mongoose]

Re WOFF and WOTR, you could try Mark Andrews at (email address removed - moderator) although the last that I heard from him was the end of 2008. Clive may still be in touch.

[AnKor]

I know WOFF team attempted to make a m3d plugin for newer versions of MAX, but it wasn't finished.
I wonder what is the state of CFS3 sources now. Microsoft is quite open these days and its gaming division is on the rise, but I guess even if sources aren't lost, they are entangled in many legal and copyright issues and no one will ever consider releasing them.

gecko, the dll probably works faster because it is the same process, but as for being less error prone - no, a wrong address is wrong regardless of how you access it.
OTOH, running a separate process does not use cfs3 process memory, which is 32bit and limited to 2-3gb.

One issue with your AHK scripts I noticed is that you used many .exe files. It is pretty inefficient, since each exe contains a copy of AHK interpreter. I was surprised it worked so well, although there was a noticeable lag the first time a script is invoked.

I remember considering making a dll that integrated AHK support into cfs3. That could have allowed, for example, invoking scripts directly from a keybind instead of via messaging. But then I figured your approach is much more flexible and you constantly discover new things and having a fixed set of features would actually limit you.

[gecko]

Re OBD, while they're certainly great guys, and I've been in touch with them on and off, the dlls are core of their product. It's like asking them to hand you the keys to their business for free.

Also, James, you might want to edit your post to avoid sharing someone's personal email on a public forum.

Re AHK, I'm certainly interested in improving efficiency. What exactly are the efficiency drawbacks to the multiple exe files? I know it definitely takes up more disk space, and I've experienced the same lag. On the other hand, I found that spreading the functions into multiple scripts actually improved the response times. For instance, on the Spitfire Mk.V I'm working on right now, the starting procedure described in the pilots notes calls for rapid, repeated pumping of the primer. I initially had the primer code in one of the busier scripts, but found it too slow to be able to use the Mk.V procedure successfully. After moving it to a smaller script, the primer worked satisfactorily.

The main reason why there are so many scripts is to get around the AHK limitation of only being able to play one sound at a time. So each sound effect has its own exe, which plays it, and then closes. These are run by one of the main scripts and called for instead of playing the sound themselves. So the majority of the scripts are not running most of the time. But still, the current version of the module is running 16 scripts continuously in addition to the various sound effect scripts opening and closing. I have no problem admitting it's an absolute train wreck from a programming standpoint! It has kind of developed haphazardly, as we keep finding new things to do with it all the time.

A dll for AHK sounds interesting, but I agree, it probably isn't best if it limits what can be done. I think we have only scratched the tip of the iceberg as far as AHK capabilities with CFS3 are concerned. What's even more interesting is that DX11 code!

[mongoose]

Admin, please delete my post here. My mistake for not doing it by PM.