The costs you're proposing are rather high, especially for the resistance technologies.
Also, if a third level is inserted, should attack technologies still give +15% damage each? Or should it be lowered to +10% each? Or melee +15% each and ranged +10% each?
For comparison:

1.15^2 = 1.322
1.15^3 = 1.521
1.10^3 = 1.331

In D3681#160460, @Angen wrote:

maybe should be dependent also on their damage?
animal with 200hp doing 40 dmg should provide more XP than animal with 200hp doing 20 dmg (numbers are just examples)
also not checked yet but animals that don't flee nor attack should provide less xp

Animals that run away tend to have less health than those that charge towards you.
Attack damage varies greatly between animals, yes, however, how dangerous they are largely depends on what resistance the hunters have. And also on how quickly they move (animals don't have ranged attacks).
What really matters in the end is how quickly units gain experience, which in this case is how quickly animals are killed; hence health. For comparison, attack damage is not taken into account for soldier experience loot either (all basic infantry grants 100, basic cavalry 130, champion infantry 150, and champion cavalry 200). D3345/rP24606 made the experience loot siege engines give proportional to their health and D2956 does the same for ships.
Basically, I opted for basing it on health only because that's simple to implement and simple to understand.

• include sharks and whales, per @borg-

• lower costs, per @borg-

That's also true for structures, right?
Also, does elevation affect minimum range too, or only the maximum range?

While I'm in favour of removing the number limit, I wonder whether a building distance requirement should be added instead (cf. army camp, military colony), considering mercenary camps can be built in neutral territory too.

• Why Athens?
• Why all resources?
• Why all technologies?

Food + metal is fine too. How much?

What do you think about converting it into a civ bonus?

Sure. Or perhaps change it to food and wood?

In D2854#160285, @Palaxin wrote:

It's not exactly offensive in the sense of destroying an enemy base, but you can place defensive buildings also offensively at your border close to the enemy,

Towers, yes, civic centres, not really (and that's what this patch is about).

And I would weigh the health/capture points of a building a bit stronger than its attack damage because (especially on large maps) it gives you more time to send rescuing troops that would otherwise be too late.

It depends; in some situations health is indeed more desirable, though in others (e.g. towers on hot borders) I'd favour attack damage.
Anyway, I'm not opposed to technologies increasing civic centre health, however, I think that should be considered separately from these technologies, i.e. something for another patch.

I was merely talking about relative strength of phase III upgraded CCs and phase I unupgraded CCs.

Yes; this patch mostly affects ungarrisoned civic centres; for fully garrisoned centres these technologies hardly make a difference.

Or introduce new technologies for those things.

At least three bonuses per civilization would be really nice, but if one has five or six, that's fine too. Not all bonuses have to be equally useful (cf. D3390).

For the record, soldiers are not affected by this patch.

Wood and food are not the problem.

They shouldn't be in late game, but they can be in early game. Being able to afford these earlier (especially pierce resistance) can help with raiding.

Maybe reduce its effect a little to 20%?

Wouldn't that bring it too close to forge technologies, though? (Those increase attack damage by 15% each.)

In D3668#160199, @borg- wrote:

small tower becomes a little stronger, so I gave the idea to reduce the max arrow count.
Max arrow count. 3 instead of 4.

Yes, a little (about 10%). However, the removal of the technology means their arrow count is 1 lower.
I'm not too sure about the tower_crenellations technology either.

In D3668#160195, @chrstgtr wrote:

I agree with the thought that defensive structures need a nerf. And, I think defensive structures were very well balanced in a23 (although I like the addition of more default arrows in a24; correct me if I am wrong that there weren't other buffs to defensive buildings between a23 and a24).

Are you sure the default arrow count was changed? I looked up and compared the relevant structure templates in A24, A23, and A22 and didn't see a difference in arrow counts. Perhaps I'm missing something?
For defensive structures in general, perhaps the most important change is that the effective attack range is now calculated differently (from a circle around the obstruction instead of from the footprint centre). And the changes to make “dancing” harder (e.g. higher projectile speed, slower unit turning) indirectly made structures (and archers) better too.
For fortresses specifically, a lot has changed: they can no construct siege engines or train champions; have a territory root; are cheaper and c. 10% easier to destroy (lower resistances).

I am not sure the proposed changes are necessary as they may nerf defensive structures too much when combined with quicker production times. I would keep it the same for now and revisit if necessary.

There are dozens of open gameplay patches and there is no fixed order in which they would be reviewed or committed. Waiting for something else to change first is generally not a good idea. In principle, each differential ought to be considered on its own. Adjustments can be made, if and when necessary.

The damage-per-second values of ungarrisoned structures:

wall tower:         8 × 0 / 2 s =  0     → 10 × 0 / 2 s =  0
small tower:        9 × 1 / 2 s =  4.5   → 10 × 1 / 2 s =  5
  with technology:  9 × 2 / 2 s =  9
large tower:       12 × 1 / 2 s =  6     → 10 × 2 / 2 s = 10    
  with technology: 12 × 2 / 2 s = 12
civic centres:     12 × 3 / 2 s = 18     → 10 × 3 / 2 s = 15
fortress:          16 × 3 / 2 s = 24     → 10 × 4 / 2 s = 20
army camp:         25 × 1 / 2 s = 12.5   → 10 × 3 / 2 s = 15

Each garrisoning soldier adds another +5 (instead of +4, +4.5, +6, +6, +8, and +12.5, respectively).

We are having a problem in a24 that the defensive structures are a little strong, especially at the beginning of the game. this patch solves the problem in parts.

Yes, I'm aware of that. This patch slightly lowers both the default (ungarrisoned) damage-per-second and the damage-per-second per garrisoning soldier; this should help both in early-game raiding and late-game conquest.

but sentry tower is even more damaged, making the rush even more difficult, maybe reducing the total amount of arrows to 2 instead of 3?

Sorry, I don't really understand the 3, could you rephrase?

Maybe watch tower instead of purged can have another function like vision ranged?

Could you clarify what you mean with “watch tower”?

https://wildfiregames.com/forum/topic/36771-why-are-kushite-and-carthage-mercenary-camps-still-limited/

Another thing I suspect made ranged cavalry less effective is the changed turn rates. Those probably have to be tweaked again, though with extensive testing, therefore something for another patch (I won't). Nevertheless, different turn rates might necessitate different movement speeds; I don't know.

I kept 0.89, well it doesn't make much difference.

The reason I prefer 0.9 is the same why I objected to 0.835 in D3483: it's unnecessarily precise. If it hardly makes a difference, choose the easier number.

Thank you for weighing in! And yes, I was also quite fond of Age of Mythology.

affect both defensive (HP, capture points, capture regen) and offensive (arrow count, range) capabilities.

Actually the proposed technologies do increase both arrow count and base capture points regeneration.
Moreover, your defensive vs offensive is a false dichotomy: structures can't move, their combat function is purely defensive. Doubling a structure's attack damage is fundamentally equivalent to doubling its health and capture points; both mean they can kill twice as many attackers before they're destroyed.
But yeah, the proposed technologies are not that effective; they give a small advantage which might make a difference locally, but won't determine the outcome of an entire match. This is intentional; right now people are already complaining on the forums that defending is too easy; having far more powerful technologies (such as hellenistic_metropolis.json) is probably not a good idea.

The training time increase sounds reasonable and is proportional. As for the speed change, just round it to 0.9. Furthermore, you forgot the heroes:

template_unit_hero_cavalry_archer.xml
template_unit_hero_cavalry_javelineer.xml

In the meantime, you can consider using programmers quotes?

That's what's currently used and one of the things this patch changes. The straight programmer's quotes are far from perfect:

• they don't look as good (also, no difference between opening and closing);
• proper quotation marks are used elsewhere, therefore it's inconsistent to use straight quotes only here;
• they have to be escaped (\"), which can cause problems if a translator doesn't do this properly (by omitting the backslash or inserting a space or something).

Don't worry, I'm not annoyed at you, I'm just having difficulty understanding why Vulcan is complaining in this case.

Thank you for the clarification, I was just curious why you chose to use that word.

“mostly”

@Freagarach wrote:

Apparently the quotes _are_ the issue.

It shouldn't be. They show up properly, both in game and in Atlas. The quotation marks are also present in the wonder_population_cap.json technology and aura. It isn't a problem either in random maps: https://code.wildfiregames.com/D3493#change-B4A2iJ3q2j2S
So why is it problematic for scenarios and skirmishes?

Doing a grep -r movea shows the same typo is also present in the following `libraries/source/spidermonkey/moz78.6.0/ files:

js/src/jit/Ion.cpp:  // As long as JitCode isn't moveable, we can avoid tracing this and
js/src/jit/IonBuilder.cpp:  MGetPropertyCache* moveableCache(bool hasTypeBarrier, MDefinition* thisDef) {
js/src/jit/IonBuilder.cpp:    return cache.moveableCache(/* hasTypeBarrier = */ false, thisDef);
js/src/jit/IonBuilder.cpp:    return cache.moveableCache(/* hasTypeBarrier = */ true, thisDef);
js/src/wasm/WasmInstance.cpp:// Note, dst must point into nonmoveable storage that is not in the nursery,
nsprpub/pr/src/md/windows/ntio.c:DWORD dwRemoveableDrivesToCheck = 0; /* bitmask for removeable drives */
nsprpub/pr/src/md/windows/ntio.c:    // Calling GetVolumeInformation on a removeable drive where the
nsprpub/pr/src/md/windows/ntio.c:                    dwRemoveableDrivesToCheck |= 1 << dwDriveIndex;
nsprpub/pr/src/md/windows/ntio.c:    dwMask = dwRemoveableDrivesToCheck;
nsprpub/pr/src/md/windows/ntio.c:        // Calling GetVolumeInformation on a removeable drive where the
third_party/python/pipenv/pipenv/vendor/pipreqs/mapping:buildout:buildout.removeaddledeggs
third_party/rust/jsparagus/jsparagus/extension.py:    # Consider all shifted elements as non-moveable elements, and insert other

If you spot more typos, feel free to include them all in a single patch. There is not really a need to create a separate differential for each.

• correct and complete

• complete and correct

It's a leftover from the past (Mauryas didn't have rams or any siege engines prior to A23), removing this exception is fine.
The patch is correct and complete.

• exclude ranged cavalry <UnitMotion>

• exclude scenarios and skirmishes

All the other unrelated changes make it hard to review.

The trouble is all changes are related. Take, for instance, the boar. fauna_boar.xml has:

<Damage>
  <Hack>12.0</Hack>
  <Pierce>0.0</Pierce>
  <Crush>0.0</Crush>
</Damage>

However, those zero lines can't be purged right now, because its parent has:

<Damage>
  <Hack>1</Hack>
  <Pierce>1</Pierce>
  <Crush>0</Crush>
</Damage>

Therefore its necessary to clean up the attack nodes in fauna templates.

This patch solves the following error I'm currently experiencing when running the checkrefs.pl script:

Loading GUI XML...
Unexpected GUI XML root element 'page':
$VAR1 = {
          'page' => {
                      'include' => [
                                     'campaigns/common_scripts.xml',
                                     'campaigns/default_menu/endgame/endgame.xml'
                                   ]
                    }
        };

• rebased

That's odd.

Wide character in subroutine entry at checkrefs.pl line 335.

The line in question is:

my $settings = decode_json($map->{ScriptSettings});

I don't know what that means, nor which file, line, or character is causing it.

What do you mean?
I did run perl checkrefs.pl --check-map-xml --validate-templates prior to updating this patch and the only error I got is:

Loading GUI XML...
Unexpected GUI XML root element 'page':
$VAR1 = {
          'page' => {
                      'include' => [
                                     'campaigns/common_scripts.xml',
                                     'campaigns/default_menu/endgame/endgame.xml'
                                   ]
                    }
        };

which I get both with and without this patch, therefore I conclude it's not caused by this. Is there something I'm missing?

• 1 → a, per @Freagarach

• rebased

This diff reverts that and instead increases COMMAND_DELAY in MP. This makes turns 200ms in both SP and MP

Sounds great! I can't say I understand this patch, though treating single-player and multiplayer the same seems sensible. And it would also allow reducing those excessive cavalry melee attack ranges, right?

To be clear, this patch does not lower village- or town-phase territory size. What is does is lower the city-phase area increase to +69% (proposed), instead of +125% (current).

This patch is heavily outdated. Besides, some parts of it have been included in other commits.

Why is “Continue Campaign” listed twice?

While it would be nice to list the cheats and their descriptions somewhere in game, I'm not sure this patch is the best approach. They're listed in yet another location, making things harder to maintain. Moreover, it means more work for translators (especially if this is only a temporary solution). And as you already pointed out in the summary, the cheats themselves shouldn't be prompted for translation, only their descriptions. Also, I'm not sure how many players would expect to find the cheats listed in the manual?
Perhaps you could try adding a separate page for cheats (cf. Catafalques), and do it with JavaScript, JSON, or XML, to allow limiting what gets translated and what not?
(The entire intro.txt ought to be replaced, but that aside.)

Wouldn't it be better to load them directly from the simulation/data/cheats/*.json files? Like what @s0600204 did for the civilization bonuses etc. in the civilization overviews?

• added range overlay to quinqueremes, per @borg-, and fireraisers, for consistency
• did not add range overlay to other ships

Great!

How about the following?

• finish a resource
• return to the nearest dropsite
• go to resource nearest to gatherer

What do you mean?

• purge “no starting walls for Iberians” sentence
• fix some linter things

Three skirmish maps (libyan_oasis_2p.xml, sahyadri_buttes_5.xml, watering_holes_4p.xml) mention Iberians don't have starting walls. Wouldn't it be more consistent to simply purge that sentence from those three descriptions? Currently only about half of all skirmish maps actually have starting walls for the Iberians.

Civic centre costs ought to be revisited regardless of this patch. Right now they're very expensive, making it really hard to rebuild after your last centre has been destroyed. I think e.g. 600 wood, 300 stone, 0 metal would be more reasonable. Anyway, that's something for a different patch.

Thank you! I've tried your patch, it works, and it's really much better than the current situation!
I'd even go as far as saying that if there is an A24c, this should be included.

In D3303#157162, @Freagarach wrote:

Why is that?
[EDIT] Ah, I think you mean ResourceGatherer/BaseSpeed?

Yeah, I did: the current situation (replacing the rates of each resource sub-type) was done to ensure treasures were still gatherable; now they're in a separate node, that technology file can be cleaned up significantly.
When writing my previous reply I copied and pasted the wrong lines, I apologize for the confusion, I should have checked before clicking “Submit”.

Apparently I misunderstood, thank you for the clarifications.
I fully agree this patch should just contain the necessary code to support resource regeneration, without actually changing gameplay here, which can be done later in mods or future patches.

You should also replace the last modifications in simulation/data/technologies/unit_mercenary.json with:

		{ "value": "TreasureCollecter/MaxDistance", "replace": 0 }

or something. (What happened with the Rate?)

In D1718#157120, @Freagarach wrote:

In D1718#157119, @Langbart wrote:

Regeneration for berries/ fish does not work. rP24938+D1718

Not implemented :)

Why not? Resource regeneration makes especially sense for fish and fruit. Moreover, I don't really understand why it would work for animals (meat) but not for them (fish and fruit), they're not that different, are they?

If anything, making the default Walk Speed "10" might make more sense.

Given that archer attack ranges were lowered (from 72+4+4 to 60) recently, I think a lower base movement speed is justified. Moreover, some people somehow complained maps were smaller; having a lower base speed could give a larger feel (as does a smaller land grap: D3601).

The unit that really bothers me is the ranged cavalry, they are very slow.
For infantry I would be willing to see it a little faster, but I have no problems as it is now

If infantry is a bit faster and cavalry is left unchanged, then ranged cavalry will effectively be relatively slower.

I don't think we can make Archer cavalry much faster without completely breaking the game though.

I think changing the 0.835× to 0.9× could be tried, especially since cavalry melee ranges are much longer now (D3483).

Unrelated, but are you up to make a "normalise armour" path?

Yes, I am; I was actually planning on that for A25 anyway. D3397/rP24689 did it for animals, D2956 does is for ships, and D3600 does it for foundations. Once that one is committed I intend to standardize structure resistances; soldiers can follow later.
As for elephant archers, 300 + 4,3,15 is about the same as 400 + 1,1,12; I could include that here, if you like.

(@wraitii Please mind the effect this has on poison/fire damages.)

I don't think the poison (Mauryan maiden archer) and fire (Iberian champion cavalry) damages are particularly balanced right now.

In D3599#157026, @wraitii wrote:

In D3599#156997, @borg- wrote:

Having to build ele stables is a fair drawback, but they are _strong_ units.
Having them take 2/3 pop would make sense IMO given how bulky they are.
I'm not sure about the HP increase - I think they also have higher armor - need to check consistency with other eles and with cav.

−50% damage with +50% health makes them effectively 25% weaker (0.5×1.5=0.75).
One should also keep in mind elephants can't gather and cavalry moves much faster.

I'm not sure about the HP increase - I think they also have higher armor - need to check consistency with other eles and with cav.

Health and resistances:

basic infantry             :  50 ;  1 ,  1 , 10
basic infantry spearman    : 100 ;  5 ,  5 , 15
basic cavalry archer       : 100 ;  3 ,  1 , 15
basic cavalry spearman     : 160 ;  4 ,  3 , 15
elephant archer            : 200 ;  4 ,  3 , 15

In D3563#156369, @borg- wrote:

Any opnion @Nescio ?

D3602