Ykkrosh

Not with the capital B and copyright symbol like that If I add a #error then run "make -k", it only recompiles (and fails for) mocks_*.cpp and status.cpp, it doesn't try rebuilding the .gch files or anything that depends on them (which it should).

There's a note on the build instructions page about that error. (It would be good if we could detect and select the right version automatically, but I don't really know how...) If you're using this AUR package then it should already do that replacement for you, though.

Thanks, should be fixed now. (I hacked trac/Timeline.py to say event['message'] = re.sub(ur"[^\x09\x0a\x0d\x20-\ud7ff\ue000-\ufffd]", u"\ufffd", to_unicode(message)) which seems to stop it dying fatally. (XML is so awesome.))

Oops - fixed. The -new one doesn't quite work yet, and probably needs more testing, so it's not the default. I'll rename it to update-workspaces.sh once it's more stable. The number changes when the tests change

I expect so - I've been meaning to work on it for ages but hadn't got around to doing anything, but I think it's doable now without too much effort, and it'd be good to get it working and integrated for the next release so we can test and see if it's a good design or not

The XMB files are generated when loading XML files (to cache them in a more efficient format) - you shouldn't ever need to interact with XMB files directly, just use the XML instead. (Normally you shouldn't even see the XMB files, but the saving-map-files-into-cache-directory bug makes you look in there.)

Encountered a new bug: makefile dependency tracking broken for PCH

Would those act exactly like normal settlements in terms of territory shape computation? (just with no visible actor, and different build restriction rules)

I started experimenting a bit with territories, in particular how to compute the borders. The old implementation (before the simulation rewrite) did them in a purely geometric way (as Voronoi diagrams), but that seems complex and inflexible, and I think tile-based methods might be better. A simple tile-based territory assigner, with largely similar behaviour to the geometric approach (i.e. each tile is assigned to whichever settlement is closest in straight-line distance), on Death Canyon with six settlements, gives something like: (The edges are a bit wobbly due to an implementation detail which could probably be improved a little). I think it's problematic since it ignores the river entirely, resulting in e.g. a bit of green territory in the bottom-right which is cut off from the rest of that territory by the river and by the magenta. It's more interesting when changed to depend on terrain, so each tile is effectively assigned to whichever settlement is closest in pathfinder distance (not straight-line distance): (This is using the default passability behaviour, so deep water and steep slopes block paths, shallow water doesn't). That results in territory boundaries following the curve of the river, except where they extend over bridges/shallows and spread onto the other side, and the blue/cyan boundary is along the middle of the steep canyon side. I think that gives much more sensible and useful behaviour, though somewhat less predictable (e.g. if you move the yellow settlement a tiny bit closer to the river then suddenly it takes over a big chunk of land between blue and cyan, since cyan is blocked off by the big hole in the middle left). To provide more controllability to map designers, while still allowing most of the behaviour to be automatic (i.e. not requiring them to paint everything by hand), I added some objects that influence the territories by overriding the terrain passability costs: That has some blocker objects along the bridges (so they act more like deep water, and the territory edges align along them), and some un-blocker objects along the steep canyon bits in the cyan area (so that the cyan area can extend more freely). (The idea is that these objects would be visible in the editor but invisible when you play the game, and have no effect on anything except the territory computation. An alternative would be to use a tile-painting mechanism instead of these magic objects to influence territories - I'm not sure which is better, but the objects are easier to implement the UI for since they don't need a special Atlas mode or special painting tools.) There's some other changes that could be implemented, like trying to make all territories to cover an equal number of tiles: (no magic blockers here, so compare to the 2nd image). That should be theoretically fairer (at least if it's implemented properly, not as a quick hack like this), but probably it looks too weird.

Export is a little problematic since our heightmap is 16-bit - it's possible to do 16-bit PNGs but I don't know how widely supported they are, so more likely we'd have to do a lossy 8-bit export, which doesn't sound entirely ideal.

I think in theory there's no maximum size for decals, so I'm not sure why they wouldn't work. Haven't tested it yet, though. Projecting a texture onto the terrain ought to be pretty easy to implement - someone needs to make CRenderer call m->terrainRenderer->RenderPatches() with texgen set to convert x,z coordinates into UV with appropriate scaling, then load and bind the texture as appropriate. Maybe an alternative feature would be the ability to import a bitmap as the heightmap? Convert the image to greyscale and paint out the seas and clouds etc in Photoshop, then tell Atlas to load it to replace the current map's elevation, then the outline will be visible and you can manually adjust the terrain as necessary.

I committed stuff now. Run update-workspaces-new.bat / update-workspaces-new.sh and otherwise it should be pretty much the same as normal. (One difference is that Unix builds default to release mode now, and you have to run "make config=debug" if you want debug mode). (I'll rename update-workspaces-new back to update-workspaces once it's been tested enough). It seems to work for me on Linux, and with VS2008 on Windows (though I haven't tested Atlas); further testing would be appreciated, particularly on OS X and VS2010.

common-api and testbot were just my first unfinished prototype attempt at a design, so please don't take them too seriously as being perfect or complete or unchangeable . It's quite possible that they'll be redesigned entirely, if someone comes up with a better way of doing them. Also there's no guarantee of maintaining compatibility with AI scripts, given future changes to the script design or to the engine - we need more experience and a better design before being able to offer stability. The only documentation is this which is very minimal, and even that might change incompatibly. So the AI design isn't good or stable or documented yet - what we need is for people to experiment with it and identify problems and propose improvements, so that we can hopefully converge on something that works well, eventually The autostart command-line options are often useful for testing. The metadata thing is a way for AI scripts to associate arbitrary AI-specific data with entities (e.g. remembering whether they're meant to be a worker or a soldier etc), with a bit of engine support so you can assign metadata when training units and it will be remembered when the unit actually gets created. All other methods are either examining the entity's state at the beginning of the turn, or issuing commands that will be executed on the next turn. You can't - AI scripts only have access to a snapshot of the simulation state that's passed into some common-api function every turn. (Files like binaries/data/mods/public/simulation/components/AIProxy.js are used when constructing that snapshot, and they're a normal simulation component.)

It stops SDL (the library that handles input devices) from using its DGA mouse code, but I'm not quite sure what that is . Disabling it seems to make the mouse behave more like in standard X, which I think is what we want, so hopefully it doesn't introduce any new problems. r9819 makes the game disable DGA by default now.

Does the mouse work better if you run with the environment variable SDL_VIDEO_X11_DGAMOUSE=0 (e.g. run "SDL_VIDEO_X11_DGAMOUSE=0 0ad" from a terminal)?

I believe it changed with the forum upgrade - it used to preserve case but now it forces everything to title-case. Maybe there's a disableable configuration option for it?

OpenSUSE 11.1 hasn't been supported by its developers since about six months ago, so you probably ought to upgrade to a newer version for security fixes etc. If you're not using a packaged version of the game, you need to follow the build instructions to compile it yourself, then run the "pyrogenesis" executable which it creates.

If you mean you get SVN conflict warnings when updating, that just means you've got locally modified versions of those files (probably due to compiling it yourself) - the "revert" command should get things back to normal.

r9767 should fix the ENet build errors (after running update-workspaces again) (thanks to access to historic_bruno's OS X). r9766 should hide the Atlas build errors by not building it by default; run "./update-workspace.sh --enable-atlas" to re-enable it. (The errors should get fixed but Atlas won't work anyway because of harder problems so it should still be disabled until that's fixed too.) Previous attempts to advertise widely for OS X help seem to have been miserable failures as far as I remember, and it kind of makes us look unprofessional and desperate, so I think it's probably not worthwhile. (Not that we aren't unprofessional and desparate - it just seems better to avoid projecting that image )

r9768 does something similar to this, which seems to work as far as I can tell. (The important thing to check is the alpha warning in the top-left of the menu, where it says "the game’s vision" using a non-ASCII character.)

Reminds me more of butter.

I strongly agree it should be fixed, but the problem is that won't happen unless someone fixes it . (I can't test on OS X myself - I can continue making blind guesses but it usually takes 24 hours for someone to test it and report the results, so iteration is very slow. I don't suppose anyone happens to have an SSH-accessible machine we could use for build testing (with root access so we can run MacPorts etc) or something along those lines?)

Looks like the error comes from the CUDA compiler rather than from GCC. I think it's been tested successfully with CUDA 3.0 - what version do you have? (The CUDA code is optional and the game doesn't use it, but it looks like NVTT detects and uses it automatically and there isn't an entirely trivial way to disable it.)

The Ubuntu PPA ought to work fine on Kubuntu.

I think Rasterise is called rarely so its cost shouldn't be particularly important (and it could be optimised significantly by only dirtying subregions of the grid when obstructions move, regardless of this change). The tile-based A* would have to increase its max steps by 4x to match the old behaviour, so it should be 4x slower in the worst case, but it's about the simplest possible A* so algorithmic improvements (which are needed anyway) should mitigate it. So I think it'll be hard to compare performance impact usefully now since we need optimisations that will totally change the performance later. Comparing how well they work in terms of implementation difficulties and path quality and unit stickiness sounds like it'd be pretty useful, though. Might as well handle them all the same way, I think - that doesn't sound like it should be any more complex and it might result in better behaviour around static shapes like rocks and buildings.