An alternative would be to make it just a visual effect. Once the tree wood resource is at 50% (or something), play the falling animation and make it a trunk. No behavior change. The animation is very cool anyway.

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

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

Entity limits, semi-functioning reference suite.

I really like this idea, and it would make fire a lot more interesting. To keep fire from being overpowering, is there a way to extinguish a burning unit?

I second the Nifas suggestion.

I also like this as visual feedback.

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.

I would really much like this in the game.
what would you think about spawning not only the log which supplies the wood resource, but also a tree stump actor which at first only has visiual effects and could later (if implemented) be the base for a regrowing tree?

I will probably redo this in a way which couples the resource supply with the health, instead of spawning the resource on death. Otherwise you would be able to burn down a forest with D4973 and still be able to collect the wood, which makes no sense.

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

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

get it out of the queue since it's WIP

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

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

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.

cmpAttack has CompareEntitiesByPreference function that might help too.

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

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

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

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

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.

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

I just tested this again I I can still say that I don't see *huge* problems emerging with these values. Units tend to push each other away from resources a bit more, but the normally find a better position quickly, so no endless loops.
This could be further reduced by increasing <MinimalForce>0.3</MinimalForce> up to <MinimalForce>0.35</MinimalForce> or even higher.

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.

It's good to load the value from the config.

We should probably have some kind of naming convention for such integration tests. (So that they do not get confused with other unit tests).
Might be good to commit the rest of the test to reduce the scope of this one too.

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

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

Adds configure option network.enetmtu.
Moves header and implementation from lowlevel to network.

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

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

In D4969#211913, @Stan wrote:

The Readme should probably mention you need to install GLSLC (does it have a minimum version?)

Added.

Thanks for updating the patch with more information.
The Readme should probably mention you need to install GLSLC (does it have a minimum version?)
The python file should have a copyright header.

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

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

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

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

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.

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

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

Game runs, GUI needs updates.

Haven't forgotten the package ->packet change, was just waiting for more discussion to happen before pushing out a new version of the patch, will also wait a day or two to allow people to comment on making it configurable. Given the release still has no name we aren't in that much of a hurry.

sera wrote:

Given that it was merged

How about network.enet_mtu. That way, in case ENet corrects the definition of the mtu variable then 0ad's config variable will still be correct.

How should the config option be named, network.mtu is about as misleading as ENET_HOST_DEFAULT_MTU. Any good suggestions?

sera wrote:

Given that it was merged we can consider adding config support, just that it won't really work until server upgrades enet to HEAD. So offering [config support in 0ad for overriding the mtu] might result in user expectation that can't be fulfilled.

The only change that upstream patch brings is that now server can specify a lower mtu which is then used for communication in both directions. This patch here doesn't make use of this.

phosit and I tested this patch today in multiplayer via the lobby, and it works as expected. I hosted, and phosit connected as a client. Our MTU was 1372 bytes in every view of network statistics (server and client). We did some stress tests with cheats enabled in order to produce large packets. The maximum packet size seen was 1372 data bytes (1400 bytes on wire). There were 21 such packets sent by phosit, and 180 such packets sent by me. None of the packets were fragmented, despite the fact that I was using a Wireguard VPN. Note that phosit was not using a VPN.

In D4967#211859, @phosit wrote:

Thats much better.
host (and m_Host) should be a std::unique_ptr but that would requires more change.
Propably PS_ENET_HOST_DEFAULT_MTU should be in the cpp file (an implementation detail). No strong opinion.
We use another function-naming stile. But I think it's ok to use that from enet.

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#211872, @real_tabasco_sauce wrote:

Have you tried these values? I think they are pretty good, closer to the status quo, but perhaps there are still improvements to be made.

No I need to actually do it. I think I should get the time this week.