Norse_Harold

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.

Glad to hear that our troubleshooting session on IRC was helpful. Here are the logs for anyone who might also find it helpful. Thanks for posting about this issue on the forum, and thanks to Stan for the advice that has resolved one of the main problems. Yes, next is long-term testing with the Snapdragon CPU. Things might work better with a 64-bit executable, because then the Snapdragon CPU wouldn't be emulating the instructions. Right now 0ad only has 64-bit executables available for MacOS and Linux. You could install Linux in order to use the 64-bit version of 0ad.

It seems complex at first, but you only need to use a small portion of its functionality. The quick start guide shows you the essentials. In fact, running another CPU intensive program at the same time potentially changes the conditions of the test, because it might change how often the CPU frequency is being adjusted. This is a reason to also record a video with a camera instead of using OBS-Studio. You can control the governor manually with this command as root, or with sudo. echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor When you want to undo the change, easiest is to reboot, but the default might be schedutil, so to revert the change you can replace performance with schedutil in the above command. Alternative software is listed in this Arch article about CPU frequency scaling. It also includes documentation on the governors and tuning the CPU scaling system. I have a theory that the CPU frequency is being adjusted too often, despite the CPU usage when 0ad is running only being about 20%. Every time the frequency is changed, the CPU is idle. Some CPUs take 900 microseconds or more to change the frequency. That could explain the stuttering. There might be a way to adjust the settings so that Linux is reluctant to change the CPU frequency so often. But, first test with the CPU scaling governor set to performance so that the CPU frequency is locked to the maximum. Then check whether the stuttering continues, or not. Also, please check whether the stuttering problem is present when the game is windowed, before and after adjusting the CPU frequency scaling governor. You can toggle whether the game is windowed by pressing Alt+Enter when the game is at the main menu.

D4871 is outdated. D4987 is more in line with what I have planned. Even that is outdated, because changes are planned. Help wanted.

Would you mind posting a video of the problem. You can record it with screencapture software like OBS-Studio. If the problem is not visible in the recording made by screencapture software then it is interesting and possibly points toward the video output cable or monitor. In that case, please also post a video recorded with a camera instead of screencapture software. Troubleshooting advice for the game juddering is here. Especially note my idea to set the CPU frequency scaling governor to performance in order to prevent micro delays due to changes in CPU frequency. Also see the additional advice further down the page in that topic.

Maybe someone has been watching too many Batman movies and playing too much Grand Theft Auto. Anyway, GTA has a lesson: there's always a higher power that can be brought in to counter whatever firepower one brings to the situation.

Actually, one is expected to be more peaceful when one is carrying a concealed firearm, at least in the US. Here the courts tend to be reluctant to consider a shooting to be in self defense unless the person did as much as they could to avoid, defuse, and in some states, retreat from any potential conflict. In California, gun owners are expected to run from their own homes if they're attacked by home invaders... I guess that it's similar or even more difficult to successfully argue self defense in most other countries.

leopard did not ask me to punish weirdJokes. I issued the infraction because I perceived a violation of the terms of use. Regardless of severity, I consider it a significant violation of the terms of use because it's a form of bullying. It was not a mistaken punishment. The infraction points will help to remind weirdJokes that he needs to avoid doing that sort of thing again, even as a forum private message. I don't think that leopard is a saint in terms of his conduct, as I've seen him insult people and lose his temper at times. Still, two wrongs don't make a right. I think that it would be good to gather the three of us for a discussion in order to find common ground, do arbitration, and do conflict resolution. I want to be friends with both leopard and weirdJokes. I want to get past this video clip. I want to discover that weirdJokes actually means no harm and is not acting in concert with Geriatrix. I want to reassure both of you that you are and can be friends, who follow the rules, and who treat each other with respect. The way to do that is to have a mediated real-time conversation. weirdJokes and leopard, when are you available to meet me on IRC, preferably around 17:00 UTC on a weekday?

Great, glad that our troubleshooting session helped narrow things down enough to identify this issue as the cause of the symptoms. For those watching at home, logs of the troubleshooting conversation on IRC are here and here. Before I buy new hardware I do some searching for discussion of how well it's supported by Linux. Fortunately, there are pretty thorough and updated lists of which wifi products are supported here.

I would like to help with this, but there isn't enough information here to know what the cause of the problem is. I would say that it's rare, but I can think of some possible causes. like wireless interference, router misconfiguration (for example use of port triggering instead of port forwarding or port mapping), use of a VPN protocol like wireguard that doesn't handle large packet sizes, malware protection that monitors and blocks network activity, etc. I can help you interactively via IRC. Otherwise, please post mainlog.html and userreport_hwdetect.txt from each computer. I would suggest that you try connecting both computers with ethernet cables and try connecting to someone else's hosted game, but the problem may not even be at the network at all. Maybe it's caused by competing or disrupting software on one of the computers. I also suggest testing other networked applications, specifically peer-to-peer UDP games like ioquake3.

This is why I have a rule in games that I host where "ghosting", meaning revealing important information as a spectator, is disallowed. It's rare to see spectators revealing information about what's happening in the game, and I think that most hosts disallow this implicitly. I sometimes see them punishing people who reveal information as spectators. Instead, spectators tend to speak in global chat for social reasons, or as an audience reacting to what has already happened in the game. I think that the vast majority of people know what kind of conduct is expected as a spectator.

This was confirmed by the moderation team to be the actual private message that Player of 0AD sent to leopard. Player of 0AD was issued infraction points on the forum for the abusive, harassing, and sexually oriented conduct. Please get along, people. Let this resolve this issue, and be friends or at least neutral, please.