Norse_Harold

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.

All signed legitimate mods will be overwritten with hacked malware edited mods instantly. Fixed it for you. Automatically sending mods from hosters to other users is a recipe for disaster. Instead, I advise comparing SHA512 or similar hashes of the mod content between users.

Of course this is a good idea. This idea can be applied to the idea that I have described, as well. Hashes can be sent over the network and compared with the host's hashes of required and optional mods. I think that we should be brainstorming for all good ideas for solving the problem as completely as possible, listing how much time it would take to implement each idea, then letting the user base decide where they want to draw the line on what time investment, and perhaps bug bounty investment, is worth it compared to the expected value of the proposed feature. Proposal 1: Add a feature where hosts can require that only signed mods are used by clients. This list is enforced by mod.io zip hashes. GUI requirements: one additional checkbox in gamesetup. Proposal 2: Add a feature where all users in a match are shown all mods in use by all other users in the match. GUI requirements: make the names of users in the match clickable in order to see the mods that they are using, including versions and possibly hashes of mod content. Alternatively, add a new GUI page that shows the mods in use by each user. Proposal 3: Add a feature where hosts can define two lists of mods allowed to be used by clients of games that they host: required mods and optional mods. These lists are enforced by hashes of the mod content compared between hoster's content and client's content. As a convenience to hosters, if they want to skip downloading optional mods that happen to be available via mod.io, zip hashes from mod.io can be used. GUI requirements: new GUI page for defining mod allowed mod lists. How much development time, in man-hours, do you think it would realistically take to implement each proposal? The user base should also be aware that Proposal 1 is an immediate compromise and would not, as completely as possible, solve the problem. I think that the combination of proposals 2 and 3 would as completely as possible, while staying open source, solve the problem. Maybe there's even more that we could do, but I haven't thought of it. What other technical solution ideas are available? Separate topic: what process or software do you advise for WYSIWYG editing of GUI pages for 0ad?

This is my opinion, as well. I agree with this. I don't think that this would solve the problem. WFG isn't signing mods frequently enough to satisfy the userbase, and probably never will. Many users choose to use unsigned mods, even in ranked games. I guess that your proposal is an attempt to minimize the effort for attempting to solve the problem. I think that it would not actually solve the problem, though. I think that it would be better to put the effort in to adding a feature that shows all players the mods in use by all players in the match. It would also be useful to add a feature that allows the hoster to define two lists: a list of required mods, and a list of optional mods, and to enable a setting that blocks users from joining unless they have mods consistent with those lists. I think that this is the most that we can do to resolve this conflict short of using a kernel-level anti-cheat system.