Norse_Harold

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.

To save the game, click "Menu" at the upper-right, then "Save", then type a description and click "Save". There is currently no automatic reminder to save the game. You said that your hoplite can't pass through the blue margin. I don't know what you mean. Do you mean your influence boundary, or do you mean a body of water? If you mean your influence boundary, I guess that you're playing on Acropolis Bay. You start at the top of a rocky plateau, and the influence boundary is about the same location as the edge of the cliff of that plateau. There are two roads that slope downward from the center of the plateau, and units can move on those roads to move outside the influence boundary. Maybe you mean that a unit can't cross a body of water. If it's a river then you can usually look for shallow parts of the river where units can cross. They typically have plants visible. If it's an ocean or lake then you need to build a shipyard, produce a ship, and garrison units in the ship in order to move then across the body of water. I wrote instructions here on how to do that.

I can host successfully with or without STUN, but I always host with STUN disabled. I have an Internet connection that is not carrier grade NAT and is not endpoint-dependent. I have the port forwarded at the router or else at the VPN endpoint. I also have the port opened in my firewall. Those are the only requirements in order to successfully host with STUN disabled. Operating system is not relevant, although I usually use Linux. I think that there are several other users for whom hosting without STUN would work, since they have similar setups, although I think that they might be using UPnP instead of manually configuring port forwards. And, from looking at network traffic captures while connecting to some of their games, I have observed that nearly all of them happen to have STUN enabled unnecessarily. These users are the ones for whom all or nearly all users are able to connect. It would be interesting if they would test this hypothesis by temporarily disabling STUN and observing how many users can connect before and after changing that setting. This article explains why things like carrier grade NAT disrupt STUN. If we want to make hosting multiplayer games less complex then I think that we should support IPv6. Carrier grade NAT is increasingly common due to exhaustion of IPv4 address space. I think, though I haven't tested it, that supporting IPv6 would solve the problems that most people have with hosting and connecting. I guess that you want to remove STUN for developer convenience because maintenance of the source code for the non-STUN code path is extra work. I want to keep the non-STUN codepath. I would be okay with manually configuring my public IP address in the settings window. Other software requires this, such as qBittorrent. However, still other software does not require this, such as Transmission. I think that Transmission uses a STUN server for querying the user's public IP address but not for initiating connections with clients. 0ad could use either of these methods to solve the problem, but I would prefer to give the user a choice. There are advantages to disabling STUN when it's unnecessary for a hoster with correct network cofiguration. People have said that they are able to connect immediately to my games. I think that it's because the delays associated with UDP firewall hole punching are skipped when STUN isn't used for connecting. Another advantage of disabling STUN is that the hoster's firewall configuration can be tightened to only allow outbound traffic related to an already established connection, whereas STUN requires allowing new outbound traffic on a wide range of randomly selected ports.