the “” technology

Units have different gather rates for resource subtypes, therefore it makes sense to mention both the subtype (what you gather) and the resource (what you gather) in the tooltip. We already have “Harvest grain for food.” in the field tooltip and my suggestion is to follow that format for the other resource entity tooltips. Flora has wood.tree or food.fruit. And animals have to be killed before resources can be collected, hence the “Kill to”.
But yeah, sentences should be proper English; robot language is undesirable.
(Also, lumber is something quite different than wood; look it up in a dictionary.)

I have no strong opinion on the tag changes; if someone else agrees with them, let’s go ahead. Otherwise, let’s keep them as before to minimize string changes.

In mark-up languages it's customary to close tags on the same line, e.g. LaTeX \textbf{lorem}, HTML <b>ipsum</b>, MarkDown **dolor**, hence my preference for [font="sans-bold-14"]sit[font="sans-14"] in this text file, which also makes it easier to see if a tag is forgotten.

panels

Before I can update this, we still need to find a proper format for the formation and garrison aura types.

Maybe what we need first is to have two completely different words to refer to (1) formation as in a way a group of units can organize themselves and (2) formation as in a specific group of units. For example, if we used ‘group’ for the latter, “Same group [class] [change] [attributes]” may work.

A group is an arbitrary selection of entities, which can be defined by e.g. Ctrl+1 and selected by pressing 1 or clicking on the group panel at the left of the screen.

[font="sans-bold-16"]
Modes
[font="sans-14"]
The main menu gives access to two game modes:

This means four lines, two of which show up as white lines in game; cf.

Updated, keeping flavour text and capitalizing classes.

As for the font tags, I don't fully understand your point. The number of tags remains unchanged. What this patch does is instead of having one font tag in two lines, e.g.

[font="sans-bold-16"]Modes
[font="sans-14"]The main menu gives access to two game modes:

it is changed to two font tags in one line, e.g.

[font="sans-bold-16"]Modes[font="sans-14"]
The main menu gives access to two game modes:

to be consistent with e.g.

• [font="sans-bold-14"]Multiplayer[font="sans-14"] – play against human opponents over the internet.

As you can see Siege Engines is capitalized, as requested. Other exceptions probably ought to be listed on the https://trac.wildfiregames.com/wiki/EnglishStyleGuide page.

I think we should capitalize them.

Agreed.

So basically you prefer [verb] for [resource] instead of [verb] [subtype] for [resource]?

Those are not philosopher names, those are titles of works.

ESC → Esc

Updated because of rP22650.

@Gallaecio, feel free to commit this and other patches that have been accepted. I can't.
Also, you might be interested in D2006 and D2110.

We can post-pone this discussion and merge as is.

If you mean whether or not classes should be capitalized, no, I don't think postponing that decision is wise. There are a few patches updating strings and there will be a couple more after this one is committed. Capitalization is a recurring question so we should settle one way or the other and have a clear decision for this and future patches.
I can see arguments both for and against. Excessive Capitalization Can Make Texts Harder to Read, besides, English isn't German, and having uncapitalized classes is aesthetically better. However, gameplay-wise capitalization of classes does make sense for added emphasis. Personally I don't mind either way, provided it is done consistently.

Siege Engines

For the record, it seems all classes are uncapitalized here.

• capitalized classes
• removed trailing zeroes
• checked against https://trac.wildfiregames.com/wiki/EnglishStyleGuide#Stats

Thank you for committing this! Perhaps you could also have a look at D1935?

(Spaces in map file names remain problematic (D1042).)

Roughly speaking, in Latin (and Greek) prosody a syllable scans as long if it is:

1. a short vowel followed by two or more consonants
2. a long vowel followed by two or more consonants
3. a long vowel
4. a diphthong (ae, oe)

(There are a few subtleties but you get the idea.)
Now Pinkster indicates vowel length for both 2 and 3, Glare (and other dictionaries) only in case of 3.

Thanks for checking, I appreciate it!
When writing this patch I used the concise dictionary of H. Pinkster (2nd edition; Amsterdam 2003); for your feedback I also consulted the larger dictionary of P.G.W. Glare (2nd edition; Oxford 2012). Let's see if we can find some common ground.

I guess the only remaining thing is removing .0 from numbers, right?

That and a decision whether or not classes should be capitalized in descriptions and tooltips.

Indeed, 0 A.D. doesn't have tides.
Wouldn't it be simpler and more correct to keep “island” but replace “a narrow strip of land” with “shallow water” or something?

Why the hele_ in the file names?

Now I'm confused. What has the Cote d'Azur to do with Greece?

Updated script

Looking at https://trac.wildfiregames.com/wiki/Civ%3A_Carthaginians it seems this feature was originally wanted (that design document page says “Garrison: 1” for infantry, “Garrison: 2” for cavalry, “Garrison: 3” for elephant and ballista). There might be a trac ticket somewhere.

Thanks, it works!
So if I understand correctly, for something to show up in the structure tree tooltip, it has to be defined in globalscripts/Templates.js?

Now suppose I want to display a new stat (e.g. garrisonable size) in all tooltips everywhere, what do I need to do then?

So selection_details.js corresponds to the in-game tooltip and selection_panels.js to the structure tree tooltip?
Both have getGarrisonTooltip, though.

What does gui/common/tooltips.js then?

Apparently I'm doing something wrong then. I gave cavalry a garrisonable size of 3, but it doesn't show up in the techtree:

Could you show a screenshot of the garrisonable size tooltip?

By the way, do fishing boats get a gather bonus from garrisoning a worker inside? I vaguely recall reading that somewhere (might have been a previous alpha, non-implemented feature, or mod), but if it's implemented, it should probably be moved to its xml template as well.

Not implemented, but worth considering: use – (space en-dash space) instead of : (colon space) to separate hotkey and description, e.g.

Display backslash (\ won't show up, \\ does) and add names of other punctuation symbols for better visibility.

Per @elexis' earlier remarks.

Yes, a merchant ship with 15 traders inside generates four times as much resources as an empty one. Or to put it differently, garrisoning traders in merchant ships is only profitable if an empty merchant ship generates more than five times as much as a trader walking its own route.
A much cheaper option is to simply construct additional merchant ships. (Four empty merchant ships cost 4×100=400 metal in total; one merchant ship with 15 traders inside costs 100+15×80=1300 metal and 15×100=1500 food in total.)

Out of curiosity, what's the difference between var and let? And if it should be let, then why do so many files have var? (Try running grep -cr 'var ' in the ai, components, and helpers folders.)

The aura description formats should be clear and unambiguous.

garrisoned type: Garrisoned [class] [change] [attributes]

Agreed.

garrison type: Hosting [class] [change] [attributes]

E.g. “Hosting warship +10% health.” Would the uninformed player understand that means the hero is to be garrisoned?

formation type: Formation [class] [change] [attributes] or Accompanying [class] [change] [attributes]

E.g. “Formation spearmen +10% health.” Wouldn't that imply all spearmen in any formation, rather than only spearmen in the formation containing the aura-entity (e.g. hero)?
E.g. “Accompanying spearmen +10% health.” Again, how is the player supposed to know that means only spearmen in the hero's formation?

True, neither traders nor merchant ships are capturable in 0 A.D.
I'm wondering though what would be the most logical place to define this bonus: the entity template that receives it or the entity template that gives it?

I think we should avoid trailing zeroes on user-visible text for now.

Agreed. In that case the GUI should probably be edited to not add any trailing zeroes for e.g. armour either (in a different patch, of course).

should classes be capitalized or not?

I would postpone this decision as well.

I don't think postponing that decision is a good idea. Everytime a string is updated, the entire string has to be re-translated again for all languages, which means that changing capitalization later doubles the work-load for our translators. Besides, the purpose of this patch is to improve consistency, and a policy to keep it uncapitalized in some data files while demanding it to be capitalized elsewhere doesn't seem very consistent.

Shouldn't it be Trader-based instead of Merchant-based? That would allow e.g. gaul trader adds +0.15, mace trader +0.20, pers trader +0.25.

rP16022 broke the pull templates? And the wall templates fixed by rP22070 and the trigger templates fixed by rP17270? But then why does Josh say in #3613 that it was working in Alpha 18 (released march 2015 after rP16022, see Changelogs)?

No idea when exactly it was broken, but try placing other/territory_pull.xml in A23 in Atlas and you get these errors:

ERROR: RelaxNGValidator: Validation error: preview%7Cother/territory_pull:1: Expecting an element RetainInFog, got nothing

Things to be decided upon before I'll update this patch:

• +1 or +1.0 armour?
• should classes be capitalized or not?
• formation, garrison, and garrisoned aura description format.

Let's keep those sentences in the catafalque aura descriptions then for now.

Also, the question remains whether it's right to remove the history flavour sentence from these catafalque aura descriptions (other aura types don't have that).

Looking at the April 1 version:
formation type: [class] in his formation [change] [attributes]
garrison type: [class] he is garrison in [change] [attributes]
garrisoned type: Garrisoned [class] [change] [attributes]

As for +3.0 vs +3, I have no strong preference, provided it is done consistently. The gui displays armour with one decimal, though:

Thanks for the notification, I missed that one; I'll reply over there.

template_territory_pull.xml

Those height maps aren't used, their copyright is unclear, and none of their commit messages says anything about them.
I just opened the three maps/scenarios/Height Map Import - Demo * files and they're all three blank maps without any entities. I'm not sure what they demonstrate; if one wants to know how to import height maps I suppose they could have a look at e.g. maps/random/hellas.js. So perhaps delete all those Height Map scenario files (png, xml, and pmp)?

If I understand you correctly, you suggest those heightmaps to be deleted, but want to know on what grounds exactly?

template_pull.xml -> template_territory_pull.xml and pulls/territory_60.xml -> territory_pulls/territory_pull_60.xml?

The parent template doesn't actually have a territory component, because that's specified in its children, so wouldn't it be a bit weird to name it template_territory_pull.xml? Otherwise I have no objections.

Yes, I'd like to have one; no idea how to do it myself, though. Perhaps you could help?
[EDIT]: the Persian trader has +25% base gain, so it should presumably add 25% (= 125% of 20%) when garrisoned in a ship, rather than the default 20%.

Thanks! Found it, simulation/components/Trader.js line 5:

// Additional gain for ships for each garrisoned trader, in percents
const GARRISONED_TRADER_ADDITION = 20;

Wouldn't it be better to define that value inside the trader template, rather than hard-code it in this javascript component?

Currently I'm looking at the template_unit_ship_merchant.xml's tooltip. Is the “Garrison a Trader aboard for additional profit (+20% for each garrisoned).” part actually implemented? If so, where? If not, wouldn't it be better to remove that sentence then?

Please have a careful look before changing this.
This aura affects entities with the “Market” class; doing a grep -r Market reveals we should look at the following templates:

campaigns/campaign_city_minor_test.xml
campaigns/campaign_city_test.xml
template_structure_economic_market.xml
template_structure_military_dock.xml
structures/cart_dock.xml
structures/cart_market.xml

The first and second don't actually have a <Market> node, the third and fourth have:

<Market>
  <TradeType>land naval</TradeType>
  <InternationalBonus>0.2</InternationalBonus>
</Market>

to which the fifth and sixth add:

<Market>
  <InternationalBonus op="add">0.1</InternationalBonus>
</Market>

Then we also might want to have a look at simulation/data/technologies/trade_commercial_treaty.json, which has:

	"tooltip": "Market +10% International Bonus.",
	"modifications": [
		{ "value": "Market/InternationalBonus", "add": 0.1 }
	],
	"affects": ["Market"],

As far as I understand it—please correct me if I'm mistaken—the international bonus is a bonus based on what you'd get when trading with your own markets. In other words, 0.1 means 10% more than non-international trade.
What this proposed patch actually does is increase the bonus by 0.02 (= 10% of 0.2), i.e. 2% of normal gain, rather than the 10% it does now.
So if something is to be changed, then probably the tooltips, not the values.

[EDIT]: Seems to me we need a definition of restrictedClasses ;)

No, not really; e.g. spearmen inflict both hack and pierce damage; they should be able to attack structures even if structures would be immune to pierce damage.

See also D1397.

Thanks! D2006 is a similar patch, perhaps you're interested in reviewing that one as well?

It's a bit unfortunate that tooltips speaking of classes are in formation templates, whereas it's actually unit templates that decide what formations they can have.

Is it a good idea to change that? Not sure.
Sounds like that should be changed, formation templates should imo define what units can go in (as the formation parents the units).

Yes, that would probably an improvement.

Rephrased skirmish formation tooltip, per @bb.

Perhaps you can add a reference to the source? For future reference and may help to persuade people ;)

Herodotus Histories book II is about Egypt and Kush (“Aithiopia”).
For the Ethiopians in Xerxes' army, see Herodotus VII.69-70.

(If you're interested, D1881 is similar, since all other wallsets are inside structures/.)

Now without vision files (adding those is perhaps not a good idea).

No idea; I stumbled upon this when viewing triggers/ files because of territory pull discussion.

Moved to gaia/fauna_arctic_wolf_domestic.xml

Agreed, let's delete those pngs then; updated script:

Updated script:

what to do with the scenarios/Height Map *.png files

The question is which purpose do they serve.
If they're in the public.zip, I suppose players dont actually see the files?
Can post copies of the files in some place that people look up, wiki page, forum post, trac ticket, and or phabricator page and or commit to art repository.

I don't know what their purpose is. Where should they be moved to exactly? Or do you think they should simply be deleted?

Or Or fauna_arctic_wolf_violent.xml? (Other wolves are merely aggressive.)

Thank you for your comment.
Yes, these pulls become permanent when connected with a territory root; I suppose their usefulness is limited to scenarios where players can't build new structures (e.g. maps/scenarios/Campaign Test Map.xml).

It seems Jenkins is failing the build of the map file again, presumably because of spaces in file name (see also D1042).

Thanks! However, template_*.xml files don't show up in Atlas either, so it wouldn't actually solve the issue? Or do you mean creating additional files?

template_territory_pull.xml
territory_pulls/32.xml

Updated, now with footprint and obstruction.
Also minor workshop templates corrections.

@Nescio, you are my superior in this

Am I?
Because it involves javascript, you actually need someone else; perhaps @bb is willing to.

Actually “splash” implies a liquid (the word itself is an onomatopoeia), so I'm not sure it is the most appropiate term for anything we use in 0 A.D.; anyway, that's probably outside the scope of this patch.
I merely chimed in here because I'm curious as to why you think this particular occurrence has to be renamed.

Updated