Hammerwatch Forum
General Category => Hammerwatch Discussion => Topic started by: DivinityArcane on June 27, 2014, 05:26:24 AM
-
Hi there.
I was thinking of writing a custom server for the game (to add random features for myself and some friends), so I was wondering if there is any public info (or any plans for there to be) on the actual protocol the server<->client uses.
I could write up a proxy and figure it out manually, of course. But it's always easier if it exists already. :)
Also, kudos on the game, it's great. I even managed to get the wife playing it.
-
Oh wow, that is quite the project. So the game doesn't really have a well defined protocol for communication, but we use the lidgren network library (https://code.google.com/p/lidgren-network-gen3/) for all messages, which you can take a look at for the protocol for reliable messages and heartbeat and all that. Then we have a whole bunch of messages with their parameters defined in an xml file, you can extract the assets.bin to take a look at network.xml, or just look at this (http://pastebin.com/JTaNYf3L) one.
You're probably still going to have to do a bit of packet analyzing for more details though :\
-
Oh, awesome. I've actually heard of that framework before, and since I'm working mainly with C#, I can use that if I don't want to port it.
A proxy to find the rest shouldn't be hard. It looks like the game uses a pretty straight-forward way of doing things, unlike games I've worked with before (Conquer Online (http://co.91.com/) being one of them)
Thanks for the reply!
-
Quick question.
I see it's not possible to change the port the via the client, and I haven't found it hard-coded in the client (by normal means. Hex search returns 20+ results for 270B, which is 9995)
I checked the hex dump of assets.bin, and it did have an occurrence there, but it was just the string that says "Port: 9995", and did not affect the client or server aspect at all. I assume [unless I'm missing something here] that the port should be in either the main binary (Hammerwatch.exe) or the assets file. Any pointers on which file I should look to, to modify that? Modifying a hex value is easy enough, I just don't want to go on a wild goose chase, modifying every occurrence of the value, only to find that I was changing values in the wrong file.
-
Sure, it should be in the Hammerwatch.exe, more specifically in the class LobbyMenu if you use a decompiler.
-
Alrighty, thanks. Since it's a const int (32bit integer) I know that for little-endian I'm searching for 0B270000 (9995 stored in a little-endian 4byte integer). I was able to find 7 occurrences at these offsets: 23E0B, 2B1B0, 2B21D, 2B2BD, 2D06D, 2D191, 6F310
Since I'm only looking to change the client port so I can add a middle-man proxy to log packets, I simply changed it to 0C270000 (9996), but it can be changed to any port needed. Did the changes using a hex editor and saved the new Hammerwatch.exe, and it works like a charm.
Thanks for all the help so far Myran :)
EDIT: Something to note for the devs. In LobbyMenu.cs, though this.port is defined as a const int, the port is hardcoded in various spots in the file. Not a big issue, but it's less of a hassle to have those hardcoded numbers just refer to this.port. Not that it matters at the moment, since the client doesn't provide a way to change it.)
-
Well, after looking over the source of the game binary and all the networking tidbits involved, it's safe to say that a private server would be a bit.. impractical at the moment. As it stands, HW's "server" aspect is simply a relay, so clients can tell eachother what they're doing. The problem with this is that basically all the logic is left up to the individual clients, making a dedicated server a bit of a "waste", short of writing some sort of server to just relay the packets and select one of the clients to be the actual "host", which would be a bit pointless. It also creates a bit of a problem, since HW utilizes UDP mainly as opposed to TCP, so a middle-man would be more of a harm than good. HW also doesn't really _have_ a protocol, but rather just passes around objects via packets and the clients just pull the objects from the packets.
So, well, I guess my hopes are dashed. While I slightly dislike the method used for multiplayer in the game (for reasons like the fact that each client can give themselves unlimited mana/hp/etc, as well as send false packets to gain things like unlimited lives or keys, which would reflect on _all_ clients), it does do its job as intended.
I'll just wait around to see where the game goes from here :) I enjoy playing it as-is, so that's fine in the long run.