Ykkrosh

If you don't need any graphics at all, replay mode will run the simulation code blind. Otherwise you can run Engine.SetSimRate(10) in the in-game console to make it try to run 10x faster.

If it's slow at the beginning of the game, I think the most likely cause is your graphics card. Changing graphics settings may help with that. If it's slow later in the game with lots of units and/or lots of AI players, that's just because the game needs more optimisation work

source/tools/atlas/AtlasUI is probably the best place to look

Has anyone tried compiling from source on 10.7, and does it work or crash there? (If it crashes, maybe try editing source/ps/GameSetup/GameSetup.cpp and remove the setlocale(LC_CTYPE, "UTF-8") line and see if that makes any difference.)

Probable driver bug. Edit: No need to ask the same question in two threads

We'll probably have to extend it a little to let AI players handle territories, but no other changes are planned soon. (I expect we'll need to do a major redesign some time in the future, based on experience with the current prototype implementation, so it'd be useful to know what people find good and bad about the current design and what might work better, but I don't know when that'll be worked on.)

If I remember correctly from when testing AoEO a while ago, it was just an optional graphical effect and didn't influence gameplay (and e.g. buildings would still pop into visibility in a tile-based way). Don't really know how it was implemented, but I'd presume it's basically a very-high-resolution texture stretched across the entire map, and on each frame they'd fade it back to FoW colour and then draw thousands of circles onto it (one per unit/building) and then use that as the FoW/SoD texture. Maybe that's wrong, but if not then it doesn't sound too complicated, though performance would most likely be unacceptable on low-end hardware, so it'd have to be an optional extension (and probably lower priority than features that will affect all users).

Hmm, the console information on that page is almost entirely wrong - someone should probably fix it (or just delete it). Currently the console is running in the GUI script context. That means you can't access the simulation state directly - you can only interact with it using the same function calls that GUI scripts can use, which don't allow you to do things like change a player's resources. (Also you don't prefix with ":" or "?" any more, just type in the JS statement directly.) If you want to change the parameters set in the entity template XML files (binaries/data/mods/public/simulation/templates/template_structure_civic_civil_centre.xml), you'll have to just edit those XML files then restart the game - there's no way to change them at runtime.

The current version of 0 A.D. is based on the period around 500BC to 1BC, which is like a millennium before medieval, so it might not be entirely perfect in terms of historical accuracy The game's art data is released under the CC BY-SA license, which means you can freely copy and modify and distribute etc but need to provide attribution (in particular say the original author of the graphics is Wildfire Games and link to http://www.wildfiregames.com/ , and also say it's CC BY-SA and link to http://creativecommons.org/licenses/by-sa/3.0/ , in some reasonably noticeable place (like alongside other credits or copyright notices)). Also, any graphics you distribute that are based on the game's art must themselves be released under the CC BY-SA license, so that anyone is free to further modify and distribute your modified versions (as long as they include attribution to you too). Apart from that you can pretty much do what you want . Other graphics (and code etc) in your game that are not based on our graphics can be any license and aren't affected by any of this.

Yep, and that'll already work - it's nothing to do with components in particular, the XML-with-inheritance code handles disable="" on any arbitrary XML element. The current XML-with-inheritance format doesn't support that - an element can only have a single child element with a given name, so the inheritance processing and the C++ API and the JSON conversion remain straightforward and non-listy. In the few cases where we currently want some kind of list of items, it's done like <SoundGroups> <select>attack/siege/siege_select.xml</select> <order_walk>attack/siege/ram_move.xml</order_walk> <order_attack>attack/siege/ram_attack.xml</order_attack> <trained>attack/siege/ram_move.xml</trained> </SoundGroups> where the element name is effectively the ID of the list item. (One could imagine writing '<SoundGroups><SoundGroup id="select">...</SoundGroup><SoundGroup id="order_walk">...' instead, if it was designed that way). It'd certainly be possible to add some new kind of list handling to the system, but it's much easier if we can avoid doing that, especially if it's only used for hypothetical features which the game design doesn't need

The only way I know: Get Linux, and a PC-compatible Xbox 360 controller, then run xboxdrv, and put "joystick.enable = true" in the game's config file, then you can use the analog sticks to move and rotate the camera relatively smoothly. (Not a very widely applicable solution, though )

Added a WELL based on the GPG code that seems to match the behaviour of WELL512a.c; hopefully there's no blatant problems with it. None of the code uses it yet, but I guess I should move the mt19937s over to it, and probably switch the rand48s too (Math.random() in RMS and AI and simulation scripts) since why not.

Fixed. (The code was calling Boost's uniform_real with min==max, and in 1.47 that generates a number then returns if result < max_value else it tries again. Since it always generates a value equal to max_value it never returns and loops forever. I think that may be a Boost bug, since it requires only min <= max (not min < max), but I'm too lazy to check and to figure out where to report it.)

Did you also run it as pyrogenesis_dbg (the output of CONFIG=Debug builds)? It probably shouldn't optimise things out in that case. I tried compiling myself with Boost 1.47, and get the same hang, so I'll try debugging it here. Hmm, interesting. I just used mt19337 since it's easily available (in Boost, which recommends it if "you have no idea which generator to use") and it's not rand48 (which is used for Math.random() in scripts to match SpiderMonkey's default Math.random() implementation, but has visible patterns when used for graphics stuff like actor randomisation and probably particles). I implemented a Boost-compatible WELL512 now (copying the seeding algorithm from Boost's MT (where it mentions Knuth) since I assume that'll do) which seems pretty straightforward so we could use that - the only concern is how to verify that the implementation actually works correctly.

I assume the idea is that territories are still each owned by a single player, and computed independently of diplomacy, so the borders won't change as diplomacy changes, and the only new feature is that you're allowed to build on an ally's territory; as opposed to having a territory be owned by an alliance, where all the buildings of that alliance's members are summed together (as if they were effectively a single player) when computing the territories? (To give a specific example: say players 1, 2 and 3 have civ centers arranged in a small triangle. Each player's territory is basically a third of a circle since it's symmetric. If 1 and 2 ally, they can each build on their combined two-thirds; as opposed to combining the influences of their two civ centers, which would push back against player 3's influence and so player 3's border would shrink towards its civ center, so the alliance would end up with more than two-thirds of the area. (The latter option sounds more complex and unpredictable for players, and also hard to pick meaningful border colours for, and also incompatible with non-symmetric or non-transitive diplomacy (say 1 and 2 are allies, and 2 and 3 are allies, but 1 and 3 are enemies), so I'd be happier to go with the first approach.)) Separate question: If you have a situation like this where a house (or whatever) is creating a bit of territory around itself, but is cut off from a civ center, so the building will be slowly losing loyalty (or hitpoints or whatever), should the red player be allowed to build in that bit of territory around that house? or should you only be able to build in territory owned by you (or an ally etc) that is still connected to a civ center? That sounds kind of cyclic, which is bad - to compute a player's territories, you first have to decide whether that player's towers are in their territory (and should influence it) or aren't (and shouldn't), and you can't decide that until you've computed their territories

It'd probably be most useful to run the game (preferably compiled in debug mode) in gdb, wait for it to freeze, do ctrl+c in gdb, then do "thread apply all bt full" to see what it's doing.

Overlaying those two images, it looks to me that CT's image is a redrawing of that image but not a direct tracing of it, since the shapes and proportions are different (CT's rider's feet are much thicker, his rider is leaning backwards much more, his leopard head is vertically above the horse's front knee whereas in the other image it's much further back, the curve of the reins is different, etc). So I don't think it's a direct copy of that image, though it probably still counts as derivative work (so still potentially problematic in terms of copyright).

I made it remove SoD in owned territories now. (Windows autobuild should be uploaded soonish.) What additional functionality is critical for proper gameplay testing of territories?

You're running the unoptimised debug version, which is intentionally slow . Compile the optimised version with "make CONFIG=Release" and run pyrogenesis (not _dbg), and it should be faster.

I think none of us really have any experience with this - we're all learning as we go along, which is what makes this fun . I implemented the game's current pathfinding code, but that was the first time I've ever done non-trivial pathfinding, so that (plus a random collection of articles I've noticed on the web) is the limit of my expertise, so I don't know what approaches will really work well I think that's true (ignoring ships, which will be handled separately). But if you have 64 units in a phalanx formation, it might be nice if they picked paths that avoided going near obstacles that would cause the formation to break up, so clearance could perhaps be useful in that case. But that's probably an unnecessary complication Yeah - the current problem is that the tile grid is a poor approximation for the obstruction shapes of trees/rocks/buildings/etc, so units either get stuck or fail to find valid paths. Reducing the pathfinder tile size would allow it to be a better approximation. But we probably have units larger than half a tile, so clearance might be important for that. This is all kind of hypothetical though - we don't have any definite plans, and it would be good to keep things as simple as possible (but no simpler). I wrote a wiki page - does that help?

In theory the pathfinder limit should be 724x724 tiles. I suppose it'd be nice if the game engine worked better for extremely large maps, but not if that has any harmful effect (on performance or complexity etc) for sensible-sized maps, so there will probably always be some overflow-dependent limits.

Hello Yeah, and I think a lot of features worked superficially but had fundamental problems (that would really hurt with multiplayer (which never properly worked), saved games (which weren't even attempted), AI (not attempted), etc, and was inflexible and crash-prone and generally painful to work with), which contributed to programming stagnation since it was too hard to improve the code and nobody wanted to work on it and there wasn't much point working on the rest of the game if the gameplay couldn't work. That's all redesigned and reimplemented now, building on the benefits of hindsight, and (in my (admittedly pretty biased) opinion) works much better - the game doesn't really look more advanced than it did many years ago, but the technology is much more complete and robust and can actually work this time, so we're in a much better state

Might be best done like special/territory_block.xml with <TerritoryInfluence>. (The <OverrideCost> means that tiles under the entity's obstruction shape will have a traversal cost equivalent to that number of normal tiles. Water and steep terrain have a traversal cost of 4 (coming from simulation/data/territorymanager.xml), so if a territory would have a radius of 64 tiles on normal land then it'll extend at most 64/4 = 16 tiles over water instead; OverrideCost overrides that terrain-dependent cost of 4 to whatever you want it to be (but not higher than 255).) That will block all players' territories equally. In particular the wall will block the territory which it itself is built on top of, so it'll probably immediately be considered disconnected and start decaying... I guess it should be restricted to not affect its owner's territories? Like this? (That makes the problems at sharp corners more prominent (most notably the grey one, but also e.g. the yellow has some self-overlapping quads too) so that really needs to be improved ) Oops, forgot about that - fixed.

I believe the same underlying issue applies to land units attacking ships, or attacking units on another island, so changes to fish won't solve the problem.

My current vague plan is that the editor UI would be generated automatically based on the definitions of XML structure which we currently use for validating correctness of templates (like here), so it will always be up-to-date with the latest structure and won't need any extra manual work as the components are extended. (Going to take some effort to get it set up in the first place, though...)