In D1343#55589, @Nescio wrote:

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.

When artists will provide the Mercenary Camp, the mercenary technology will be available from that building, in that way it will be consistent with any other civ with a dedicated building.
The topic is going in a more complex direction involving stuff that probably needs to be redesigned, thus discussed and approved by devs.

1. it makes perfectly sense that Maces/Hammers do Crush damage instead of Hack like an Axe or a Sword, still there is an issue with units Crush armor as most unit (if not every) has high crush armor ( i didn't go further thus i don't really know the reason why ). Reducing every organic unit ( infantry, heroes and cavalry, supports and perhaps elephants ) crush armor would result in more room for crush damage dealers like sieges ( which shouldn't be allowed to attack units, for such a system to work ), slingers and eventually Macemen. This is the reason why splitting Macemen damage ( yoddhas too ) from pure Crush to Hack and Crush would be a workaround for the system to work, for the moment. They would be trained and play a role in fights and not just in sneaky sieges, at least.
2. it makes sense for Axemen to be Hack damage dealers with a bonus against sieges and wood structures ( which aren't really defined in the current system, but i am talking by abastraction ) and no penalty at all in armor. Soft counters are useful to handle such particular cases.

While i agree with the initiative, i still don't feel comfortable with women able to gather meat at same rate of soldiers, and probably with the fact that infantry have different gather rate than cavalry where the only real advantage is to use horses to be able to chase animals and faster delivery meat to dropsites.
Other than that, I am of the opinion that the "gather_animals_stockbreeding" is obsolete as it is a must to search anyway for a continuous flow of meat gathering. So why don't just fix corrals training time at "researched tech" training time and remove that tech replacing it with a cavalry only heardable gather increase? 5x gather rate is fine for corrals gathering.

sorry for the funny mistakes.
Slaughter max range has been fixed to 2

Referred max range reduced to 3.5 for parent templates.
Spearmen add 1 max range ( 5 was too much ).
Pikemen multiply basic max range * 2 ( for a total of 7.0 ).
Dogs and women have 2.5.

I remind you that the patch is intended to be an estetic patch only. Any gameplay change is unwanted thus I am still open for suggestions.

In D988#54967, @temple wrote:

Making champions and heroes consistent with citizen-soldiers is good.
The new values are sword 3.5, spear 3.5, pike 7. But it seems to me like spears should have a longer range than that? It looks like 5 is good.

I tried 4.5 for spears and apparently it was good too ( for hellenic spears at least ) as there wasn't any significant change from the esthetic point of view. Still i agree that spears should have longer range than swords. While higher range suits good for hellenic spearsmen, other type of spearsmen ( i.e. celtic ) are equiped with shorter spears and 3.5 seemed to be a good compromise. Still 4.5 seems good.

The new values for cav are sword 4.5, spear 5. But here I think they should have the same range as their infantry counterparts -- their weapons aren't any longer. You can use the actor viewer in atlas to compare. So I'd do sword cav 3.5, spear cav 5.

This seems reasonable.

Rams and elephant are siege, hard to judge. But women maybe 3, dogs 2, what do you think?

Sure, I'll have a look at women and dogs animations too. Sieges and elephants are hard to judge as they interact with buildings which seems to have smaller obstruction than their textures size. Matter of fact rams intersect roman fortress while attacking and workers intersect with gaul fortress while repairing/building.

Sword infantry max range was changed in rP16285 for balance, but if their range remains smaller than spear then there shouldn't be much of a difference in gameplay. Otherwise doesn't look like ranges have been adjusted. There's D981 which changes how range is used, so all the range values might have to be revisited in the future.

What really changes is just the first hit an unit can perform when he reaches the enemy unit. I didn't really notice if the hit is performed when the unit reaches the opponent instantly or if it waits attack rate time before the first hit.
Lower range unit will get closer to perform his hits anyway, too long range for short range animation/weapon looks not natural in game as they can't even reach each other ( the clear example are champions with the same max range ).

I'd say that pikemen available from Town Phase is fair enough.
Other civs have more available units in Town Phase and can't find a good reason to have pikemen available in City Phase yet.
As Axe champions are a brand new unit, i have no strong opinion on that. Just -1 something armor and +30% attack against something seems not good numbers.

athen_infantry_spearman_b.xml now correctly inherit max range from template_unit_infantry_melee_spearman.xml instead of having own MaxRange entry.

In D988#54458, @Nescio wrote:

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

In D988#54449, @temple wrote:

Can you update the patch to just the range changes?
Did you test with large armies? Did the battles have different outcomes (i.e. do we need to rebalance attack stats too)?

In D1279#53769, @temple wrote:

I've committed the changes listed in the summary. Thanks for everyone's input. I was hesitant about the spear cav buff so I fell back to 5.5 dps instead of 6.5. (They trade about evenly with sword cav, but they cost wood instead of metal so that's a win.)

I'm still concerned about rushes, particularly with spear cav. They shouldn't be impossible to defend, so maybe we'll need to reduce cav speed at least in the village phase. And of course we'll probably need to make some other tweaks as well. I guess the best way to find out is to play a lot of games! Hopefully lobby players will migrate to svn and we can get some feedback.

As I am also involved, I'll try to explain some changes:

Thank you for the interest for the diff (even if implicit ? ).
The parent revision explained the arc issue, thus removed.

I think not, but I'll check since it seems reasonable to have all sounds inherited from template_unit and then overriden

I'll update the proper patch asap.

Whenever the game is started without any mod enabled, the Quit button replaces the Cancel button and that's really intuitive now.

Accepted after the discussion about buttons organization.

In D859#44412, @elexis wrote:

So you're saying ["CitizenSoldier Infantry"] means Citizen and Infantry, but "CitizenSoldier Infantry" means Citizen or Infantry`?

according to: https://trac.wildfiregames.com/wiki/Aura_Templates

In D995#44421, @elexis wrote:

I agree with increasing Loot of promoted units (not to confuse with Looter). I hate the whitespace, every property on its own line IMO, temple has a patch.
Agree with mimo that it should be just a bit.

i thought that having tabulations between fields on the row would make comparisons easier. I will provide to put every property on its own line as long as i understand the direction of this patch.
Even if I am still of the opinion that the loot values are good (taking care of higher rank units is strategically correct), perhaps +2 at Advanced and +3 at Elite ranks would suit better?
Perhaps healers may give some amount of food and metal instead of 1 of each resources like women.

Although avoiding global auras is a good policy, the original idea was to force the player to garrison a ship to benefit from a good bonus with the weakness to lose the batch, the hero and the ship if the ship sinks ( which is interesting ) but the aura is exploitable as long as players are allowed to garrison and ungarrison the hero as they please in order to have many ships benefit from the aura and it is unwanted. Perhaps not game-breaking for the high metal costly champions but the situation gets different when units cost is lower e.g. mercenary archers and possible affecting training cost auras.
Directly affecting the interested units instead of the structures training them grants more control over the training flow.

In D1043#40987, @elexis wrote:

That doesn't restrict the 'healing' to siege units does it?

is this aura json file necessary?
standing at GarrisonHolder component, there is the BuffHeal entry which job is to regen health of garrisoned unit class already.
( while at it, i guess that 1hp / sec for elephants is kinda low ).

In rP20446#24800, @Stan wrote:

True. :)
But starting from there everything n could be committed from WW2 tanks to entire civ because why not. It's extreme but you get the idea. Maybe we should have a special optional mod for scenarios. Dunno

I kinda agree with mimo, diversity is needed among the civs and "unused" doesn't mean "useless".
my personal opinion is that Yoddhas are supposed to be an alternative to mechanical sieges since they basically only have crush damage despite they are vulnerable to pierce damage aswell like War Elephants, standing at their current concept, which may be interesting but not polished. Thus the siege may eventually replace yoddhas which are rarely used ( they aren't very cost / efficient in the current version, at least) and maiden may eventually be able to switch between weapons in order to at least keep some unique traits and not to become an "alternative textured" Persia.

is this screenshot ok?

In D408#40402, @bb wrote:

Ai doesn't work, or at least warning the value at some different places after modification doesn't return the new value (by placing warns at some places in the entity.js ai component). Didn't test if this is the case for other values then loot too, or maybe I tested the wrong places: a "proof patch" for the ai would be nice (just something that warns the value in the AI code before and after a tech)

In D408#38502, @Nescio wrote:

This patch would be more useful if it would only support modifying loot via technologies (instead of actually using it to increase the loot of promoted units, which might be controversial).
Because this is something I was looking for, I've incorporated your code into my mod (0abc), and it seems to work:

• 0+1=1
• 5*2=10

However, less suitable is:

• 1+0.5=1.5
• 5*1.5=7.5

Cost and loot resources are supposed to be integers (I believe), therefore you might want to add a function to round off values (floor, ceiling, or whatever).

Perhaps this may be a good starting point to compare units of same class in order to see how different weapon wielding units sharing same price-logic perform in game.

I really understood what's that about. But don't worry, I got the feeling that something fancy will come.
Indeed there is a cost inconsistency because melee total cavalry cost is 135 instead of 140 like happens for cavalry ranged.
I am not totally against such a patch but I simply wanted to point at the fact that, although the current melee cavalry cost is unusual, the higher than average wood cost requires different decisional paths ( e.g. more workers on wood or even the research of the wood gathering technology from storehouse) which increases the decisions doable by the player.
I am aware that there are team decisions constraints, anyway I would have given priority to skirmish cavalry situation first over any other balance related stuff that.

Indeed it is, what I meant was to point out of different strategies used in "rush" situations thanks to the price difference.

Actually I am of the opinion that having different resources costing units would increase number of decisions a player can take. ( I am quite ok with the fact that a player has to invest wood into spearmen to deal with wood costly melee cav )
Still, to keep costs coherent with a total sum of 140, melee cavalry ( thus spear cavalry and sword cavalry ) could have the current cost with wood cost increased by 5.
( I am not gonna talk about champion cavalry health coherence here )
( cost won't affect unit decision if effective. take skirmish cavalry as example )

Owner allies can still see the timer going on despite a player loses the wonder.
I wonder if displaying the owner team number also may be useful to recognize which team is gonna win in case of more than 2 teams in a game.

uploaded the formula suggested by mimo.
I tried to update tooltips aswell, but they aren't very accurate though.

In D879#37099, @mimo wrote:

In D879#37098, @Grugnas wrote:

perhaps a sqrt growth goes against the initial design of linear gain where a tangent could have a more flexible impact depending on the map size, thus the impact degree the trade has in such a game.

I don't understand this comment: these are two different effects.
tanh drives the behaviour vs dist for a given map size.
sqrt scaling drives the normalisation of the trade multiplier for different map sizes

so both were supposed to be used         gain/dist = tradeMultiplier(at 1024)*sqrt(1024/size)      *      size*tanh(dist/size)

That's what was shown in the plots above.

What you propose in your last patch is the top-right which is definitevely not satisfactory

I am sorry, i replaced the tanh with sqrt and the result didn't satisfy me. That's why i raised a concern.

Ok, after some testing using sqrt instead of tanh, I have to retake back my position in favor of the current uploaded formula as long as sqrt doesn't change at all the current gain/dist ratio in normal map which is unwanted. Someone may argue that the gain could be changed by tweaking the multiplier but having as tan(gain * affecting trade technologies) [i use this formula as explanation thus not intended to be implemented] the gain/sec * affecting metal gathering technologies of a citizen soldier worker is direction this patch wanted to have.
perhaps a sqrt growth goes against the initial design of linear gain where a tangent could have a more flexible impact depending on the map size, thus the impact degree the trade has in such a game.

2. second point is the scaling of the gain with the mapSize (the original goal of this ticket). The more i think about it, the more i'm convinced that such a scaling is too strong.

To illustrate that, the plot tradePerDistVsSize.png shows the ratio gain/dist vs dist for 3 map sizes (tiny=512, medium=1024 and giant=2048). The top-left is without any scaling, and the top-right with the scaling with mapSize as originally proposed in that patch. None have satisfactory properties. So i come back to my initial proposition to scale by sqrt(mapSize) bottom-left which looks more adequate to me, or alternatively to only scale part of the gain as shown in bottom-right where half of the gain is not scaled and half of it scaled. This partial scaling (more or less equivalent to sqrt scaling when both parts are 50%) is maybe better for modding as it would allow to easily change to any setting between the two upper plots (left = 0% scaled and right = 100% scaled) by varying the proportion if we add it in some template.

Thank you for the plots, now the comparison between the different formulas is even easier.
The gain/dist growth of the bottom-right plot seems to fit most the intent to let the trade to have a bigger impact on the game over time (at least for small sized map) but the saturation for the 1024 size is too strong thereby may result in a really too low gain/dist, thus i totally agree on using the bottom-left plot.

this is a nice improvement in order to keep things more transparent and easier to compare.
I wonder if it makes sense to have absolute values for "root" unit and building templates like (infantry, cavalry, heroes), (economy, military) while looking at child templates.

In D859#36182, @fatherbushido wrote:

In D859#36176, @Grugnas wrote:

Is that a recent update? I recall thst different classes are defined by different strings thus space is interpreted as AND

I could be sarcastic. I won't.

Is that a recent update? I recall thst different classes are defined by different strings thus space is interpreted as AND

this patch should be complete already.
this is the diff new sound:

</Identity>
<Sound>
  <SoundGroups>
    <trained>interface/alarm/alarm_create_infantry.xml</trained>
    <order_heal>voice/{lang}/civ/civ_{gender}_heal.xml</order_heal>
  </SoundGroups>
</Sound>

EDIT: just noticed that i commented but the comment has never be sent..........
Anyway looking at the patch again, seems like the patch has to inherit the new template

sorry if i wasn't clear. I meant that this unit template name is inconsistent because it is a mercenary but not mentioned on its template name:
https://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/simulation/templates/units/mace_cavalry_javelinist_b.xml

macedonian cavalry javelinists are mercenaries

abandoned because of different design decision.

In D905#35328, @Nescio wrote:

quoting my self:

2% for a total of 65% max movement speed for Trireme and ~45% for Bireme warships.

Those numbers are wrong, 2% each for 30 units is actually more than twice the value with 1% each. Do the math, and keep in mind the bonus stacks (compound), then you get:

 x  1.01^x  1.02^x
 5  + 5.1%  +10.4%
10  +10.5%  +21.9%
15  +16.1%  +34.6%
20  +22.0%  +48.9%
25  +28.2%  +64.1%
30  +34.8%  +81.1%

Personally I think a 10% speed bonus is significant and can already make a difference. Besides, Athenian champions are infantry and also increase the number of arrows fired.

In D905#35314, @Nescio wrote:

Don't you think 2% is too much? +22% and +35% are already huge bonuses, and 1.02^20=1.49% and 1.02^30=1.81 are ridiculous; why would a fully loaded trireme move +81% faster than one without passengers? I think the +1% aura bonus is already high enough.

Perhaps 2% for champions only isn't too much because having 30 champions in a ship is quite risky. Despite champions perfomance on land, in naval games having sea monopoly is crucial and having 30 champions garrisoned in 1 ship only is counter productive.
quoting my self:

2% for a total of 65% max movement speed for Trireme and ~45% for Bireme warships.

While using the Observer Perspective, i experienced thi issue:
the player 2 structures capture point status bar color doesn't match with the player color ( they are diplayed green like hp bar).
I don't pay attention during the game but after something went on in game, new built structures only correctly displayed capture bar. Using Player 2 perspective, the bars appear correctly as intended.
here is a screenshot.

added Sword class to the affected Champion not Mercenary class.

In D904#35300, @temple wrote:

I think like this it would apply to the gym champs as well? Might need to add in "Sword".

Perhaps this diff isn't needed at all because D904 addresses the issue in a different way.

Despite the aura initial concept was mainly addressed to Cretan Mercenary Archers in order to equally distribute them in the Warships, now Champions not Mercenary units implement this aura.
Since champions are costly units and since they don't really give a nice contribute while garrisoned in the ships, I'd rise the aura effect from 1% to 2% for a total of 65% max movement speed for Trireme and ~45% for Bireme warships.

updated. Now the aura directly affects the wanted units.

In D905#35265, @Nescio wrote:

Sorry, I do not understand. Which technology do you mean? This “marine” aura does not need, nor use, your marine class. Just inserting:

<Auras datatype="tokens">
  units/marine
</Auras>

in the athen_champion_marine.xml file is sufficient to apply the units/marine.json aura. No civ requirement is necessary at all, since only the Athenians can train this Athenian champion unit.
The “Marine” class is completely unrelated to this marine aura (D905). You introduced the marine class (D903) to distinguish units trained at ships from other units, which is necessary for your proposed Themistocles aura (D904).

Sorry, I mean athen_marine aura. "athen_marine" name seems quite accurate because civ specific.
I am kinda convinced of having the aura to affect non mercenary champions only.
Casually i resolved the D904 with no need to introduce a new class, but would be nice to have all units templates trainable from ships sharing the same format to avoid confusion:
i.e. pers_cavalry_swordsman_b_trireme into pers_marine_cavalry_swordsman_b

In D905#35253, @Nescio wrote:

So there is D903, D904, and D905, which are all related. Why not do everything in a single patch? That would have been less confusing, for me at least. And if not a single patch, then that class does not belong here in this marine aura patch. but in that Themistocles patch.

I splitted the patches because D903 is a proposed fix to a possible "abused" and perhaps unwanted effect that perhaps could be resolved in a better way by a more experienced dev, thus i spitted the Marine class part in the D904.
D905 ( this one ) is a proposal unrelated to the aura effect fix but uses the Marine class.

Anyway, it doesn't hurt to apply the Marine class also to the Persian cavalry, because the Athenians can't train them, and the Persians can't train Themistocles.

If you mean to use Marine class to distinguish ordinary units from special one ( actually Persian cavalry is special ( they even cost more metal ) ), then I agree. in that case i suppose i should add a requirement in the athen_marine technology in order to be specific for Athenian civ only (as i said this is intends to be a civ bonus related to the famous greek naval supremacy especially against Persian navy).

In D905#35249, @Nescio wrote:

To clarify: if this patch is implemented, I think the *aura* (which increases speed) ought to be applied to the Athenian marine champion only, and the *class* (which does nothing at all, as far as I understand) consistently to all units trained at ships.

This "movement speed aura" is remotely based on Themistocle Athenian hero aura.
This helps to explain the Marine class: D904.
This is an athenian civ bonus, it shouldn't be applied to other civs.

In D905#35247, @Nescio wrote:

In D905#35234, @Nescio wrote:

An interesting idea, I think I like it, however, I would prefer to limit the aura to the marine champions, and not apply it to those cheap Cretan mercenary archers (also because (other) Cretan mercenary archers are available to mace and ptol).

I partially agree because you are right by saying that those archers aren't "Marine" units and the file name tricked me, also the fact that they are actually trained in docks only (couldn't find the reason why Cretan Merchenary Archers are available from docks after the research of "Iphicretean Reform" technology though) . Initially the "Marine" class has been thought for Themistocle aura, standing at D904.
The intent was to give a slight advantage ( not in damage ) to Athenians in sea fights where the only contribute units can give is to increase the max arrow count of the warships.
After some reading i found this from wiki:

A varying number of marines (epibatai), usually 10–20, were carried aboard for boarding actions. At the Battle of Salamis, each Athenian ship was recorded to have 14 hoplites and 4 archers (usually Scythian mercenaries) on board,[53] but Herodotus narrates that the Chiots had 40 hoplites on board at Lade[54] and that the Persian ships carried a similar number.

this could justify the
Standing at this reading would be reasonable to classify all not Mercenary infantry champions (thus: Spearman , Archer, Swordsman ) as Marine and let the aura apply to champions only (in that case the aura would become an athenian civ bonus).
Also,

EDIT: And rename the aura to “marine” (without the “athen_” part), just in case someone wants to apply it to other factions and units in a future release or mod.

The initial thought was to have different auras for Marine ( despite the only marine are the champions from Athene ) units only but yes, your statement makes sense. Thank you for pointing that out.

In D879#35039, @Nescio wrote:

In D879#34359, @FeXoR wrote:

@linear gain: Then I'd always chose the shortest possible trade routes since it's the same amount of resources per time and trader no matter the distance ... and nearly no risk involved.
@square is to much: What about an exponent about 1.5?

In general I don't understand why the map size should play a role here. Because it's less likely an enemy stumbles about a trade route on large maps?

In D879#34443, @fatherbushido wrote:

Agree that capping (not done in the proposal) is more important than taking care of the size of the map.
Agree that tanh or any logistic function will do that job.
Agree with mimo.

In D879#35036, @mimo wrote:

In D879#35029, @Nescio wrote:

Personally I still don't see why trade gain ought to depend on map size (actually I disagree with the principle), but if the concensus is this is necessary, I won't object. Besides, replacing the distance squared formula is certainly an improvement.

I think people should express their concerns/opinions: as i said previously, while i understand the need for scaling, i always thought that a scaling with mapSize is too much and i would have favoured something in between no-scaling and linear-scaling, so my sqrt(mapSize) proposition in previous comments. I didn't insisted on it because i thought i was the only one with such opinion, but if that's not the case, ...

Well, at least I'm not the only one ...

In D879#35036, @mimo wrote:

I think people should express their concerns/opinions: as i said previously, while i understand the need for scaling, i always thought that a scaling with mapSize is too much and i would have favoured something in between no-scaling and linear-scaling, so my sqrt(mapSize) proposition in previous comments. I didn't insisted on it because i thought i was the only one with such opinion, but if that's not the case, ...

perhaps this is easier to read?
While on the code, aren't checks on gui components e.g. cmpTrader meaningless because they are always true?

In D895#34991, @fatherbushido wrote:

The only thing that struggles me is: some of those technologies display 15% rate in tooltips and multiply by 0.15 in the code. Is it a real rate or is it a repeat time like for the attack and heal? ( thank you for the quick reply :) )

Can you precise? (also take care that sometimes we can do a computation in the tooltip)

reverted and updated comments.

In D895#34859, @fatherbushido wrote:

I don't care of strings, you can find something better. I just focus on numbers. And that's not a rate but a repeat time. And also consistency.

The only thing that struggles me is: some of those technologies display 15% rate in tooltips and multiply by 0.15 in the code. Is it a real rate or is it a repeat time like for the attack and heal? ( thank you for the quick reply :) )

In D895#34984, @fatherbushido wrote:

In D895#34859, @fatherbushido wrote:

Rate ->RepeatTime

• first step:

"Healers +25% healing rate" -> Healers -25% heal repeat time"

• second step:

Rate -> RepeatTime change in the code

Probably making available every "basic" unit from the civic center helps players to well understand type of workers and soldiers, thus I'd keep cavalry in the civic center.
Women are the main fruit and grain gatherers.
melee and ranged infantry units for general purpose from gathering to build military structures.
cavalry for scouting or gathering meat ( they are the fastest meat gatherer over there).

In D894#34930, @mimo wrote:

As i said in the forum, i believe now that this kind of patches is useless: it would be more useful to do a patch which uses relative ranges for all units and structures (first without any changes in the final ranges to allow an easy and non controversial review, and then (and only then) play with ranges.

Ok, indeed this patch didn't consider such changes and those weren't even in the main purpose of this patch.

( last update used @mimo tanh(d/mapsize) suggested formula ).

In D894#34880, @Nescio wrote:

Although I'm not opposed to lowering infantry archer maximum range to 60, I think it would be a bad idea to reduce vision range below that. If units are attacked, they ought to be allowed to see by whom or at least from where they're attacked.

This situation happens only while attacking because the defender can train archers (ptols, mauryans, carthage, persia) and have vision of the attacker only if there is any melee unit in phase 1 (otherwise they are forced to move at vision range distance). In my opinion this defender "surprise effect" is interesting.
Attacker can see from where the arrows are coming from.
Although those opinions, a vision range going down from 80 to 60 is barely noticeable.

In D894#34874, @fatherbushido wrote:

The argument would have been:
"There is then the issue of range/vision consistency (refs Attack, Heal, UnitAI)."
That implies having the whole picture in mind (And also other things).

Take archer units: they have 60 attack max range and 40 vision range in phase 1. In phase 3 they will have 60 attack max range and 64 vision range. Elite Rank archers in phase 3 will have 68 attack max range and 72 vision range.
All units have higher or equal vision range than their attack range in phase 3. Which consistency do you refer to?