So we are now iterating 2000+ templates to get 14 player templates?

So they get picked up by GetCivData.

In D4958#211329, @Freagarach wrote:

Move players.

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

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

Update copyright year and add full diff context

The change to Requires sounds good to me.
We (probably) won't commit this before the release, since it requires the translators to retranslate all the touched strings, for too little benefit.

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

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

Also define the batch size.

In D4964#211602, @real_tabasco_sauce wrote:

@Freagarach any idea how to sort a list of entities by range?

https://code.wildfiregames.com/source/0ad/browse/ps/trunk/binaries/data/mods/public/simulation/helpers/Position.js$10

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

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

In D4964#211601, @Stan wrote:

You said they are ordered by distance. So idx = 0 is closer than idx n when n is > 0

My point is you also need to sort by class :)

You said they are ordered by distance. So idx = 0 is closer than idx n when n is > 0

In D4964#211599, @Stan wrote:

Is sorting less expensive than range queries? What data structure should I use to sort?

It depends but in general yes sorting should be faster.

What sort method is typically used?

Array.sort((a b) => a.weight > b.weight)

Is entities.length the range?? I thought it was the length of the array.

It's not I'm just abusing it to compute a weight.

Is sorting less expensive than range queries? What data structure should I use to sort?

It depends but in general yes sorting should be faster.

What sort method is typically used?

Is entities.length the range?? I thought it was the length of the array.
If not, I am unsure how

In D4966#211595, @Stan wrote:

In the future we need to replace all textures by CLAMP_TO_EDGE, because border color might be only black, white or transparent on some hardware.

Can you clarify this for me? Do you mean texture samplers? What is the border here?

I mean address mode of texture samplers, particularly Sampler::AddressMode::CLAMP_TO_EDGE.

@Stan
Is sorting less expensive than range queries? What data structure should I use to sort? What sort method is typically used?
Would this be done in "fire arrows" or "OnRangeUpdate"?
I am thinking the latter, since this is where new units are added and units outside range are taken off the array.
Sorry for all the questions, I have never written in js before.

In the future we need to replace all textures by CLAMP_TO_EDGE, because border color might be only black, white or transparent on some hardware.

Can you clarify this for me? Do you mean texture samplers? What is the border here?

In D4964#211587, @real_tabasco_sauce wrote:

"Because targetUnits is filled in order of proximity, it makes a lot of sense to just use an array."
Well, after testing, this is true. However, since the order is taken when the units arrive at the area, the closest unit remains the "closest unit" even if it is moved far away. I am thinking "targetUnits" will need to be refilled every 2 seconds. I am not sure how this would effect performance.

Sorry if I wasn't clear =>

• Get entities ordered by position
• Weigh them by closest and class e.g:

let entity.priority = entities.length + (entity.hasClass("a") ? entities.length / 2 : 0)

• Sort them by weight
• Take N entities where N is the number of arrows.
• Shoot them.

"Because targetUnits is filled in order of proximity, it makes a lot of sense to just use an array."
Well, after testing, this is true. However, since the order is taken when the units arrive at the area, the closest unit remains the "closest unit" even if it is moved far away. I am thinking "targetUnits" will need to be refilled every 2 seconds. I am not sure how this would effect performance.

In D4964#211571, @Stan wrote:

I mean you could prefer closest humans?

Some other tower might focus on closest ships, or closest fish

I mean you could prefer closest humans?

In D4964#211547, @Stan wrote:

What was so bad about prefering human units and weighting them higher?

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

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

{} -> null

What was so bad about prefering human units and weighting them higher?

Typo

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

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

increase cc and fort spread, after comparison with archer damage distribution (archers have spread 2.5)

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

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

Also exclude siege units from the first check alongside buildings.

In D4964#211535, @chrstgtr wrote:

In D4964#211534, @real_tabasco_sauce wrote:

In D4964#211533, @chrstgtr wrote:

I’m a no for the reasons stated in the forum thread. (I would be a yes in the community mod to experiment). No need to rehash debate here.

https://wildfiregames.com/forum/topic/106469-non-random-buildingai/

Mainly for the fort vs tower differentiation with respect to overkill right? Feel free to suggest changes, for instance, I can increase the ungarrisoned arrows of forts while decreasing the max arrows of CCs.

Honestly, I think I am conceptually opposed. Big part of it is overkill. This would be helpful against 1 unit at the rate of fire whereas before it was helpful against a lot of units (albeit, that helpfulness could also translate into 0 kills) but the prior system could kill many, many units in a short period of time. The prior system also introduced multiple variables when a player would have to decide whether or not to pushback (health of units and number of units) whereas the proposal makes it a single a variable calculation (just the number of units). I also like the overlapping CCs, forts, and towers "issue" because that encourages more strategic building (even if you dislike this, I think more sense to modify the towers themselves than change the AI).

I don't think your suggested examples are relevant because your proposed system really discourages garrisoning more than a few units (because of the overkill issue). Changing the number of ungarrisoned arrows is beyond the scope of this imo.

One suggestion I do have is that you should increase the dmg of forts, towers, CCs to compensate for lower accuracy. Otherwise, something like a sentry tower will be pretty useless because they will keep missing (warning: this could still be unhelpful and make sentry towers like skirm cav in a21).

I'm not trying to hijack or hold the process hostage. Do what you will, but that's just my opinion (and of some others). I don't know if I right or if you are right (and I don't think we can know until it's extensively played with), which is why I suggest it for community mod

In D4964#211534, @real_tabasco_sauce wrote:

In D4964#211533, @chrstgtr wrote:

I’m a no for the reasons stated in the forum thread. (I would be a yes in the community mod to experiment). No need to rehash debate here.

https://wildfiregames.com/forum/topic/106469-non-random-buildingai/

Mainly for the fort vs tower differentiation with respect to overkill right? Feel free to suggest changes, for instance, I can increase the ungarrisoned arrows of forts while decreasing the max arrows of CCs.

In D4964#211533, @chrstgtr wrote:

I’m a no for the reasons stated in the forum thread. (I would be a yes in the community mod to experiment). No need to rehash debate here.

https://wildfiregames.com/forum/topic/106469-non-random-buildingai/

I’m a no for the reasons stated in the forum thread. (I would be a yes in the community mod to experiment). No need to rehash debate here.

Apply the patch and compile the game (release and debug)

Yes for release and debug

Run the game (release and debug)

Yes for pyrogenesis and pyrogenesis_dbg with -conf=rendererbackend:vulkan -mod=public -mod=0ad-spirv

Fix a bug introduced in Phab:rP18938.

How did u end up in rP18938, instead of rP18758 ?

• for the description of the tooltip, be aware of #6755
  • DelendaEst often uses a more vague language for describing the effect of the BatchTimeModifier
  • github.com/JustusAvramenko/delenda_est

• Units derived from template_unit_ship_heavy.xml still fire infinitely when ordered directly to attack a structure that is just enough in range.
  • Ref: rP25341 (templates/template_unit_ship_quinquereme.xml was renamed to template/template_unit_ship_warship_heavy.xml in rP27341)

Looks promising, let's wait what @Freagarach says about:

Hi, @Stan did you discuss this with @Itms?

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

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

this patch get AI Data, Civilization Data, Save Map and retrieve InitAttributes

In D4961#211483, @real_tabasco_sauce wrote:

keep in mind, they already have the crossbow training upgrade which allows xbows to be trained almost as fast as women (as fast if they have the roman bonus)

keep in mind, they already have the crossbow training upgrade which allows xbows to be trained almost as fast as women (as fast if they have the roman bonus)

In D4961#211478, @real_tabasco_sauce wrote:

@chrstgtr I actually think this might be a good thing to give to champ buildings. It seems that most of the time dedicated champion buildings are less effective than champions trained from barracks/stable.
it makes sense that dedicated champ buildings could train champions better than barracks/stable. A -15% or -20% batch train modifier for champ buildings could go a long way for making champ buildings more balanced compared to training from barracks/stable.

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

@chrstgtr I actually think this might be a good thing to give to champ buildings. It seems that most of the time dedicated champion buildings are less effective than champions trained from barracks/stable.
it makes sense that dedicated champ buildings could train champions better than barracks/stable. A -15% or -20% batch train modifier for champ buildings could go a long way for making champ buildings more balanced compared to training from barracks/stable.

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

update patch to address review

In D4961#211472, @real_tabasco_sauce wrote:

In D4961#211465, @chrstgtr wrote:

In D4961#211462, @marder wrote:

In D4961#211461, @chrstgtr wrote:

In D4961#211460, @marder wrote:

In D4961#211458, @real_tabasco_sauce wrote:

In my opinion, features like this should have a particular set of strengths that make them interesting, rather than ALL of the possible strengths (my thoughts on han in general tbh).

also agreement on that

Separate it out to make it a new tech? For Han or another else. I don’t care, but I generally dislike cutting things instead of balancing them

I would keep it (for the Han) for now albeit a bit nerfed.

And yes cutting features is also bad - I mostly wanted to agree that each civ should imo have a well defined set of positive traits and weaknesses.
Just reminded me on the whole discussion about what type of soldiers the the Han should have and one opinion was: every possibly type.
But to me it doesn't seem that fun to have a faction that has every possible feature stacked.

I agree/am ok with every that’s been said. My only point is that we should modify what we have (even if that is just giving it to another civ) instead of scrapping it entirely.

I don't think removing 1 bonus of the super CC is "scrapping it entirely". It's not wasted effort to delete one line from an xml file.
"Modifying" the super cc would be removing one of its bonuses. It is not good design to allow one feature to have all the possible benefits. Imagine we add a hero that gives a move speed aura, damage aura, armor aura, healing aura, and capture aura to all soldiers. It would be ridiculous.
Halving it to 25% would make it more balanced I guess, but from a design standpoint it is questionable to have one building thats good at everything.

In D4961#211465, @chrstgtr wrote:

In D4961#211462, @marder wrote:

In D4961#211461, @chrstgtr wrote:

In D4961#211460, @marder wrote:

In D4961#211458, @real_tabasco_sauce wrote:

In my opinion, features like this should have a particular set of strengths that make them interesting, rather than ALL of the possible strengths (my thoughts on han in general tbh).

also agreement on that

Separate it out to make it a new tech? For Han or another else. I don’t care, but I generally dislike cutting things instead of balancing them

I would keep it (for the Han) for now albeit a bit nerfed.

And yes cutting features is also bad - I mostly wanted to agree that each civ should imo have a well defined set of positive traits and weaknesses.
Just reminded me on the whole discussion about what type of soldiers the the Han should have and one opinion was: every possibly type.
But to me it doesn't seem that fun to have a faction that has every possible feature stacked.

I agree/am ok with every that’s been said. My only point is that we should modify what we have (even if that is just giving it to another civ) instead of scrapping it entirely.

Had a weird issue on Telegram but it seemed like it might have been a compilation leftover. @Langbart if you have some time, can you test too, just to make sure?

In D4961#211462, @marder wrote:

In D4961#211461, @chrstgtr wrote:

In D4961#211460, @marder wrote:

In D4961#211458, @real_tabasco_sauce wrote:

In my opinion, features like this should have a particular set of strengths that make them interesting, rather than ALL of the possible strengths (my thoughts on han in general tbh).

also agreement on that

Separate it out to make it a new tech? For Han or another else. I don’t care, but I generally dislike cutting things instead of balancing them

I would keep it (for the Han) for now albeit a bit nerfed.

And yes cutting features is also bad - I mostly wanted to agree that each civ should imo have a well defined set of positive traits and weaknesses.
Just reminded me on the whole discussion about what type of soldiers the the Han should have and one opinion was: every possibly type.
But to me it doesn't seem that fun to have a faction that has every possible feature stacked.

Guess it wasn't that easy after all

In D4961#211461, @chrstgtr wrote:

In D4961#211460, @marder wrote:

In D4961#211458, @real_tabasco_sauce wrote:

In my opinion, features like this should have a particular set of strengths that make them interesting, rather than ALL of the possible strengths (my thoughts on han in general tbh).

also agreement on that

Separate it out to make it a new tech? For Han or another else. I don’t care, but I generally dislike cutting things instead of balancing them

In D4961#211460, @marder wrote:

In D4961#211458, @real_tabasco_sauce wrote:

In my opinion, features like this should have a particular set of strengths that make them interesting, rather than ALL of the possible strengths (my thoughts on han in general tbh).

also agreement on that

In D4961#211458, @real_tabasco_sauce wrote:

In my opinion, features like this should have a particular set of strengths that make them interesting, rather than ALL of the possible strengths (my thoughts on han in general tbh).

How about we go for <BatchTimeModifier op="mul">0.8</BatchTimeModifier> / slightly worse then half the current effect

I side more towards removing it:
It is currently considered a "Super CC" which is aptly named.

I like it on a balance level and for "fixing" the issue. Lowering the min range is also nice.

In D4961#211443, @Silier wrote:

What if it would be halfed instead of removed?