Norse_Harold

I prefer to avoid using that feature. I don't want the game's executable files and vanilla content to be writable in case there is a flaw in the game that causes any of those files to be incorrectly overwritten. Also, my personal security policy says that I should not allow a non-administrator user account to have simultaneous write and execute permissions on any files. This is inspired by the NX-bit security feature on CPUs that prevents executable memory from being written. Another reason to avoid using -writeableRoot, in my opinion, is to test the most common code path that others are using. This makes it quicker to reproduce symptoms that others may observe. As a result, I keep the game installed in C:\Program Files (x86), or the equivalent path on Linux, and I run the game as a non-administrative user.

Thanks for editing the guide with the improvements and credit for the idea. I should have talked to you about it privately instead of making it seem like you did something wrong. You didn't do anything wrong, and my asking for credit is kind of petty. I was responding hastily since it was just before I was going to sleep. And, my impulse to ask for credit might be the influence of corporate culture. Sorry. Okay, my bad. Good job on that.

Thanks much for writing this up as a step-by-step guide with screenshots and downloads. I consider it quite important to be able to use both versions of the game when a new version is being seriously tested. The "shortcut" created by the batch script is actually a symbolic link (also known as symlink). This is necessary because a simple shortcut would not tell the game to look at the destination folder for storing its files. Note that the batch files make symlinks for all three folders, not just the config folder. You might want to add instructions and screenshots in the guide for users to, before running any batch scripts, rename 0ad to 0ad26 in each of the 0ad user data folders. This will preserve their data for the current version of 0ad. If they don't do this then the batch script won't work correctly, since the RD commands (abbreviations of RMDIR) won't work unless the directories are symlinks or empty. Sometimes there are problems caused by copying the user data files from one version of 0ad to a newer version. An example is a black or very distorted user interface. Another example is old configuration entries causing the game to malfunction in a very significant way, such as no audio or a strange screen resolution. In that case, I advise starting with empty user data folders for alpha 27 and configuring 0ad from scratch through the game interface. It might be necessary to right-click on a batch script and click "Run as administrator" in order for symlink creation to work correctly. Anyone who wants to use these scripts should read and understand what they do before running them. It's all plaintext, and each command has documentation here. If anyone wants me to explain how the scripts work line-by-line then talk to me via Element. guerringuerrin, would you mind crediting me in the guide for sharing the ideas of installing to a separate folder and using batch scripts that make symlinks in order to give each version of the game separate config folders? I think that I told you about this before alpha 26 was released and sent example batch scripts. Either that, or I shared them with someone else and they shared them with you. I see that the scripts were modified in good ways to make them more organized. Again, thanks for writing this up and sharing the information and scripts. This is quite helpful for the user base.

I think he's just using Yeka's preferred gender pronouns. As far as what I've seen and know, there are indications that Yeka might be male, and there are indications that Yeka might be female. Because of the uncertainty, and expectation to use preferred gender pronouns, I have decided to use the pronoun "(s)he" because it covers all bases. It says "I just don't know exactly what the truth is," and that's the most accurate way to describe it in my opinion.

Some new forum and lobby accounts have appeared that behave and write similarly to Yekaterina. Yekaterina has used duplicate accounts to Create a false consensus by making it appear as though several people support an idea whereas it is actually one person in control of each of the accounts. Examples are balance changes and which features or bugs to prioritize in development. Bypass the ban that is still active for Yekaterina for forum and lobby activity. The ban is for allegedly conducting or facilitating high-volume spamming of the lobby with automated tools, sending National Socialism song lyrics as lobby messages, using duplicate accounts to confuse people, publishing information about how to cheat, teaching others how to evade bans, encouraging others to be disruptive and evade bans, and stating that (s)he would do as much as possible to be disruptive to 0ad moderators. Share accounts with others and obscure who is actually playing or speaking at any particular moment. One of the goals of this, according to Yekaterina (using name Sevda at the time), is in order to create "complete chaos and everyone lose identity" and to obscure Yekaterina's duplicate accounts. Here is a guide for recognizing potential duplicate accounts of Yekaterina. I feel that the user base needs to be informed about this in order to be on guard for manipulation. Often has a female gender identity Despite supposedly being a brand new account, has significant and/or advanced knowledge about 0ad and its player base Has significant interest and knowledge about mathematics Despite in some cases appearing to be located in the UK, doesn't consistently use UK spelling of words. Publishes information on how to cheat Does development on the same mods that Yekaterina does Pretends to be brand new and polite, but in a few days, weeks, or months spontaneously becomes an OP player Has the same friends and foes as Yekaterina Take a look at these accounts. AInur has points 2 and 3. Seleucids has points 2, 3, 5, and 6. Astra- in the lobby has points 2, 7, and 8. Also, on 2024-11-18, Astra- stated in the lobby that (s)he is AInur on the forum. There may be additional points that I haven't yet noticed or I'm unable to disclose due to privacy reasons. Also note that Yekaterina has access to a variety of operating systems, distributions of Linux, and computer hardware configurations. Although Yekaterina seems to favor Arch Linux, (s)he also knows that it would be too obvious if all of his/her duplicate accounts used that OS, so many of the duplicate accounts have used Windows or various distros of Linux. Yekaterina explained in the past that (s)he has sometimes put a lot of effort into creating alternate identities. This involved imagining and writing down not just different names, but also detailed personalities and biographical information for each.

Yes, this is my hypothesis for what causes users to not see their own rating when they should. Another possible explanation is if the user has an additional session (which is a connection to the lobby server) with greater or equal "priority", with another XMPP client. It could be a seemingly-crashed process of 0ad with nothing visible, or a third-party XMPP client like Pidgin, Psi, or Gajim. The lobby server is designed to send the rating list as IQ stanzas to one session per nickname. Based on what I have observed, and maybe based on reading about the design of slixmpp's xep_0045 method get_jid_property and ejabberd, that is the user's session that has the highest priority. If there is more than one session with the highest priority then the last session will be the one that will receive the rating lists. XMPP clients usually hardcode a priority value to each availability status. So, a session marked as "Online" has the highest prority. A session marked as "Away" or "Busy" has lower priority. When you have an existing session and connect another one then the new session will not receive the rating list right away. It will only receive the rating list once another user has connected to the lobby or completed a rated match. Sometimes this takes many minutes when it is late at night and there aren't many players online. Troubleshooting the situation where a user can't rejoin a game because they don't have their rating involves the following. Get tired of superstitious methods like "host a game and come back", or "reconnect to the lobby server", or "host a rated 1v1 with an AI and complete the game", or "disable TLS encryption for the lobby", or "arrange rocks in the sand to say please please please RatingsBot give me my rating with as much faith, hope, and desperate longing as you can muster'. Disconnect all of your sessions to the lobby server and wait long enough for the lobby server to terminate hung connections associated with your username. How long this takes is a research topic. It might be right away, or 60 seconds, or it might be more. Remember to check Task Manager and terminate all pyrogenesis.exe, 0ad, or "main" processes that might still be running despite closing all visible 0ad windows. Remember to disconnect third-party XMPP clients. Start 0ad and login to the lobby. You should get your rating instantly. If you still haven't gotten a rating then it's probably because RatingsBot hasn't considered your new connection to the lobby server to be a new connection with highest priority. That means that you probably have another session connected. If your new session has greater or equal priority to the old session then you will eventually get a rating, but only once another user joins the lobby server. Either double-check the earlier steps or wait long enough for someone to join the lobby. This should trigger another ratinglist broadcast.

Please visualize combining Proposals 2 and 3 with reactive checking of replays for mods that offer an advantage. Whether we trust the report of mods in use by a user during gamesetup depends on whether the user is trustworthy. That can be determined over time. "Trust, but verify," is a good motto in my opinion.

Great, thanks. What a refreshing sight, someone helping. The more detail, the better. Do we want to add an icon next to the names of players who are using certain mods (which can be specified somewhere by the hoster)? This could help with rapidly balancing teams. If someone would make a pixel art icon suitable for it then it would be helpful. And, what should the interface look like that allows hosters to define required and optional mods? Where should it be located? Atrik, do you want to help with these tasks? It would be great if you would have some buy-in to these proposals.

This seems like a lot of assumptions to me. It could also be that there is not widespread agreement because it's not that big of an advantage. It's also possible that users want to see less micromanagement of economy and more tactical combat. If players were using mods that made resources out of thin air, invulnerable units, and clairvoyance, then there would be widespread agreement that those mods are cheats, despite language barriers. There is no means of negotiating during gamesetup if we don't know up front who's using ProGUI and who isn't. That's why ensuring that ProGUI use is only overt should be the primary goal.

Unfortunately, knowing the usual pattern of open source software development, often when there's an approximate feature implemented then it's used as leverage to silence people asking for a proper feature to be implemented. Also, Proposal 1 is likely to make the problem worse because of player psychology. They'll start to actively hide use of ProGUI.

"Many hands make light work." A significant amount of the labor of Proposals 2 and 3 can be done by people who don't know how to write C++. Anyone who wants to see these proposals implemented, please make mock-ups of how the GUI would look. You can use image editing software like MS Paint or Photoshop. Take a screenshot of the starting point in the 0ad interface and modify it to add the GUI elements that are necessary.

Your choices resemble someone who wants a "really strong" cabinet installation. The person overtorques every screw and ends up breaking all of the screws or else the surfaces they're installed in. The end result is something very weak. If you force everyone to take an extreme side then you end up with a substantial number of people taking the wrong extreme side -- that of hiding ProGUI use. Instead, one could say, "I will design and build it according to physics principles." And then one uses screws the way they were designed, which causes the cabinet installation to be very strong in the end. If you acknowledge that there are limits to the effectiveness of technical means of enforcing rules about cheating and that there are varying opinions about whether ProGUI is cheating then the solution can be designed to accommodate the physics of the technical enforcement and the psychology of those varying opinions. Then few or no people will hide ProGUI use. That's the most important goal, right? Eradication of ProGUI is a secondary goal of yours, right? ... right? This is another question on which people have varying opinions. Is it balanced for the team but unfair for the players to have 1200 rated players in the same team game as 1800 rated players?

This is interesting. I would like to hear what @Stockfishhas to say about it before anyone jumps to conclusions.

Yes, I thought of this, as well. However, ProGUI use is already occurring in team games. We need to make choices that are a solution for all stakeholders, not just some of them. If you select Proposal 1 then it only acts as a (attempted) solution for the hard-liners who totally oppose use of ProGUI. The reality is that there are a wide variety of opinions about ProGUI in the user base. And, if you choose Proposal 1 then some may see it as unreasonable and therefore see adjusting ignoreInCompatibilityChecks or other ways of hiding ProGUI as reasonable. I think that what we want ideally is only overt use of ProGUI. That way we can negotiate either balancing teams based on which players are using it and which aren't, or else ask players to not use it based on hoster, and like-minded client, preferences. This is true, BUT it's reactive, and it disrupts balance. We want a proactive way to know who is using ProGUI so that we can balance teams or enforce rules before the match starts. Proposal 1 doesn't do that. Proposals 2 and 3 do that.

In thinking about this, I realized that Proposal 1 would potentially have the average effect of driving ProGUI use underground. This is because ProGUI is only practically used with ignoreInCompatibilityChecks set to false, and therefore isn't practically available on mod.io. Users will likely edit that setting in mod.json, which will cause the mod to fail zip signature checks, which will cause users to either not use the mod or attempt to hide use of the mod in matches that have Proposal 1 enabled. As a result, Proposal 1 would not actually solve the problem of other players not knowing who is using ProGUI. Proposal 1 might even make that problem worse.