Radagast.

If visibly garrisoning is used, chariots' animations seem to get reset constantly. Though I still could not find the issue (my guess was it was due to UpdateGarrisonFlag), I figured that - luckily - the animations are not screwed for the shieldbearers. It's the first time I see visble garrisoning working like a charm even with animations. Heureka Sander.

The art department is rocket again, currently. Amazing work comrades!

Great! Thank you! If the visual appearance didn't differ, then perhaps the actor could be reused, but the stats of the two guard types might still be too different to merge both in one? Please allow, what do you mean by "because they are a cavalry unit". Does it mean that cavalry units in general (within almost all civs) shared little differences? Thanks again, also for the excellent texture references. Amazing research showing the full picture.

@lako3000: What you mean is giving the player the choice as of which attributes to train (though we already have that via techs ... so your proposal essentially boils down to add techs that each influences another of these attributes. Heroes currently aren't allowed to construct things but they can have a great boost for other nearby worker units. (at least there is one hero that specifies such an aura effect that makes nearby units construct 50% quicker) I like the cavalry idea to train other cavalry, but I see it more general, i.e. units should be able to share experience and train each other (technology transfer in the bigger picture).

The code exists, but it doesn't work for buildings, which is surely possible to fix. (To test type F key when having a unit selected and moving the camera anywhere on the map. It should jump back.)

Btw. we already have graphics settings, though that doesn't include resolution and such or does it?

Before rewriting the pathfinder, I'd still like to see how the ES31 20% performance boost plays out. The pathfinder rewrites are too big a task to simply finish if you have not the full picture of how it works (I think only Philip has it as he already rewrote the long pathfinder). LAN works, and it even works to start several 0AD instances on the same machine. 0AD is really great in comparison to commercial products that mostly require you to enter keys, and only allow online connection and not even LAN anymore at all. But that may depend. If it will help against the command / order lag is a question, I'd like to ask Josh. I remember Josh, scythetwirler and Alpha123 talking about the command delay some time ago and there was some reasoning but hopefully we can get rid of the lag soon. I think Europe and America is connected via pretty thick glass fiber cords. So I think that the physical distance is misleading and not a significant factor for the speed of light.

I already created a template, where I want to test if Obelix can take out enemies with one-hits only. The crush attack is immense, especially if Obelix charges, the enemies should fly around, poor legionaires.

As so often there is a patch - #1899 ([PATCH] Cycle entities) - on trac that jumps through all the buildings when typing e.g. J. for civic centers . To address the problem you mention, why not get inspired by how blender des it? Blender uses the first unassigned letter of the building: e.g. if you have archtower, assembly hall, blacksmith, and cc: type a to select the closest to camera archtower entity (press a again to select the next and so on, just like alpha123 did it in the above mentioned patch).type s to select assembly hall, because a was already assigned before for archtower.b to select blacksmith, press b twice in a row to select all blacksmiths on screen, three times to select all in territory or globally on the whole map.c for civil center,... and so on.@Llanos: sounds useful. Though I'd keep F for focus instead of the spacebar, just because it already is like that currently for units. (F hotkey unfortunately is not working for focusing on structures). @RoekeloosNL: Can be done, though in reality fields can't be destroyed/taken out anyway other than by using fire or by flooding them. Or by preventing the enemy harvesters to reach the field. So I see no issue with how it currently is other than that units should be able to block harvesters, perhaps a command to surround a field to build a meat wall/isolate it. (fields should not be attackable other than by fire or water) That's not a patch, that's in-game. It just immediately goes to your base (no shuttling needed), and we have no graphics for it. Normally, the attacker gets around 10% of the original cost of the unit killed or structure demolished. It's a patch, because currently only the goods traders bear are looted. And also the artificial loot as defined in the killed unit's entity simulation template. That's what the patch addresses: Robbing the dead entity of the resources it carried with it as well as the garrisoned entities.

Okay, I see that even villages could have had cavalry - not a trained one - but at least all the farmers' horses conglomerated to a battle line which might break easily. For me village phase means village phase and this means, that a cavalry corps might not be present. If we allow for cavalry then we could set a cavalry cap like 5 horses (all the other horses of a village will be unsuitable for battle anyway).

They bear up to 3 units, items or structures. (only units working currently)

thx, didn't know how the spread changes turn out. I wondered what less than 1 changes mean. Having no cavalry units in village phase looks okay to me. Perhaps make them all depend on a cavalry tech, which itself is auto-researched when town-phase is reached. (or make all cavalry depend on the town phase if that's prefered). You will find a solution.

If you are on Windows anyway, then CrazyBump is the easiest way. Followed by InsaneBump on any operating system. Finally I didn't know your method and it helps me a lot because I neither have a working CrazyBump nor an InsaneBump. Thanks Stan!

Water is not shown. I think I must have broken the water, despite water_4x4.xml being attached in the correct height. At least I'm sure as neither attaching to root nor to (prop-point) waterlevel fixes it. If someone wants to lessen the field's size then please create a new actor with "6x6" instead of simply changing the "8x8" one. We also might have to further deepen the rice plot's / terrace's depth into the ground. Edit: I admit what I did so far for the terraces is not enough. It's really not looking good.

The farmstead is only an actor, without any simulation effect. Only visibly garrisoning (and its subvariants like turrets, inventory, ...) can bear props that have influence on gameplay. It's only as a 1% probability for the wild rice field, which is only placeable in Atlas as eyecandy. (can a wild rice field be grown?) Our main simulation Han plot_rice.xml field actor is still unchanged. We now have two options: 1) Add the new terraces actor plot_rice_field_8x8.xml as a variant or 2) Create a smaller variant (6x6) and fully exchange the current single rice plot with the one where it is drop-propped as terraces. 3) Same like 2 but with 8x8. (my favourite because I think many terraces are needed to make it look good and thus 8x8 is better than 6x6, but we might have to check) I committed an improved version of the rice terraces/stairs:

Sorry for the late reply, I already added the stairs / terraces field like LordGood and Ayakashi wanted. Problems: Not enough rice. Will be hopefully fixed with my next commit. I'll also try making the square terrace even smaller. Water doesn't show up. See below. @Stan: That water doesn't show up in Atlas, was my problem ever since. It not even showed up for me in the original field you provided. Probably graphics settings or graphics related. I'll have to pull from 0AD SVN and recompile. Note: one field consists of multiple terraces / flooded individual fields.

Agreed. Thanks! See here, I had used your farmstead in the fourth main variant (which didn't work until now because the variant name wasn't distinct). It's been the only variant I had added that used 6x6 size instead of 8x8. Ignore the variants with those big plants. I'll readd at least my big terrain-adapting wild rice field if you are okay with it. (in a separate actor + simulation template)

I like both. A grass hill in a desert will always look funny anyway.

http://noiv.pythonanywhere.com/agentx/0ad/explorer/hannibal.html#!0;athen;MAPS;map The maps tab there is nice. I feel like 0AD is beginning to shape really promising. We can finish this. The only thing I didn't get to work on your webpage is the Plan functionality.

clarified my blurry post

Thanks for sharing! Useful especially for all 0AD Extended research as there each item (weapons, tools, kinds of horses, ...) will get its own simulation template + its technology which may be either auto-researched on time tag or manually researched by a player if the progress (tech research) is quicker than other civs (allowing to produce cannons earlier). Once this technology is available, those more modern buildings are constructable and later-epoch units are trainable. Old - still alive - units may survive even up to modern times if we don't add something like life-time limit. This way we achieve a guided history simulation, teaching history combined with the fun of mixing different evolution states of the civs (e.g. meeting knights with Napoleon). It's still up to discussion if even the most basic units' actors should retain their textures from previous epoch until they die or if they should be re-picked by the engine. I feel like keeping the textures would be more fun (and easier programming-wise). Edit: We have to distinguish textures here, because we can neither prop nor garrison them to/into units. This means we can't make certain clothes available using our technologies (e.g. our still to program time tag).

Your and Ayakashi's work here is epic. Keep it up, comrades! I'm your fan.

Hannibal is coming along nicely. Your recent Map Analysis wiki entry is related to this topic. Any news on if it will be integrated into 0AD as experimental bot prior to the planned Git transition? Or do we have to provide it as a mod? Funny I now reused our AI tournament state machine for a storylineMachine too. I like those 0AD bots. Always makes me want to continue on the Hybrid AI, of course it will build upon Hannibal, perhaps turning my command machine (yet another usecase of the state machine) into Hannibal compatible plugins.

Deriving an additional output and/or train time modifier from the health ratio (current health vs. max health) might be useful and motivate the player to repair his stuff.

Creating an elven and dwarf mod can't be a problem if we stick to generic names (derived from Tolkien's works on Elvish + Dwarvish). Just consider all those LoTR-like books out there which seem not to have copyright issues at all. Nothing must look like in the movies and we're fine. Though finding non-cinema references for Tolkien's world is quite difficult nowadays that the movies have been created and spread far. Anyway great to see these characters. Didn't expect even the nine lost human kings to be doable with existing actors only. Awesome.