mimo

I'm pretty sure that can't happen: if there is no farm, the ai won't try to build any. There are some maps with disabled farms (like survival of the fittest) , and that works. Houses is another story: the ai use them for the population bonus. If you don't have houses, it won't know how to increase population, so the code is currently not protected against no houses (better have a dummy ai in that case).

This does not have much sense: - either you have something which acts analogously to the standard game (a xzorkut for example which has the same purpose as a field and you can expect that the ai will be able to deal with it if you rename it as "field" ) - or your buildings are completely different, with different purposes, and you have to write an ai to deal with them.

The civ.json files are in simulation/data/civs And why don't you follow simply the 0ad naming scheme, i.e. calling your houses "structures/hylian_house" if the civ code for that civ is "hylian"? you have in the Identity component some GenericName and SpecificName (which are those seen by the player) that you can change as you like, but the template name itself should not change until somebody write the code for the AI to adapt itself to any template name.

yes, that's a bug! that smells like some missing updates when diplomacy changes. Thanks for noticing. If you feel like it, you could post the bug in our bug-tracker, see https://trac.wildfiregames.com/wiki/ReportingErrors (preferred method)

lol what do you know of the original purpose? you should stop comparing things you are used to in other games and try to be a bit more creative.

That can't be the first error encountered? it is not the main one which is important, but the first one. Usually all followings warnings are just consequences and not useful to understand what could have happen.

this message has been removed from the latest version. Are you sure that you have not kept the old phaseRequirements.js in your petra directory? this file should be removed (its content is now more generic, and has been reincluded in the other petra files). From my tests, Kushites and Chinese work well, and Imperial Romans is a question of chance (the AI does not know yet how to interpret obstructions with Left/Right and believes it has no obstruction, so it may or may not succeed to position it depending on the terrain, will be fixed in a future commit). PS Looking at your github, why do you have a shared.js in the ai directory? your serialization could be broken if you do not update it.

Would we more useful if you would copy-paste here some of these warnings (in fact the first warnings you got).

Thanks Dunedan, at least i'm not alone with that bug PS An additionnal info, the problem does not happen with non-visual replays

Currently, the AI has been tuned with 300, and a simple empirical factor (sqrt(maxPop/300) is applied on its objective numbers (for example, it requires a 40 pop before switching to phase 2, and 80 workers for phase 3: such numbers are scaled when maxPop < 300). This scaling is only a "reasonnable guess" (as i've never played with smaller maxPop), but should be improved by somebody with such experience. If you could tune them, that would be great. You may see that the code doing that is in ai/petra/config.js Concerning the wonder, the code to make the ai builds one is simple, but we have to define some conditions (so that it does not try to soon, or too late), and i'd no time to test what would be adequate. Here again, if you are ready to contribute to such tests, that would help.

I had the same values, and you have no problems when starting 0ad while firefox was open with some tabs? should then be something in my system

After some investigation, the problem is linked to the new tab multithreading of firefox, actived by default on my kubuntu with firefox 55. I switched "browser.tabs.remote.autostart.2" to false in about:config and that cured the problem (although loosing the multi-threading). But still i don't understand why this only happened when starting Oad. I'd be interested if others are also running firefox 55: what are your values of browser.tabs.remote.autostart and browser.tabs.remote.autostart.2 in about:config? and do you see the same problem when multithread is activated?

As i was not sure how it is set when i compile it, i've installed the 0ad A22 package from ppa:wfg/0ad and have the same problem.

I had disabled them, with still the same problem.

Since my update to firefox 55, I'm facing a strange bug: each time i start a 0ad game, all my firefox tabs become empty, even when reloading. Reopening a new tab works though. It could be a bug with firefox55, but no other application apart 0ad give me that problem. Anybody facing the same problem? I've 2 pc with kubuntu 17.04 and both have it.

Yes, i also really like where they are going to, and agree they would be a nice addition to vanilla. Maybe you could start a discussion about it within the team?

yes, any naval map should do it. Just check that it now builds shipyards. D705 is quite small and could be included in A22 if well tested. While D654 touches too many parts and it's safer to wait for after the release.

Tests of https://code.wildfiregames.com/D705 with delenda would be nice, but you need to remove first your petra changes (it seems you've included D654 which is not a good idea as not necessarily compatible with latest ai changes, it will need to be rebased).

Strange, in my own tests, it built cult statues. Currently the patch only works well for simple requirements like vesta temple. If the Arch needs glory, somebody has to learn him how to accumulate glories, that was not the purpose of D654.

The AI knows it (that's the easy part), but somebody must write the logic to find a good location (what are the requirements for a good position, how far from your borders, how to defend it, ...).

I've made a patch for the phasing up, with the delenda requirements in. Could you test it? https://code.wildfiregames.com/D654

I've no time left to work on mod's support, but some of the points listed here looks generic enough and should definitively be implemented. When A22 is out, i may have a look at the phase requirements, but don't think i can do much more. You should post tickets on trac about them (with the AI keyword) hoping that they may get the attention of some developpers.

Should be https://trac.wildfiregames.com/changeset/19209 so already quite old

No that won't be enough because the update to 17.04 seems to remove the libboost-filesystem-dev package (I had the same problem yesterday when switching to 17.04 and had to reinstall it with apt get). So check that you have libboost-dev and libboost-filesystem-dev packages installed and then proceed as Itms said.

@wowgetoffyourcellphone : how can it be complex to have the fields decay when unattended and regenerate when attended? that's on the contrary something which looks natural to me, and certainly not less natural no more complex than having health regen when passing nearby a temple, or when idle if we have a medecine tech. Futhermore, while i understand that everybody can change its mind, it's funny how you can say the exact opposite of what you said previously in this same thread that does not support taking your opinion too seriously, at least up to the next change of mind @WhiteTreePaladin : why would you ever need to keep track of these rates? do you also try to follow the changes of rate each time a man comes near a female? hopefully not! a game should stay a game, not a mind torture. For me, the only useful information is the base rate (knowing that a female is x% more efficient than a given male soldier), this does not change because of tech, mill, auras ..., nor because of D227, except the female aura which you should then also find much too complicated! @niektb : as said before, no complexity here. And don't worry, nobody has asked you to give a yes or a no, my only demand was to test the patch for people to give a useful feedback Just to clarify what is D227: fields are built much faster (15s instead of previous 50s), but starts with a lower rate which increases with time. Typically after 2 mn, it reaches the nominal rate which won't change anymore as long as you have people working on it. As fields are long term resources, nobody cares about the rate of these 2 first mn. Then when abondonned, the rate that the field can provide decreases, and this "field rate" is visualized by the health bar (the field is destroyed when the health reaches 0). What it brings is that, when a field is half destroyed because of an attack, it looks more natural for me that the farming rate is decreased accordingly during the time the field is restored. And if when attacked, you garrison all your gatherers in the nearest cc, your fields will start to decay, which also looks more natural, but more importantly that makes raids against fields more efficient even if the defender has used the town bell.