Coldest

The source from the SourceForge git repository compiles properly now. However, I don't think the dedicated part works. I copied and pasted the make -j3 DEDICATED=1 right into the terminal, but when I run the binary that is made, it's no different than the regular game binary (as far as I can tell...). Is it supposed to be that way, or is it supposed to be a console that I can type in everything?

Are you using the CMake build system? In that case, you need to enable the server building either using ccmake or similar, or setting the flags on command line:
cmake -DBUILD_DEDICATED_SERVER=YES -DBUILD_MASTER_SERVER=YES ..
After which the servers will be built as separate binaries with plain make -j3 without extra parameters.

Yeah, sorry, I forgot to update the dedicated server page with the new instructions.  Should be fixed now.

It also occurs to me that this is probably what you meant about a lot of errors in the other thread.  I'm guessing the dedicated server wasn't building correctly in the last svn revision, so that makes more sense.

Awesome! Thanks! I can confirm that it compiled fine, although you might wanna mention somewhere that it makes a binary for the client as well, with the options so nobody mistakenly compiles the game twice thinking they're completely separate. In other words, "If you ever want to host a server, in addition to playing on other servers, compile with these options."

I'm not sure whether it shows up on the master server list, as it didn't show up when I wanted to join my own server, but I was able to connect to my IP directly. This has happened before when I've hosted other games, but I could confirm my server showed up because of web page server lists, such as the following: =1= (http://legendsthegame.net/index.php?m=masterserver), =2= (http://www.infinitycommunity.net/icpservers.php), =3= (http://www.maxogc.net/tribes/t2/master.php) .

I'm not sure how to confirm it, so I'll probably try to leave the server up during this weekend, as I'll be busy with other things anyway, and it seems to require minimal resources to host.

Also, I'm guessing the master server binary is there for testing? or backup? Is there a current master server running somewhere?

I added a note about the build process.  Although it wouldn't hurt much to do multiple builds as nothing would really happen for the second one. :)

There was a network configuration issue on the master server that was making it fail to respond to traffic from behind a NAT.  That's fixed now, so when you start the client you should get a bunch of messages in the console and log that list all of the servers that the master server knows about (most of them won't be running at any given time though).  If your IP is in there then it should show up in the server list.  I should mention that I don't see any running servers in the list right now though, even after fixing the master server problem.

The master server build stuff is only included because it uses some of the same code as the rest of the game so it makes sense to use the same build system.  Nobody except me should ever need to build it, unless they're working on the master server itself.

That is strange. I have yet to see a "Received server announcement for" for my IP. I even tried opening the extra ports, but no change. And I don't see my server on the list, only a "Coldest Testing Server" (Ping 100-200).

With the update, I did get a server.bin , but it gives me an error:

server.bin: error while loading shared libraries: libboost_filesystem-mt.so: cannot open shared object file: No such file or directory

That file was not included in my installation of libboost-1.41.0, but it IS in the lib directory of the game directory.

I'll try to re-download and recompile everything (may be unnecessary, but as it's pretty quick, and quicker than a response, why not ;p).

Woah! Major problem found! I managed to get the server.bin working by copying all the necessary libs into the same directory as the bin, and seemed to run ok, but before I even checked if the server was on the master server's list, I found a problem. I tried to end the program with CTRL+C and even closed the terminal, but on gkrellm (internet + system monitor), I noticed I was still receiving a large number of packets, even though nothing else was running (even checked processes). I even restarted the computer, but the packets received were still there.

The only thing that worked was restarting my router. This is a problem. I don't want to try that again, so I'll hold off on hosting till stuff like this can't happen anymore... losing all control over it like that is scary, and maybe even dangerous, as far as I can tell.

When you ran server.bin, did you run it directly?  There should be a server script that sets up LD_LIBRARY_PATH so it will use the included libs, and that's how the server needs to be started in the packaged version.

As for the other problem, the only possibility that I can come up with is that the master server was trying to send something to you at the same time you ended the server and it continued trying to send even after the server was stopped, but even in that case it can't send packets more than once every half a second because it sleeps for that long in between sends.  The other possibility would be a client trying to connect, but if it's not showing up in the server browser then I don't see how that would happen either (and that also shouldn't be able to generate that much traffic, but bugs do happen ;)).

I guess the only thing I can say is that if it happens again you could grab a wireshark dump of the traffic and send it to me.  I should be able to figure out what's causing it from that.  Otherwise I'm not sure how much I can do - I haven't seen the problem myself and at this point I can't come up with a plausible explanation for how it would have happened.

Actually, I guess there are a couple of other things I would be curious to know too though.  First, how much traffic are we talking about?  A few kbps or maxing out your connection?  Were you running the client at the same time this happened?  And as it appears you are on Linux, did you download the updated -bin file?  Unfortunately I broke the updater in new and exciting ways last release so it won't properly update the coldest.bin file by itself.  I'm not positive what effect that might have, but I'm pretty sure it wouldn't be good. :)

Oh, and I should probably mention that the Coldest Test Server is something I set up on an Amazon EC2 instance.  It turns out they will give you a year of their smallest image free, so I figured I would take advantage of it to set up a test server.  We'll see how it works as I think it will be a bit constrained on memory and CPU, but it's still a good bit faster than the server the site is hosted on and there isn't a "no game servers" clause in their AUP.

I was trying to run the binaries directly that time (having copied the static libs into the same directory), but I've tried it again with the scripts now, and I can confirm the same thing happens (finds the libs correctly, but still the connection spam). I was NOT running the client at the same time, or anything else for that matter, not even a browser.

I receive a pretty constant 684 bytes per second, with occasional spikes to ~1.7 kbytes and reductions to 300 kbytes. Starting another server doubles those numbers. However, I did find that typing quit, in the terminal running the server, exits properly (no more connection spam). It seems only CTRL+C or closing the terminal while the server is running causes the problem.

Wireshark seems to be missing a WireTap library ... or I'm thinking misplaced.

Hmm, I have absolutely no idea what would be causing it then.  It turns out that it couldn't be the master server because that never sends anything to servers, only to clients.  Based on the amount of traffic my guess would be the announce packets, but you shouldn't be getting any incoming traffic from that.  That would also cease as soon as the server stops regardless of how it stops.  Since I'm not seeing any incoming traffic when I run a server and I can't come up with a reason for it to be there I don't think I'm going to be able to fix this without seeing the traffic. :-\

Then, I'll try to find a way to get Wireshark to work, maybe even a pre-compiled one. That or something similar.  :-\

Then, in the mean time, you have no way to test the "improper server exit" I mentioned?  ???

Well, the thing is that there shouldn't be any difference.  In both cases the same code gets run to shut things down.  The one exception might be closing the terminal window because that can kill the process with extreme prejudice and might not let it run cleanup code, but just ctrl-c shouldn't be a problem.  Until I can see what the traffic is I'm pretty much in the dark as to why it behaves differently.

OMFG! I can't believe it! It turns out that it has NOTHING to do with the server!  :-[ :-X It's the client, and it always was. I just didn't realize I ran the client at least once each time (I ran it so many times to try to figure things out, I could have sworn I didn't run the client!). The client does not exit properly when you click "Exit". It seems recent, as I never remember the client doing this in the prior versions (my memory may still be faulty though to due exhaustion... be warned  :o ).

The files I captured with Wireshark are here: http://www.multiupload.com/H9DPUE8ZVX

Ah, now that makes more sense.  It was the master server sending the traffic (and don't worry, it will time out and stop sending eventually but it will take around 40 minutes by my calculations), but the bug was in the client.  It was ignoring the ack packet so it kept sending version requests and the master server kept responding.  Then when the client exited, the master server still had the last request and continued trying to respond to it.  I've pushed a fix to the Git repo and I'll get a fixed build out to the update server too.

Thanks for your help with this. :)

Out of curiosity, what kind of fix was it? Because I just checked another version out from the Git repo and it still does it. Maybe the update is overwriting the source fix for now?

Shouldn't be.  The version on the update server includes the fix so even if it's overwriting your source version that shouldn't be causing problems.  I just checked and I'm not seeing any spurious traffic after closing the client so I don't think you should be seeing it either.  If you want to make sure the fix is in your copy of the source, you can look at the file ClientNetCode.cpp on line 347.  You should see this:
Pay particular attention to the packettype != "A" at the end as that was the fix for the original problem.

Now that's just plain annoying! A bug that just won't go away and makes no sense! I see that line and that particular ending in the code, but it still happens.

Maybe it's me doing something wrong, especially since you don't have the problem... Here are the particulars of what I'm doing:

1) After building the source, I chose NOT to install it, so I just copied the same directories as are in the Linux 64-bit (http://www.coldestgame.com/site/content/download) pre-built binary (Full Download), into a directory in my home directory.

2) I ran it for the first time using the binary available in the source, since I didn't realize "startscript" was the same as the "coldest" script that's downloaded in the update.

3) After updating for the first time, it automatically tries to restart, but fails to find the lib-boost and therefore ends (what the script is for).

4) I run it using ./coldest in the directory I made in my home directory.

5) I only run the game for less than 15 seconds, then exit using the regular Exit button in the Main Menu.

ALSO, I still see the problem with the Linux 64-bit (http://www.coldestgame.com/site/content/download) pre-built binary (Full Download). So it's not just from compiling the Source Code. Again, I run ./coldest in a directory in my home directory.

I would highly recommend not allowing source builds to update.  It's going to overwrite everything you compiled anyway, which kind of defeats the purpose.  You can either set checkupdates to 0 in autoexec.cfg, or create a file named version in the root of the source tree and put a big number in it (something like 9999).

As far as the problem, I haven't really had time to look into it much yet.  They broke ground on my house this week so I've been kind of busy. :)  If you wanted to take another Wireshark trace of the traffic that might help though.

I've been having trouble with wireshark since the time I provided the report. It even broke soon after, somehow. The wireshark site is pretty often on the fritz too. I was hoping I wouldn't have to use it again, but I had to use a hack just to install it right on 64-bit.

Wireshark Report: http://www.multiupload.com/FNBBJNAAUN

Okay, I finally made time to look at this and it was indeed still a problem.  Unfortunately this one didn't show up if you had updates disabled in the console like I usually do, so that was why I wasn't seeing it.  I pushed a new revision into the Git repo that should fix this problem.