I've been having some ideas for a new net fix.
Previously, we attempted to patch a few bytes here and there to make the network protocol work from behind NAT routers. The patch dealt with the issue of the encapsulated IP, but not with the issue of ports. Basically it let people play, provided they could properly setup port forwarding. Actually fixing it so port forwarding wasn't required would have been a much larger patch.
Seems the port issue was fairly important though, as most people have resorted to using Hamachi to play. It also seemed to make patching less critical, since pretty much everyone could play now, they just needed to install Hamachi. Of course some people refuse so use Hamachi and have stopped playing, so maybe this still needs to be addressed after all.
Anyways, I think we might finally know enough about how the network system in OP2 works to actually replace the core component that is responsible for all the NAT problems, including both the IP and port translation. This can mean two things in particular. One, that unassisted, people could play direct IP, where only the game host needs port forwarding, (and only 1 port would need to be forwarded). Two, that we could design a new networking component to make use of some sort of game matchmaking system. With that in place, not even the host would require port forwarding. Basically anybody would be able to play without any configuration using the match making system, and if that ever goes down, or this site ever dissapears over time, then simple port forwarding for the host would be enough for anyone with the fix. (The fix being required by all players of course).
As for how this could be done....
At the multiplayer menu, where you choose the type of network game (TCP/IPX/Modem/Serial/SIGS), each button activates some object that takes the user through all the screens to start the network game, and in so doing, also creates the underlying network object to transport all the messages between clients, and establishes all the connections. Now this first initial object is very simple, with only 4 virtual functions, and no member variables. As such, it's very easy to replace. Also, the objects are assumed to be statically constructed, and an array of object pointers is used to access them. We could simply overwrite one of the pointers in that table to install a new object that would take the user through a different set of pre-game setup windows, and create a different network object.
Now, the game Join/Host window is fairly simple, and can be reused since it's not tied to any one protocol and it not responsible for creating any of the network objects that need to be replaced. (It already is reused by the different protocols). However the code that controls the following screens gets fairly dependent on the network component that needs replacement, and as such would probably need to be replaced as well. This would include the broadcast/search for games, and the create game screen. But since these screens sort of suck anyways, why not just replace them all? Well... ok, that's a bit much work. The pre-game setup window, where you can chat with opponents, choose color, etc., is fairly independent of the underlying network type. Once you've reached that screen, the needed network object is already created and functioning. We could just use that screen as is, since we'll need to create a network object that's compatible with Outpost 2 anyways, so we can save a bit of work here. At least for now anyways.
It would be nice to somehow combine the max player setting, and the game type with the pre-game setup screen, so the host doesn't need to abort and remake to change those settings. But that's quite a bit bigger of a project. It would also have been nice to do better checksumming of files and actually dermining who and what file is different, and it would also have been nice to allow auto downloading of missing files. But again, too big of a project for now. (Btw, definately need some sort of security confirmation before downloading any DLLs, and maybe tech tree files as well).
So, the proposed change then is to replace the object that controls the sequence of windows to setup a game, (and install that object in the required table), to replace the intermediate windows, and to replace the underlying network object that is responsible for making all the network connections where all the NAT troubles lie.
Ok, so how big of a project would this be? Well, initially I thought this could be done with a couple days of hard work, which means I've already spent about a week on it, and it'll probably take at least a month.
Currently, I've replaced the object that controls the sequence of windows, and replaced one of the table entries to install this object. I've created an intermediate window layout using the dialog editor in MSVC, and I'm able to get that displayed in game nicely skinned. There's pretty much no code behind that user interface yet, but it does pop up the pre-game setup window when you click create or join, and the cancel button will take you back. I've got just enough of an underlying network component written to keep the pre-game setup window happy and not crash or behave too oddly. Create actually makes it looks pretty normal, but join just sort of leaves it waiting to receive settings from some game host, which of course will never come because the underlying network component is not even close to finished.
Most of the work needed is in getting the new GUI to work, and writing the network protocol to search for and join games, as well as start the game (i.e., the whole "Replicating Players List" part). That will probably end up being a fairly substantial amount of code. After that, we might also consider writing some sort of game match making system.
Here's what the current intermediate screen looks like:
(in-game, skinned)
(in MSVC, unskinned)
.PNG)
I was also thinking that clicking cancel at the pre-game setup window should bring the user back to this window, rather than all the way back to the main menu.
Anyways, let me know what you think of the user interface. Or better yet, if you have suggestions, make the changes yourself. I'm attaching the .rc file that contains the dialog resource. You can edit it yourself in MSVC, or any other dialog editor that understands .rc files.
