I briefly tried to compile the megaglest 3.2.4 package on windows earlier this evening, I introduced a few typedefs and two defines to get rid of most of the problems, but I wanted to test something, so I've left it for the moment. I'm happy to save you the trouble of setting up a windows build for Code::Blocks, but it may have to wait until the weekend.
I believe I have found the ultimate cause of the problems with online play though. Hailstone wants some sort of stable multiplayer for GAE 0.2.13, and with Daniel MIA again, he has set about reverting our multiplayer code to that of 3.2.2 for the time being. We have a problem though, clients are lagging badly, getting worse and worse as the gmae continues, while more keyframe updates arrive, until the socket's buffer is full and it rejects new data and the server disconnects it.
This is not nice news for us, I'm confident we'll find the problem, but for now it alludes us, however it is something of a blessing in disguise... In looking at this problem I've had a good look around the client/server interfaces and how they work with the game.
For online play with TCP, the client(s) are doomed to experience some lag, unavoidable. However, the game never stops... The server never
waits for clients once the game has begun, if a client arrives at a keyframe and it hasn't received the update for that keyframe then it waits. On the server, the game continues, 'flat chat'. On a local network this is unlikely to be a problem, but once we send our packets out 'into the wild', there will be losses, TCP will sort it out for us, and deliver it all in the right order, but clients will start to lag.
The more problems 'along the way' the further it will lag, the worse the game experience will be for the client, and eventually the socket's buffer will fill, and disconnection will follow.
I can't absolutely confirm now, I was just trying to test a modified glest 3.2.2 (just logging the amount of data remaining to be read on the client after processing a key frame) with PolitikerNEU but we had router/firewall issues. But the code says what the code says, the server does not wait (ever), and the client occasionally does wait, it can only ever be the same or get worse, never better.
Two solutions are feasible, 'server wait' and/or 'client catch-up', ultimately I think both is ideal, but for now giving the server a maximum 'lead time' and requiring 'Acks' from clients for each keyframe, and the server pausing if it doesn't have acks from all clients for, say, 3 or 4 key frames before where the server is at (subject to a timeout and potential player ejection of course).
This would be the easiest, and while it may result in choppy play sometimes, it should prevent any clients falling so far behind that they end up will a full buffer and disconnection.
I think with what you have done so far, and a little bit of logic to make the server a little more polite, this could all turn out very well indeed
Hope to get some good testing time in this weekend, IRC folks!