Ykkrosh

Fixed. (Will update the autobuild tomorrow.)

It should be possible, but not trivial. There is a trivial way to antialias OpenGL lines but it often has absurdly terrible performance so we can't use that. What we probably need is the circle shape in a texture underneath the unit (fitted to the terrain appropriately), which'll allow more control over the rendering. If this is the behaviour we want, I can add a task to Trac and hope somebody (not me) implements it soon. The thickness of the circle is increased (if you compiled from SVN), like in the image I linked - do you mean it should be increased more, or do you not see the thickness at all? (I guess it's possible some old OpenGL drivers might not support it.)

Added a .desktop file now. Sure. I think what I'll probably do for now is leave Ubuntu for the PlayDeb people so I don't have to worry about it myself. If that turns out to be a problem (if we need more flexibility or promptness etc) then I'll look into PPAs, but this all seems to take a load of time and effort (particularly since I'm starting with no knowledge) so I'll put that off as long as possible.

I changed the colour of selection circles to match the player colour (instead of always being white) and also changed them to 2 pixels wide, like this, in an attempt to make them easier to see and easier to distinguish from other players' units. I don't know whether this is the best design - do people have experience/examples/opinions of what would look good and help players the most?

That's crashing somewhere inside the driver code so it looks like it probably is a driver problem. (The code in FixedFunctionModelRenderer.cpp works fine on other systems so it seems less likely to be an error in our engine code). I'm afraid I have no idea how to go about debugging that kind of problem

(Fixed the test error now.) Can you run the game in a debugger to see where it's failing? (Run "gdb ./pyrogenesis_dbg" then "r" then wait until it fails, then switch back to the gdb window and do "bt full".)

libraries/devil/ is only used on Windows. On Linux you need to use some distro-specific method to install DevIL into the system (it might be a package called libdevil-dev perhaps).

You need to run "make clean" before recompiling. (It gets confused by outdated dependency information.)

#516 was fixed, so there's now a smoothing tool. Does that do what you wanted?

Looks like it currently uses about 200KB plus around 2KB per unit at the start of a game, and it was configured with a 4MB heap size. Since we didn't have decay in that match, it's possible the corpses were just too much for it. Should be better with decay, and I've changed it to 8MB and added a dumpHeaps() function (in the console) (only in debug-mode builds) which may help debug any future problems.

That version is the latest release but it's about three weeks old. We'll do a new release some time soon, which will include the more recent fixes (that are currently only visible if you compile it yourself from SVN).

Hijacking this topic for more conclusions from multiplayer testing: * Need to work out why the A* part in that profile log is so much larger than the times I get. * Need to profile and understand JS memory usage, since in long games it can run out and then it becomes very unhappy. * Need to cope better with >200msec latency. * Need to fix pathfinding through dense groups of buildings. * Need to fix receiving orders relating to now-nonexistent entities. * Need decay of corpses and projectiles. * Need in-game chat. (Also it should be logged, so we can refer back after testing (even if the game crashes).) * Data-file verification would be good, to report mismatches helpfully rather than throwing an immediate OOS. * Trees should probably have more wood, else they get used up very quickly. * Female citizens should sound less manly when they die. * Selected units should be highlighted on the minimap.

APE is a particle engine. It's probably obsolete and useless now. Skeletons are defined in this file. <standard_skeleton>s give the skeleton structures which the game understands; <skeleton>s define a mapping from a 3D modelling program's skeleton structure and naming conventions onto the standard skeletons. ColourTester was for textures where parts get displayed in different colours for different players - it just shows what the recolouring looks like. I don't know how useful it is - it's probably better to just use the Actor Viewer mode in Atlas to see what the textures look like. Entities are now in mods/public/simulation/templates/

Yes.

You can follow our news feed and we'll announce an alpha release some time fairly soon, which will have these improvements (and more!) We're trying to make the game historically accurate in many ways, but not realistic - it's a game rather than a simulation . Regrowing trees might be useful if we want players to have more resources available late in the game, but I don't know if that's a good thing. It's probably good to have limited resources so matches can't go on forever, and it forces players to spread out and become more vulnerable when they are searching for the last resources on the map and discourages turtling.There's no enemy AI, so your opponents won't do anything at all. It's a complex feature and we haven't started working on it yet. Yeah, the current unit movement code assumes that all moving units are sort of round, so that it never has to care about what direction they're facing. We'll probably need a completely new movement implementation (i.e. replace UnitMotion) for ships, to take account of turning radius and acceleration and size, if we want it to be non-rubbish.

There's a big difference between C++ and Java, because Java is not incredibly hard to parse . With C++ you have #includes that can't be resolved unless you know exactly where the build system is going to tell the compiler to look for headers, conditional compilation (should you auto-complete debug-mode-only code? what if the disabled code has syntax errors?), types and variables defined by complex nested macros, templates where you can't determine data types until you've parsed all instantiations, syntax that is ambiguous unless you resolve data types, etc. And you can't use existing compilers like GCC to parse the code, since they're designed solely for compiling and don't expose the information an IDE would need. Eclipse is great with Java since the language avoids most of those problems, but quite poor at C++.(I've been playing a bit with Clang, which is basically a new C++ compiler that's designed (among other goals) to work much better for the kind of things that IDEs need, as well as being a proper production-quality compiler (it works well enough to compile 0 A.D. now), so hopefully that could lead to interesting things in the future.) (But now a lot of the code I write is JavaScript, which is even harder for an IDE to handle since you often can't even tell the type of a variable until you actually run the code )

I'm planning to fix that later today There's a patch for that, it just needs some fixes before being applied. They do that, since a few weeks ago (after the latest release). I don't think that's been part of our design. Why do you suggest that? Brian has worked on implementing fishing, so hopefully that'll be there soon. There aren't villagers, there's just citizen soldiers (most infantry units, trained in lots of places) and female citizens (trained in houses). You can't (yet).

I think VS2010 will work iff we upgrade Boost. Eclipse CDT can integrate with GCC Makefiles which we use on Linux, so that can work, but we don't compile in GCC on Windows so you need VC++ instead. (I use Eclipse as an editor on Linux, but compile and debug on the command-line instead of in the IDE.)

On Windows you have to use Visual C++ to compile the code (the free Express version works fine, as long as it's 2008). (I don't think there's any easy way to integrate its compiler into a different IDE, and that'd be needlessly complex anyway.)

There's no automatic way to download maps (though it's something we'd like to support in the future) - you just have to upload/download/install manually. There isn't any good way to find players yet, but you could try joining the IRC channel and see if anybody is there and willing to help test.

Looks like you have wxWidgets 2.6, which is very old - you need to upgrade to version 2.8. (There's a lot more compile errors than just that wxString one when using 2.6.)

You probably need to run "make clean" and then "make" again. (It sometimes forgets to recompile changed header files.)

I would expect so, since that would make them slightly less useless . (We'll probably need some new system for constructing walls - you won't just place each segment individually - so it'll take a bit of effort to get it all working properly. Currently the wall meshes seem to be centered around one of their ends, so we can't easily make them block movement properly with the current engine code (which assumes meshes are symmetric around their centers).)

Hmm, I get a runtime error on Fedora 13: "ERROR: dlopen error: /usr/lib/libAtlasUI_dbg.so: symbol _ZN7wxSound6CreateERK8wxStringb, version WXU_2.8 not defined in file libwx_gtk2u_adv-2.8.so.0 with link time reference" That symbol is defined in that file, but I don't know anything about linker versions. The build server builds with wxGTK-2.8.10-9.fc13; Fedora currently runs wxGTK-2.8.11-1.fc13. Looking at this and this, it sounds like a versioning problem and rebuilding with the correct version should maybe fix it. I've no idea how to try doing that, though. (In a perfect world I guess ABI compatibility would actually work and we wouldn't have to worry about this, but that doesn't help really help us in practice...)

It's not particularly important, but the build service supports it so if it only takes a few minutes to fix then we might as well - there's probably still quite a few users on the older versions. (In fact my machine at work is still running Fedora 7...)