unserializable

Antivirus-companies have whitelisting programs for removing false positives. For Norton whitelisting request can be made at https://submit.symantec.com/whitelist/isv/ From what I have heard, unless some special procedure is gone through (probably with digital signatures), whitelisting will only apply to one specific version (installer, exe, etc) and for subsequent versions whitelisting needs to be done again (on Norton's whitelisting page it also says: 'If your file/software changes or updates then you will need to re-submit the request for your updated software.') Someone with windows version could upload 0 A.D. binaries (executable files) to https://www.virustotal.com/en/ and see how many tools report them as positive for viruses.

The failing assertion is when finding the minimum size of large memory page on your system (wcpu.cpp:121, higlighted). if(pGetLargePageMinimum){ largePageSize = pGetLargePageMinimum(); ENSURE(largePageSize != 0); // IA-32 and AMD64 definitely support large pages ENSURE(largePageSize > os_cpu_PageSize());}According to MSDN doc of 'GetLargePageMinimum':If the processor does not support large pages, the return value is zero. Apparently on your system zero is returned. Your computer has Xeon processors that does not fit under IA-32 and AMD64 mentioned in the assertion comment, so this could be an issue. What OS are you using anyway? Edit: And on http://msdn.microsoft.com/en-us/library/windows/desktop/aa366720%28v=vs.85%29.aspx it is written that WOW64 on Intel Itanium-based systems does not support 32-bit applications that use this feature. The applications should be recompiled as native 64-bit applications.So it seems this codepath should not make this assertion in 32 bit compiled binary that runs on 64 bit system.

If alpha 16 manages to speed up the game lag considerably, especially with pathfinder (that obviously uses square roots), 'Pythagoras', or 'Pythagorean' could be a very fitting name

You took instructions bit too directly -- '/PATH/TO/pyrogenesis' should be ACTUAL path to 'pyrogenesis' binary on your system. Like '/usr/games/0ad/pyrogenesis' -- or wherever it's located.

My gloox is the same libgloox.so.8 you mention: x@y:/bleh/blah/$ ldd pyrogenesis | grep glooxlibgloox.so.8 => /usr/lib/libgloox.so.8 (0xb7032000)I am using self-built 0 A.D. alpha 15 (from official a15 src package) on a 32-bit Debian based Linux system. Lobby seems to work fine. 'apt-cache show' reports following about libgloox-dev package installed: Package: libgloox-devSource: glooxVersion: 1.0-1.1Installed-Size: 3176Maintainer: Jose Carlos Garcia Sogo <jsogo@debian.org>Architecture: i386Depends: libgloox8 (= 1.0-1.1), libgnutls-dev, libidn11-devDescription: C++ jabber/xmpp library devel filesDescription-md5: d53f3d80607744e5e7183ee034c7c8f8Tag: devel::library, role::devel-libSection: libdevelPriority: optionalFilename: pool/main/g/gloox/libgloox-dev_1.0-1.1_i386.debSize: 803940MD5sum: 63df00a1f5eded16b47f21464ab26f6bSHA1: af7e5812398be2c7dafef0d5d7bd693735aa3f3bSHA256: 310c6822792102d732eb9c43ba8689a3496c21f2fc4a6dd14ff047a652bc6c9

Unfortunately crashlog.txt does not contain a call stack. Did you compile 0 A.D. from source yourself? SVN revision reported in your crashlog.txt is '14385' (in my self-compiler alpha-15 SVN revision is 14386-release) and crashlog.dmp refers to SVN folders 'd:\0ad\svn\binaries\system\pyrogenesis.pdb' and 'C:\0ad\svn\binaries\system\glooxwrapper.pdb'? If you compiled 0 A.D. yourself and debugging symbols were enabled, you might be able understand where the game crashes by recovering the crash call stack from 'crashlog.dmp' with WinDbg or Visual Studio -- read http://trac.wildfiregames.com/wiki/Debugging about general instructions on how to do that.

*I* want many things that are no concern of yours. Please, refrain from bringing up what *I* want and read what the crash handler tells you when the game stops. You say your computer has 4 GB of memory. That is 4 billion bytes. Assuming you are running 32 bit operating system with 32 bit pointers, this means that there rougly 1 billion reasons (memory pointers) that could cause 0 A.D. to try to read from the forbidden location 0x00000008 that is reported in crash handler. For anyone to be able to figure out why the crash actually happens, crash handler tells you that you should report error on TRAC and attach error logs, namely 'crashlog.txt' and one other file. You opted to ask help on forums, which is fine, but you still need to supply the relevant information. There exists similar topic at: http://www.wildfiregames.com/forum/index.php?showtopic=15467 where historic_bruno has explained this in some detail, also providing exact location of log files on Windows systems, + @niektb link has same information and more.

@Gazourmah You have given no details about your system at all. What is in 'crashlog.txt' that is referred to from the crash handler? A15 did not crash for me on the first run, but my setup is not most typical.