TnA: Try opening the case and look closer. Sometimes files hide in the cooling fins of the CPU heatsink or between memory modules.
No, seriously, what EXACTLY did you do?
Swampy: That only gives a tiny bit of new information (the CriticalSection thing), and without knowing the Debuggy program, I don't know what to make of it, sorry. I also tried using your configuration; apart from the welcome message not being set correctly (which just had the effect that there was no MOTD) and the Language settings on English (should be British English/American English) which is caught and corrected, there seemed to be no problems with the versions I tried.
I'm currently building a release with debug symbols, but before you try that: could you send a debug recording of the server crash? The configuration documentation describes how. Then, we'll at least have a better idea at what point the program crashed.
So far, I'm suspecting that something goes wrong in the network interface setup. That's the only thing I know that is affected by something outside of the configuration files (but the config files, too).
I checked the SF docs; files for the file release system you upload to
ftp://upload.sf.net into the incoming directory stay there at least 24 hours and at most 48 hours. So here's how I imagine things going from here (forgot to say so in the first post...): The builders grab the soruces (tarball or CVS tag), build, name their files armagetronad-(dedicated-)0.2.8_beta1.something and upload them to
ftp://upload.sf.net/incoming.
If in doubt, choose Luke's aabeta naming rules which I quote here with irrelevant parts snipped:
The Holy Standard of Luke wrote:Filenames should be of the form
Product-Version[-rPkgRev].PkgType.OS.Arch_Bits.PkgFmt
Where:
Product -- Software product: armagetronad or armagetronad-dedicated
Version -- Full version: 0.2.8_beta1
PkgRev -- Package revision; omit for zeroth
OS -- Operating system identifier: redhat, gnulinux, windows, etc
Arch -- System architecture: x86, ppc, sparc, etc
Bits -- System architecture bitness: 16, 32, 64, 128, etc
PkgFmt -- Package format: rpm, deb, exe, zip, etc
Of course, redundant information can be omitted. if the OS is msdos, Arch is automatically x86 and Bits 16
win32 can be an abreviation for windows.x86.32.
Then, the builders either add the files to the 0.2.8_beta1 releases themselves in the
File Release System (don't forget to set the correct type, and don't mark the release as active and don't send notifications just yet), or inform me here and I'll do the adding.
