It works fine on my end without any errors or warnings, and I did a grep, but I'm the author, so reviewers shouldn't believe me, and test for themselves.

Actually I think specific scenario text strings belongs in a separate diff; this one should focus on GUI elements, loading screen tips, descriptions, tooltips, etc. Moreover, scenario text does not necessarily have to follow the same criteria.

How would you phrase “If you accidentally select a Cavalry Citizen Soldier, hold Ctrl and click on the Cavalry Citizen Soldier icon of the selection panel at the bottom of the screen to remove the Cavalry Citizen Soldier from the current selection.”?

To me that sentence sounds unnecessarily precise. I'd replace the current:

"If you try to select the three idle female citizens by clicking and dragging a selection rectangle over them, you might accidentally select additional units. To avoid that, hold the I key while selecting so that only idle units are selected. If you accidentally select a cavalry unit, hold Ctrl and click on the cavalry unit icon of the selection panel at the bottom of the screen to remove the cavalry unit from the current selection."

with something like:

"If you try to select the three idle female citizens by clicking and dragging a selection rectangle over them, you might accidentally select additional units. To avoid that, hold the 'I' key while selecting so that only idle units are selected. If you accidentally include a different unit, hold 'Ctrl' and click on the unit icon on the selection panel at the bottom of the screen to remove the unwanted unit from the current selection."

Or perhaps condense it:

"Hold the 'I' key while clicking and dragging in order to select only idle units. You can also remove units from your current selection by holding 'Ctrl' and clicking."

Notice however that this criteria only applies to "gamey" text, not to historical or background text.

Descriptions and tooltips (the vast majority of strings changed here) is actually far more important than historical background texts, because hardly anyone opens up the history section to read everything, whereas descriptions and tooltips are constantly being displayed in game.
In my opinion descriptions and tooltips should be:

• generic
• precise
• consistent
• brief
• proper English

I might be biased, but I can see many reasons in favour of just 'cavalry' and not really any for the more verbose and less correct 'cavalry soldier units'.

In my opinion the strings ought to be e.g.:

• train citizen cavalry
• use spearmen against cavalry
• cavalry +10% movement speed
• promote your cavalry to advanced rank

Actually I dislike both 'cavalry soldiers' and 'cavalry units'. Both strings are superfluous. Cavalry implies soldiers, cavalry soldiers is saying twice the same: soldier soldiers. And e.g. the 1st Cavalry Division is a cavalry unit.
What should be used is simply 'cavalry'.

cavalry [noun] (in the past) soldiers who fought on horseback. / modern soldiers who fight in armoured vehicles.

While at it, could you also correct "Seleukus" into "Seleucus" in that string?

Replaced programmer's quotes ("catclaws") with proper opening and closing quotation marks (“...”). Also corrected a few minor things (e.g. Oresteia I → Agamemnon).

Oops, it actually should end with two i's; reverted previous "correction".

Corrected typo (thomsoni ends in one i, not two).

Removed unnecessary specific name from flaming pig, per Stanislas.

Wikipedia is a great help for finding names of species and for animal images. E.g. there are five quite different rhinoceros species, but 0 A.D.'s looks clearly like the "white" one.

In D1472#61049, @fatherbushido wrote:

https://wildfiregames.com/forum/index.php?/topic/21563-subfolders-in-simulationdatatechnologies/

Unfortunately I can't access that forum, but thanks anyway.

Also, gives all catapults a SelectionGroupName, gives all bolt shooters a SelectionGroupName, and gives all siege towers a SelectionGroupName.

Doesn't this mean packed and unpacked will be grouped together as a single entity?

While at it, could you also look at the decay of siege weapons? And ships? They use different accelarations with 0 delay.

Here you go: D1467

To me the units sink too quickly into the ground and it should be reversed a little for the release, it should ideally not be noticeable by the player when looking at it. Nescio wanna do a patch?

Personally I don't care what arbitrary numbers are chosen, nor do I have any idea how it affects performance (the rationale behind this change), but yes, I could propose a patch, if you like.

Without the patch they should disappear in 140 s, with the patch in 37 s. A delay time of 10 s with a sink rate of 0.02 should mean they're gone in 60 s; 40 s and 0.05 should give the same result; other values are possible too, of course.

Perhaps you should consider removing the crush damage from bolt shooters, then bolt shooters become pure anti-soldier units, unable to raze structures, and other siege weapons become effective counters vs (massed) bolt shooters.

Update: renamed a few more miscellaneous files

I understand the frustration but adding new things is the reason we have been delaying the release for so much time. For instance at the moment I am working on something that blocks the release. If I didn't have it I could land this, but if it was the case we would be releasing already. We need to make choices at each release, that is never easy 🙁

I was thinking I could commit this but I'd like to rename folders at the same time and it could mess up the translations. Just before the release is not a good time :(

A23 has been "just around the corner" for months. If is to be released in a couple of days, then yes, it would be better to wait; but if A23 won't be released in the next few weeks, you might as well correct this name now.

It would be great to let those places use the new function while adding the function to he codebase.

My programming skills are rather limited, but I'm willing to give it a look, see if I can find them, and possibly make use of the new vso function.

Updated comment

Also moved the updateViewedPlayerDropdown function into the new file (per @bb ).

Split patch in two: this one introduces the "vertically space objects" function; D1410 moves the "update top panel" into a separate file.

The reason I'm proposing this patch is to improve mod support for myself and others who'd like to modify e.g. the resource bar like I did in my 0abc mod.

Corrected another typo

Another correction (apparently I'm too quick with arc diff --preview)

Corrected typo in comment

Updated

Yes, the aim of this patch is to improve map files naming consistency and to remove inconvenient white spaces. However, random maps and scenarios do not include player numbers in the file name, only skirmishes do; furthermore, other data, such as map size, aren't included in the file name either. Removing the player numbers from the file names would thus improve naming consistency and also allow the removal of parentheses ().
Nevertheless, we still need to find a proper way to differentiate the "Azure Coast" scenarios and the "Corinthian Isthmus" skirmishes. Any suggestions, anyone?

Currently all skirmish files include the number of players within parentheses in the file name, e.g. Acropolis Bay (2).xml Is this actually necessary? Most maps have just one version.
If those skirmish player numbers were removed, file names would be shorter and simultaneously more consistent with other maps, which don't include player numbers in their name either. There are just two cases to distinguish different versions of the same map:

scenarios/Azure Coast.xml
scenarios/Azure Coast(2).xml
scenarios/Azure Coast(4).xml
skirmishes/Corinthian Isthmus (2).xml
skirmishes/Corinthian Isthmus (4).xml

Better move all the entity limits from the player_kush.xml file into the generic player.xml file for consistency.

I am not sure so only pointing this.
Should not be run speed at least a bit higher than walkspeed?

Actually it already is. template_unit.xml has a walk speed of 9.0 and a run speed of 15.0, which are subsequently multiplied in child templates.

Less trees for the dry season?

Why would there be fewer trees in the summer than in the winter?

You're right, I'm mistaken; the default has <Actor>units/britons/hero_chariot_javelinist_boudicca_m.xml</Actor> and the new one <Actor>units/britons/hero_cavalry_javelinist_boudicca_m.xml</Actor>. Six signs are different, I should have looked more carefully.
However, since they are both javelinists, the _javelinist part in the template name is unnecessary, brit_hero_boudicca_cavalry.xml would be sufficient. Also, you might want to correct the generic name, currently "Boudicca (Sword)", into "Boudicca (Cavalry)".

brit_hero_boudicca_cavalry_javelinist.xml seems to be a duplicate of brit_hero_boudicca.xml. Better delete it to avoid making things unnecessarily complicated.

I would rather keep the unit name Clubman, clubs are more primitive than maces afaik.

(Besides, kush_champion_infantry.xml sounds like it should be kush_champion_infantry_archer.xml, in particular since kush_champion_infantry_apedemak doesn't inherit kush_champion_infantry)

Removing the mercenary technology from the barracks is logical. Hero aura improvement seems sensible. I've no opinion on the trireme tweak.
For the clubman, I'd recommend D1354; for the axeman, I'd recommend D1355.

Currently infantry, females, and slaves have a food.meat gather rate of 1 and a capacity if 10; they also have the “Worker” class, which means they benefit from farmstead and storehouse technologies.
Cavalry has a food.meat gather rate of 5 and a capacity of 20. I'd recommend to just lower the rate to 2 (twice as high as infantry) and keep their capacity unchanged at 20. Introducing a cavalry-specific technology seems unnecessary to me,
And if a hunting research is to be introduced, it probably should affect workers as well (and only increase gather rate, not capacity).

Mace had the bonus that they were the only civ that could build siege workshops. That is now gone. Shouldn't they get a new siege related bonus?

Perhaps. Maybe a discount on the workshop or -20% training time on siege weapons? Anyway, specific civ-bonuses could be done in separate patches.

Also updated barracks.

Build failure - The Moirai have given mortals hearts that can endure.

Thanks, Itms! To summarize, I think the correct order now is:

• apply this diff first
• leave maps/random/ as is (already has consistent naming with underscores)
• leave maps/scripts/ as is (no spaces or hyphens there)
• rename files in maps/tutorials/ with Itms' command
• rename files in maps/skirmishes/ with Itms' command
• rename files in maps/scenarios/ with Itms' command and subsequently correct some renamed file names there:

Updated: this patch now corrects script references; files can be renamed via Itms' command

Do you upload them manually or do you use arcanist?

Command line arcanist. Is there also a manual option then?

Update, this time without problematic map file.

It seems to be a normal hyphen though, not a minus, en-dash, em-dash, or other similar sign. I guess the problem might actually be the space in the map file name. I vaguely recall having problems with that before, which is why I proposed to rename map files in D1042.

Updated again (hopefully no build error this time).

Kushites are too strong as they are

Don't you think giving one of their champions a new +30% bonus attack vs all champions would make them even stronger?

Updated again (also included kush in Identity list).

Updated.

as suggested by Itms: Penteconter -> Pentekonter

Out of curiosity, how have you chosen these specific ranges? E.g. why 3.5 and not 3 or 4?

If you have more template rename patches, tell us which files should be renamed, so that we don't have to trust or proofread the changes.

Here an example how I use this code to display five resources vertically in my 0abc mod (A22, mind):

Could also be athen_infantry_swordsman_marine_champion

Personally I'd favour simply athen_infantry_swordsman_champion, without “marine”, and remove the unit from the Athenian docks — but then this patch would change gameplay :)

Negative resources could represent debts and famine. And you still need a positive amount of resources in order to actively spend it on something.
I've been happily using it for several weeks in my 0abc mod, and I figure others might want to try it out in future mods. This patch is not terribly important, just a nice to have for modders.

Won't it cause stuff like negative resources ?

Yes, it does; negative resources actually behave quite nicely. (E.g. if you have −100 food, the game informs you you'll need 150 more food before you can train a female with a food cost of 50.)

Updated. Champion naming scheme standardized, e.g.:

maur_infantry_maceman_champion.xml

(instead of maur_champion_infantry.xml).

In D985#41055, @bb wrote:

However Xenophon and themistocles2 should be named to there civ

They're not being used in any template, so which faction do they belong to then? Athens?

Also renamed introductory tutorial.

In D1042#41032, @elexis wrote:

Also take care about the JS files which are referenced in the XML file and need a manual change. You can just tell me the filenames to update (or I can just check the few maps with JS files I guess)

Good point! Here they are:
scenarios/cinema_demo.xml: line 106
scenarios/triggers_demo.xml: line 69
scenarios/units_demo.xml: line 44
skirmishes/gallic_field_(3).xml: line 98
(The other .js files were not renamed, because they already have lower case and underscores.)

Actually I didn't really understand what to do with “hele”, since without this patch there already exist the following files in art/textures/ui/session/portraits/units/:

athen_hero_iphicrates.png
athen_hero_pericles.png
athen_hero_themistocles.png
mace_hero_alexander.png
mace_hero_craterus.png
mace_hero_demetrius.png
mace_hero_philip.png
mace_hero_pyrrhus.png
spart_hero_agis.png
spart_hero_brasidas.png
spart_hero_leonidas.png
spart_hero_leonidas_300.png