Norse_Harold

Okay, thanks. You should still check the RAM in your system with memtest86+. Also, check the S.M.A.R.T status of your storage devices with smartmontools.

In fact, both are useful for diagnosing the problem. We can compare the log files to see what's different when sound works. Also, please post the output of the following commands at two different times: when sound isn't working for 0ad and when sound is working. You may need to install a package named like openal-info in the snap. The command to do that might be: sudo snap install openal-info snap openal-info snap cat /proc/asound/cards And, please provide the output of the following commands when sound is working for 0ad. This will tell us the hardware that is available, independent of the Snap sandbox. openal-info cat /proc/asound/cards Also please test sound with whatever version of 0ad is available as a native package for your system. If it works reliably there then that's a clue that the Snap sandbox might be interfering with access to the audio hardware. Basically, ask the question, "under what conditions does sound work reliably?" and construct controlled experiments that test various conditions and make observations. Is it due to the hardware that you're using? Try different hardware temporarily. Is it due to the audio backend that you're using? Try using a different audio backend with OpenAL, as explained in the FAQ answer about sound. And, did you follow the advice in the FAQ answer about sound? I've updated it a few times over the months. Scroll down to the answer to "No sound, no audio, or 0 A.D. is the only app with sound".

Thanks for copy/pasting the error messages. Can you attach mainlog.html and system_info.txt? What was happening in the game at the time that the error occurred? Can you cause it to happen again? What happens if you reboot your computer and try to cause the problem to happen again? Which mods were you using at the time? How can others reproduce the symptoms? Without further information and testing, we can only guess what would cause that. The error message states that the checksum of a part of a Zip archive failed to match the correct checksum. This could be caused by corruption of the data on the storage device. Or, it could be caused by faulty RAM or CPU. Please make a backup of the game data and then reinstall the game. If that doesn't fix it then check for hardware problems. For example, you can check for faulty RAM with memtest86+.

Please follow the lobby Terms of Use, everyone. Duplicate accounts without authorization are not allowed, so any duplicate accounts that anyone has, please disclose them to the lobby moderators and the reason for having them. Also state which account you would like to consider your primary account from now on. We'll review the request for authorization and might actually authorize a duplicate account or two for legitimate purposes. G.O.A.T, please stop calling duplicate accounts "smurfing". Smurfing, as far as I know, means more than just using duplicate accounts. It means lying about one's skill. I think that Yekaterina is good about disclosing their skill level when asked, so that games can be balanced. weirdJokes, an unfactual acccusation of a crime (for example breach of contract by violating the terms of use, bullying on the Internet , or ddosing people. These are crimes in certain jurisdictions.) is called libel. Please don't do it. If you have witnessed misconduct or a crime then please disclose the evidence to the moderators. Don't make accusations without evidence. That goes for you too, G.O.A.T.

I would advocate for a fix being implemented into the default game in the next update, but I'm not the decider of that. @Stan`what do you prefer? 1. Adjust the default MTU of 0ad to 1392. 2. Add a feature for users to override the MTU in the configuration and/or command line. (Note that without options 1 or 3, user education would still be necessary in order to actually solve the problem.) 3. Ask ENet to adjust the default MTU to 1392. 4. Options 1 and 3. Guard option 1 with a check of the version of ENet or a check of the value of ENET_HOST_DEFAULT_MTU. Undo option 1 when options 3 or 8 are implemented and used widely by the player base. 5. Add logic to 0ad to adjust the MTU of each connection between two peers to the minimum of those two peers. 6. Add logic to ENet to adjust the MTU of each connection between two peers to the minimum of those two peers. 7. Add logic to 0ad to sense a correct MTU. 8. Add logic to ENet to sense a correct MTU. Notice that most or all options can be combined. They are listed roughly in ascending order of time required.

Today we ran some tests with 0ad while I was connected via VPN, and Helicity was connected via school wifi. We first ran a controlled experiment without the MTU adjustment patch applied. As expected, the maximum outgoing packet size was 1400 data bytes, in fragments of 1400 bytes on wire and 28 bytes on wire, and the problem occurred where Helicity was disconnected after adjusting the number of player slolts to 5 or more. Then I hosted a game with the patch applied that adjusts the MTU to 1392. Helicity connected, and I varied settings in the gamesetup that would normally have caused him to get disconnected. He remained connected. We used cheat codes to create armies of 200 to 400 units and have them fight. It worked well, and Helicity remained connected until we ended the game voluntarily at about 6 minutes. During the test, the maximum outgoing packet size generated by 0ad was 1392 data bytes (1420 bytes on wire), of which there were 133 such packets, and none of which were fragmented.

This sounds a bit like luck that the order was preserved. Linux is able to re-order received out-of-order fragmented packets, within reason. See the documentation for sysctl variables net.ipv4.ipfrag_time and net.ipv4.ipfrag_max_dist in (Linux kernel source code tarball)/Documentation/networking/ip-sysctl.rst I would have thought so too. What other tests would you recommend in order to be sure one way or the other?

I haven't tested a game with Helicity yet, but as I said with the patch applied to my copy of 0ad, longsentenceasname was able to stay connected for an entire game, despite large packets of at most 1392 bytes sent to him during the game. Therefore, there was not packet loss of the large outgong packets. There is stilil fragmentation of incoming large packets (1400 bytes), and it would be nice to have the ability to prevent that as a host, but those packets aren't being dropped. I'm leaning toward it being a bug in ENet or 0ad. I'm surprised that so far I have found no feature in ENet for automatically adjusting the MTU of the link, but maybe that means that the user app is responsible for adjusting the MTU. I think that a proper solution would involve looking at the OS's indication of the MTU of the link that's in use, and harmonizing the MTU used by ENet (or 0ad) to that value at first. Then, upon connection, both peers use the minimum MTU of each side of the connection. It may be difficult for the library or app to determine which link is in use, because when a VPN is in use there is more than one default gateway, and multiple routing table rules are in place. Therefore, maybe a system could be added that would allow the user to hint which interface is in use or at least the MTU to use.

Okay, Helicity did the ping command. Here are the results. White redaction: Helicity's user and host name Red redaction: Harold's VPN IP address Blue redaction: Helicity's IP address Then I asked Helicity to test with a packetsize of 1400 bytes: We also tested a packetsize parameter of 1393, and it resulted in fragmentation needed. So, it seems that the maximum is 1392 bytes. By the way, normally my firewall blocks all ping requests and replies. At first, Helicity got no replies regardless of the packetsize chosen, as expected. I added a firewall rule to allow ping requests and replies with only Helicity's IP address, which produced the above output when Helicity ran the tests.

You're referring to in-game mute functionality, of course.

I think that in-game GUIDs are randomly generated for each connection. It would only be linked to a username in the mainlog.html files of each user that was connected to the game before the user with GUID E4E25B1B022557AC disconnected from the game. 0 A.D. deletes mainlog.html each time it's started up, so unless the users backed up the file then it was likely deleted long ago. Even Helicity lost his copy of the file. Anyway, there's at least enough information to know that the unrecognized GUID wasn't wang_wei. In the attached mainlog_excerpt.html, wang_wei's GUID was F59C7E5A8195BC9B, not E4E25B1B022557AC.

Also, there's this, maybe for the humor value. I joined a team game hosted by juarca as spectator on March 6, 2023 at about 17:00 UTC. This is observer chat. DoctorOrgans (1853): its wrong to say that for that idiot that just came in the specs DaddyCooL (1648): who? DoctorOrgans (1853): Norse_Harold DaddyCooL (1648): why is he idiot DaddyCooL (1648): over for Duck_ DoctorOrgans (1853): first, because he's low IQ , second because he mutes me for anything DaddyCooL (1648): what is your iq leopard (1242): 0 leopard (1242): 0.1 DoctorOrgans (1853): 3 because he bans me from his games even if i never did anything to him kun0 (1560): 90 kun0 (1560): 900 kun0 (1560): 9000 leopard (1242): 99999 DaddyCooL (1648): over for Stockfish (1722) DaddyCooL (1648): okay no DoctorOrgans (1853): Norse_Harold, why are u such an idiot by muting me for no real reasons ? It's because you are a mod, you think i respect you ? DaddyCooL (1648): is Norse_Harold a moderator? DaddyCooL (1648): Norse_Harold are you abusing Modartor force? Norse_Harold: Modartor force, is that like Jedi force? DoctorOrgans (1853): he's not even a real moderator .. Norse_Harold: midichlorians? DoctorOrgans (1853): he can only mutes .. DaddyCooL (1648): Norse_Harold what is your problem with DoctorOrgans (1853) DaddyCooL (1648): why are you so jealous? Norse_Harold: I enforce the rules. I have no personal beef with anyone DaddyCooL (1648): Norse_Harold, DoctorOrgans (1853) claims you hate him because he is unstopable Norse_Harold: he can claim whatever he wants, doesn't make it the truth leopard (1242): DoctorOrgans (1853) is a good player bad human being DaddyCooL (1648): your truth or absolute truth? DoctorOrgans (1853): there's no "rules" just interpretations .. i saw someone blatantly insulting someone else .. no mute leopard (1242): he is not Valihrant DaddyCooL (1648) Norse_Harold: I don't mute on every infraction DaddyCooL (1648): who was insulted by him? DoctorOrgans (1853): indeed ! Norse_Harold: I mute after a person builds up enough infractions for it to be significant DoctorOrgans (1853): bla bla bla DaddyCooL (1648): he says bla bla bla Norse_Harold: you must not be paying attention DaddyCooL (1648): i think he disrespect you Norse_Harold Norse_Harold: DrDisrespect DaddyCooL (1648): maybe instead of a mute you should considering banning him DoctorOrgans (1853): i said "over for vincel" and he mutes me .. just lol .. enough evidence to remove you from any responsabilities leopard (1242): stop DoctorOrgans (1853) if you don't want to be like shift sierra DoctorOrgans (1853): shift sierra , whos that ? Norse_Harold: shyft* DoctorOrgans (1853): dont know who it is leopard (1242): we respect you DoctorOrgans (1853) Again, let's avoid "insulting him back", please. Just be assertive and crack constructive jokes or make observations about his behavior, without using language that is against the lobby Terms of Use, in response. Meanwhile, collect evidence and report it. Thanks.

Helicity reported verbal abuse from DoctorOrgans in a team game on March 4, 2023 at 11:30 to 11:50 UTC. He sent an excerpt of mainlog.html, and I parsed it in order to see the chat messages and who sent them. DoctorOrgans (1853): french favela Timmy_Death_Lord (1306): tf? GaiusJuliusPfifficus (1470): slums of paris? DoctorOrgans (1853): france is africa now DoctorOrgans (1853): thx to jews DoctorOrgans (1853): and white women Helicity (1377): really? GUID E4E25B1B022557AC: racist JC as usually Timmy_Death_Lord (1306): true GaiusJuliusPfifficus (1470): /allies don't think of nations, every person is different GUID E4E25B1B022557AC: french need the immigrations DoctorOrgans (1853): yeah ... anti-racist brainwashing 24/7 GUID E4E25B1B022557AC: all shits jobs are taken from them DoctorOrgans (1853): bs DoctorOrgans (1853): just pay the jobs more DoctorOrgans (1853): all this is a ponzi scam Helicity (1377): why, DoctorOrgans (1853) do you live in Paris? DoctorOrgans (1853): just make stable families, dont make @#$% study useless stuff and make them dumb feminists DoctorOrgans (1853): only girls with IQ > 115 should be able to study wang_wei: my brain hurts DoctorOrgans (1853): abortions in france is 200.000 year Helicity (1377): DoctorOrgans (1853) I disagree, because IQ test is as unreliable as 0AD ratings wang_wei: every time JC talks about women Timmy_Death_Lord (1306): whos in paris? DoctorOrgans (1853): @#$%s DoctorOrgans (1853): and jews Timmy_Death_Lord (1306): fr DoctorOrgans (1853): and lot of sand @#$%s too Harald_from_LOR (931): is phoenix going to reconnect? Helicity (1377): seriously wtf DoctorOrgans (1853): lol wang_wei: Jc dont use that word wang_wei: @#$%ing piece of crap wang_wei: you re from belgium? Timmy_Death_Lord (1306): @#$% the arabs wang_wei: one of the worst colonizers wang_wei: you @#$%ing crap Helicity (1377): Please stop this wang_wei: dont ever use that word again in my games DoctorOrgans (1853): yeah, i love to triggered anti-racists DoctorOrgans (1853): which word ? GUID E4E25B1B022557AC: Timmy_Death_Lord (1306)??????? Timmy_Death_Lord (1306): they are all terrorist Helicity (1377): ENOUGH! DoctorOrgans (1853): Helicity (1377) are you sand ? GUID E4E25B1B022557AC: lol gg i leave with this behaviours idiots DoctorOrgans (1853): :D One user, referenced by GUID instead of user name, disconnected before the CPlayerAssignmentMessage, so we couldn't determine with certainty the player's name. However, based on context, Helicity said that the player was probably wang_wei or Marre-Vrickad. Attached is the mainlog.html excerpt as it was sent to me by @Helicity. He copy/pasted the text into a forum PM instead of attaching it. Note that the forum software automatically replaces some Terms of Use infringing words with strings of characters like "@#$%". In the future, please attach the file so that the forum software doesn't auto-censor infringing words. Multiple people had some language in the conversation like profanity and pejoratives. I encourage everyone to simply collect evidence and report misconduct instead of engaging in "retaliation". I see that DoctorOrgans had the majority of problematic language. As lobby moderators, we don't moderate in-game conduct. Except, sometimes we do if it's bad enough. Please report future events. mainlog_excerpt.html

Thanks, Lion.Kanzen. Is there somewhere that this is documented? I searched the Internet for a half hour and couldn't find any hits for cojone except Spanish cojones.

Okay, I made a small source patch to adjust the MTU to 1392 bytes instead of 1400 bytes. It affects only the MTU of outgoing traffic. I don't see a way for the server to control the MTU used by clients for packets sent to the server, unless it's somewhere in the ENet logic for constraining the MTU. And, ideally the MTU is decided automatically instead of hardcoded in the source code. The ICMP traffic necessary for the OS to do that might be blocked locally or remotely, although that is not necessarily what ENet is relying on. Note that "ping -M do -s 1392 play0ad.com" through the VPN link succeeds. Edit: An idea for allowing the server to control the MTU used by clients: apparently MAX_CLIENTS peers are allocated immediately by the call to enet_host_create() in CNetServerWorker::SetupConnection() . We can iterate through all of the elements of the m_Host->peers array and adjust the MTU before the peer structures are used for actual connections. Anyway, I used the improved MTU when hosting several games through VPN today. longsentenceasname, who was unable to stay connected in the past was able to stay connected and play a complete team game hosted by me. I assume that the modification will also allow Helicity, Cousin, and others to stay connected now. And no, clients don't need to apply the patch. Only hosters using VPNs, such as @Ginnungagap might need to apply this patch. For anyone choosing to apply the patch, you need to have a build environment setup first. The build environment instructions mention the SVN version of the 0ad source code. Instead, use the source code for the stable release of alpha 26, since that's what this patch is intended for. That way it's usable with the current player base. See the attached file below for the patch. Adjust-MTU-for-VPN-link.patch

This is the screenshot, in case the external image hoster discontinues hosting it. Google Translate from Italian to English: Bakixeddu: nz. motherf______ come back (in Italian) nz.: call your mother Bakixeddu (in English) Bakixeddu: nz. but s___ me (in Italian) nz.: good, I am reporting you (in English) Bakixeddu: but get off the f___ you (untranslated: cojone) (in Italian) Thanks for the report. I count 4 or 5 instances of profanity in this report, depending on whether or not "cojone" is Italian profanity. I've added it to the list of Bakixeddu's infractions, which affects the recommended mute duration. I've applied a lobby mute of 1 day to Bakixeddu for this behavior and will be watching for future violations by Bakixeddu. To everyone, please report any other abusive behavior that you may observe. Also, consider avoiding Bakixeddu until he chooses to improve his behavior.

Someone else will have to help with that test, because if I ping myself then it just sends the packets over the loopback adapter. The problem seems to be fragmented packets that are being dropped some time before they reach Helicity. Two fragments: Packet of size 1420 bytes on wire, 1400 data bytes Packet of size 28 bytes on wire, 8 data bytes These aren't being acknowledged at all by Helicity when Helicity plays with his laptop and school Internet connection. Today he's using his dad's network, and it seems to be working. But, I want to avoid having fragmented packets being sent out. How does ENet determine what MTU to use? Maybe it's looking at the wrong interface. My ethernet interface has MTU 1500 bytes (maybe data). My VPN interface has MTU 1420 bytes on wire. ENet is using the default MTU of 1400 data bytes. I want ENet to use a lower MTU, such as 1392 data bytes.

I remember advice about preventing packet loss when using UDP protocol. Because ISPs and Internet backbones are more likely to drop UDP packets that are larger, the advice for real-time network protocols like VoIP and gaming is to use smaller packet sizes. If I recall correctly, about 500 bytes is the maximum recommended. Maybe some Internet backbones used by Helicity, and the 5 other known players who have trouble staying connected to VPN users, have implemented the Random Early Drop QoS algorithm, preferring to drop larger UDP packet sizes. Is there a way to easily adjust the maximum packet size used by 0ad? Even so, it doesn't seem like the "reliable" feature is working as expected. Note that VPNs have a lower MTU than the average Internet connection, by almost 1000 bytes. I see a packet flag in the ENet library: /** packet will be fragmented using unreliable (instead of reliable) sends * if it exceeds the MTU */ ENET_PACKET_FLAG_UNRELIABLE_FRAGMENT = (1 << 3), Hopefully this is not in use by 0ad, but if it is then it might explain what's happening here. Edit: there's only one call to enet_packet_create() that I can see, located in source/network/NetHost.cpp. Apparently all packets have the reliable flag, and do not have the unreliable fragment flag. My new hypothesis is that the number of retry attempts is being exceeded and the connection is being forcefully reset by ENet.

Helicity is on Linux, not Windows. We can reproduce the symptoms with no mods enabled, simply by setting the number of player slots to 5 or more, or toggling settings like capture the relic very rapidly with 4 slots. There are no JavaScript errors when the problem occurrs. When the problem occurs, the reliable data in transit increases to several thousand bytes and does not decrease. Then Helicity gets disconnected after a few seconds. I think that this is caused by packet loss, either on delivery of update packets from the host to Helicity, or on delivery of acknowledgement packets from Helicity to the host. The problem so far only occurs when I host via a VPN. When I hosted without VPN, Helicity remained connected despite using 8 player slots, and much rapid adjustment of game settings like capture the relic and number of relics. Helicity got disconnected from another host as a player in a 4v4 game today. People commented that he regularly has connection problems. My assessment is that there is not a bug in 0ad, but there is a combination of network or computer problems with the players involved. Maybe VPN traffic is bursty, and maybe Helicity's connection or computer has trouble with that.

You did redact the player's name, but there seems to be enough information combined with screenshots that I've taken in the past to determine the player's name. Don't worry, he's not reported for purposes of any rating adjustment. But, it's still useful to inform the player base about the player's behavior. It looks like the player is tonyfurg. He is probably using the customRating mod to make his rating appear to be 1176, as I see in past screenshots. But, his official rating is 1397 after that rated match was completed. Of course, a player's true skill level is rather subjective, and it depends on the skill level of the opponent. If you post the replay then players can get more of an accurate gauge of the player's skill. Also, unless your opponent is familiar to you, I advise that you always ask your opponent to tell you an actual skill level. Don't assume that your opponent's rating is accurate. That way, if they lie then you can call them on it. If you don't ask then they can just say, "Oh, you shouldn't have assumed that my rating was accurate. It's your fault for not asking."

@StockfishPlease attach the replay file (commands.txt) from the game to your post.

@HelicityThe screenshot shows the errors that appeared when I enabled regicide and hero garrison mode at the same time. It's not what I was asking about. Please start 0ad from a Terminal window, connect to a game that I'm hosting with randomly generated map like Mainland, and copy/paste the JavaScript errors from the Terminal window to a forum post. The reason that this is necessary is because we should not assume that the root cause of the problem is regicide mode + hero garrison. There could be a different cause of an infinite loop during initialization.

Okay, Helicity and I did some testing, and we discovered that it's probably caused by the bug related to hero garrison with regicide mode. Helicity said that sternstaub recommended that he check for that bug and disable persist match settings. Merely disabling persist match settings was not enough, though. Here is how to fix the bug related to hero garrison and regicide mode. Except that Helicity couldn't find matchsettings.json or matchsettings.mp.json. So, I hosted a game with a non-random map, such as Acropolis Bay. Helicity connected, and unlike when I was hosting with a random map like Mainland, he did not get disconnected. Then I enabled Regicide mode. Helicity noticed an error message that pointed toward the hero garrison bug. I enabled hero garrison, then disabled it. Then I switched to a randomly generated map (Mainland). And, Helicity did NOT get disconnected this time. Success. Later, with Helicity's "normal settings" (with community-mod and other mods?) the problem returned. So, there is still some troubleshooting to do. Note that there were some files in Helicity's mods/user directory, which is like having an extra stealth mod enabled that changes unexpected files. Files don't belong there for non-developer users, so we made a backup of those files and deleted them. It didn't fix the problem, but it is something else to watch out for in the future. The next step for troubleshooting would be to narrow down a setting or mod that is a minimal way to reproduce the symptoms. Note that there are three places where settings are stored for the game. There's default.cfg, local.cfg and user.cfg. Check in each of those paths for matchsettings.mp.json and matchsettings.json, and check in each of those config files for settings related to hero garrison. Backup any data that you remove before removing it so that we can identify the root cause(s) of the problem. If you choose to remove default.cfg then reinstalling the game will restore it to the correct state. Another clue: Helicity said that he neither hosted a game nor played as a player of a game involving regicide. However, he did spectate a game involving regicide. Developers, is there a way for match settings to become persistent in the game other than matchsettings.mp.json? It's strange that the problem would even happen without regicide mode enabled. Maybe there is a different root cause that induces the same symptoms as the hero garrison+regicide bug. Helicity, can you please provide a copy/paste of the console messages about the JavaScript errors related to the infinite loop, please?

Anyone on the list of players allowed to join my games who has trouble joining my games should join IRC so we can conduct troubleshooting. It might be a problem on my end, it might be a problem on your end.

@ikluEnsure that the audio device that you plan to use is connected to your computer well before you start up 0ad, as 0ad doesn't seem to be able to pivot to a different audio output device at runtime. Also, ensure that you have the correct audio device configured as the default output device in playback devices before starting 0ad. Are you using HDMI audio output? 0ad may have a bug with HDMI audio output. Consider helping us resolve the bug by testing hotfixes. It would be necessary to setup a build environment and test patches. Or, consider using a different audio output device. If it's still not resolved then see the FAQ answer to the question "No sound, no audio, or 0 A.D. is the only app with sound".