should take all player' capture points into account.

You might want to have a look at gui/session/selection_panels_middle/single_details_area.xml lines 29 to 42.

Being able to make e.g. city walls or siege towers completely immune to pierce damage seems far more elegant than merely assigning an arbitrarily high armour value as is currently the case. However, units should never be able to attack entities they can't harm.

Separatedly, someone with more knowledge and experience of the art/ files should correct the following:

• "akin" [sic] into "akinakes"
• "gladus" [sic] into "gladius"
• "pillum" [sic] into "pilum"
• "tessalian" [sic] into "thessalian"

(involves file moves etc.).

As for consistency, if animals are visible in the fog-of-war when alive, then they ought to be visible when dead as well.
That said, I don't have any idea what UnitAI.js or resource.xml actually do.

A few options mentioned so far:

• Automatically insert “Territory root.” at the beginning of the tooltip text line
• Automatically insert “Territory root.” at the end of the tooltip text line
• have a separate territory root line (current diff), e.g. “Territory root: true”
• have a separate territory influence line, e.g. “Territory: root: true; radius: 38; weight: 40000.”
• have a combined <BuildRestrictions/Territory> and <Territory/Root> line, e.g. “Territory: own, neutral; root: true”

Thank you for reviewing and committing this, I appreciate it! Are you interested in D2000 and D2025 as well?

Something similar is that <BuildRestrictions/Territory> (own, neutral, enemy, ally) is sometimes mentioned in a tooltip text (e.g. outpost), but certainly not always (e.g. civic centre). Perhaps we should move that information in this patch as well and display it on the same line as territory root, e.g.:
Territory: own, neutral; root: true
On the other hand, when you're attempting to place a structure in invalid territory, the previewed structure turns red and the tooltip informs you already why it can't be placed.
It's just something to contemplate, possibly though not necessarily a good idea.

Yes, it's unfortunate. And although the classes which could join a certain formation are defined in the templates, the formations that are actually available are defined in the {civ}.json files.

<ElevationBonus> affects the effective maximum range of units (and also ought to be used by <RangeOverlay>), so why would it be an improvement to move it into the <Projectile> node? (I'm just curious.)

While at it, I would rename this to "ElevationRangeBonus", and change that everywhere.

Or HeightBonus, or HeightOffset, or RangeHeightBonus, or something else.

Capitalized classes.

Alive and dead is equal to not having them at all.

Isn't that confusing?

Alive + Dead + Notbeinggathered only works when not being gathered.

Why? Surely something can't be alive and dead simultaneously? (No Schrödinger's cat in 0 A.D.)
Also, what if someone wants a resource change that only works when being gathered (making something)?

Hence limit.

Then why ChangeLimit and not just Limit?

Thanks, that's helpful.
Alive and Dead are clear for fauna (fatten when living, decay when killed), but not really for gaia templates (is a tree considered alive or dead?).
Does NotBeingGathered means it will or won't work? Also, shouldn't there be a OnlyWhenBeingGathered tag then too?
Furthermore, there is probably a clearer term for ChangeLimit.

It's been a long time since I last looked at this. If it's not too much trouble, perhaps you could explain how it works/syntax in xml templates?

Also, here is a relevant page from P. T. Daniels, W. Bright (eds.) The World's Writing Systems (Oxford 1996):

Revert pers.json corrections; the civ.json files should be checked and standardized for all civilizations in a separate patch.

We currently show this info for two seemingly random buildings only (one civ's monument, and one civ's pillar). For all other buildings with territory root, this information is not discoverable in-game right now. Having that available, as this commit does, I think is a clear improvement.

Yes, I fully agree with that, I'm just not convinced it should be on a separate line.
Wouldn't it be better to simply add "Territory root." at the beginning or end of the tooltip text string?
Have a look at the farmstead, where the tooltip informs us it's a dropsite for food, important information.

Although I'm not opposed to the idea per se, I'm not convinced the proposed implementation would really be an improvement.

Another error occurs when the AI has built a market:

If you select food to sell, you should get a number on the coin? If that is not the case, please report :)

You're right, I mixed up, selling works fine. My problem is actually with the buying part. Instead of bartering a fixed 100 silver and getting +409 food in return, I want to buy 100 food and pay only the silver equivalent.
For comparison, if you go to the supermarket, you don't want to know how much bread you can get with €100, you want to know how much one bread will cost you.
Basically, there is a fundamental difference between a barter-based economy and a currency-based economy.

Alternatively, keep the resource amounts fixed at 100, and display the currency equivalents:

     || 100 food  | 100 wood  | 100 stone | 100 iron
buy  || −a silver | −b silver | −c silver | −d silver
sell || +w silver | +x silver | +y silver | +z silver

So I tried out incorporating D1846 and D1957 into my 0abc mod; silver has
"properties": [ "barterable", "currency", "tradable", "tributable" ],
the other four resources only [ "barterable", "tributable" ]. Also, silver, food, wood, stone, and metal have a "truePrice" of respectively 100, 20, 40, 60, 80 (to correspond to the fact they have different gather rates).
When launching a game, building a market, and opening the trade window, this is the result:

• the -100 numbers on top of the sell resources are not really meaningful; what we actually want to know is how much silver we get if we sell 100 of a resource
• the barter and trade window width apparently only takes the tradable resources into account and overlooks the barterable resources need to be displayed as well
• the position of the currency resource silver is a bit odd; perhaps we should have three rows: select currency (in case there are more than one), sell resource for currency, buy resource with currency
• and a js error:

ERROR: JavaScript error: simulation/ai/petra/diplomacyManager.js line 412 SyntaxError: missing ; before statement InitGame@simulation/helpers/InitGame.js:57:1
ERROR: Failed to load script simulation/ai/petra/diplomacyManager.js
The line in question is:

requiredTribute = gameState.ai.HQ.pickMostNeededResources(gameState).find(res => tributableResources.indexOf(res.type) != -1));

What I don't know for sure is what causes the errors (D1846, D1957, me including them, some other file in my mod, or something missing in A23 compared to A24, something else).

By the way, <FriendlyFire> is wrapped inside the <Splash> node, but shouldn't it be applicable to non-splash attacks as well? E.g. an archer shoots an arrow at an enemy, but the projectile spread causes it to land on another unit of yours right next to the target, then it would be nice to have if that one was wounded, for realism.

<Delay> could also make sense for melee attacks, e.g. a unit who plants bombs.

Please correct me if I'm mistaken, but currently ranged attack has everything melee attack has, plus <Delay>, <ElevationBonus>, <Projectile>, and <Splash>.

Thank you for the clarification, that sounds great!

What does it do? Won't different attacks conflict? And how do units know which one to select?
Also, wasn't @bb working on something similar?

Ideally different projectiles would also be able to have different damage, therefore what is eventually desirable is support for multiple ranged attacks, e.g. a fortress able to fire both arrows (long range, low damage) and javelins (shorter range, higher damage).

Melee attack also has range, but no projectiles. You're right, it has no immediate gameplay effects, it would just be a more logical grouping in the xml files. Currently there are already separate nodes for <Bonuses>, <Damage>, <Projectile>, <RangeOverlay>, and <Splash>. I believe <RangeOverlay> is based on <MaxRange> and <MinRange>, so it would make sense to put those (and <ElevationBonus>) inside the same node, and rename it to simply <Range>.
I suggested it because most mods are based on A23, this patch has already broken support for them, requiring them to be updated when A24 is released, so now would be a good time for regrouping other elements.

Thanks, I guessed that was possibly the case, but I wasn't sure.
Anyway, to avoid future confusion, I've inserted a tiny section in the CC:
https://trac.wildfiregames.com/wiki/Coding_Conventions?action=diff&version=42
Feel free to correct, or revert if I wasn't allowed to.

Sorry, I'm not really familiar with js, nor can I safely say I know exactly the difference between objects and arrays.
What I did is follow D1953#81077.

This would allow enabling special resistances in the future - a unit invulnerable to some damage type shouldn't be killed even if the attack is "instant-kill".

Sounds great (e.g. structures immune to pierce damage)!

"gather speed"

The question is whether the "Name": field in the {civ}.json files should equal the generic name or the specific name. Looking at all those files, it seems currently:

• athen, cart, gaul, kush, mace, spart use English common names
• brit, pers, ptol, sele use native language
• iber, rome could be both
• maur uses English "Ashoka the Great" for one but Sanskrit "Acharya Chāṇakya" for another

Maybe it should be standardized in a future patch; this one simply sticks to maintaining the status quo.

Thank you for this patch. Next question, should we also have a <Range> node? E.g.:

<Attack>
  <Ranged>
    <Damage>
      <Hack>0.0</Hack>
      <Pierce>9.0</Pierce>
      <Crush>0.0</Crush>
    </Damage>
    ...
    <Range>
      <ElevationBonus>9</ElevationBonus>
      <Max>70</Max>
      <Min>10</Min>
      <Overlay>
        <LineTexture>outline_border.png</LineTexture>
        <LineTextureMask>outline_border_mask.png</LineTextureMask>
        <LineThickness>0.175</LineThickness>
      </Overlay>
    </Range>
  </Ranged>
</Attack>

instead of:

<Attack>
  <Ranged>
    <Damage>
      <Hack>0.0</Hack>
      <Pierce>9.0</Pierce>
      <Crush>0.0</Crush>
    </Damage>
    <MaxRange>70</MaxRange>
    <MinRange>10</MinRange>
    <ElevationBonus>9</ElevationBonus>
    ...
    <RangeOverlay>
      <LineTexture>outline_border.png</LineTexture>
      <LineTextureMask>outline_border_mask.png</LineTextureMask>
      <LineThickness>0.175</LineThickness>
    </RangeOverlay>
  </Ranged>
</Attack>

Interesting, thanks! It hasn't made it yet into the ODE: https://www.lexico.com/search?utf8=%E2%9C%93&filter=dictionary&dictionary=en&query=genericize

"genericizing" [sic], a neologism? English already has "generalize".

Updated because of rP22379

Actually I disagree; damage is a mass noun, unlike resources.

Arbitrarily including some diacritics and omitting others would probably make things more confusing, don't you think? Besides, a single symbol can have different meanings in different languages—those four you call “simple” are already used differently in modern European languages, e.g. French cité is equivalent to Italian città.
In Old Persian, accents were not written, so we don't have to worry about those. However, vowel length is indicated and should thus be properly transcribed.

Yes, I highly value consistency as well, no disagreement here. However, I'm unsure what you meant with your last remark. Currently diacritics are used in at least some of the specific names of cart, kush, maur, pers, and rome, as well as in those of the Greek factions (athen, mace, ptol, sele, spart).
Anyway, let's limit this patch to the Persians only—it's already expanded far beyond the first diff (changing one of occurrence of Anatolian into Lydian).

You mean the use of letter signs for numbers? That's actually quite common. Keep in mind the “Arabic” numerals reached Europe only in Medieval times.
You're probably familiar with the Roman numerals (I=1, V=5, X=10, L=50, C=100, D=500, M=1000).
A similar system, the so-called “Attic” numerals, existed in the Greek world (Ι=1, ?=5, Δ=10, ?=50, Η=100, ?=500, Χ=1000, ?=5000, Μ=10000, ?=50000).
In manuscripts, however, the newer Ionian system from Milete was used (Αʹ=1, Βʹ=2, Γʹ=3, ... , Ιʹ=10, Κʹ=20, Λʹ=30, ... , Ρʹ=100, Σʹ=200, Τʹ=300, etc.).

Here you go, now with correct spacing.

Is it? Good to know. But shouldn't it then also for cost, requirements, and affects?
E.g. upgrade_rank_elite_infantry.json:

{
	"genericName": "Elite Citizen-Infantry",
	"specificName": {
		"mace": "Pentakosiomédimnoi",
		"spart": "Pentakosiomédimnoi",
		"athen": "Pentakosiomédimnoi"
	},
	"description": "Upgrade all of your citizen-soldier infantrymen to Elite rank.",
	"cost": {"food": 500, "wood": 0, "stone": 0, "metal": 500},
	"requirements": {"tech": "phase_city"},
	"requirementsTooltip": "Unlocked in City Phase.",
	"icon": "upgrade_elite.png",
	"researchTime": 40,
	"supersedes": "upgrade_rank_advanced_infantry",
	"tooltip": "Upgrade all of your citizen-soldier infantrymen to Elite rank. This increases their military prowess, but decreases their resource gathering rates another -25%.",
	"modifications": [
		{"value": "Promotion/RequiredXp", "replace": 0}
	],
	"affects": ["Infantry Advanced"],
	"soundComplete": "interface/alarm/alarm_upgradearmory.xml"
}

or should it be:

{
	"genericName": "Elite Citizen-Infantry",
	"specificName": {
		"mace": "Pentakosiomédimnoi",
		"spart": "Pentakosiomédimnoi",
		"athen": "Pentakosiomédimnoi"
	},
	"description": "Upgrade all of your citizen-soldier infantrymen to Elite rank.",
	"cost": { "food": 500, "wood": 0, "stone": 0, "metal": 500 },
	"requirements": { "tech": "phase_city" },
	"requirementsTooltip": "Unlocked in City Phase.",
	"icon": "upgrade_elite.png",
	"researchTime": 40,
	"supersedes": "upgrade_rank_advanced_infantry",
	"tooltip": "Upgrade all of your citizen-soldier infantrymen to Elite rank. This increases their military prowess, but decreases their resource gathering rates another -25%.",
	"modifications": [
		{ "value": "Promotion/RequiredXp", "replace": 0 }
	],
	"affects": [ "Infantry Advanced" ],
	"soundComplete": "interface/alarm/alarm_upgradearmory.xml"
}

Shouldn't the folder be called simply damage/, to match the <Damage> node of D1950? For comparison, we have resources/, not `resourcetypes/.

By the way, should the Armour damage types also be in some (the same) kind of container? I guess not because Armour can only have the damage types as options? (But then there is "Foundation".)

No, I don't think it's necessary; for comparison, <Cost> has a <Resources> node, but <Loot>, <Looter>, and <ProductionQueue/TechCostMultiplier> don't.

So that's why the AI strongly prefers sabremen (hack) and ignores spearmen (thrust) in my mod!
Perhaps the damage strength value should default to 1/n when undefined?
Or even better, set it in the proposed damage files (D1936); for comparison, the resource files have a "aiAnalysisInfluenceGroup" setting.

How do D1936, D1938, D1945, D1946, and this one (D1950) relate? Any particular order in which they ought to be committed or are they completely independent from each other?

Indentation

template_unit_ship_fishing.xml
template_unit_siege_ram.xml

In principle I think D1936 and D1938 are a welcome improvement; I was merely wondering whether or not it would make sense to wrap the damage types inside a <Damage> node and yes, thus change all relevant templates; cf. D1171.
As for capture attack, it has a Value (which affects Capture Points), not damage types (which affect Armour and Health). I don't think Value should become a damage type; for comparison, time and population are resources that are treated differently from the others.

code is what is used in the templates and data files, and name is what is displayed by the GUI and marked for translation, right?

Atossa, Hystaspes.

Updated because of rP22328.

Also updates the hero specific names and descriptions in the pers.json civ file.

Perhaps it's just me, but I have a hard time trying to imagine what a damage subtype could be, conceptually. Resource subtypes I can understand: you gather fruit, fish, grain, meat at different rates and you get food. But damage types? If fire, ice, lightning magic all affect the same armour (magic), then they're effectively the same; and if they would have different armour types (fire, ice, lightning), then they would be effectively fully different damage types.
The trac ticket doesn't mention subtypes either. Wouldn't your code be much cleaner without?

Why the subtypes? Damage types (crush, hack, pierce) are children of attack types (melee, ranged, slaughter), not the other way around.

Sounds great! Does it also remove the need to set the damage type in every attack component of every template?

Put some information at https://trac.wildfiregames.com/wiki/SpecificNames (can be changed later).

Updated, now indicating vowel length and using š.

Then let's use š in Old Persian.
Also, could you create a page https://trac.wildfiregames.com/wiki/SpecificNames, so I could write down a few things there?

Do you want to have vowel length indicated, e.g. Latin hastātus? And for Sanskrit, do you want to use ś or sh?

The specific names are specifically non-English, so I'm not sure that style guide would be the appropiate place. I vaguely recall @Itms stating he wanted to write a page on transliterations months ago, but undoubtedly he's busy with other things.

Not all diacritics are accents :) And yes, we already use accents for Greek (e.g. mace_civil_centre.xml has “Agorá”); furthermore, the game has no problem with displaying polytonic Greek either:

No, there is nothing wrong with š itself (in fact, I would prefer it), however, it apparently leads to confusion, because some files have š, more sh (e.g. Kurush Cyrus), and others s (which is wrong). Because English has sh but not š, I standardized it.

Thank you for reviewing and committing this, I appreciate it! The fewer inconsistencies in the templates, the better. Are you also interested in doing D1794?