janwas

Thanks for reporting it, that problem has been mentioned (and hopefully fixed) in post #18. I still need to test the proposed workaround on Win32 though, after which we can commit. Thumbs-up for posting a bug report OK, I have no experience with YASM, and would propose sticking with (possibly older versions of) NASM until this issue is fixed unless someone comes up with a good reason to switch to YASM. Unfortunately I can't help here, am a Windows developer and have little experience with wxW and the GCC toolchain. Hopefully Philip will have an idea soon

Sorry, but that message gives more hope than it should. While people are welcome to try it out, the game just won't run adequately on gfx cards without S3TC compression, multitexturing and certain other extensions. I'd say at least GF3-class graphics cards are needed. Good question in general (and the game will tell you via binaries\logs\system_info.txt), but in this case even newer drivers won't help because this chipset isn't really up to the task.

I too am using VC2005 Pro at home. The first raft of errors is due to dbghelp definitions not being found, but the cause is unclear. PSYMBOL_INFOW requires dbghelp 5.1. Unfortunately you apparently can't tell the installed version from the header. If it helps, my Microsoft Visual Studio 8\VC\PlatformSDK\Lib\DbgHelp.Lib is dated 2006-06-22. Have you installed the Platform SDK and not inadvertently disabled/deleted anything? If so, additionally installing the Debugging Tools for Windows (of which dbghelp is a part) would probably solve this problem. The many other missing headers make it sound like you're using VC2005 Express. Here's mention of the rpcerr/mac headers and a workaround: http://channel9.msdn.com/forums/TechOff/13...e-Platform-SDK/ If that works, it'd be appreciated if you could add these steps to the Build Instructions wiki page.

Aken and Mahaf are somewhat fitting (see http://www.touregypt.net/godsofegypt/mahaf.htm) names for a kernel-mode service and user-mode library that calls it to action. They are used for mapping physical memory and port I/O, which are required for ACPI table access and proper high-resolution timing due to various bugs in chipsets and Windows XP. If disabled, the timer falls back to the usual Windows API routines, which are prone to problems (see http://www.gamedev.net/community/forums/to...opic_id=451305; the PDF referenced therein is now located at http://algo2.iti.uni-karlsruhe.de/wassenberg/timer_test.zip). The driver isn't signed because I don't have the means of doing so; if you are able or know someone who can, help would be very much appreciated.

My bad. A somewhat complicated memory allocation data structure's invariant is apparently being violated. This has also been reported in another thread. Are you running 64-bit Linux?

Oh yes, thanks, we'll fix those. Unfortunately I am really busy ATM (just got back from a business trip) but may manage during the next few days. Further to what Philip has said, there is an (admittedly inconvienent) workaround, namely updating the individual top-level directories and skipping binaries\system. Ooh, that is very bad indeed, it's a warning that a somewhat complicated memory-allocation data structure's invariant has been violated. I hope to be able to investigate this at work soon, too. Thanks heh, going by previous experience on such issues, it probably would on the first try (unfortunately GCC and VC apparently differ in this area). I'd be happy to test the patch, but my home repo has more of those incorrect checksums throughout the tree, and it'll take a while to re-download the affected portions. Have sent it to my work address as well, maybe someone will beat me to it. Exactly. It'd be fairly simple for me to add a local precompiled.cpp to the other shared project that uses this code, after which it'd be OK to delete source/lib/precompiled (note lib vs lowlevel, the former is the directory name and the latter is the project name). Ugh, that's bad news. Would you recommend switching to yasm entirely? I thought that YASM was newer and therefore prone to more bugs. Are there any other compelling reasons? Thanks to the both of you for posting your issues and information, hopefully we'll get all of this fixed soonish

Thanks for reporting the problem, it appears to be the same as above. Excellent, it looks like we've found the culprit, then. You can work around it for now by commenting out everything but the contents of the %ifdef OS_LINUX block in amd64_abi.inc (a proper fix follows). @olsner: could you please add "-dOS_LINUX=1 "; to Premake's GCC command line? (amd64_abi.inc relies on that being set, else it uses Win64's calling convention, thus causing CAS to misinterpret its arguments and segfault).

Great, thanks very much! Just in case someone runs into the same problem: my TortoiseSVN reported a checksum mismatch in build/premake and build/workspaces. I'm not sure as to the cause (possibly corruption of my local disk), but it can be fixed by deleting those directories and restoring them via SVN update. hm, that looks fairly harmless (probably similar to the FCollada problem about int/long int being distinct types or not). Either way, the self-test is independent of the main executable. Thanks for doing a backtrace! Since the same asm code works on Win64 with the exception of register renaming to match the platform's convention, I'd suspect that is where the problem is. It looks like our idea of the registers is correct (c.f. http://en.wikipedia.org/wiki/X86_calling_c...ABI_convention). Could you please add an %error statement to the %else block in source\lib\sysdep\arch\amd64\amd64_abi.inc and rebuild? This will verify that we're using the right set of registers - if not, OS_LINUX isn't being defined on the NASM command line.

Yes, details are given in the Getting Started guide, which is referenced from the open-source page mentioned above. Thanks

Good to hear that the ia32 problem is gone after forcing arch=amd64. Yes indeed, that's strange. Did you run the same update-workspaces script initially and after changing the premake script to force arch=amd64? It'd be great if you could add some error("text") statements to the various branches of the if/else statements in premake.lua:20 to understand if it's getting there at all and whether OS == "windows" or HOSTTYPE != x86_64 (hopefully your environment variable doesn't have it in quotes). First of all, can you please ensure you have NASM >= 0.99.0? Running nasm -v will indicate the version, and nasm -hf indicates what formats are supported, which should hopefully include elf64. We apparently need to pass -f elf64 instead of -f elf to NASM for 64-bit builds. This is done by premake in build/premake/src/Src/gnu_cpp.c:520 . As a quick fix, you could just change elf to elf64, but to properly support 32 and 64 bit builds we'd need to upgrade to premake 4.1 (see http://industriousone.com/platforms-0). Would you be interested in such an undertaking?

hm, the intent is to exclude ia32.cpp from 64-bit builds. Since it remains included, Philip is right about the root cause of the problem. Our premake script checks a HOSTTYPE environment variable - is that not set on your system or doesn't it equal x86_64? Unfortunately I don't know about GCC compiler switches for 32 vs. 64-bit, but at least the ia32.cpp problem is something that we'll easily be able to fix or work around.

heh, this may be the first time I'm grateful to a spammer That's right. We have a basic A* pathfinder and a much more advanced TRA* (triangulated A*) system, but the latter is currently in limbo because it depends on a library for constrained Delaunay triangulation that's incompatible with our open-source license. Pathfinding being really important for RTS games, it sure could use some more work. One worthwhile undertaking would be a multilevel scheme that subdivides large maps into sectors (it doesn't make sense to perform long-distance searches at the full resolution). PM sent!

I'm not sure about the inflation either, but what irks me is the attempt to hide the fact that the taxpayer is paying for all of this. Printing more money or the other Republican suggestion (tax breaks) - both are disingenuous, the latter hiding behind a higher deficit and long-term debt. Amen! Bailing out the greedy crooks that lied to their risk-management systems isn't fair, and worse, won't exactly discourage future shenanigans. For the "self-interest" prerequisite of capitalism to work, there has to be some disincentive for risk and failure like this. As others have noted, this doesn't sound like (even regulated) capitalism anymore. Instead, FDR had it right: You may be right about them eventually going broke, but it's interesting that so much effort is going towards papering things over. Sounds to me like someone knows that the entire financial system is a house of cards and that they have to try to intervene.

"Multi-levelling" is not possible because the terrain is representated via heightmap. With exactly one height value per tile corner, the terrain is "2.5D". Something like Starcraft's Nydus canals / C&C's attack holes would still be possible but aren't planned for.

That's still an open question, our capability to do so is fairly limited (we only have a few developers using Linux). It's possible that the alpha release would be in source-code form and require compilation.

Good news: the game currently runs on 64-bit Linux, but the Win32 environment is our main development platform and sees more testing. It is also possible to choose an arbitrary resolution via config file; we'll see whether the in-game options menu will be operational before going alpha.

Thanks for reporting this Matei has contacted the video game trading site in question and they've removed it. I do wonder who would try to trade a (probably old and incomplete) 0ad build for a few bucks when the whole thing will be available for free - pretty soon, too. Oh well.

This is just a warning - the VFS is indicating that it's being told to load a zero-length file, which is at least questionable. When did it happen? I bet that creating an output file failed, resulting in an empty file; the ensuing load generates this warning. However it's definitely possible that zero-length files can happen, so I've changed the code to safely handle this without complaint. heh. Yeah, that's rather silly and part of the reason Philip wanted it banished to the very end of the crashlog. I've changed the message to "OSError = 0 (no error code was set)".

Seems to be fixed now, I can log in and see several other 0ad guys (e.g. Erik, Matt). [am using Miranda 0.7.2.0 with msn.dll version 0.7.1.3]

In response to Michael's suggestion, Erik has posted a solution in the staff forum. Here's the relevant steps to take: Cheers!

Welcome Thanks for the warm words. Hard question. Here's a developer's perspective: When designing and coding a console game, you usually have much more limited resources (most of all: memory). There are also requirements from the platform owner prescribing all sorts of hard limits, e.g. maximum load time. Finally, the hardware is often a bit wacky (see PS1, or the decidedly non-SMP configuration of PS3). PCs have fewer such constraints and problems. Then again, with a (single-platform) console title you do not need to worry about different graphics card capabilities and so on. Counterbalance that against the inconvenience of needing a Devkit to test the build. As you can see, there's no clear answer - everything is tradeoff.

heh. Well, we have thought of using TeamSpeak/Skype - we might get to the point of recognizing everyone's voice I believe Matei also met up with Jason some time ago.

Nice Unfortunately I was sick, so there was no Halloween here. Looks like the dorm party was fairly nice, though http://galerie.nice-pic.de/thumbnails.php?album=7

heh. By that reasoning, we don't need or want to be open because one gaping security flaw is already apparent: the client has to be trusted, where the military definition of "trusted" applies (viz. someone can screw the pooch). On the one hand, we have the lockstep simulation model (used by most RTSes) requiring all clients to know everything, and on the other hand we have the client hiding information from the player to prevent them from gaining a gameplay advantage. Obviously this can't be secure because the player can influence or even control the client. If people manage to make the source code release network-compatible with the secured version, thus exposing all honest players to rampant cheating, may shame be heaped upon them. Consider the secure version to be an extra effort - a bonus - to increase the chance of 'clean' online play for everyone using it. Of course people can do with the source code what they wish, but we'd be very disappointed if they were to take advantage of the source code availability to cause harm to the community. I don't believe we have a final word on that yet. While we had planned ahead on the source code side and all signed off on an agreement that grants WFG certain rights, I don't think that's been done on the art side. In the worst case, every contributor would have to be contacted and convinced, which may be difficult. Cheers! Jan

Hello and thanks for your interest! The programmers are sympathetic to open source and are indeed wanting to open the code. However, that can't happen with the entire codebase for security reasons. We've come up with the following plan: releasing a open source playable/moddable version, and a separate, closed-source, slightly modified secure version for online play. That is indeed our goal We have valued community involvement from the start. The main thing holding up an early release/beta program is that we've been wanting to improve the netcode first (moving from sockets to ENet to allow NAT punchthrough and fixing desync issues). This has gotten off to a slow start, but we'll get there. Cheers!