Solved the problem of reflections being too faint.
Solved a problem with artifacts on land; it yielded to a number changed in the Schlick approximation from 1.0 to 1.15.
Found another mistake: The refracted bottom had no incident lighting computed; it was essentially an emitter.
Added a hack to make coasts exhibit a darker band resembling wetness. It was at the cost of draining some of the water (lowering the level, optically).
Added crossing waves at 90 degrees with different scaling, to try to break or hide the tiled look of waves.

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

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

Use if to make it more explicit

Include CI changes

You need an ordered set by insertion, all the others options are just doing the same with extra steps. Maybe you can skip the set and do a linked list if you can guarantee no insert repetition.

Requires an update and rebase.

This is technically not looking for the resource nearest to the dropsite.

An alternative that I would maybe prefer would be to generalise the 'military colony' building, with an 'outpost' building that's relatively cheaper & weaker, but acts as a territory root to claim territory. Possibly we'd want to give another bonus to civil centres though.

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.

Certainly the patch encourages the use of new ccs and military camps and makes the use of theaters more interesting. It also opens up a possibility for new auras / technologies to gain territory.

Good patch. I will include only quinquireme.

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.

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

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

Update AI.

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

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

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

Restore to the previous version + rebase

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

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

More extensive testing.

In D1202#157175, @Stan wrote:

One thing you can do is close this one (abandon) and commandeer the other one so we can finish it.

I didn't commit it cause I could not reproduce the bug D1593 looks simple enough for me to commit it. One thing you can do is close this one (abandon) and commandeer the other one so we can finish it.

I'm not sure which code is correct either. Mine is taken from official documentation but looks dirtier

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

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

Change merc-tech.

Happens :)

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”.

In D3303#157158, @Nescio wrote:

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

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

or something.

Why is that?

In D3303#157158, @Nescio wrote:

(What happened with the Rate?)

Not yet implemented, so no change with how it worked before.

I really wish we would have gone for alphabetical schema ordering, it's soooo easy to autofix. I did it for hyrule and it's pretty cool.

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?)

@Nescio, this diff does not change template values, that is for another diff. It _can_ be done after this one.

In D1718#157155, @Nescio wrote:

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?

Essentially regenerating resources will lead to one of two things:

• it's infinite
• it's micro-intensive and annoying.

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?

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

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

Use a ProcessMessage UnitAI function.
Some minor style stuff.

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

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

Update without gameplay changes.

Did you see D1593? It has a different approach not sure which is better

Update patch for git 0ad

With wxWidgets-3.1.X version compilation now successfull (linux+gcc)
With wxWidgets-3.0.X version compilation failed

@DanW58 I believe these problems can be solved, and I support you.

• Update year
• Value now natural digit
• String can be translated

I am not in favor of increasing the vision range and also the same vision range for all units.

I am willing to accept. I really like this change.

In D1718#157119, @Langbart wrote:

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

Not implemented :)

Decay works for goat (loss of about 2 meat per second).
Regeneration for berries/ fish does not work. rP24938+D1718

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

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

Fix AI.

just note.
slower units would mean more time for ranged units to kill them, they need speed to get to them relatively fast

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 D3488#157098, @borg- wrote:

The unit that really bothers me is the ranged cavalry, they are very slow.

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

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

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

People can always set the speeds differently ^^

Yeah I think we have to face the fact that our current player base, in MP, enjoys 0 A.D. because it's fast.

In D3599#157033, @Nescio wrote:

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

champion infantry archer   : 120 ;  3 ,  3 , 20
champion infantry spearman : 200 ;  8 ,  8 , 20
champion cavalry archer    : 240 ;  5 ,  3 , 20
champion cavalry spearman  : 300 ;  8 ,  7 , 20
champion elephant          : 750 ; 10 , 10 , 20

Some players are reporting that the game is "slower" now, due to the movement speed of some units, which goes against this patch.

For me are nice changes, nothing against this patch.

Well, now we have time haha.
I did some tests and in general it looks good, but the damage of iber champion fire should be increased a little.

After some tests, the attack is really very strong.
It is not an op unit because they are slow and expensive (champions can easily kill for example), but the patch is very valid for me.

Yes it is limited, but not minimal and I feel like making it more compleat also increases complexity _a lot_ which reduces the chance of review/merge. IMHO we can have this as a first step and the internals can be changed/generalised later.
(Also good to notice that the gameplay affecting template changes will (at least should) not be committed.)

I would say the code looks surprisingly clean (maybe I'm misremembering older diffs).
I haven't tested it but it looks OK to me, as in "could be merged".

Thanks! I'll try 3 with 2.
I'm not sure what you mean with the passthrough functions, though? (Things like: TimerHandler, OnMotionUpdate and ConstructionFinished?)

Overall, I think this is an excellent cleanup. See inlines for a number of cosmetic/naming remarks.

Good idea 👍

Orders shouldn't call StopMoving(), but leave handlers should ;)

I'm somewhat surprised that you can actually remove that many, but I guess the logic is sound if orders calls StopMoving() correctly.

Full context + screenshot

I still think that it is not working right now
You cannot add endonyms if you cannot provide the glyphs in which they are printed