Norse_Harold

@grisfort Help for that problem is in this post.

I am taking a temporary break from lobby moderation. I will use the name Skyforger_Harold for off-duty lobby purposes. Yes, it is an officially authorized duplicate lobby account. Please direct questions and requests regarding the lobby to Dunedan for the time being. What I have written about why I am taking a break is hidden by Dunedan for a reason, which I dispute. Okay, now the post is unhidden.

I'm taking a break from moderation for a while. Dunedan is about to apply some policy decisions for the lobby that I consider poorly planned. Examples of policy that he has proposed are muting of users for, in my opinion, excessive durations of more than 24 hours, and perma-banning users where temporary banning would be more appropriate and more effective. I have tried discussing this with him many times, and he has refused to acknowledge key facts, such as the history of attempting to enforce bans in the lobby, and instead insists on ending debate and applying arbitrary policy decisions. These proposed policy decisions would in my opinion cause a setback in progress enforcing the rules. I feel like the manual monitoring of lobby chat that I have done has been taken for granted by Dunedan. I don't want that done in my name. I've been out in front appearing to be in control of the lobby, the only one with an @ symbol next to my name. I've been the only one mentioned in the message of the day greeting. Yet I'm not actually in control. So I'll take a break from moderation and let Dunedan take responsibility and control instead of just control. I've been doing the heavy lifting and have saddled the emotional burden of the lobby without getting the credit. I have been helping new users with troubleshooting installing and networking 0ad. I have been stepping in to stop people from fighting with each other. I have been basically the only one monitoring chat manually for the past year and issuing mutes as appropriate. I have been hosting games with rules regularly to create a space for people who want to get along and treat each other with respect. The Outcast affiliation still doesn't work, even after I completed testing of the update that would fix it, and Dunedan said that no further testing was necessary. This means that it is not being fixed for political reasons, not technical reasons. Unless Outcast affiliation works then I do not have the ability to ban lobby users. In my opinion, I have been demoted. What kind of Administrator doesn't have the ability to ban a user? Dunedan at one point said that if there is a complaint about his "authority" then he is the only one who can be consulted about it, that no one else can be consulted. What ethical organization has a policy where there is no transparency or oversight for an administrator? Fortunately, I did not let this deter me from getting sunlight on the situation. I shared chat logs with Stan after obtaining reluctant permission to do so from Dunedan. Unfortunately, after I talked to "upper management" of Wildfire Games by sharing examples with Stan and Itms of what I consider bad behavior by Dunedan, it was met with inaction. Dunedan's choices have been effectively rubber stamped by Stan and Itms. I will take a break until better decisions are made. Realize that without people helping new users install the game and get it working, there will probably be a decrease in player count over the long term. I don't like this fact, but it is the reality of things. In the meantime I will use the name Skyforger_Harold for off-duty lobby purposes. Please direct all lobby moderation and administration requests to Dunedan for the time being.

What OS are you using? If it's Linux then which distro, window manager, and are you using Wayland? If you're using Linux then try the workaround described here. Yes, it's a workaround for a different problem, but it's similar enough that it might have the same cause. Alternatively, try making the game windowed by pressing Alt+Enter. Or, try toggling windowed to full screen by pressing it twice. It seems likely that it's caused by a bug in the window manager or SDL library. Please share the versions of these that you're using.

Disable TLS cryptography is only applicable to the initial login to the multiplayer lobby. It has no effect on connecting to an actual match. You're right that the error message is about UDP port 20595. The advice in the error message is outdated. It should recommend that people check whether they have an Internet connection with Carrier Grade NAT. Workarounds for Carrier Grade NAT Use a different Internet connection that has endpoint-independent NAT mapping and firewalling Subscribe to public IPv4 address service with your ISP Use a VPN that has endpoint-independent NAT mapping and firewalling Use a VPN that supports port forwarding and apply a source code patch to 0ad to allow control of the local port used for outgoing connections (contact me for this patch) Ask someone without Carrier Grade NAT to host a match with port forwarded and firewall opened for that port These are explained in more detail in the FAQ entry about the UDP port 20595 error message.

I think that the rate limit for registering account is one account per IP per hour. That's a good idea to use different Internet connections to register multiple accounts.

Hey, this is really cool. I'm guessing that the games only included players at the Internet cafe. I think it makes sense for newbies to have a sandbox environment for a while where they're not competing with skilled players. Later you can include people over the Internet in the games. It reminds me of the song lyric, "Here our soldiers stand / From all around the world / Waiting in a line / To hear the battle cry," from Manowar - Warriors of the World United. Before you try to make the games public, I think that some testing should be done with the cafe's Internet connection to determine whether it has carrier grade NAT, supports UPnP, etc. I can help with this if you provide advance notice.

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.

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.