Ykkrosh

Middle-click-and-drag does that. (I don't really like the current control layout - I think we should probably simplify it (don't have two different rotation modes, don't rely on middle button, don't rely on mouse+keyboard combinations). But that can wait until later.) Hmm, I hadn't thought of that. It's a useful feature in paint programs but I can imagine it might be a bit weird here. I don't know if anyone else has tried it, but it might be interesting to experiment with. I think that's an Ubuntu/PulseAudio/OpenAL bug, and should be fixed in later versions of them. Whoops - houses were reducing the population limit, instead of increasing it. Fixed in my local copy; I'll upload to SVN soon. That's bad. How are you closing it? It'd be great if you could run it in gdb to see where it's frozen ("gdb pyrogenesis_dbg", "r", exit the game, see that it freezes, switch back to gdb window, ctrl+c, "thread apply all bt"), but that'll probably require you to build from SVN instead of using the non-debuggable packaged version. Yeah, when you first place the foundation it should tell friendly units to move out of the area, and then your units shouldn't be able to start construction until the area is free. That's not implemented yet, since it'll probably need some integration with the pathfinder, which is currently rubbish and needs to be rewritten

That looks a lot like a driver bug. You should probably try running the latest bleeding-edge drivers (probably listed here) to see if the problem has already been fixed, and otherwise report it to the driver developers - I don't think there's anything we can do about it here.

Because it was not yet available when you read the page . The people at PlayDeb have made one available now.

Hmm, if you apply a patch like --- a/build/premake/premake.lua Fri Apr 02 19:27:04 2010 +0100 +++ b/build/premake/premake.lua Fri Apr 02 23:21:48 2010 +0100 @@ -20,6 +20,7 @@ end else arch = os.getenv("HOSTTYPE") + arch = "amd64" if arch == "x86_64" then arch = "amd64" endand then run update-workspaces.sh again (which regenerates the Makefiles - maybe you missed that step?), then it really shouldn't give that error any more. Since it'd be nice for premake.lua to detect this automatically, could you give the output of "echo $HOSTTYPE" and "gcc -dumpmachine"? (This is the kind of situation where the Premake-based build system gets rather messy and makes me wish someone would rewrite it in a system that has better automatic configuration detection )

If you set arch="amd64" then apparently you'll get ../../../source/lib/sysdep/arch/amd64/amd64_asm.asm:27: error: `64' is not a valid segment size; must be 16 or 32(and possibly some wxDebugReport errors? if so, then remove the "--atlas" from update-workspaces.sh to disable the editor (which doesn't really work on OS X anyway)). That sounds like NASM is trying to assemble in 32-bit mode instead of 64-bit, apparently. Does anyone know why, or how to fix it?

There's some architecture-specific C++ and assembly code (around here) which would need to be rewritten, and there's possibly a few bugs throughout the code related to big-endian vs little-endian which would need to be found and fixed, and the build system would need some tweaks to cope with the differences. I don't imagine it would be impossible, and if somebody did the work then I'd be happy to add it into SVN if it doesn't add much complexity to the rest of the code.

The game doesn't work at all on PPC, and it'll take some effort to make it do so, even if the dependencies were working. Sounds like the other issue is possibly that it's a 64-bit build and we're not detecting the 64-bit environment correctly - if you look in build/premake/premake.lua and change it to force arch="amd64" then does it work better?

What are the problems with MacPorts? I have it running okay on 10.5 (since yesterday), and the game appears to compile successfully now with Xcode 3.1 and (I think) the default GCC 4.0 without any hassle, though the tests fail because it terminates whenever it throws an exception (and I have no idea why). So it probably ought to mostly work for you.

Yep - the .dae format can represent some animations losslessly, but it doesn't understand the details of all the biped transforms, so the exporter flattens those to one keyframe per frame. I think there's an exporter option like "bake transform matrices" which forces everything (even simple linear movement) to be keyframes, which is sensible to ensure the more complex animation modes don't get misunderstood by the importer, but it shouldn't make a difference for skeletons.Currently, the engine code samples the .dae file at 30fps (so make sure your exported animation is at 30fps too) and outputs another file (the .psa) with simple keyframe data per bone per frame, and the renderer interpolates between keyframes. We could (and ideally should) change this so that it stores the animations in a much more compact form, by skipping unnecessary keyframes (and interpolating more cleverly), and that wouldn't need any changes to the .dae files - that'd probably be quite tricky to implement well, but it might be worthwhile if the animations end up using up far too much memory.

The Radeon 7500 is apparently quite old, so one thing to try is disabling some graphical features: create a file ~/.config/0ad/config/local.cfg saying fancywater=false shadows=falsewhich will (hopefully) switch those off and make it a bit faster. (I don't know if fancywater will be disabled automatically due to lack of fragment shaders, or if Mesa will emulate them in software very slowly. We ideally ought to have something to automatically disable the more expensive effects if they're going to be very slow (#475).) Another thing to try is compiling the game with optimisations (the default is unoptimised to make debugging much easier): build with "CONFIG=Release make". Hopefully that'll make things smoother. Another thing to try is pressing F11 in the game (maybe once or twice), so it'll show a breakdown of exactly what parts of the code are taking time - that should suggest whether it's the rendering or simulation processing or something else.

Do you want to use both the mesh and the animation in the game? To use the mesh, the export needs to include the mesh and the skeleton (so that it includes the skin weights), but it doesn't need the skeleton's animations. To use the animation, the export needs to include the skeleton and its animations, but doesn't need the mesh. You can choose to export one file that includes the mesh and skeleton and animations, and use that file for both purposes - the game will just ignore the data it doesn't need. (You'll still need to make two copies of that file, since the game looks in different directories for meshes and animations.) Assuming you're using the standard Biped skeleton, you'll also need to make sure it's called Bip01, so that the game recognises the skeleton structure. (binaries/data/mods/public/art/skeletons/skeletons.xml defines the skeletons that it knows - it translates the exported skeleton (e.g. the Biped) into a standardised form, to help compatibility between meshes and animations that were produced independently and potentially by different modelling programs. If you have a weird skeleton then you'd have to add it to skeletons.xml.) Some export options may be important, but I don't remember what all the options are or which are needed. The animation can be any length. I think you need to ensure the first frame and last frame are identical, so that it will loop smoothly. Unless it's the exact opposite of that.

What version of 3ds Max? In new ones it should just be File -> Export (then select the .dae file type), I think. Older ones may require you to install ColladaMax first. That should export any kind of animation, and if it's a skeletal animation and things are set up just right then the game should be able to load it.

In particular, binaries/data/mods/public/gui/session_new/ is the files for the new in-game GUI. ("session/" is the one for the old simulation system, and is obsolete now). There's some documentation on the wiki, though I'm not sure how up-to-date that is. It's easy to experiment by running the game in a window and modifying the GUI .xml/.js files in a separate text editor window, and the game should automatically reload and display the changes whenever you save the files (there's no need to restart the game).

I'm afraid I've broken this a tiny bit . You'll need to look in binaries/data/mods/public/simulation/templates/ for the new entity template files, and they're a slightly different XML structure (to match the new modular organisation of the code). (Also they're missing some data for unimplemented modules - I'll convert them all automatically at some point). But the basic idea is the same as before, including the parent inheritance, so it shouldn't cause any major difficulties

I've made this the default now, so you should get the new system when running the game or editor normally. (Use the "-sim1" command-line flag if you want to run the old one instead.) This is still very incomplete - the gameplay feature status page gives a rough overview of what's needed, and many things that previously worked are either missing or poorly implemented. But I think the foundation is pretty solid now, so it's a good time to start implementing features properly without (hopefully) running into any roadblocks in the future. The new code shouldn't crash, so please report any problems of that kind, though gameplay bugs (e.g. units walking on top of each other and on the bottom of the sea) probably aren't worth reporting now since they're just a consequence of the known incompleteness. The in-game GUI is also quite ugly (I just hacked it together with whatever textures were already available) and needs some proper design attention, but it should fix problems like the update latency that the old design suffered from, as well as the scary complexity of the old GUI XML code and deeper problems like the interaction with the deterministic network-synchronised simulation state. A lot more of the code is scripted now - if you look in binaries/data/mods/public/simulation/components/ and binaries/data/mods/public/gui/session_new/ then there's lots of files you can play around with (and the game should automatically reload and immediately start running any changes you make, without needing to restart the game) if you're interested in that kind of thing. (Need more documentation for all of this, of course - hopefully that's something we'll work on soon.) There's a lot of rough edges to clean up over the next few months, but I think this is a good starting point that will allow some real progress

Thanks, I forgot about updating that - removed the js/js-devel and all references to NSPR now.

That's using Windows' ancient non-hardware-accelerated OpenGL implementation. Do you have the latest NVIDIA graphics drivers installed? What happens if you don't run in compatibility mode?

Okay - I agree that's usually good, but I'm not convinced it's the best tradeoff in this specific case. In its current state the game is very insecure, and bugs in SpiderMonkey are the least of its worries - it'd be better to focus on reviewing and fixing the game's code first, so it never uses null pointers or overflows buffers etc. The disk space impact is minimal - it's well under 1% of the size of the game's data files. In most cases we have no reason to prefer a specific library version, so we use the standard system packages as much as possible, but I think the drawbacks for SpiderMonkey (the risk of different bugs and features and incompatibilities between versions, given that the game relies heavily on its precise behaviour and performance, and the time wasted on debugging those problems) outweigh the benefits now.Using xulrunner sounds like a better idea than using the standalone JS releases, since it's much more up-to-date, but it's got sub-optimal build settings (we want non-JS_THREADSAFE builds now to avoid complexity and performance overhead) and we'd still have compatibility problems whenever a new major version is released, and it would delay us adopting new or experimental SpiderMonkey features (e.g. the new JIT). I consider that to be a bug

No. SpiderMonkey isn't designed around regular stable releases - the versions that have been released are very old, the version that some people are planning to release soon is also very old, and the developers aren't interested in changing that (since they're mainly focused on Firefox; the recommended process for embedding SpiderMonkey is to just pick a recent snapshot and bundle it with your own code, like we do). The behaviour between versions often changes in incompatible ways, so using a different version to what's in SVN is quite likely to introduce test failures and subtle bugs and network out-of-sync errors. The particular version we're using also has a patch to avoid some thread-safety issues - using a different version means the game will randomly crash or corrupt memory in rare situations, which is not good. So you shouldn't do that Why do you want it to use the system library?

That's a known bug with the old simulation code. It should be obsoleted by the new simulation system very soon, so there's no point fixing it now.

Welcome! We've got a collection of issues in Trac, and have attempted to collect a few 'starter tasks' that suggest ways to jump in (though it's unfortunately not a very long list at the moment . Need to spend a bit more time organising things in Trac). There's also a rough overview of the recent in-progress gameplay rewrite which has a number of things that might be relatively approachable. There's probably more stuff we haven't written down - are there any particular areas you think you might be interested in, where we could expand on the details?

That would make it awkward for Windows developers to keep up to date - it might be okay for programmers, but I don't want to make it more complex for artists and designers etc and require them all to mess around with downloading extra files from a different server and extracting into the right locations and updating whenever it changes. Keeping all the files in the source control system also helps a lot with debugging, since we can trivially go back precisely to any given point in the past and use the old debug symbols and matching code. It would be possible to set up a secondary SVN URL which filters out the Windows binaries and libraries (using SVN's authz stuff) - I think that could be useful, but it'll take a little work and it hasn't been a priority yet. Might set it up in the near future, though. Ideally most people wouldn't download from SVN at all - they'd download some kind of .tar.bz2 that has just the Linux source code and data files from a recent relatively-stable release, and all the irrelevant Windows stuff would be excluded from that. That's what I was planning to do in a week or two, but then all these people came and unexpectedly started downloading it now

Glad it works . Probably better to leave the post here in case other people hit the same problem and find this.

You could delete C:\ps\binaries\data\mods\public\art\meshes\props and then run cleanup and update again - that should avoid any problems caused by SVN getting confused over files in that directory.

Have you run update-workspaces.bat again and done a Rebuild in VS? Might be necessary to do that before it'll work. (It looks like it compiled successfully in the autobuilder so I believe I didn't just forget to add all the files, though that's always possible too )