Ykkrosh

Whoops. Fixed in r7543. (I must have only tested Atlas recently on Linux, where the error happened to not occur - need to be more careful about testing )

Thanks, looks like the assembly code was using the wrong registers - should be fixed in r7541. (You'll probably need to do a "make clean" before rebuilding, else it won't recompile the right files). Does that help? Edit: Oops, that was a bogus fix (it'll break Windows) - r7542 should be better (as long as you run update-workspaces.sh before building).

Can you try running it in the debugger to see where the segfault is? ("gdb ./pyrogenesis_dbg", "r", (wait for crash), "bt full")

"The Humble Indie Bundle experiment has been a massive success beyond our craziest expectations. ... Now it's our turn to give back. As of 5/11/10, Aquaria, Gish, Lugaru HD, and Penumbra Overture pledge to go open source."

Hmm, I don't know why AtlasUI would fail when pyrogenesis links okay, so I've got no ideas there . But Atlas doesn't work on OS X anyway (#500 which will probably need a lot of work), so you could just disable it for now: edit update-workspaces.sh and delete the "--atlas" argument at the bottom, then run update-workspaces.sh and it should no longer try to build AtlasUI.

Do you mean it gave the error message "libxml2 must have threading support enabled"? I changed the code recently - I tested it on OS X (10.5) and the _REENTRANT flag didn't appear to be necessary, but if you get that error then seemingly it is necessary . I've changed it back in SVN - if you revert your changes and update, does it work better now? Those errors are because you commented out the pkgconfig("libxml-2.0") line - it should work better with the version now in SVN. Thanks, added.

The 90% quoted at the start of that article came from World of Goo, where they counted the number of IP addresses of users who chose to connect to the online high score server, vs the number of sales. I expect some commercial games have similar systems, and they can also count how many hundreds of thousands of downloads are reported by torrent sites etc. They're all pretty rough numbers, but it doesn't really matter if it's 95% or 75%. What I find quite worrying is people like this - it sounds like he can't even conceive of the notion of paying for games ("I saw the words 'banned' and I was gutted, completely gutted. ... I love it, I love playing Xbox live. ... Now I don't know what to do"). Everyone seems perfectly happy with the idea of paying for hardware (and paying for modchips), because that's natural and how it's always been and you get a complex physical object to justify it, but there's so many free games on the web nowadays that people expect software to be free - it seems weird to pay large amounts of real money for something that costs nothing to reproduce and distribute, when there's already loads of stuff in the same medium that you don't to have pay for. There's a similar problem with e-books - people are used to paying for a book and associate the price with the physical object, even though the cost of the physical object is maybe 20% of the price (the rest is for marketing, proofreaders, editors, authors, etc). But people are used to getting millions of words of text for free over the web, and an e-book costs nothing to reproduce and distribute so why be expected to pay more than a couple of dollars for it? With a physical object you can hide the up-front production costs in the unit's price, and nobody will notice that they're paying ten times the manufacturing costs of the object they're getting - they'll believe it's worth what they pay, and competition will ensure the prices stay low but sustainable. But software and digital distribution make it clear that the manufacturing costs are zero and so it breaks the illusion - now you're paying for something much more abstract (an unknown tiny share of the unspecified production costs) and it's hard to relate that to the concrete activity of handing over money. That sounds dangerously close to what I'm claiming to be concerned about . It shouldn't matter whether the content is downloaded or already on the disc, or whether it was produced during or after the rest of the game, because what you're really paying for is the developer time needed to produce that particular chunk of content - but it feels very wrong to pay for simply unlocking disc content. Players have to judge the value of the entertainment they'll get from that content, but they're no good at doing that - they'll be milked by extortionately high prices or they'll demand unreasonably low prices (then turn to piracy) because it's too abstract and they can't reconcile the value and the costs.(I don't have any suggested solutions to the hypothesised problems, of course )

Good question . If you're on Windows, do Start -> Run -> "%appdata%\0ad" and then look in (I think) data/screenshots/ to find them. On Linux and OS X, look in ~/.local/share/0ad/screenshots instead. (F2 is the integrated non-big screenshot function - see binaries/data/config/default.cfg for the list of all the keys that are currently recognised.)

By the way, you can use Ctrl+Alt+F2 to take high-resolution (6400x4800) screenshots and then scale them down in a paint program to emulate nice antialiasing

The heuristic ought to decrease as you get closer to the goal, but I think that one stays the same all the way along the straight line, so that's not going to work so well . It should find the straight path but it'll be inefficient and search far more tiles than it needs to. It could be used as a tiebreaker in the heuristics though, like here, but since it always prefers the straight line between the start and the goal (regardless of any obstacles in the way) it'll find ugly paths like this.

Hmm, if pkg-config says that and if the files exist there, then I can't see why gcc wouldn't find it... The .xcodeproj file won't work - you need to build FCollada either by running update-workspaces.sh, or by running "make" inside libraries/fcollada/src. From some searching on the web, it sounds like the CFBundle.h:147 error is an issue in the Snow Leopard header files and it requires you to use Apple's version of GCC. Could you check "which g++" and "g++ -v" to see what version it's using? (If you have a MacPorts version of GCC selected by default then perhaps that's the problem.)

"sudo port install libxml2" ought to give you the necessary files. What output do you get from running "pkg-config libxml-2.0 --cflags"? Is there a file "/opt/local/include/libxml2/libxml/tree.h"?

Over long distances, it uses the tile-based A* pathfinder. That finds a path moving between horizontally/vertically adjacent tiles (so going diagonally doesn't save any movement cost), with an ugly hack (or clever tweak, depending on your point of view) in the cost function to make it prefer 30-degree and 45-degree diagonal paths when it has a free choice. So if you try to walk along a 30/45/90 degree line then it should go pretty straight, otherwise it'll do a curve made of 30/45/90 degree line segments. (Many of the games I've tested have the same issue except they only use 45/90 degree lines so they're even less straight. I guess our options are to ignore the problem, to find a cleverer trick in the cost/heuristic functions to make it straighter, or post-process the computed path to make it straighter (as long as that doesn't cause it to hit obstacles or expensive terrain etc).) The unit then picks a waypoint on the long-distance path, and goes in a nice straight line towards it (using the new precise obstacle-avoiding pathfinder), and when it gets close enough it picks another waypoint to head towards. So that part should be mostly a straight line.

Yes - actors are the same, and if you select the "actor" dropdown (I think that's what it's called) in Atlas's entity list then it should show any new ones you add. If you have a working actor, and you add a new entity file in the new location (binaries/data/mods/public/simulation/templates/) using the new file format (copy one of the existing ones), then the entity should appear in the default entity list and work. If it doesn't work then something must be wrong, and hopefully the log would mention any errors

Are you running the game on Windows? You should run OpenLogsFolder.bat and look for logs/mainlog.html - if there are any error messages then that might indicate what the problem is.

The current basic scripting capabilities are just for technical tests, not for real playable scenarios. It will probably evolve to be a bit more powerful, and could theoretically be used by scenario designers, but most would probably want a more carefully designed and easy-to-use system which is likely to be difficult (in design rather than coding) and isn't currently a priority.

I think it's worked surprisingly well so far, but I agree it's far from ideal. There have been various discussions about changing the build system (upgrading to Premake 4, or switching to CMake), but as far as I'm aware there hasn't been any real work on that yet. If you're using a Gentoo ebuild then dependencies ought to be handled automatically - why are you having problems with enet? According to a comment in build/premake/extern_libs.lua (and here), pkg-config breaks with enet on Ubuntu. Looks like it's fixed in the package in Lucid but not in Karmic. Gentoo doesn't set up pkg-config for enet at all. I don't know if there's an easy way to avoid these problems - otherwise it looks like it will cause more issues than it solves. Yeah, currently the only way to add extra include/lib paths is by hacking the .lua files, which isn't good. Not quite sure what you mean - the build instructions already list the dependencies, and commands to install them on various Linux distros, which seems the best we can do. I've got an occasionally-updated Hg repository with a mirror of the source code from SVN, but completely replacing SVN would be hard since we use it for lots of binary files (including the large precompiled Windows .exes which add up to many hundreds of MB over the repository history) and for lots of work-in-progress non-public files, so we'd need some wider changes to make everything work with a new source control system. SVN isn't great for the source code, but splitting things across two repositories would make it harder for everyone. So it's not clear to me what would be a good solution We use #0ad on Quakenet (for historical reasons). You can register yourself

Hmm, I'm not sure what would cause that. SVN checkouts seem to work fine for me. Does it always fail on update-workspaces.bat? Can you access that file in a web browser? Maybe it's possible there's some kind of proxy server that dislikes certain files. You could try doing an SVN checkout from https://svn.wildfiregames.com/public/ps/trunk/ (ignore any warnings about invalid certificates) which may work better.

That sounds exactly like a scene in that other shining paragon of historical accuracy, 300 . Those kinds of unexpected one-off attack are good for exciting emotional moments in films where the hero does something magnificent, but I'm not sure how well it would translate into an RTS game where units are anonymous and 20 pixels tall and have infinitely replenishing projectiles to throw.

The 82845G chipset was released in 2002, and back then it was a low-end option with similar performance to (much more expensive) NVIDIA cards from around 2000. We've always targeted GeForce 3 level capabilities (high-end in 2001), and I've run the game with bearable performance on Intel mobile chipsets from around 2006. I'd be surprised if there weren't people giving away free second-hand computers that were more than adequate for the game

With the current construction system, it's not expensive - if an under-construction building is destroyed then you get back (100%-progress)*original resources. That sounds basically the same as immediately placing a special non-obstructing 0%-progress foundation, and only making it obstruct movement when a builder reaches it and gets it above 0%. I think it's better for those almost-foundations to be visible objects, so you can plan around them or cancel them or send multiple builders to them, rather than being invisible until the original builder gets close enough.

That's my current understanding of what ought to happen (based on what other games seem to do) - units are ignored when placing the foundation, then it tells friendly units to get out of the way and blocks them from walking over the foundation any more, and a builder can get the building to above 0% build progress once there's no units in the way (including enemy units), and after that point the foundation blocks enemy units walking over it too. (That avoids your own units blocking the building, but also avoids the exploitation of foundations to block enemies). Just need to implement it

I've committed the current version now (see r7484), which I think is basically working (though certainly not perfect or complete). (The precompiled Windows binaries should be in SVN within an hour.) Some things to try: Run the "techdemo3" map. Select the four horsemen on the left, right click on a nearby corral building - they should walk to the nearest point on its edge. Find the group of archers on the right, and select them all. Tell them to attack the temple they're standing around, and they should spread out to their minimum range (in a square pattern) and attack. Tell them to attack the temple on the far right, and they should move to within their maximum range (in a circular pattern) and attack. Tell the spearmen on the right to attack the temple, and they should move to their maximum range (in a square pattern). Tell some people to gather resources. Tell some people to build a building. (Click and drag to rotate during building placement. It should prevent you building on top of other units or buildings, but not enforce any gap.) Use the "pathfinder overlay", "obstruction overlay", "motion overlay" options to see some of the internal operation. Run the "techdemo1" map and train some units. They should spawn in locations that don't collide with any other buildings or units. (I've made training times 10x faster than normal so it's less tedious to test). Find the archers in the lower right, turn on "control all units", tell one to attack an enemy then make the enemy run away or run very close and the attacker should move to keep the target in range. Some known problems: * Occasionally units can walk inside each other or get stuck walking past each other, which I believe is due to some numerical accuracy issues. All the geometry code is done with 23.8-bit fixeds which is a bit rubbish (especially for unit vectors) so I think I just need to be better at using appropriate ranges and precisions. * Units don't respond sensibly when colliding with other moving units. * Units animate incorrectly if they're stuck and can't move at all. * Some important algorithmic optimisations are missing (like using quadtrees to efficiently find nearby objects). * Lots of low-level optimisations are missing (like somehow making CheckVisibility not do so many 64-bit multiplications, since it's called many times). * (It's particularly slow in debug-mode builds - on Linux you need to compile with CONFIG=Release for the faster optimised version.) * I don't like UnitAI.js - it's a poor attempt at a state machine and units blindly follow orders regardless of how the world changes around them. * I've not tested any of the code much, and keep finding various dumb bugs (particularly in the geometry algorithms). * It doesn't work nicely when you tell a large group of units to walk to the same point; it probably needs group/formation code so they don't all try walking to the same point. * And more! But hopefully not a lot more. Feedback on problems (preferably very specific details about what's wrong and how to reproduce it, or just general concerns about the whole approach) may be appreciated

The 845G apparently only supports OpenGL 1.3, and I think we require OpenGL 1.4, so it probably won't work, and if it did work then it'd be incredibly slow . But you can get a (low-end) modern AGP graphics card for $40 which should work perfectly well

Thanks, I've seen those before and they have some useful ideas. Hmm, that paper is about units with linear and rotational momentum, which I don't think is a good model for most units in our game - we currently have instantaneous acceleration and turning and I believe that's a sensible approach in terms of the gameplay (real humans can change direction very quickly and shouldn't feel 'floaty' like the robots in Spring) and implementation complexity/robustness (it makes it easier to not get stuck and to go exactly where the player commanded). The steering model with no momentum seems to degenerate into the original problem of picking which waypoints to move towards, so I don't think it adds much that helps.(We might want a momentum-based model for ships and charging cavalry, because it's silly if they can turn instantly and it's okay if they're cumbersome and can't follow the player's commands precisely, but I think it's easier for that to be done separately from the normal unit movement code - we should be able to mix different movement algorithms and shouldn't need a single all-encompassing one.) Yeah, I think it'll be necessary to make pathfinding asynchronous - a unit requests a path on one simulation turn, and doesn't get the result until the next turn (or even later), so the engine can schedule the computations to spread the load. But it may be okay for each pathfinding operation to be uninterruptible (it rarely takes more than a millisecond with the current not-very-optimised code) so that only batches of multiple pathfinding requests have to be split across frames, which should simplify things.