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.

I'm confused. I thought that distributed systems was a technical term for things like Beowulf clusters, where computation is done by many separate computers that communicate with each other for division of labor and collection of results. Articles here and here. I don't think that 0ad is a distributed system. It has one virtual private server hosting its services. Game matches are each hosted by one user's single computer. In multiplayer games, the state is fully simulated on each user's computer and game state hashes are sent over the network to detect out of sync (OOS) state. Does that count as a distributed system? If so then it's a trivial distributed system, because there's no speedup as a result of distributing the workload to all connected clients, because each client processes the full workload. If anything, the total efficiency decreases with each additional user connecting to the match. I once tried to use an existing open source game for a software engineering course instead of writing software from scratch. It took me months to read the source code, identify the code flow, and attempt to write Rational Unified Process documents based on it. It was impossible to accomplish within one semester, in my opinion. There was such a large amount of source code written by someone else that I had to get familiar with. My advice would be to only use source code that you're already very familiar with and that you're already certain is consistent with the expectations of the course. Beowulf related software tends to be open source, by the way.

@BroederTuck can you post a video of the steps you followed in attempting to complete that task of the tutorial? Another user was confused by incorrectly translated text for that exact same step. They said when they put the waypoint on the farmstead it didn't work, but when they put the waypoint on the grain field then it did work.

@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.