Edit: This project for now is discontinued. You might still ask for the files if interested. Not sure when I find time for this again..
About:
This version is the finished Layer of DirectPlay, still using DirectPlay without of any changes to the connection.
It is fully multiplayer compatible to unchanged versions and should work with any mod or BotF version.
(Of course without of solving the well known mod incompatibilities and version conflicts)
The only thing it is doing, is protocoling every DirectPlay call to a file named "MP DPNetworkEmulation-Log.txt" in same path as trek.exe.
There may occure false positive errors in the log, cause BotF often behaves in a try and error manner.
Anyway, there should not occure more or less crashes to BotF without of this Protocol-Layer.
This version is just intended to show that it is working and for beginning work on analysing the messages sent and received by BotF!!
A new Networkengine is to be expected, but I can't tell when.
Attention:
This version doesn't improve gameplay in any way yet, and even though it shouldn't, it may cause additional 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.)
If people are interested in the sourcecode, you may ask me.
Install Instructions:
This version doesn't have an installer and you need to alter trek.exe with an hexeditor like HxD ( http://mh-nexus.de/en/hxd/ )!
But it's an easy task everyone is able to do, even if knowing nothing about hexediting and stuff.
First store your current version of trek.exe so you have a backup before hexediting anything and can always change back easily!
Then, after having created the backup, 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 of HxD. Just a matter of some few seconds.
Of course you need to place the new dlls in the BotF execution path.
Now BotF should work as normal but log every DirectPlay message to the log file in mp.
Preview:
Progress now will concentrate on wrapping DirectPlay and supporting an Interface that can be used by the upcoming Networkengine as well.
Additonally, some of the initialisation calls of BotF will be handled internally and some protocol entries will get removed or deactivated.
Serial- and modem as well as IPX connections will get disabled.
Afterwards, RakNet is to be expected as the new Networkengine, being supported through the wrapper-class of DirectPlay.
RakNet will allow NAT punch through and bypass, so most or even all connection troubles should get solved without of additional NAT or modem or firewall configuration.
Firewalls shouldn't ask more but once for the game to pass through.
Cause RakNet doesn't seem to support changing its sleep duration after initialisation and for NAT punch through every millisecond counts when establishing a connection, it's not sure by now how much performance will get lost.
A server for establishing NAT punch through and bypass connections is already available and tested.
All multiplayer games except LAN games using the new Networkengine are thought to automatically try to establish the connection first with NAT punch through and afterwards with bypass.
It shouldn't matter if you use the network configuraion menus of BotF or a lobby system like WarZone to establish the connection.
All players will have to use the same Networkengine.
There might be an option added to stbof.ini to swap between Directplay and RakNet.
That's it for now.
Old stuff:
--------------------------------------------------------
First, I still can't assure that it will be possible to develope a new networkengine for botf.
But I've done some deeper research on it in the last few days (after getting shocked by the recent WarZone downtime).
And I've already had some promising success as well as some damn setbacks.
So, next comes the goals I'm aiming at.
Goals
Solving most connection problems by supporting NAT punch-through as well as a stable bypass:This would of cause require our own server, but I already know some people that are willing to provide us and we would find more for sure.
But it will also require adopting and wrapping a complete new networkengine for botf as well as supporting some kind of userinterface like a lobby-client.
So this would need alot of work and isn't to be expected in near future.
Solving crashes and freezings on chat:This might be (but doesn't have to be) more easy, cause it's just happening due to a wrong order of received messages.
For reordering, a layer between DirectPlay and botf as well as some analysis of the messages and data getting sent would be necessary.
Speeding up the loading progress:I'm sure that loading just takes so long cause of the big distance we all have to each other (and fiberglass cables already relativate the far distances through ocean). A savegame is very, very tiny, just a few kilobyte. As we know, it depends on the number of players, so it unnecessarily must get sent one by one. But it's still much too long!
I think they've implemented it by a loop of sending a few bytes, waiting on reply, sending next few bytes, waiting on reply and so on.
It should be possible to drastically shorten this and just tell botf it got received, temporarily buffer the content and send it to every player at once as a whole. That shouldn't have a much bigger delay than receiving a chat message.
It would require some analysis of the data getting sent, maybe some checks for requesting missing/corrupted (internally buffered) packages again, as far as not already covered by TCP/IP and Networkengine, and at least need a layer between botf and DirectPlay.
Solving most of the mp specific crashes and allowing a stable timer:This should be achievable by implementing a better synchronisation algorithm. It would at least require a layer between botf and DirectPlay as well as alot of research on the messages getting sent by botf between the computers. The timer currently is quite buggy, cause it's more likely that you'll do something just in time with the end of the turn and messages may loose order in the web.
Allowing additional people watching an active game:This would at least need a layer between DirectPlay and botf, a complete new userinterface (cause botf probably can't be used for this without getting a Sync Error nearly every turn for the watching person) and it would require having analysed most of the data getting sent by botf so it can get parsed.
This goal is out of my personal intention, cause it would take lots and lots of work.
Allow developing a complete new AI:Yes, I think this goal should become POSSIBLE, after having analysed every single bit botf sends and receives on mp. Possible, nothing more.
It's simply unexpectable if all data will ever be analysed so botf won't crash, but with implementing the AI as MP opponents, and with analysing 5 player games (so current AI won't disturb that much) or better games without of minors and all AI killed as well as no random events, it might become possible one time and I simply love that idea, although it's not part of my intention.
Maybe someone finds more goals but these seem to be more than enough for me.
Analysing progress
So, what I've done so far is reading alot about DirectPlay, finding the old DirectX 7 SDK on http://www.vbgamer.de/vb/index.htm including the whole documentation of DirectPlay (just unpacked, didn't install)!
And I've been using Dependancy Walker from http://www.dependencywalker.com/ and HxD from http://mh-nexus.de/en/hxd/ to analyse trek.exe as well as dplayx.dll and ole32.dll that get used by botf.
The good: thing is, that with profiling trek.exe (so all dynamically loaded functions get logged by Dependancy Walker) it kept being DirectPlayCreate, DirectPlayLobbyCreateA in dplayx.dll and CoCreateInstance, CoInitialize, CoUninitialize in ole32.dll that are used by trek.exe. I've not tested this yet in really playing mp, but it should keep being just these five functions, with refering to the DirectPlay documentation and a tutorial found on web: http://www.gamedev.net/reference/articl ... cle764.asp
And these functions are well documented, including their function parameters and even headerfiles are available in SDK.
The bad: All my attempts to develope a layer so far failed and caused crashes.
The good: I'm still not out of ideas and I've already been able to compile my own first dll with http://www.codeblocks.org/ (MinGW distribution) that really got loaded and called by botf.
And it's even enough to add the dlls to the botf folder, cause it always will look up in the installationpath first cause botf doesn't explicitly call the system dlls.
The bad: With reusing dplayx.dll or ole32.dll as names, these libs seem to be accessed by other libs being loaded by botf as well, cause of the same name, not forgetting about my layer needing the real dplayx.dll or ole32.dll.
The good: It's really easy to change the dll names that get loaded and used by botf. Just search the Hexcode of trek.exe for them and give them another name of same length. You may even be able to change the function names/adresses getting called by botf.
Anyway, it will require an edited trek.exe.
The bad: With using MinGW and GCC, the corresponding headerfiles dplay.h and dplobby.h, ole2.h->objbase.h already declare the functionnames used by botf with '__stdcall', not a problem for compilation but causing @[parametersize] appendancies to the names in the dll. Additionally DirectPlayEnumerate gets an ordinal of 1 instead of 8 like it has in the real dplayx.dll cause gcc automatically orders exports alphabetically by functionnames and isn't configurable on this. Not enough does hexediting the ordinal after compilation result still in wrong order for calls of trek.exe, not for Dependancy Walker.
The good: trek.exe always will just ask for a function by its name, or it's ordinal or its hint (another ordering number), and it's just using the ordinals for dplayx.dll and the hints or functionnames for ole32.dll as can be seen by Dependancy Walker. For debugging purposes it doesn't even matter if the right one with right parameterlist got called - trek.exe will crash after return.
The bad: There will be lots of work to completely separate DirectPlay, including ole32 with it's com interfaces, cause they pass many functionpointers that may all be used by botf (luckily documented), and seperating DirectPlay requires replacing two libraries for botf, not one. But developing a layer or wrapper should not be split to two libraries! So there has to be a third library getting called by the two replacements and calling itself the real libs. Damn!
I think I'm not the onlyone interested in this, and as a documentation to myself I found starting a thread about would be a good idea.
Not to mention, well, yeah I'm sorry my approches in developing a savegamegenerator didn't find it's time yet!
And a new graphic engine, damn, when shall I do this?
What's about all my other projects and uni and other work?
Could anyone rent me some time please?
cheers, Flocke
p.s. have I missed any smiley
oh yeah, this one 
Edit: Oh, I've forgotten to tell about the -L parameter trek.exe gets called with by the WarZone client on launching. I tested this with a little trek.exe replacement and by calling trek.exe with this parameter (like -Mudd) by myself. You'll see that it works and the singleplayer button is deactivated.
BotF will then initialize DirectPlay, create a Lobby instance and determine all needed information for Direct IP connection (which are hold by DirectPlay, being initialized through and used by the LobbyClient itself), and even interact through DirectPlay with the LobbyClient in a way (the lobby client itself will query DirectPlay to determine the status, nothing more). I read about this in some of the documentations and it's always better to know how things are working before touching them! ^^
