mimo

but still, when you say that things work or don't work, does that mean that it does what you want in game, or the structree works? Making it work in game should be straightforward (with what you describe, having only generic phases, with the wanted civ requirements in the phase_metropolis_generic.json). But as i said, i think the structree is broken when civs don't have the same phase sequences (it does not check for civ req when building the phaseList, and there is only one phaseList for all civs).

In fact, looking at the structree code, i've the impression it can work only if all civs have the same phase sequence.

or maybe try to understand what happens instead of doing random changes and testing only through the structree (which goes through a different piece of code) such that, reading previous posts, i'm unable to say what you really want to achieve and what does not work. I guess that you want to prevent a phase for a specific civ (let's say gaul)? if yes, as they fall_back to generic, the normal way would be to add { "notciv": "gaul" } in the tech requirements of the generic json file (Note that i have not tested any of that, just saying what i would try, and also that may be you'd have to do it for all higher phases than the one you want to remove, i.e. if you want to remove the town phase of gaul, you have to add { "notciv": "gaul" } in phase_town_generic.json and maybe also in phase_city_generic.json). Then you should first test in game (so without looking at the structree) to check if that does what you want. The quickest being using the scenario map sandbox_gaul and trying to update phases. If that works, then check the structree to see if it needs some changes.

I don't see anything specific to AI or pathfinding in the question. Anyway, no use to ping me anymore on such mods without code access (although people have asked several time a svn or git), unless i've missed it as i no longer read that thread. I've no motivation for that, and even if i had, i can't do anything without seeing the code.

lol put more informative titles if you want to get attention . I would never have looked at it as i thought it was about problems on intel cards which i don't know anything. The AI does not use the flag quoted above, it tries to determine itself if it will need ships or not. What is supported for the time being is going from A to B with ships, but it does not know how to go from A -> B -> C if it has to take 2 ships (i.e. if it can't go directly from A -> C). So maybe that's the problem in your map. What surprises me is that you say you have the same problem when you open up the center island (if you mean you made a way for ships to go through it?). But anayway, i can't answer more without the map, so if you need more help, upload it somewhere.

thanks, fixed in rP21757

Thanks for reporting it. Upgrading from a garrisonHolder to a non garrisonHolder was not supported in petra. Should be fixed by this patch. Try to use it in your tests, and if no more problems, i'll commit it later. petra-upgrade-v1.patch

Can you upload the corresponding commands.txt, and on which 0ad revision?

Thanks for all those quick fixes. Also missing in that mod are the team bonuses for chin and zapo. For chin, i would suggest something related to trade, and i've no idea for zapo. But certainly people here will have good suggestions.

You new nomadism tech could have "Cost/BuildTime", "multiply": 0.8 and/or "Cost/Resources/food", "multiply": 0.8 affecting Animals. And maybe it would be even cleaner if we add in vanilla game a TrainableAnimal class to the few trainable animals that would be used for that purpose. And you haven't fixed the requirements of the phase_city_xion. { "all": [{ "entity": { "class": "Yurt", "number": 12, "class": "Town", "number": 2 }}] } is clearly wrong. I guess it should be something like (but not tested) { "all": [{ "entity": { "class": "Yurt", "number": 12 }}, { "entity": {"class": "Town", "number": 2 }}] }

Yep, needs a small change in petra: It builds corral when the civ has no field, but xion have fields but no field builder!! I'll make a change in petra later to build corrals also in such cases. Also, is it wanted that sheep production has no cost and only 1s duration?

OK let's use this thread for reporting terra_magna problems. In addition of those quoted in you should also add the Class Corral in your corral, so that the AI will be able to use it.

I've tested the xiongnu (from TerraMagna github), congrats to those who make it, that's quite nice. Here are a few problems i noticed: Two errors on loading (files missing in the git repo?) ERROR: CCacheLoader failed to find archived or source file for: "art/textures/skins/structural/leather.dds" ERROR: CCacheLoader failed to find archived or source file for: "art/textures/skins/structural/celt_siege_ram.png" And see screenshot of the xion cc: may-be due to the missing texture? xion_female_support: SelectionGroupName = units/spart_support_female_citizen xion packing ability could be reserved to xion civ, i.e. captured structures should loose it. You could add a new tech (for example nomadism, autoresearched for free at startup only by xion) which would be required for packing. civil_centre: why do you call the template xion_civil_centre_unpacked.xml instead of xion_civil_centre.xml. That prevent the ai to expand and to build its own phase tree (these are ai limitations which hopefully will be removed in the future, but won't in a23). In addition, it would be better to add the proper superseding on your xion phases so that only the next one is displayed (phase_city_xion supersedes phase_town_xion not phase_town, see how it is done in vanilla for athen). Finally, the requirements of the phase_city_xion are wrong (i suppose only the last one is kept): you should have an array of two objects. Then there was a problem in petra, where the xion cc did not train units. This is now fixed in rP21748.

Yes, as you said, i've not enough time to support mods. But this feature looks simple enough to implement, and here is a patch which should do that. It is basically untested (i've only checked that it compiles), but can be a starting point if you or somebody else want to fix/improve it. Also, as i've no idea how many statues are enough, and i've put a max of 5, but change it to an adequate value (that max number is not used when phase requirements). cultStatue-v1.patch

Then isn't it enough to add in ProductionQueue kush_merc_camelry_... {civ}_merc_... so you seleucid player, after capturing it, will be able to produce both mercenaries. No need for {native} as long as you only deal with final templates ({native} is only useful if you want to take advantage of template heritance).

It looks like you want the {native}_ replacement D1084.

I quite agree with the word "selfnishness" that you've used I think what most players would love is a better pathfinder and less lag, much more than a new civ or some new buildings. Does that mean we should delay the release until we have them? And even without going to that extreme, there are always some improvments (a new animation, a new feature, ...) which would be nice to have and with somebody thinking it would be a good reason to delay a release. Futhermore, even with several major changes, people will talk on the web about a new release for no more than 2-3 weeks, and then switch to something else. So, to maintain the interest on the game and attract more new players, I think it would be much more efficient to have a short release cycle (six months looks good) rather than indefinitely delaying releases.

Yes, the AI is more or less able to cope with them, although some final tweaks will be needed when these structures are really in. But more globally concerning this thread, we agreed in the team some time ago to wait until a23 is out before enabling these structures, and i don't see any good reason to change that decision and delay more the release. My motivations to support this decision were: - only enabling the existing structures is not enough, we should take this opportunity of new available structures to give more diversity (based on history) between civs, and not just adding what is available. And that will take time. - that will inevitably require some balance, which will also take time to have it right (even if some people here seems to think it is useless for an alpha, i don't see how it can help the fame of 0ad to release something unbalanced). - A23 is already quite late compared to what we wanted (we were aiming at beginning of february) and staying in a pre-release state for too long does not help development as it prevents the important changes that people don't dare to do before a release. - A23 has already a huge highlight, the kush, and most of the other changes may go unnoticed in comparison. I'd much prefer to have a short A24 in a few months highlighting these new structures with possible improved diversity between civs.

all playerData are reloaded from simulation every turn (as they could changed), so modifying inside petra won't have the desired effect and should not be done. If you want to disable something, you must: - either set the disabled templates directly in the simulation - or create your own list of disabled inside the ai, and change the gameState.isTemplateDisabled function to do an OR of your own list and gameState.playerData.disabledTemplates instead of only using gameState.playerData.disabledTemplates Concerning the corral itself, you may force its construction by setting the HQ.needCorral = true during HQ initialisation. Nonetheless, in the case you described, i think the simplest fix is to test on the field existence, that is replace in baseManager.js gameState.isTemplateDisabled(gameState.applyCiv("structures/{civ}_field")) by gameState.isTemplateDisabled(gameState.applyCiv("structures/{civ}_field")) && gameState.getTemplate(gameState.applyCiv("structures/{civ}_field")) But once again, that problem is already fixed in a23 and i'm afraid the work you are doing will have a very short life-time: hopefully a23 will be released before two months from now, and the mod will certainly switch to it soon after that, and everything will have to be redone. I already said that, but better say it again: it would be much more useful (in the interest of that mod, but also for 0ad and petra) to switch to a23 now so that it is ready to be released with a23 when this happens and that all ai adaptation that may be needed are commited directly in svn.

If you are adding some own stuff and don't follow what petra expects, you can also replace that line if (template.hasClass("Storehouse") && this.metadata.base) by if (template.hasClass("Storehouse") && this.metadata && this.metadata.base) So that petra works even if you don't fill the metadata it expects (in fact i should add that protection in the svn version).

I think adding the preview in public/art/textures/ui/session/icons/mappreview should work

@wowgetoffyourcellphone phase_city_imp should supersedes phase_town_imp and not phase_town_roma (same problem with phase_imperial_imp). That prevented the ai to update to these phases in some tests i was doing.

You should go to the diplomacy panel, and change your diplomatic stance to what you want. If your change it to what the ai asked you, that mean you accepted the ai proposition. Otherwise, it will be understood by the ai as a request for an alliance.

yes, good catch. I've added a fix in svn https://trac.wildfiregames.com/changeset/20658 But i encourage you to report such issues either on trac (if you only report it) or phabricator (if you also provide a patch). Forum posts are not always read (at least by me) and it would be a pity to have to rediscover all these issues in the next version a few months from now.

Can you be more explicit? The AI uses GetIdentityClasses from globalscript/Templates.js which is a concatenation of Classes and VisibleClasses (which it calls internally Classes). If you have examples where this is not the case, it's certainly a bug and you should report it either here or on trac.