Is this even something that will actually be used in the vanilla game? Just balance wise? Because with the current implementation, where the fire can actually spread, this would completely shift balance and strategy of the game.

Made the function more elegant as per @Stan 's recommendations.
I checked ships and towers, preference was in the correct order.

Thanks for the tips @Stan , I'll see if these changes work.

uses sort to fix proximity, uses GetPreference() to handle preferred classes instead of hard coding.

In D4964#211953, @Stan wrote:

For 1) I think siege/structure should not be hardcoded but instead get the attack preference. You can set that to whatever in the template. Here it's pretty bad cause it's not easily moddable and we don't want balancers to have to mess too much with the code

On that note, what do preference values look like? From the original code, it looks like 1+ some value.
In the xml files it just says "preferred class", and I can't find the value of this preference.

In D4964#211953, @Stan wrote:

For 1) I think siege/structure should not be hardcoded but instead get the attack preference. You can set that to whatever in the template. Here it's pretty bad cause it's not easily moddable and we don't want balancers to have to mess too much with the code

In D4971#211942, @marder wrote:

In D4971#211842, @wraitii wrote:

I think you could probably bump to from 0.8 to 1.2 and it would look a little better, but this seems like a good change to me.

1.2 seem fine - if there are no objections from anyone else I would commit this soonishly.
I also tried this for siege & elephants but there the spinning issue seemed to get a bit worse.

my current values:
0.2 0.1 0.3 0.9 0.65 0.2 0.9 0

In D4970#211946, @wraitii wrote:

In D4970#211945, @real_tabasco_sauce wrote:

By "Bog down" is that the slowdown when units clump while moving? If this is already slightly in effect currently, I think players will dislike increasing it. I think we should avoid introducing any sluggish movement as much as possible.

Yes, it's that behaviour. The current settings are quite strong, the diff settings are rather weak, I suggest maybe lowering them a bit from SVN

(also my comment above applies to the diff, not your revised numbers)

In D4970#211944, @wraitii wrote:

I did some actual testing -> I maintain my 'needs revision'.

• The static extension is too high. Some units get stuck in a loop of 'gather, get pushed away, go back to gather' too often on berries and things like that.
• I like the changes to the movingSpread factor, that seems to have good behaviour.
• I dislike the changes to the pressure system. It basically removes the 'bog down' thing which is a feature IMO. I'd rather lower both values by 0.1, given the increased MovingSpread.
• MinimalForce comment is indeed correct, so the new value must be < 0.25. Take two units, click them to move to a specific point, they will overlap and not un-overlap. This is broken.

Overall I think you should keep the MovingSpread tweak, do a slight update to Pressure, and see how much you can tweak static extension before it gets problematic for berries and such.

In D4970#211889, @wowgetoffyourcellphone wrote:

I tried these settings in DE. It's hard to see any "improvement" without more testing, but I see no new negative effects. I'll test them some more.

In D4970#211869, @wraitii wrote:

Yeah trying to improve is certainly fair, as I said. I guess I'm saying it's probably better to end of the side of 'smooth, clumped-up pathfinding' over 'slow, spread-out'.

What do you two think of these:
1.2, 1.1, 4.0, 0.9, 0.9, 0.2, 0.7, 0.2

In D4970#211864, @real_tabasco_sauce wrote:

Yeah, as written, units can push each other off of resources. Ex. women on 1 bush, soldiers chopping 1 tree.
However, this is very brief.

Yeah, as written, units can push each other off of resources. Ex. women on 1 bush, soldiers chopping 1 tree.

In D4970#211849, @wraitii wrote:

Sure, seems sensible. Testing on a wide scale would definitely be a good idea.

The issue is imo in all situations to a certain degree, hence me changing all values.

For what it's worth I don't think you can completely fix the 'problem' _and_ have smooth pathfinding. There's some level of abstraction to an RTS that makes movement somewhat unrealistic by necessity.
Just as an example, there was a thread on reddit recently about how people don't accurately count units in Age of Empires 2, because the archer units can bunch up a lot more than you'd expect. That's part of the skill of that game, and you can't really "fix" it, there's not really a problem.
Doesn't mean we can't improve on current values, but something to be aware of.

Well, currently the unit pushing values allow for large armies to condense into blobs. When this happens, its hard to tell how many units you are up against.

@marder thanks for making this patch. I think more pushing is a welcome change, as currently armies can squish together too much. I am not sure how much pushing is needed, but I am thinking that plenty of players might call it too much pushing. Perhaps 1.25 would be better for StaticExtension, but I have little familiarity with these values and I trust your judgement.

In D4964#211610, @Freagarach wrote:

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

Some questions:

• What do you give priority, preferred class or position?
• What happens to those nice artillery towers (that may well be buildable in a mod) that now try to shoot units, although they're highly effective against siege?

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

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 entities.length the range?? I thought it was the length of the array.

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

"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

In D4964#211547, @Stan wrote:

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

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

Also exclude siege units from the first check alongside buildings.

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/

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)

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

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

1. Changed the name to Empire Maker as builder is too literal
2. Changed "armor" to "resistance" in tooltips
3. Removed "Non-elephant" as per @Langbart's suggestion

@Freagarach what do you think of "Empire Builder"?

From @wowgetoffyourcellphone 's suggestion via PM, I changed it to "Empire Builder."

In D4952#211121, @wowgetoffyourcellphone wrote:

"Standing Army" sounds like more of a training bonus or something. :)

In D4952#211117, @chrstgtr wrote:

Totally missed the armor buff. Still, I think it’s fine. But it’ll be one of the better heroes

"Great Standing Army" now only applies for non-elephant units. Stacking both auras on elephant units would make them very OP.

I will instead make one for chandragupta maurya.

In D4944#210818, @chrstgtr wrote:

Seems like a big buff to archer ele and could have a snowball effect. We’ll only know if that’s a problem with testing.

added repository and reuploaded.

Fix 4 stray "</Fours". I guess these were from deleting all but the last line before before pasting.

Removed extra whitespace from sele/wall_medium.xml

C sounds good. I actually moved a lot of other hotkeys to be more accessible to my left hand, so this is welcome as default.

high shadows:
ultra_high:

ok so i got more time to do a comparison. This was on the second bundle you sent out (27485).
Fullscreen worked fine for me, except for some tearing while panning the camera on vulkan. This was fixed with Vsync. I kept Vsync on for the GL test.
Vulkan:

In D4905#209683, @Langbart wrote:

addendum

• the x86_64 bundle with the number 27485 does work when I also enable the 0ad-spirv mod and use the env variable MVK_CONFIG_FULL_IMAGE_VIEW_SWIZZLE=1
  • otherwise it will crash

# this works
MVK_CONFIG_FULL_IMAGE_VIEW_SWIZZLE=1 /Applications/27485.app/Contents/MacOS/pyrogenesis -mod=public -mod=0ad-spirv -conf=rendererbackend:vulkan -conf=windowed:true

Yes, works for me too, with no army of pyrogenesis.

In D4905#209677, @real_tabasco_sauce wrote:

In D4905#209676, @real_tabasco_sauce wrote:

@Stan the same behavior occurred. Only this time, I did not wait for the game to load. I quickly force quitted and began to stop all the pyrogenesis threads. I got apple "quit unexpectedly" windows after the application was stopped, which is interesting.
Somebody else should try the intel mac version to see if it is just me.
Here are a couple of my log files, not sure which of them will help here.

interestinglog.html668 KBDownload

mainlog.html8 MBDownload

its almost as if vulkan fails, and then instead of quitting with some error, another executable is started. That being said, vulkan did "work" (I was able to render everything), just not very well, presumably because of how much ram all the pyrogenesis threads were taking.

In D4905#209676, @real_tabasco_sauce wrote:

@Stan the same behavior occurred. Only this time, I did not wait for the game to load. I quickly force quitted and began to stop all the pyrogenesis threads. I got apple "quit unexpectedly" windows after the application was stopped, which is interesting.
Somebody else should try the intel mac version to see if it is just me.
Here are a couple of my log files, not sure which of them will help here.

interestinglog.html668 KBDownload

mainlog.html8 MBDownload

In D4905#209676, @real_tabasco_sauce wrote:

@Stan the same behavior occurred. Only this time, I did not wait for the game to load. I quickly force quitted and began to stop all the pyrogenesis threads. I got apple "quit unexpectedly" windows after the application was stopped, which is interesting.
Somebody else should try the intel mac version to see if it is just me.
Here are a couple of my log files, not sure which of them will help here.

interestinglog.html668 KBDownload

mainlog.html8 MBDownload

@Stan the same behavior occurred. Only this time, I did not wait for the game to load. I quickly force quitted and began to stop all the pyrogenesis threads. I got apple "quit unexpectedly" windows after the application was stopped, which is interesting.
Somebody else should try the intel mac version to see if it is just me.
Here are a couple of my log files, not sure which of them will help here.

nono, its not that.
As soon as I start with vulkan enabled, they start multiplying. I only let it try to open for 5 seconds and 800 appeared. Whats weird is they continued to multiply after I closed 0ad too. In total probably 1000 to 1100.

Hi @Stan thanks for adding a bundled version. I tried the intel mac version and it worked. However it seemed to be performing very poorly. It took a minute or so to boot up, with the audio playing to a black screen at first. 10 to 20 fps in the menu with large stutters. I decided to try the test until a failure of some kind, but I was actually able to load units_demo. As far as I could tell, everything loaded, but It took 5 minutes and I had 1 fps.
I could perhaps be missing something important, or maybe my computer just doesn't work well with the vulkan backend.

In D4873#208504, @wowgetoffyourcellphone wrote:

I just realized the swapping of resources for poison_arrows and poison_blades doesn't make sense realistically. Shouldn't arrow techs cost wood and sword techs cost ,metal? But whatever, I get it. Balance. lol

In D4877#208512, @real_tabasco_sauce wrote:

added sele_farms new file for civ bonus

added sele_farms new file for civ bonus

removed whitespaces, pasted correct minus sign.

Included both removing ship_fire.xml from Han roster AND "-units/{civ}/ship_fire" from han/dock.xml

In D4875#208324, @Stan wrote:

Was removed in https://github.com/0ADMods/han_china/commit/08a2626d7853a3285c35393bb4d2868884ea22c9
No explanation given at this time.

Looks great to me! Thanks!

In D4872#208269, @vv221 wrote:

In D4872#208262, @wowgetoffyourcellphone wrote:

In D4872#208249, @vv221 wrote:

In D4872#208237, @real_tabasco_sauce wrote:

Maybe one potential improvement could be to add to the tooltip/description of swordsmen and spearmen:
"Elite rank <swordsmen or spearmen> may be promoted to champion centrurions."

Could you please point me to the files I should edit to update these descriptions?

Small nitpick: "can be promoted to" sounds a bit more natural than "may be promoted to" in my opinion, but I am not a native English speaker.

Just need <Tooltip></Tooltip> in the <Identity> component of both infantry_swordsman_e and infantry_spearman_e.

Done with https://code.wildfiregames.com/D4872?vs=21317&id=21318#toc

Does that look good to you?

In D4875#208257, @wowgetoffyourcellphone wrote:

If they can't be built by the Han's own dock, then it probably shouldn't be trainable from a captured dock either. I wonder though why the fire ship was removed from the Han roster. I don't remember that specific discussion.

Well basically, if you are Han and you capture an enemy dock, you can train fireships. I don't believe this is intended, but if it is we could just close the patch.

Maybe one potential improvement could be to add to the tooltip/description of swordsmen and spearmen:
"Elite rank <swordsmen or spearmen> may be promoted to champion centrurions."