Ykkrosh

I think most graphics drivers come with control panels that let you set global AA/AF options to apply to all games or to specific games, so there isn't really a need for each game to duplicate those controls itself. It's probably still nicer to let the player select the options from within the game but it's not really necessary. Yeah, the only fragment shader is for water and everything else is per-vertex lighting with diffuse texturing (plus player-colour modulation, and shadows) and that's about it. The current renderer code has some flexibility to support more shader effects, but I don't know whether that really works or how easy it would be to utilise.(Maybe in the long term it'd actually be better to use an existing fully-featured well-maintained graphics engine instead of extending our own - our engine is fairly modular so it probably wouldn't be infeasible to replace the renderer (keeping the current code for actors etc), though it would still be a lot of painstaking work to sort out all the details.)

See binaries/data/config/default.cfg for some graphics options - create local.cfg and try changing fancywater=false (to avoid fragment shaders), renderpath=fixed (to avoid vertex shaders), shadows=false, maybe novbo=true, etc, and see whether any of the options make it run better.

I expect there won't be an automatic tool for creating new civs, since it would be used too rarely to be worthwhile, but all the civs are just controlled by XML files and can be edited with nothing more than a text editor. The game engine code doesn't have a fixed list of civs so there's no restriction on adding new ones. (It won't be easy, but that's because civs require lots of data and lots of art content - it will at least be possible and hopefully we'll avoid artificial barriers as much as possible.)

The logic looks sensible to me For serious errors, use debug_warn(L"Unable to set LC_ALL env variable"); - that currently prints to stdout, but in the future we'll have to make it do a GUI dialog box (for people who don't run from a terminal), so that's the best thing to use for unexpected errors that the user needs to be told about. For warnings, use LOGWARNING (which writes to stdout and the log file and the in-game console). For constructing a complex message, it might be easiest to use a std::stringstream in place of std::cout and then do a single LOGWARNING(L"%hs", stream.str().c_str()). Instead of computing SZ, use ARRAY_SIZE(LocaleEnvVars). We don't use threads much (I can only remember the one for file monitoring) and we can do this locale check before starting any of them, so that'll be fine.

Applied fix now (seems to work for me but let me know if it causes any problems) - thanks

The Ubuntu package comes from PlayDeb, who are currently down (since over a week ago) but should be back within a day or two.

When I first joined this project it was already quite daunting - there's a huge amount of things interacting in lots of complex ways, and there's never enough documentation to get a good high-level view of everything. And it's grown quite a lot since I first joined, though I think it's also somewhat cleaner and better documented and better tested now. A few random thoughts: * A good IDE helps - I really like Visual Assist X since it makes it easy to navigate code (jumping to definitions, seeing expansions in tooltips, using autocomplete to find available methods, etc) and it seems fast and reliable even when the code is doing pretty complex things. (Then I moved to Linux and now use Eclipse and ack, which is nowhere near as nice for this.) * Don't assume that all the code is well designed or well implemented - some is overly complex, some is obsolete or redundant, some is buggy, etc. Everything was done for a reason, but it may not have been a good reason or it may not be applicable today. So don't be fazed by seemingly crazy code - see if anyone can explain it, but then you might just have to accept it and ignore the problems (or, ideally (with sufficient time and confidence), fix it ) * I like tests - if you're not quite sure how a piece of code works, sometimes it's good to write test cases for it, since that lets you run the code in isolation without the rest of the game engine interfering. (Also it helps find bugs and prevent regressions, which is always good). So the test writing process is probably a useful thing to learn. * Most of the engine isn't doing anything very novel, so you can probably find similarities with other libraries or with published articles which give a better high-level description of the underlying concepts - that's easier than trying to reverse-engineer the intended behaviour from the code. * The engine is largely complete (though far from being finished), so there aren't many easy standalone tasks (they've mostly been done already) and most work will involve interacting with big chunks of code that are already there. So it's not going to be easy to dive in - I think it needs a lot of patience, and a desire to learn about everything (from low-level C++ details to high-level architectural designs), if you want to understand it deeply and do significant chunks of work on it. * It's only ~200K lines of code (and half of those are comments or whitespace), so it's not really that large for a game or for an open source project . It's a big step up from a single-developer hobby project, but it isn't an unfathomable monstrosity (it's not OpenOffice or GCC; it's not even Doxygen) so you shouldn't be put off unduly Trac has lots of information, though be careful that some of it is inaccurate or obsolete. E.g. the new simulation system (which I've been rewriting recently) has some high-level documentation that's still reasonably accurate; the old entity XML documentation is all wrong now. The GUI documentation covers the early design which is still mostly followed but there's been various extensions and changes. The graphics code has never been documented much. I don't think the networking code has ever been documented. Other parts of the code are in various states of documentedness. I guess it's good to scan through most of Trac to at least see roughly what's there, and then ask (on IRC or forum etc) for pointers on anything else.

Hmm. That DLL works for me (on the computer I compiled it on), and the Release mode one was compiled at the same time. I guess the significant difference is the CRT DLL it uses, and maybe for some reason it's not picking up the msvcr80d.dll that it needs, perhaps because of the evil SxS/manifest thing. Still not sure how to understand what the problem really is or fix it, though.

Lots of things change, which makes it hard to work out what is breaking it . Maybe you could try changing build/premake/extern_libs.lua to use "FCollada" where it currently uses "FColladaD" (then run update-workspaces and rebuild), to see if it's happier when it's not trying to use FColladaD.dll?

Models are cached in a custom binary format after they've first been loaded from the Collada source files, which is why they're still visible when you go back to a Debug build. You have to delete the %appdata%\0ad\cache folder (I think) to force it to reconvert. In binaries\system\, could you try copying AtlasUI.dll.2.config to FColladaD.dll.2.config and see if that makes any difference? (The log indicates Windows is looking for that file.)

See #482 for a tiny bit of information. I think build/premake/src/Src/vs.c is probably the relevant file (look for "cxxtest" and try to work out what it's outputting into the .vcproj files and what it should output instead). (Use the Premake.sln to compile; I think you then have to manually copy premake/src/bin/premake.exe into premake/ to use it.)

Hmm, odd that that actually loads it first... One possible idea for debugging: Try running Process Monitor to log all file accesses, and then see what it outputs during the game's call to LoadDLL. Maybe that'll indicate some unusual files it's missing (e.g. apparently Windows sometimes wants AtlasUI.dll.2.config because of the insanity of the SxS DLL system and compiler service packs; perhaps there's something similar here).

They ought to work - the test_gen project generates a load of test_*.cpp files, and the test project compiles them. What output do you get when building just the test_gen project? Edit: Oh, but if your SVN checkout is in a directory containing spaces then it won't work. The build page on the wiki warns about that . (Probably just a minor quoting error in the build system somewhere which ought not to be terribly hard to fix.)

The natural way of implementing capture would be that the building wouldn't change at all (it would just update an internal variable saying which player owns it). It probably wouldn't be too hard to implement changing civ-specific buildings to match their new civ, but it would take more effort than not doing so

It shouldn't actually have an open connection for a long time - the server's configured to require a single HTTP request per file, because the default bulk-update behaviour uses ~200MB RAM per checkout and the server dies if several people use it at once . It's also configured to reject requests (with a 503 response) if there's too many at once (to save Apache from using all the RAM) but I believe that shouldn't happen unless the traffic is much more extreme than it currently is. So I don't have any idea what causes it to abort early for some people, which is quite annoying. (If anybody happens to debug it by catching the failure in a packet monitor or something, or if anybody knows the secrets of running an SVN server more reliably, please let me know )

Oops, should be fixed now. (I expect ENet headers were defining that symbol.)

The cause of all the errors is the one that says which is triggered by dll.LoadDLL() failing in source\graphics\ColladaManager.cpp line 82. The question is why does it fail to load the DLL, but I don't know how to discover that.

They're largely at the stage of thinking that implementing formations would be a good idea. Now they just need to be fully designed and implemented

I'm definitely not a fan of Flash (I have plugins disabled entirely in my main browser since they make it a bit slow and unstable) and it's always been dissatisfying to have it on the web site, so replacing it with open standards is good . Probably not worthwhile when we're redesigning the site though, as Erik says.

Is that screenshot from a version of the game that you compiled yourself in Visual C++? It looks like it's failing to load the Collada_dbg.dll library, which should exist in the \binaries\system directory. Make sure the "Collada" project in VC++ has been compiled without any errors, and that Collada_dbg.dll exists. If it does exist, but it still fails to load, then I have no idea what the problem is . Someone else reported a similar problem over IRC, but I don't know the cause or how to debug it. The latest pre-alpha release ought to work very similarly to the current SVN version. I'm not sure how large SVN is (it depends on OS and filesystem and compression etc), but if you run the SVN "update" command in the top-level directory then it will detect and download any missing files.

Ah - binary heap is the standard English term . Actually it doesn't seem much faster in practice, compared to simply searching an unsorted array. The open list is typically quite small, so searches are not very expensive, and the array is much quicker for inserting and extracting and updating items than the heap. And the STL heap implementation in debug mode in Visual C++ is really really slow, so currently we just use the array instead. A better heap implementation or a different data structure (there was an article from (I think) Empire Earth suggesting an unsorted list plus a short fixed-length cache of smallest entries) would probably be a useful improvement.

You can check the code for the full details . It doesn't do anything very fancy - it's a simple A* over the tiles (with no diagonal adjacencies) using a Euclidean heuristic, with some adjustments in the cost function to prefer 30/45-degree lines. (Then there's a separate A* over the visibility graph of nearby obstacles, so that units aren't restricted to tiles). Not sure what you mean by "binary cells".

Yep, all you really need to do is find the right entity template file and delete the "ResourceGatherer" and "Builder" elements and then the unit won't be able to gather resources or build . More complex gameplay changes are likely to need modifications of the gameplay scripts, but the engine is designed to be flexible and makes that fairly easy.

One possible problem is that "d:\O AD" contains a space, and the build page says "Make sure it's in a path that does not contain any space characters". (By the way, it should be a zero rather than an "o".) I don't think that should cause this error, though. Does the "libraries\boost\" directory exist at all? You could try running the SVN update command to make sure it's finished downloading all the files.

You shouldn't need to access that - just use http://svn.wildfiregames.com/public/ps/trunk/ instead