FXAA doesn't work on my linux system. On dual boot Windows it's working.
Manjaro 64Bit, Radeon RX 570

Thanks for coming to the party, it is very much appreciated :)

Is there another differential for the Seleucid Cavalry Javelinist? It's also a Persian unit.

Successful build - Chance fights ever on the side of the prudent.

Also include range-check in cmpHeal.

it hides cost change from templates

As is already the case for other technologies, both autoresearched (civbonuses/cart_walls.json) and ordinary (siege_cost_metal.json).

So it seems right to remove inconsistencies if there has been no intent or no valid intent behind having the inconsistencies while actually fostering inconsistencies that are sound historically, gameplay-design and balancing wise.

That I fully agree with. (Hence this patch.)

Perhaps the number is meant to make the wonder more useful than only to gain more population.
If the numbers are equal, then it can incentivize the player to just build a new temple in place instead of moving all the way to the wonder after a long fight.
Another consequences of accumulating power at the wonder is to give the defender at his very center of the city (wonder) a boost, shaping more of an final/end-battle at that place.

As I wrote earlier:

The higher the number, the easier the wonder is to defend (kill some nearby enemies, garrison your wounded soldiers before they're killed, wait some seconds to heal them, send them back to the fight, repeat).
[...] That said, I don't have strong feelings on the exact value chosen

The wonders that are temples have the epic healing aura and there were people putting thought into it (regardless of whether that was a perfect thought).

Actually all wonders are temple complexes, including those that currently lack that aura:

• Stonehenge (gaul) is a pre-Celtic religious site (from the Third Millennium)
• Cancho Roano (iber) is a Tartessian religious site
• The Great Stupa (maur) is a major Indian religious building
• The Hanging Gardens of Babylon (pers) an actor is clearly inspired by Mesopotamian ziggurats (the small room on top is the shrine that housed the statue of the deity)
• The Temple of the Pythian Apollo (sele) is based on a large sanctuary near the Syrian Tetrapolis (Antioch, Laodiceia, Apameia, Seleucia in Pieria), the core of the Seleucid Empire

In D2682#112675, @Nescio wrote:

Ideally heroes ought to be roughly equivalent.

I disagree here, heroes should be different, a "man-of-glass" hero which boosts some non-combat stuff should have way different stats than a tanky Leo, for example.
The player should have to carefully choose what hero fits their strategy, not just pick one randomly because it won't matter much anyway.

Great! I guess the rank changes can be split from this, although they are also compleat and correct.

Method:
I am a bit worried about the procedure of how the resulting patch is determined.

Successful build - Chance fights ever on the side of the prudent.

4 health per second is 4× as higher as garrisoning units in barracks after researching heal_barracks.json and 8× as high as idle organic units regenerating after researching health_regen_units.json, so I would say it's quite quick. The higher the number, the easier the wonder is to defend (kill some nearby enemies, garrison your wounded soldiers before they're killed, wait some seconds to heal them, send them back to the fight, repeat).
I chose 4 as a compromise between the six wonders that heal at 1 and the seven that heal at 8; actually 5 would be closer to the average. That said, I don't have strong feelings on the exact value chosen, so alternative opinions are welcome.
What matters to me is that wonders are equivalent; having one civ's significantly better than another is not really “fair”, especially in wonder victory games.

please split footprint changes from name changes
else I agree, footprints should not be smaller than entity

Isn't the idea of a wonder that it heals extremely quick (as the former tooltips describe)? Thus a rate of 8 would seem more appropriate?

@Feldfeld if you agree, you may accept the patch :)

(Nonetheless, I still hope a team member is willing to review and commit this patch, as well as D2502 (walls) and D2640 (traders). Though footprints are not terribly important, aesthetics matter.)

We generally avoid this kind of patches as it makes SVN blame harder.

rP22460 and https://code.wildfiregames.com/search/query/Q1SCB8AOz4Q0/#R
That said, I agree this patch is unimportant and do not object to it being abandoned; as I wrote in the summary:

I'm not sure it's necessary, but I suppose it doesn't do any harm.

True that.

True, there is a very small (neglible?) effect, but that affects all civs equally.
More importantly, footprint dimensions are determined by what looks good in game, not by balance considerations; otherwise any commit that introduces new actors would be a gameplay patch.

It will do, albeit only slightly.

Ah yes, I see it corrects for it ^^ (Templates.js globalscript L148.)

Actually I don't think adjusting footprints really distorts gameplay balance.

Well it matter for citizen-soldiers and champions.

The difference is you can't train more than one hero. Moreover, heroes have auras. Ideally heroes ought to be roughly equivalent; having one clearly better choice is rather undesirable; giving them all the same health could be a step in the right direction.

Is that in-game or at the structure tree from the main menu?

Accessed from the main menu, but it looks the same when opened from a game session. The tooltip in game also works:

it shouldn't really matter whether they are on foot or ride a horse, chariot, camel, or elephant.
Well it matter for citizen-soldiers and champions.
Maybe they could start at 500 hp and use the same scaling as champions for example.

cf. rP22977

Is that in-game or at the structure tree from the main menu?

Also it would not be shown in structure tree and right clicking to trainable unit. (Side note, I think you need to put that technology somewhere to work if I am not mistaken)

Actually it works:

At first sight it looks good because it removes bunch of duplication, however it hides cost change from templates. Also it would not be shown in structure tree and right clicking to trainable unit. (Side note, I think you need to put that technology somewhere to work if I am not mistaken)

@ValihrAnt please accept if you (still) agree and have verified this patch :)

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

Thank you!

the chariot currently cannot be trained, and will be up to the balancers to include or not.

D2683

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

Without this patch:

• Conquest games are won by destroying all enemy structures and units
• Conquest Structures games are won by destroying all enemy structures; units are ignored
• Conquest Units games are won by destroying all enemy units; structures are ignored

Expected behaviour with this patch:

• Conquest and Conquest Structures games: foundations are ignored
• Conquest Units and non-Conquest games: unchanged

That should be easy to verify by running some test games.

Do to recent comment https://trac.wildfiregames.com/ticket/3190#comment:13 I suggest @Itms after this is commited to upgrade it straight to recent versions as done https://github.com/s0600204/0ad/tree/fmt .

Successful build - Chance fights ever on the side of the prudent.

Send the stopped message only after invalidating the target.

I agree with moving persians to the persian folders, I guess if they were indeed using more horse archers than chariots then they should use that, I agree about the icon change, the specific name change, and the chariot currently cannot be trained, and will be up to the balancers to include or not.

Strings in tests?

Successful build - Chance fights ever on the side of the prudent.

• Add test for stopping.
• Use proper prepare time when starting to heal.

I've never player Conquest only units or only structures, so no clue what is supposed to happen there.

data passed inside timer are not used so removal is ok and it eliminates object creation.
SelecAnimation takes only 3 parameters DEFINE_INTERFACE_METHOD_3("SelectAnimation", void, ICmpVisual, SelectAnimation, std::string, bool, fixed)

Did not have time to get into it yet, so pointing only style.

Successful build - Chance fights ever on the side of the prudent.

Also remove duplicate/depraced "pack" in SetAnimation.
Missed in rP21359.

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

Complete

Nice catch :)

maur_wall_gate.xml, pers_stable.xml

Thanks. D2222 is a similar patch for the {civ}.json data files.

Thanks for reviewing this, I appreciate it!
As for gates, the <Cost> component determines how expensive it is to repair the structure, and loot is 20% of the cost. The cost is indeed lower than building a long segment and upgrading it to a gate, but I think that's justifiable and the lesser evil.
Likewise, building a village tower and upgrading it to a town tower is more expensive than waiting and building a town tower directly.

Remaining pers_stable

Oops, missed that one, will correct, thanks for pointing that out!

Changes are complete.
Changes are good following similar cleaning patches and keeping CC for json.

Successful build - Chance fights ever on the side of the prudent.

The new patch looks to work fine, just tested it.

No errors, warnings, or unexpected AI behaviour? Could you describe what you tested and how exactly? Also maybe update this patch's summary and test plan.
At the very least one should verify it works as intended on:

• Conquest games
• Conquest Units games
• Conquest Structures games
• non-Conquest games

As I wrote earlier, I expect this to work, but didn't test it myself.

Remaining
pers_stable

Remaining
iber_player_teambonus.json

Removed const and gave the child template parameter a different name so it wont complain in gcc.

Not needed with the differing aproach in D2674.