Thanks again titi. Also remember that if the client crashes, you can hit Z on the server and save them game and then pick up where you left off.... although, I can't remember if it will still work or not if you do it after the other player leaves (or crashes), I think it should. When you go into the load screen and select a saved game that was a network game, you should get a similar interface as when starting a new network game where the clients can connect and you can't start the game until everybody is re-connected. Part of the original code when a client crashed auto saved, but it also forced termination of the game (which I removed). I need to go back and have it still auto-save at the moment the client disconnects and make sure the auto-save isn't overwritten if a second client disconnects (I'll have to figure that out).
I think I'm going to put the random number generator back the way Martiño had it before and maybe just add a pre-processor-enabled option to use true randomness (with my current random seeding). I'm also looking for other ways to smooth out the client's experience (less jumping around). But debugging on my laptop is really slow. I've been hacking up the msvc++ build (I created a debug+opt profile) to try to get more performance out of it in debug mode, but it's tedious. I had to completely disable pre-compiled headers to have so many different files compiled differently and compiles are a lot slower without them. Basically, I'm turning on optimizations for .cpp files that have a lot of processing in them (rendering and path finding mostly) and leaving the rest unoptimized. I can still debug optimized code, just not very effectively (I never learned x86 assembly, so I only have a very basic understanding of it and you have to really look at the disassembly & registers with optimized code sometimes).
Anyway, thank you again for your help and please tell your son(s) I said thanks!
- for the thunderbird, that one gets me. I understand why it did what it did *after* the thunderbird was stuck there, but I don't understand why it got stuck there after he told it to go away. I do know that it should have fixed its self within 30 seconds due to the MinFullUpdateInterval and if it crashed after that, then ... hmm, maybe there was some type of inconsistency in the network data, I did hack that code recently. One thing I like about using UDP is that if a packet is bad, you can just drop it and move on to the next one. But with TCP, it's just a stream of data, so an error in one place can throw the whole thing off.
I might have a good semi-optimized debug windows build, so I'm going to go for a 2 player game and see what I can come up with. Also, if you feel like playing with it again, maybe you can compile it with something like
CXXFLAGS="-O3 -g3" jam
And don't strip it, it might create better backtraces, but I'm not 100% certain of it (and it shouldn't be much slower).
