Norse_Harold

I think that isFinished() can be called multiple times when build progress is 1.0, so entsToDestroy is being processed multiple times. I've confirmed this with testing.

In my opinion, way too much is being tested at once, considering that all of community-mod is also in the test case. Therefore the cause could be anywhere. Why assume that it's caused by the walls delete trees component unless the crash can be reproduced with only that component?

Good idea to run that test. That's interesting that the crash still occurred. I advise separating the walls delete trees mod from the rest of community-mod for further testing, so that a binary search algorithm can be applied where the search space is cut in half with each iteration. If the problem is then found to be correlated with the walls delete trees mod then here are some things to consider. Normally (invisible or less visible) obstructions would be destroyed before the foundation is committed instead of after it's finished. Maybe isFinished isn't called after every structure is completely constructed. In that case, obstructing entities aren't destroyed. Units blocking construction might conflict with or be locked into the structure if return false isn't present on line 275 of Foundation.js.

This discussion about the bug in the 'walls delete trees' feature was probably better done in an issue on the Gitea repository 0ad-community-mod-a26. Next time...

Yes, we could, although I would like that it be made into a separate mod so that people can do testing and development of it.

I was not in multiplayer, but if my theory is correct that excessive destroy calls on the same entity are the cause of the crash then it's a useful line of investigation.

I mimiced the Romans player in PhiliptheSwaggerless's replay. I was not able to reproduce the crash. But I only intended to cause multiple destroy calls per entity, and I was successful in that. To see that, use the attached Foundation.js file which enables logging. Then build lots of structures and watch the logs for multiple occurrences of "destroying entity #", where # is the same number for each occurrence. It may help to build structures with lots of units and on top of grass actors. Foundation.js

In my testing, I was seemingly building over no entities, but I think that there are less visible or invisible entities that are being automatically deleted when buildings are constructed there. Also, I see your proposed changes in the fix_crash branch to re-add `return false` in Commit in Foundation.js. This is good. I think that it will correctly prevent building placement if there is an obstructing entity that is not caught by BuildRestrictions.js:CheckPlacement, such as an entity that moves into the area between the time that CheckPlacement() is called and Commit() is called. An example would be another structure being placed there in that time. This is a guess, though. I don't know whether there is actually a race condition there. Edit: Actually, I think that the purpose of the call to GetEntitiesBlockingConstruction() is to check whether there are units blocking construction and order them to move out of the way. I think that a correct solution would involve all three changes apply my patch to clear entsToDestroy after the entities in it are destroyed re-add return false on line 275 of Foundation.js, in Commit(), if there are obstructing entities. However, if the building to construct is a wall and the obstructing entities are only trees then do not return false in that case in Commit at line 259, immediately destroy all obstructing entities that would be destroyed on construction except trees. If the entity to be built is a wall then queue trees for later destruction Some of the code would seem to be redundant. Is there a way to move the wall/tree code block into a separate function so that it can be used by CheckPlacement() and Commit()?

Another possibly unwanted behavior that I notice is that obstructing entities that would normally be destroyed at the moment that the foundation is created will instead be delayed and only destroyed after the building is finished. I wonder if this could disrupt pathfinding when units are standing on the foundation at the time that construction is intended to begin. A solution to this problem would be to only delay destruction of obstructing entities if the structure to be built is a wall and the obstructing entities are trees.

If IsFinished() is called more than once on a foundation that is at buildprogress of 1.0 then obstructing entities can be destroyed more than once. Unexpected results may occur. I added some logging statements and confirmed that entities are getting destroyed more than once. I think that the solution is to clear entsToDestroy after the entities in it are destroyed. I've attached a patch that demonstrates this. 0ad-community-mod-02611-maybefixed.patch

No, but send replays, please. The simpler and shorter, the better.

In the replay, a player as Romans sends all non-cavalry units to build a farmstead, kill a chicken, then walk away. Then the replay ends. Can you confirm that this is the right replay? I was unable to reproduce the symptoms of the game crashing by following the same steps with a single player match using community-mod v0.26.11. Is something else necessary? For example, did you have a spectator join the game in order to get the game to crash? Please list the exact steps to reproduce the symptoms.

Can you search your logs for lines containing NaN and paste them, as well as surrounding lines for context? Sanafur's excerpt is optimal

Some users have reported that the game crashes with community-mod version 0.26.11. They pasted relevant mainlog.html excerpts in the lobby. according to Atrik_III: according to sanafur: I would advise checking variables that affect the building rate. To determine which variables those are, see Foundation.js.

All right, good to know. I was going by this article. Now I see that it's confusing marketing speak. It seems like an engineer provided information and then a marketer wrote an article based on that information while also removing some key terms like ARM64 instead of x64. The marketer just referred to "64-bit Windows applications" instead of "64-bit ARM applications". Connor009009, if/when it crashes again, you know what files to send for assistance with troubleshooting.