Ykkrosh

Could maybe work - probably the easiest way is for Rasterise() to compute a high-res grid like it does now, then downsample to the tile resolution (with a threshold so a tile is impassable if >=50% of sub-cells are obstructed). Or we could just increase the resolution of the pathfinder grid, maybe, and have 2x2 cells per terrain tile (instead of 1x1 like now). We need about 2 bytes per cell (for CCmpPathfinder's Grid<TerrainTile>), so a 512x512 map is still only 2MB at the increased resolution. (Or we could split it into a high-res passability grid with 1 bit per cell, plus one TerrainTile per tile, so it's 512KB+32KB). Then the tile-based A* can work over these higher-resolution cells, though we'd probably need some hierarchical-A* optimisations so it's faster at searching through the large empty spaces. Then our pathfinding cells will be a closer match to the size of our units and trees, and it won't be such a necessarily bad approximation.

As far as I'm aware, the JIT shouldn't have that much effect - the tracing JIT kicks in after a loop has done about 15 iterations, and the method JIT "should be triggering in order of microseconds" (according to Mozilla people). (JS engines are designed for web pages, so they need to be fast pretty quickly - there's no point waiting several seconds before activating the JIT since the page will have finished loading by then). The simulation scripts are fast enough that enabling/disabling the JIT didn't (when I tested it) have any significant effect on it anyway - it only matters for RMS and (sometimes) player-AI scripts. I think it's far more likely that something else is causing any noticeable slowdowns: maybe the on-demand loading of meshes/animations/etc, or maybe the player-AI scripts choosing to do a load of computation (if you have any AI players loaded), or something along those lines. Might be useful to get profiler measurements during the slow and not-slow periods and compare them to see what it points at.

Hmm, trees are 1.5m (3/8 of a tile) in radius, so if they're done exactly like static shapes then they'll often fall entirely between tile centers and won't block any tiles at all, so units will probably never choose to walk entirely around forests instead of through them. Maybe that's okay. I doubt I'll have time to look at this myself, so please feel free to fix it . (Trees ought to remain as unit shapes instead of static shapes ((these names are kind of rubbish - they made a bit more sense when only units had unit shapes)) since that makes the short pathfinder a lot faster (because it can assume they're axis-aligned), so I think it should be fixed by changing the calculations in Rasterise.)

OBS has packages that work on Fedora, if you want something to work from. Boost is so widely used that I can't imagine it's not already in the repositories. The bundled libraries that we use on Linux are ENet (not needed if you run update-workspaces --with-system-enet and have ENet 1.3 already installed); NVTT (not needed if you run --with-system-nvtt and have installed a version of NVTT which hasn't been released yet (so you really need the bundled copy for now)); SpiderMonkey (hopefully won't be needed soonish, when we upgrade to 1.8.5, if you have 1.8.5 packaged and installed); and FCollada (a fairly heavily patched version so there's no usable standalone version). I want to get rid of all those and avoid adding more, but it'll take time.

Hmm... I think the difference between in-formation and not-in-formation may just be an accident - I added the "Sort of hack" to CCmpUnitMotion::PathResult in the PATHSTATE_WAITING_REQUESTING_LONG state here, and I can't remember any reason why PATHSTATE_FOLLOWING_REQUESTING_LONG shouldn't be changed to do the same thing, so that it doesn't always abort when the long path has zero length, which might possibly help. (But it doesn't seem a totally robust solution so it would still be good to have a more proper way of handling forests so units don't often get stuck between impassable tiles in the first place.) Everything looks right to me The long pathfinder approximates the map as tiles for performance, and also so it can account for variable movement costs across different tiles (e.g. prefer moving along roads rather than mountainsides - the short pathfinder has to ignore movement costs entirely since it's not tile-based). The difficulties (and/or bugs) come in the interactions between different pathfinders that have different levels of approximation, so adding a third pathfinder would add more interactions and likely make it more complex and more fragile. It can never be perfectly accurate, since it varies depending on the size of the moving unit and since tiles are always an approximation - the impassability can either be an overapproximation (like it is now), where units will tend to avoid walking through gaps that they actually can fit through since they think the tiles are blocked, or an underapproximation, where units will think they can walk through a forest/wall/city/boulder-strewn-valley/etc until they're standing right next to it and then they suddenly realise they can't actually fit and they have no idea how to find an alternative path around the obstacle. (Hmm... Currently the implementation (CCmpObstructionManager::Rasterise) considers a tile to be impassable if the central point of that tile is within an obstruction shape (the blue squares), so it's an underapproximation, but that's only for 'static shapes' (rotatable-rectangle things like buildings). For 'unit shapes' (more efficient but non-rotatable-circle things like trees) it considers a tile impassable if the obstruction shape overlaps any part of the tile, so that's more of an overapproximation. I'm not sure that discrepancy is intentional.)

What matters is whether the building is in FoW/SoD from the perspective of the chicken's player, which is usually Gaia, and visibility isn't computed for Gaia (to avoid wasted computation since it doesn't need to care about FoW) so the chicken will always think the building is non-visible, I think. (That needs to be changed so Gaia thinks everything is visible.)

If this is a very recent problem then it may be related to #879 (the chickens might be stopping because they think the building is in FoW) which needs to be fixed soonish.

Cross-OS compatibility depends on the simulation code (which needs to stay precisely in sync between all players) rather than on the lobby service, and that already works and will continue to work (since we do something more robust than how AoK implemented it), so cross-OS play will always be possible

Is the en_US.utf-8 locale guaranteed to be available on all installations of OS X, not just English-language versions?

Re IRC: There should be two layers - the UI should not issue commands to units the player isn't allowed to control (to prevent the player getting confused by the UI indicating things are possible), and the simulation code (Commands.js) should reject any commands that violate the gameplay rules (to prevent cheating in multiplayer by people who modify the UI, and to avoid bugs caused by the command lag (e.g. commanding a unit when the command isn't executed until just after the unit is captured by the enemy)). It sounds like the UI layer is a bit buggy; the simulation layer is not yet implemented at all (since cheating didn't seem important yet).

They're precisely 50% accurate. The implemented accuracy system is rubbish and should be rewritten, it was just the simplest thing to implement for a first pass

(Sorry, still been kind of busy and not had time to think about this . I should be around on IRC all weekend if there's things to discuss, though.) Hmm, yeah, I think I agree with all that - I'd prefer to avoid spending time testing and fixing all the little details on all the platforms for CMake, and the benefits probably don't outweigh the cost plus the drawbacks, whereas adopting the Premake4 upgrade has little cost and gives immediate advantages (assuming it means VS2010 will work properly). It doesn't need to be perfect now - as long as it works, we can make incremental improvements later. So I think I'd be happy to integrate and commit it now, and fix any problems that come up in testing, and not worry about any further changes until it's stable, if that sounds alright to people. The converted files are cached in ~/.cache/0ad/ so you can delete that to force it to reconvert everything.

That's because it doesn't really show any buttons or information - it's easy to make the design unobtrusive when you omit necessary features from it . (If you want to see it in the game you'd have to go to SVN r7258, I think, before the simulation rewrite was merged (since the GUI implementation was incompatible with that).)

Looks like you're using GCC 4.0, which is very old (probably too old for us to bother supporting) - maybe it'd work better if you do "CXX=g++-4.2 make ..." or similar.

The CTerrain class stores the original heightmap as a 2D array of 16-bit ints (one for each tile vertex). It also stores an array of CPatch objects, each of which represents 16x16 (PATCH_SIZE) tiles, covering the whole terrain. CPatch stores the texture of each tile (via CMiniPatch). The renderer loops over every patch in the terrain, and if the 3D bounding box of the patch is visible to the camera then it reads the patch's CPatchRData. (That is, it does patch-based culling). If the patch doesn't already have a valid CPatchRData (e.g. this is the first time it has been visible, or the underlying terrain data has been modified since it was last rendered (since dynamic changes are supported)) then it computes a new CPatchRData. The CPatchRData stores OpenGL VBOs which contain all the vertex data needed for rendering the whole patch, so it just does some glDrawElements for each patch and that's about it

I think the simulation code currently imposes a hard limit of 16 players (plus Gaia), because it stores fog-of-war data in a 32-bit array (and needs 2 bits per player). The limit of 8 is imposed mostly by the UI and game setup code, so it should be fairly easy to relax that, particularly if the extra ones are invisible in the setup screen so we don't need to reserve more UI space for them.

Indeed - they're not even running in the same JS runtime or thread. Since the attack range is a constant that's determined by the entity template files, it should be possible to modify EntityTemplate in entity.js to return this._template.Attack.Melee.Range and/or this._template.Attack.Ranged.MaxRange, which will hopefully give the desired data without interacting with the entities directly. There aren't any attack bonuses implemented yet - it just depends on the hack/crush/pierce attack and armour values: damage = max(1, max(0, attack.hack - armour.hack) + max(0, attack.crush - armour.crush) + max(0, attack.pierce - armour.pierce))

Minimap bug.

(I'm not predictably available until after this weekend, so I probably can't do synchronous chatting until then, but I'll be occasionally around on the forums.) I tested the new build code on Linux and it seemed to compile everything fine, which is good . (Haven't looked at the code in any detail yet, though.) I started experimenting with CMake because of two main issues with the old Premake system. (I didn't want to conflict with the work on upgrading Premake, I just wanted to get a better perspective on the build process.) * Poor integration with bundled third-party libraries - currently we have the update-workspace.sh wrapper script to build them, which is slow (it builds both Debug and Release versions of everything, regardless of which you need, and it re-runs the configure commands every time you run the script) and inflexible (we can't e.g. skip building the bundled copy of ENet if the system already provides the right version of it, without a load of complexity in the shell scripts) and ugly. * Lack of a configure step for Unix platforms - currently we can't reliably tell whether the compiler is 32-bit or 64-bit (which still causes problems for some users), we have to write manual tests with 'os.execute("gcc -dumpversion > .gccver.tmp")' etc to detect compiler versions (which isn't nice), we can't reliably find libraries automatically (which causes problems when people have unexpected names for Boost libraries), and if you want to compile with a non-default compiler (icc, clang, etc) then you have to remember to set the right environment variable when running premake and also every time you run make. CMake 2.8 seems to address the first problem fairly nicely - it only takes about seven lines to use ExternalProject_Add to integrate an external project. It gets built when you run 'make' (which seems the most sensible time to build things), it can build just the current configuration, it works with parallel builds, it runs the external project's 'make install' properly (while our shell scripts just use 'cp'), and it's running in the same build script that does find_package() etc so it can easily depend on whether an acceptable library is already found in the system. CMake also does a normal configure step, which provides all the important information to the script (architecture, compiler version, etc, plus it has loads of standard modules to locate libraries), and which stores all the relevant data (compiler path, configuration selection, etc) and uses them each time you run 'make' (so it's easy to build with non-standard compilers). I've not yet seen anything indicating that Premake 4 handles these issues better than Premake 3 does (though I haven't tried confirming that by looking carefully). I only played with CMake for a few days, a couple of weeks ago - enough to get it to compile a runnable executable on Linux and to almost compile on Windows, but far from complete (e.g. I didn't look at CxxTest integration or OS X at all), and it probably has other issues I haven't encountered yet. Currently I really don't know what's the best direction to go in

Currently that's not possible, it's always UDP port 20595. Why do you want to change it?

I don't particularly care what it does as long as it does something specific and intentional and documented (at least in code comments), rather than something unpredictable. Picking the lowest sounds a fine way to do that

Yeah, they could use pretty similar code to what's now (experimentally) in the game. Some cases might want slightly different movement algorithms (the current code assumes planes always fly at maximum speed, whereas Star Wars physics might allow ships that slow down or stop) but it should be relatively easy to implement - I only spent a couple of hours on the experimental version, since the engine and gameplay code is flexible enough to make this kind of thing possible without much effort.

Sounds great If the player has multiple civ centres, does it pick the first (by entity ID)? Isn't there a "reset camera" item in the "misc hacks" menu or something?

If I remember correctly, if you move the cursor over the 3D game view area then it switches focus to that area (and away from any text boxes etc), so that you can use the arrow keys to move the camera around (instead of having the text box intercept all key presses). Without that, you'd probably have to click in the 3D bit to focus it, which doesn't sound ideal (especially since that might result in you painting terrain etc where you click). Neither way is great - any ideas on a better solution?

I think it works pretty much equally on both.