Hi wkWormNAT2 users,

Old versions of WormNAT2 have a bug which causes random desyncs/disconnects.

This can happen even when you're not hosting!

This is fixed in the latest version (v2.3). If you're using WormNAT2 (i.e. you have wkWormNAT2.dll in your W:A directory and have loading WormKit modules enabled), please download the latest version:

http://worms.thecybershadow.net/wormkit/wkWormNAT2.zip

Just drop the two files in your W:A directory and overwrite the old ones.

As an added incentive to update, I decided to remove the nag message that showed up on start-up. You might occasionally get a reminder in the lobby instead.

Users of old versions will see a message in the lobby when hosting games. Be warned, old versions will stop working completely on January 1, 2016.

Snooper authors who added WormNAT2 functionality to their snoopers:

The official version of WormNAT2 now implements the snooper protocol used by Wheat Snooper, so you no longer have to ship custom versions of the DLL. Check the source code of WormNAT2 and Wheat Snooper for details. The gist is: open a control connection to the HostingProxy server by connecting to proxy.wormnet.net:9301, read a port number (16 bit LE integer). Host the game at proxy.wormnet.net:PORT. Run WA.exe with the parameters: /wkargs /wnat2 X-Y-Z, where X is your snooper's PID, Y is the socket handle to the HostingProxy connection, Z is an event handle. WormNAT2 will duplicate Y and Z into its own process, take over the control connection and call SetEvent(Z) to inform your snooper that the game is hosted and it can release its connection handle (Y).

btw: If you whant to look into this even further - HB still doesn't reply when I send him i.e. "hello" - he used to anwer, that he's only a bot

Fixed, thanks. Will be applied on next restart.

I looked into this. It's caused by not using the "snooper" rank when using a snooper - this confuses HB. It will now send an appropriate error message.

To fix this, just set your snooper to use the "Snooper" rank.

they sabotage the whole thing.

Please stop, the sky is not falling.

There are no known cheats for the latest version. You can check which version your opponents play. If this is a problem for competitive games, simply forbid using 3.6.31.0. If the situation escalates we will take additional measures.

The emulated game version will be displayed when everyone has lit up. At that point, the host has the choice to start the game or not. You can also type /ver to see everyone's versions.

!tusmap and !tusscheme are working now. The intermittent (~daily) crashes should be fixed as well. Still working on this

Isn't it better for TUS to return downloadable content like application/octet-stream? Because some maps are BIT and can't be send as PNG map. (They could, but TUS had to convert them first which would be redundant since HB should get the BIT to load)

Err, yes, PNG for color maps and BIT for monochrome ones. I was still thinking of it from WMDB's perspective, which only supports PNG. Content type doesn't really matter.

Moreover, how does HB send the request to TUS? I mean are there any preferable methods? (simple GET? or POST?)

It doesn't really matter, but if it makes things easier, the way HostingBuddy currently integrates with WMDB is: for getting specific maps (known number), it requests http://wmdb.org/maps/{number}-download, and for selecting a random map it requests http://wmdb.org/random_map_for/{scheme}, which returns an HTTP redirect to a link in the former format.

Thanks for the quick fix