Incredible NEWS!
First pre-prep-real-phat-est version release:
About:
This version is the finished basic layer, only protocoling some few stuff yet.
Everything protocoled gets saved in a file named "MP DPNetworkEmulation-Log.txt" in same path as trek.exe.
This version isn't intended to do further analysing of BotF's mp or anything yet. The log isn't very meaningful so far anyway. It'll tell you alot false positive errors, that occure during calling directplay cause BotF is using these in a try and error manner and even DirectPlay itself is designed this way.
This version is just intended to show that it is working!! No theory anymore but practice. A new Networkengine is to be expected, but I can't tell when.
Attention:
This version doesn't improve botf in any way yet, it may even cause more crashes. Also, as you might have expected, I don't give any assurances or guarantees on it's behavior. Its use is on your own risk and will ever be.
Anyway, as you trust me, I'm absolutely sure that it wouldn't cause any damage and there is no spyware, malware, trojan or anything the like included. (Well, you have to trust any modder that changes executable binary files like trek.exe or dlls or has it's own installer. Just prefer to make things clear in this bureaucratic country.)
Install Instructions:
This version doesn't have an installer and you need to alter trek.exe with an hexeditor like
HxD!
But it's an easy task everyone is able to do, even if knowing nothing about hexediting and stuff.
First save your current version of trek.exe so you have a backup before hexediting anything!
You just need to open trek.exe with the hexeditor, search for "ole32.dll", replace it with "dpemu.dll" and afterwards replace "dplayx.dll" with "dplemu.dll", that's it. They should only be found once in trek.exe so with HxD you can just use the "Replace..." or in german "Ersetzen..." function in the "Search"/"Suchen" tab. Just a matter of some few seconds.
Of course you need to place the new dlls in the BotF execution path.
Here you get them:
DirectPlayEmulation (ole32.dll):
dpemu.dll
DirectPlayLobbyEmulation (dplayx.dll):
dplemu.dll
DirectPlayNetworkEmulation:
dpnemu.dll
Now BotF should work as normal but log some additional stuff to the log file in mp. Not much yet but it'll become more soon.
How come:
As I've told within my previous post, I've finally found my big damn fault I knew it was there but didn't found, lost all ideas and already gave up about.
Well, yeah, you didn't read, you shouldn't read!
It's hidden with a size of zero, but you'll see with quoting.
I found it while analysing some assemblercode for a new graphics engine. While analysing, I found some strange stack calls and with doing some search in the internet I read about different calling conventions. I've found out alot about how to implement a new graphics engine, but I'm not sure if it will be possible to develope a new one as well, cause the used graphics engine is from MicroProse and it isn't documented anywhere - no parameters, no classes, hidden functionpointers, nothing.
But with having read about the calling conventions of __cdecl and __stdcall it came clear to me that I've done a stupid fault. So stupid that I even got a little ashamed.
As told somewhere I had removed the __stdcall prefixes in the directplay and ole32 headers to get the right functionnames with gcc, cause with __stdcall gcc is adding an '@' and the size of the parameters to the functionnames and botf wouldn't find them (or I would have had to hex that to trek.exe as well but I did want to get the same names as there have been before).
Unfortunately this corrupted the call stack, cause with __stdcall the called functions are responsible for clearing the parameters from stack instead of the calling ones.
Such an easy thing and with having read about I even remembered having fallen in this trap some years ago. This happens cause of some little minor interpretation difference of gcc and msvc.
To solve the problem I changed back to __stdcall and hexedited dpemu.dll to get the right names, but this hasn't been a problem and it's just an adapter to dpnemu.dll anyway.
Damn, I still can't believe I didn't think about this before - just didn't came to my mind.
But however, now it is working and I wish you some fun with it.
Greetz, Flocke
p.s.: Ha! Now I'll laugh!