Ykkrosh

Oops, yes - I'd checked that libxml-dev existed, but forgot to check whether the proper one had a different name. Fixed now - thanks!

Ah, right - it defaults to the Unicode version on mine so I never noticed that flag. I've modified build/premake/extern_libs.lua to do --unicode=yes - if you run update-workspaces again then hopefully it'll work it a bit better

Wait a minute, it really says "create a filed"? I guess I wasn't awake enough to notice that

Are you using a Unicode build of wxWidgets? e.g. if you run "wx-config --cppflags" it should hopefully say something like "-I/usr/lib/wx/include/gtk2-unicode-release-2.8 ...".If so, wxChar really ought to be equal to wchar_t, and I can't imagine why it would fail. (But if it's not Unicode then wxChar is char, and ideally you should get a Unicode version instead. It probably would be possible to make Atlas compile with non-Unicode wx, but that wouldn't be a very nice solution compared to just using Unicode.)

Nooooo! As default.cfg says: ; ************************************************************** ; * DO NOT EDIT THIS FILE if you want personal customisations: * ; * create a filed called "local.cfg" instead, and copy into * ; * it the lines from this file that you want to change. * ; ************************************************************** so put the xres, yres lines into a new file called local.cfg.

That's a bug, but as far as I'm aware it has no effect, so I've never cared enough to try fixing it . source/pch/lowlevel/precompiled.cpp is the correct one; I believe the other file exists because the 'lowlevel' directory is shared with some other projects and so it has a source/lowlevel/precompiled.cpp for use when the 'pch' directory isn't present. For 0 A.D. the easy fix is to just delete source/lowlevel/precompiled.cpp, but I think janwas still wants it there, so the less easy fix is to modify build/premake/premake.lua to somehow exclude that file from the list that will get built.

Hmm, I suppose the way I see it is that SVN is for development and should be optimised for that. For distribution, we'd probably want a system that extracts all the Windows binaries and data files and makes a nice installer package, and also extracts the source code and build system files to make something that can be compiled and packaged on Linux, and also extracts the data files you need to run it on Linux so they can be packaged separately. At the moment, I think we're very much in the development stage and it'd be premature to set up a packaging/distribution system. Yeah, it's a bit of a pain. The problem is that different versions of SpiderMonkey implement different versions of JS, and we want a consistent language to avoid problems where someone writes a script that works fine on their computer but fails (or works differently) on someone else's, so it needs to be a specific version. Also, several years ago some distributions only provided non-threadsafe SpiderMonkey builds, which won't work for our game - I don't know if that's still the case or if they're all threadsafe now. Also, at some point in the future we might need to tweak the SpiderMonkey code or compiler settings so that it gives precisely reproducible results between platforms, since our multiplayer system relies on all simulations being identical.So I think we do need a specific custom version, and can't rely on the system-provided one. (But installing the custom version it in /usr/{lib,include} seems a terrible idea - it ought to be going in a project-specific directory somewhere...)

I've updated the build instructions page to explicitly list libxml-dev now - hopefully that'll be enough to make it work.

Hmm, is it standard for Boost nowadays to have "libboost_filesystem-mt.so"? If so, I think the better solution is to modify build/premake/extern_libs.lua to say 'unix_names = { "boost_signals-mt", "boost_filesystem-mt" }' (around line 59). (Actually the better solution is probably to use a proper configuration script rather than hard-coding all the names into the Premake file, but I have no idea what would be a proper way of doing it.) http://trac.wildfiregames.com/wiki/Playing...raphicsSettings

Could you upload the list of those warnings to somewhere? They do seem dangerous, so it'd be good to fix them. It would be possible, but then Windows users would be unable to compile or play the game without a load of pain recompiling those libraries, unless we had two separate SVN URLs (one for Windows users, one for Linux/OSX users) but that seems a bit ugly and confusing, so it'd be easier to stick with what it does already, unless there are good reasons to change... Why do you want to not download those files?

Currently the game isn't really suitable for packaging for users - there isn't much of a playable game, and the code isn't particularly clean or stable or well-tested, and the idea is primarily to make it available for developers who can compile and debug it themselves. User-friendly packages would be very useful in the future, but for now it seems a bit premature

You shouldn't need to do "sudo make install" - it installs into local directories (not /usr/lib or anything that needs root access) so there's no need for 'sudo', and also it does the 'install' by default so just running "make" should be fine. The Makefile for FCollada is probably pretty rubbish - I just wrote the simplest thing that would work for me (FCollada's standard Scons-based build system was needlessly complex and didn't work so I wanted something easier). So I wouldn't mind if somebody who knows what they're doing rewrites it

Hmm, I think we've only really tested it with 32-bit Linux. (I don't have easy access to a 64-bit machine to test it on.) For the ia32 error, it looks like it's possibly detecting the architecture incorrectly - if you modify build/premake/premake.lua line 15 to say 'arch = "amd64"' then maybe it'll work better, or maybe it'll just fail differently. The fcollada errors look like the external library isn't 64-bit compatible (it assumes long unsigned int != uint64) - perhaps that could be solved by simply commenting out line 139 in FUStringBuilder.h, though I don't know whether that'll break anything else. The "recompile with -fPIC" error sounds easy to solve - I've made some changes so if you run 'svn up' and 'update-workspaces' then it should be better (hopefully). An alternative is to just do a 32-bit build - I'm not familiar with how this works, but it might just involve editing premake.lua around line 140 to add "-m32" into the list of buildoptions (and making sure you have 32-bit versions of all external libraries).

No - all the animations are pre-computed by the artists, so deaths don't have any real-time physics. It'd take quite a lot of effort to implement (partly on the programming side, and partly on the art side preparing all the models with detachable pieces and defining their collision shapes and chopping up buildings into flingable pieces and whatever), and the benefit isn't huge (it's just a fun graphical effect, not something fundamental to the game), and we have limited resources, so we haven't considered it worthwhile.

Um, just a glitch in the matrix. Nothing to worry about!

Yes. (Well, we don't actually have any exporter scripts - for models and animations we use Collada, with the standard exporter provided by whatever modelling program people use, and then automatically convert it to the in-game format. But we'll release all the code for our tools along with the engine code.) Currently we extract keyframes at 30fps, and then interpolate in the renderer. There's a tiny bit of GLSL, but mostly it's done without shaders. Just diffuse. We don't have that kind of interaction between units yet. But we do have a kind of reference point system for attaching props - each animation file contains prop points (that can be attached to bones), and the actor definition can attach other actors (weapons, heads, riders, etc) to prop points - and the idea is to use the same system for sticking people onto ships.

The real life economy is full of loans and debts and credit and interest rates and all that complicated stuff. WoW's economy just has pieces of gold, and there aren't so many complex ways it can fail.WoW proves we should go back to the gold standard. Ron Paul 2012! Uh, sorry, not sure what came over me there.

What kind of GeForce card? I used to run the game with a GF4, which worked fine, and a GF3 should be similar (though slower), but anything older is unlikely to work. Pentium 4 ought to be fine, though I've got no idea what kind of speed requirements we'll end up with.

Projectiles aren't just actors, since they affect the simulation (by hitting people); but they're not entities either - they're a special new class of thing. Since they're not entities, they don't have AI or pathfinding or anything like that, and they're just a simple move-forwards-under-gravity-until-hitting-something thing, and they avoid all the complexities of flying entities.

That's not the reason . There's nothing stopping you from charging for the software by itself: "Does the GPL allow me to sell copies of the program for money? Yes, the GPL allows everyone to do this. The right to sell copies is part of the definition of free software. ... Does the GPL allow me to charge a fee for downloading the program from my site? Yes. You can charge any fee you wish for distributing a copy of the program."But there is the requirement that when you distribute a copy to someone, they have the right to distribute it to anyone else free of charge. You could make a special version of Linux and sell it for $10,000 via your web site, and that's fine; but once one person has bought it, they could upload it to their own web site and make it available for free, so you're only going to sell one copy.

The ever-reliable Wikipedia says "a 1993 analysis of 118 hominid crania concluded that the cranial capacity of H.s. neandertal averaged 1412cc while that of fossil modern H.s. sapiens averaged 1487cc". It also says the brain of a sperm whale is on average 8kg, so I'm not sure it's directly correlated with intelligence Humans didn't even have agriculture until ten thousand years ago, yet now we have digital watches. That's far too short a time period for evolution to have had any significant effect on intelligence - the important factors are knowledge, education, technology, society, infrastructure, etc, not raw intelligence. A modern human living in the wild with no knowledge of civilisation would be as primitive as one living ten thousand years ago, since we're no cleverer than they were back then.

I believe the current plan is for any birds to just be non-interactive eye-candy - they won't pathfind or collide, you can't shoot them, etc. They'll just be a graphical effect with no effect on gameplay, which is much easier to implement

Maybe we should check with some historians, but I don't think helicopters were widespread in our game's time period. There are quite a few complexities in making decent flying units: they need to take off and land; they need to move up and smoothly and not crash into the terrain; they need to crash to the ground when destroyed; they need to be shootable with ranged weapons but not melee weapons; they need to move over ground units, but not move through other flying units at the same height; if they're planes then they mustn't stop moving, and have wide turning circles; and probably various other things. None of the units in our game act like that, so the engine doesn't support all those things, e.g. it pretends the world is 2D for pathfinding and collision detection. It'd be fairly easy to make the unit exist at a fixed offset above the ground and move over any terrain, but that would be a bit rubbish, and it would take much more effort to make it work well.

A couple of points: The fundamental problem is that you want people to play your map without a password. That means the map has to contain enough information so it's decodable by the game. Exactly the same game engine is used for playing games and for the editor (there's just different UI), so if you can decode the map to play it then you can also decode the map to edit it. Given the plan to release the tools as open source, anyone could easily remove any artificial restrictions that stop the editor opening maps. Still, it's possible to make maps hard to edit. I wrote an experimental tool for AoM that would remove all the trigger names, remove all the condition/effect identifiers (and just keep the script code which gets executed when the trigger runs), mess up an internal counter so you couldn't create new triggers, and I think that was about it. The first two changes are irreversible, though they just makes editing awkward rather than impossible. I suppose it's theoretically possible that similar tricks could be applied to 0 A.D. maps, to erase information like names that don't affect gameplay, and include some encrypted data so the password-holder can recover the original data, but I don't know that it would be worthwhile or desirable. Perhaps a more useful feature would be to let you mark a map as 'final', and then if anyone edits your map it'll be displayed as "Name by Author (based on Original Name by Original Author)" so the credits are preserved by default, which might help address the credit-stealing problem that makes some people want to password-protect their maps. (What other reasons do people want password protection for?) In case it's not clear from Michael's response: Most of the map data is indeed stored in an XML file, so it's easy to edit that way. (The only exception is the terrain data, which is stored in a simple binary file because it would be insane to use XML for that.)

We're not currently planning to support pre-Intel Macs, mostly because we have some x86 assembly code which would probably take a lot of effort to port and we haven't had anybody offering to do that work. So our target is just 10.5 + Intel for now. (At least you should have plenty of time to upgrade before the game's release )