WiseKind

I think a feature like this could be applied to gathering mechanics as well. One thing I have wanted to see for a long time is the ability to have a group of worker units, then box-select some trees, and the units will automatically gather only those trees. They will gather surrounding trees if left idle after that, but this means you can queue an order to come after only those trees are gathered. For example, if you wanted to build a wall, but some trees are in the way, you can order units to gather only the trees that are in the way, then queue an order to start building the wall, and that would save you from needing to check back on those units later, or from needing to shift-click on potentially dozens of trees. You could also queue-order multiple patches of trees in a row. For example, you could order units to build a storehouse, and then queue an order to gather a patch of trees with box-select, then queue an order to build another storehouse next to a different forest, and so on. Another example is at the start of the game, for berry gathering, you could use box-select to order your women to gather the starting berries, then queue the order to build farms once those berries have run out. That would save you from needing to shift-click on each and every bush. There are so many other examples that I could probably think of for how this could work, but you get the idea.

Let's be clear, the vanilla game already has a "script" that helps to reduce the mechanical load of 0 A.D., that is the auto-queue. Granted, it's a limited auto-queue, with no logic for restarting itself, or changing batch sizes, based on the resource count, and it will complain if you run out of resources, which makes it less useful for early-game economy management. This feature is good for 0 A.D., for reasons that are depicted in the Vision. The Vision calls for the gameplay to be more strategy-oriented, as opposed to reflex-oriented. If the default auto-queue were removed in a future version of the game, that would make the game worse, since all that would do is re-introduce the need for frequent check-ins with the barracks, which does not present a fun challenge on its own, and it's just very annoying. So, if removing the default auto-queue feature would not make the game more challenging (the strategic element is unchanged), then it would not be unfair to use a mod that re-adds the feature, even if other players aren't using it. So, by extension, a mod that enhances the feature further is the same deal. The strategic nature of the game is completely unchanged; the only potential difference it makes is that your failure to check in with a failed auto-queue (or when you aren't using the auto-queue for whatever reason), is less punishing. That's what @TheCJ was trying to argue earlier, but I still need time to get back to that. I would say this specific example is bad. I know that there are other elements of gameplay that require a high mechanical load, but the game already does try to help eliminate the "many actions" of training units. It's a simple solution that ProGUI tries to build on (or so I've heard), but it works, and I have seen it come in handy before. So, yeah, the Vision really does call for removing inputs that shouldn't exist because they are repetitive and therefore boring: I don't know how it could be much clearer than that. I don't want the skill curve of 0 A.D. to come from remembering to spam click on my units every minute or two, so this should either not happen at all, or it should be done for you. That's basically what this is saying.

I, too, find it VERY annoying when there is even a small amount of input lag, or a moderate amount of FPS lag. I haven't seen either of those in 0 A.D. (maybe I just have a better PC), but I have seen it in other games, and it severely reduces my ability to play competitively. Part of it is aiming with my mouse; when the screen is lagging, I must wait for feedback when moving the mouse pointer, whereas I wouldn't have to if there were no lag. I know how you feel here, but like you said, this is probably besides the point. I cannot say I have experienced this myself. When I struggle to concentrate, it is usually due to sleep deprivation, which has now become my primary limiting factor to becoming better at 0 A.D. (as well as everything else in my life, woe is me). But this is a different point to the one you made before: Is it not? Let me clarify. Suppose that there is a modified client that has multiple features. Some of those features can be described as "macros" (i.e. single buttons to do what would normally require multiple keyboard commands), and other features can be described as "scripts" (i.e. computer code that is capable of making in-game decisions on behalf of the player, using elements of the game as input or feedback). What I tried to say in both of those paragraphs, is that neither category of tool is considered unfair to use in rated multiplayer. Those to paragraphs are logically adjacent to each other, but not contradictory at all. In fact, they go hand-in-hand. My case is that the challenge, the skill, of 0 A.D., comes from strategy. Other factors, such as a player's reaction time or coordination skills, are not nearly as important in 0 A.D. as they are in other genres (though, that is not to say that they don't matter at all). This is supported by the 0 A.D. vision, which clearly states that there should be a "greater emphasis on strategy" in 0 A.D. than other RTS games, and I interpret this as implying that 0 A.D. will de-emphasize other elements of gameplay that I described above. Macros are easier to explain: they directly reduce the mechanical load for the player, but since 0 A.D. (ideally) already does not have a mechanical load problem (or shouldn't, else this needs improvement), and mechanical load is not considered part of the game (again, stated more or less directly in the Vision), then the use of macros cannot be considered cheating. People in this thread have frequently mentioned the macros of a mod called "AutoCiv", such as the ability to create a hotkey to select only specific types of units, and those types can be finely customized. I would not consider this cheating, as it only makes it slightly faster to do what a player would already be able to do, just with more keystrokes. Though speed does matter in a real-time strategy game, it does not matter on the scale of split-seconds that one would save by using a macro (more or less, depending on their overall typing speed), nor should it if 0 A.D. is going to maintain an emphasis on strategy as opposed to quick reflexes. Scripts are a little harder to explain: my original point was that it is true that scripts can be described as making a strategic choice on behalf of the player, even if they aren't actively thinking about it in that moment. This may seem like it enables the player to offload certain aspects of the gameplay from their working memory, whereas a vanilla player wouldn't have that luxury. However, I said that using scripts in this way would be a mistake; even though a script can make a choice on your behalf, the game is deep enough that a simple script would not be smart enough to make the "best" choice in every potential scenario. You would inevitably be leaving yourself strategically vulnerable in ways you don't even realize, and an adept player would recognize those weaknesses, especially if they are common to all matches that you participate in. You could attempt to improve your script to make it better able to make the "best" choice, but with so many potential choices and moving parts in a game as deep as 0 A.D., a script that could reliably and dependably handle an entire aspect of gameplay without any human thought would have to be so smart and complex that it would effectively be artificial intelligence, and I doubt any of the mods mentioned in this thread are on that level. Even if they were, I still wouldn't consider that cheating, because I think it would be an interesting experience to compete against a fully or partially automated player, though I already know many people would disagree. Fair point. Really, I'm just trying to say that they're comparable, which you already agree with. This is important because we generally accept that we can't control the fatigue levels of each player in an online match, even though this has the potential to greatly impact gameplay (For me personally, my performance in the game is directly proportional to the quality of my sleep). Again, this was originally said by @Atrik in the old thread which was deleted, and I apologize for not making that clear the first time. @TheCJ I know that I didn't address everything that you have posted so far, particularly your point that an auto-trainer, like the one described about ProGUI by others in this thread, does not replace the need for concentration, but it does make the failure to do so less punishing. I think this is a valid point, and I have an idea of what I can say for this, but I need more time to think about it, so for now... stay tuned!

I get the feeling that you didn't even read or consider my full argument. Yes, you were focusing on in-game tools. I understood that much. I was making the point that these tools should not be regulated, and I tied this to two statements that I have already made more than once throughout this thread: The effect of these tools can be somewhat compared to the effect of life factors such as fatigue or stress, something we already generally don't try to regulate just for an online match. There are two different aspects of the gameplay experience: the mental challenge of keeping track of everything, and the mechanical challenge of implementing the strategy that one has chosen. I claim that mods mostly only help with the latter, which is already not relevant to skill because the game does a good job at keeping the required keystrokes to a manageable level, at least in my opinion. Nor should it be relevant to skill, because a game where skill is capped by a player's typing speed doesn't sound like fun at all. I'd like you to tackle these statements individually in order to claim that these mods can be described as a cheat (which, in this context, can be understood as a way to replace the needed skills to play the game competitively). And they say I'm the one making all the assumptions... I was just repeating something that @Atrik said in the old thread that got deleted. Perhaps I should have been more clear that this isn't my original idea, so I apologize for that. Maybe ask Atrik what made them say that, but in the meantime, here's the rest of my case. Illustrating my point with an example Let's bring into focus the imaginary scenario that everyone has probably already thought about, but don't want to put it into words for some reason or another. Suppose a player is VERY new to the game, either on about my skill level (Hard Petra Bot is my limit), or even weaker. I can go back to my old replays, and I almost always am able to describe the mistakes I made in strategic terms (spending too much time finding a food source in the early game, or focusing too much on early-game research and not enough on training units, etc.). Now suppose that player installs ProGUI, and uses the feature that everyone has been describing, which allows the player to set-and-forget their unit training routine, and if I remember correctly, resource gathering as well. A new player sets their rally point on the starting resources and hits "go", and they can passively watch the same early-game progression that other (good) players are used to manually performing. Problem #1: I have developed the belief that what makes a player "good" or "bad" can almost always be described in strategic terms. If you need more evidence for this claim, maybe I can pull out some of my old replays, compare them with more recent replays, and add commentary on what I really think was going wrong there. In this hypothetical example, what is making the player bad is that they don't know how to implement this strategy manually. The mod knows more about how to play the game than they do, which isn't true for even probably me. When spoken like this, it may seem like ProGUI or other tools can be used effectively as a teaching tool for VERY new players, helping them to grasp the concepts that seasoned players take for granted. Features like this may even be considered for the vanilla tutorial; something like a trigger that automatically controls the player's units to show them what semi-decent gameplay might look like. Combined with the tutorial panel, this could be a way to illustrate how a good player thinks. However, this wouldn't go very far, because... Problem #2: This game is (should be) sufficiently diverse and sophisticated that, in this hypothetical example, the VERY new player who is using ProGUI to watch their economy passively grow in ways that don't work in vanilla, would still lack the sufficient strategic understanding of the game to, you know, actually play good. The game starts, and the first thing I do is set my civic center rally point on the starting resources. As a VERY new player, I genuinely see nothing wrong with this! Oh, my population limit was reached? Time to select all of my units and order them to build houses in a row. Every single unit is no longer building resources, and is now walking across my base to build a bunch of houses, which takes a while. Now I can get back to gathering. My berries run out, so I do what the tutorial suggested and build farms next to my civic center. My wood runs out, so I build a storehouse beside the next closest source of wood. I don't build a barracks early-on, or defense towers, or anything else, because I'm a new player and I don't understand any of that. Other players have stated in the past that ProGUI doesn't automate decisions about building construction, which is what I'm going with for this example. But even if it did, it would still be a similar story. It may be true that a new player would benefit greatly from the mod in terms of raw scores, but it doesn't serve as a replacement for knowing how to play. Someone who does know how to play still has to pay attention to everything in order to get the best possible use of the mod. In conclusion: So, I just made this example knowing that there is a whole lot of room for me to have to fill in details that I wouldn't know definitively, so it's worth stating again that I still haven't tried ProGUI, and I know that there's a high chance that a lot of what I just said is inconsistent with the actual mod. I would like to say that this is besides my point. It's just an example, and you can comment on every little thing that I misunderstood, and say that I'm a bigot (I will probably do just that, once I have actually tried it), but these are all minor nitpicks, and my point still stands. My point is that even if a GUI mod is capable of making strategic decisions on the player's behalf, this cannot be considered cheating, because such mechanisms still depend on the player's ability to concentrate and understand what is happening, which will always be necessary. If I am understanding this correctly, your claim is that the lag in the game affects your ability to keep track of everything. I feel like I must put a pin in this and discuss it later, because I obviously don't know what the lag is like, since I've never tried multiplayer. I have tested the multiplayer by running multiple clients on the same computer, and the result is that every command I send has a noticeable delay, but this doesn't make it harder for me to concentrate on what I am doing (not that I was ever trying to, since those tests were mostly an attempt to explore for myself how multiplayer works in 0 A.D.). In the meantime, maybe be more specific about what you mean? Again, I have yet to experience 0 A.D. at a high level, so I can't really make a claim here, but I think it would be helpful for you to be more specific about how this works, if that is possible. The scenario that this makes me think of is one where you input your commands on the keyboard (and don't struggle to do so), but must wait for those commands to be enacted before you can begin thinking ahead. I don't see where a GUI mod fits into the picture here. A GUI mod might reduce the number of required keystrokes, but it wouldn't make the lag go away. If this is your experience, then I don't see how a mod like ProGUI would make it better. And if it is the case that you are struggling to input the key commands fast enough, then I would say that this is the Confusing UI problem like I mentioned above. Being limited by my typing speed doesn't sound like fun at all, and if that happens frequently in a typical rated match, then I would say that 0 A.D. is falling for the Confusing UI snare that they mentioned in the Vision. I think this comment is unfair. I wouldn't say that this is a troll topic that doesn't deserve sincerity. I, for one, have had a lot of fun in this one discussion, and a lot of productive and mature argumentation has already been observed, which I enjoyed a lot. I am feeling the frustration that some forum users don't seem to see my argument eye-to-eye, and make comments that seem to ignore things that I have already said. But neither @Atrik nor @TheCJ are guilty of this, to my knowledge. And it doesn't ruin the whole thread for me. Also keep in mind that this thread is actually several threads in one. There are the following arguments occuring simultaneously here: Are mods like ProGUI and AutoCiv unfair to players who aren't using them? How should we address the flaw in multiplayer that allows any player to reveal the map unfairly? (a completely different question than the one above it) How much of the community is SP-only, and therefore much harder to measure? Emphasis on singleplayer in future Beta versions? About the notorious lag in multiplayer due to poorly-optimized code As you can see, these are completely different topics that have all been brought up at least once in this singular thread. To confuse these disparate questions into one would be a mistake. I would also like to say that every opinion I have stated about "what MP should be" has been on the basis of 0 A.D. being a free software project, and I feel I do have a stake in how certain networking and social structures are implemented, because I don't want to see this great project get ruined because people don't understand my vision of what free software is supposed to be about. But I understand now that I am not going to change the opinion of other people, and I would be better off seeking out a portion of the community who is more welcoming to mod users, letting everyone else do their thing. Hearing this makes me want to try the multiplayer lobby sooner. I did register on the lobby, mostly as a defensive reservation of my username, and when I looked at the list of active games, I saw two people playing a 2v2 versus the Very Easy Petra Bot. If that is what people are using the lobby for, then I might just give it a try, maybe even today. I do plan to try that and ProGUI, mostly because it has been brought up so much, and because understanding what these tools actually are, and how they work, will allow my to better illustrate the opinion I have. But, as I have also already said, my base claim does not depend on specific facts about these specific tools. In this very post, I may have gotten a ton of stuff wrong about ProGUI, and this will probably make me cringe and want to go back and edit my mistakes later, but please understand that my base claim is that there can be no such thing as a GUI cheat mod. Therefore, no fact about these specific tools will ever change my mind. Hopefully you can understand this. I understand the frustration of seeing people make foolish assumptions about your own work, without putting any effort to understand the very thing they are arguing about. But please understand that I am not arguing about ProGUI at all; it's just a useful example that I use to illustrate my base claim that actually has nothing to do with ProGUI, and I am only working with the information that I have gathered from other forum users. If I have misunderstood one of these things that other people have described (and I have misunderstood at least one thing, I'm sure of it), then feel free to correct me, but please don't call me a bigot and say that this entire thread is just a big joke, because it's not. As I have said before, please look past the misunderstandings and see the broader argument being had.

Thank you so much for this excellent demonstration showing another angle on the claim that making the game fair-by-design isn't hard. I would say that I don't think video-streaming the game to clients is the right answer, though. Lag would be much more consequential, even if it doesn't result in OOS errors. However, I want to place emphasis on this line: This is the point that I am trying to make. It is possible to design the network protocol to fix the holes that I am describing, while allowing it to use even less bandwidth than it already does. Though I don't have the time or experience to create a technical demonstration of how this could work, I do have quite an imagination. I imagine that the simcode would work just like it already does, but with only one simple change: make it possible for the host to send packets ordering units or structures to "pop-in" or "pop-out" of existence. Then, the host would have all of the tools it needs to control what players can see at any given time. The simplest implementation on the host end would be to check on each tick if a unit is entering or leaving a player's vision range, and send the pop-in/pop-out packets for that tick. Each player command should only be synced with clients that have the affected units in their vision range at that moment. Of course, any implementation would work as long as the basic tools are available, so we can separately discuss whether running these calculations on every tick would be too costly for hosts. The host would also no longer need to send data for units that aren't visible for the client, which directly reduces the bandwidth requirements. There are two potential problems with this model, which I think are also easy to solve in principle: The map itself is also a source of valuable information when the Shroud of Darkness is enabled ("Explored Map" setting is turned off). There would need to be a way to stream the actual terrain and resource data to clients as they explore the map, otherwise players could still bypass the shroud of darkness. As I have described before, I can already somewhat bypass the Shroud of Darknesss simply by viewing the black parts of the map from an angle, and observing humps and dips in what is really a silhouette of hills and valleys that I shouldn't be able to see. Then there are replay files. If the client cannot see the whole game state (and they shouldn't), then it's worth reconsidering how replays should work. Perhaps the "pop-in" and "pop-out" commands could be recorded on the replay file directly, creating a "partial" replay, that only shows one perspective of the match. If we want players to be able to see the whole match replay at the end of the match, then this would require the dedicated server to download the replay file to each client once the winner has been determined. Alternatively, there could be a website associated with that provider, allowing players to search for their match (or possibly any match) and download the full replay file on their own time. As I said, they wouldn't need to. Nobody is actually suggesting that we do it this way; this is just a hypothetical example to demonstrate that the real bandwidth requirements to secure the network protocol aren't as you described previously. Look above to see my proposal for the simplest change that would need to be made to make the game fair-by-design. Another great example of a tool that enables a player to play faster is Adderall or caffeine, or other stimulant. I made the point above that when playing online games, it's a fact of life that we can't control factors like fatigue and comfort for all players, and we generally accept this fact. The mood of a player is likely to affect their performance much more than the usage of computer macros or other tools to implement the same behaviors they already have, but with less keystrokes. My case is that this general acceptance should also apply to client-side modifications. It's also worth pointing out that the ability to concentrate (enhanced by stimulants) is completely different from the ability to type or click faster (enhanced by mods). The former of the two is relevant to gameplay, because the inability to concentrate manifests in the lack of awareness of game elements, which leads to flawed strategies being used. The latter, however, is not relevant to gameplay. The inability to type fast manifests in the furious typing or clicking to implement the strategy that one has already formulated and decided on, resulting in direct frustration as the player is unable to mechanically implement their desired behaviors. This is a problem that I have never had when playing in singleplayer, and if it is a frequent problem in multiplayer, then this deserves its own discussion; not about whether GUI mods should be banned, but whether we should make changes in the game to avoid the Confusing UI that results in this frustration: This plays in to a point I made before: some of these tools are not meant as performance tools as much as accessibility tools. A mod that transforms the tree and berry models into red and green cubes would be very helpful to a player who, for whatever reason, has difficulty making out the patterns of these different game objects. It would also be helpful to a player who doesn't have a GPU powerful enough to render the models for the game. If you are arguing that these tools are cheats, you are essentially saying that vision problems, as well as certain neurological differences, constitute flaws in that person's skill in the game, and therefore these people should not be able to play 0 A.D. with us, because of their differences. I think that's absurd and not cool at all.

Hi, I'm not dead! I guess it could be described as an anti-cheat system by some definitions, but I would refrain from calling it an anti-cheat because such a system would be easily thwarted by recompiling the game. Someone who really wanted to hide the use of mods would easily do so; this system would be a convenience feature to ensure that casual players don't accidentally break the rules. A real anti-cheat system would necessarily be a nonfree component bolted onto 0 A.D., because it would rely on obscurity to do its job effectively, which is to make it more challenging for players to hide modifications to their game client. I wouldn't support such an anti-cheat, because it goes against the values of free software. The system I am proposing is just a simple client-side check, done at the engine level, to ensure that the player does not join games with mod settings that are incompatible with the client (such as using ProGUI in a non-ProGUI game, or even using a mod that adds new game mechanics in a lobby that doesn't use the mod, to prevent OOS). As a security feature, this would be a joke. That's why I'm not calling it a security feature, but rather a convenience feature, because it makes it easier for those using the vanilla engine to comply with mod rules. It prevents accidental violation by someone who may be new to the lobby or unfamiliar with the different rules, but it does not prevent intentional violation, since this would always require nothing more than downloading a different EXE off the Internet. Great! Then don't change anything. One of the greatest aspects about free software is that people have the freedom to form their own communities around software. I've had a tone of urgency, as if the whole project will be wasted if we don't fix this one issue, but that actually isn't really true. Even if 0 A.D. started releasing every Beta version and beyond with a nonfree license (and to be clear, I don't think this is likely to happen), Wildfire Games will never have the power to take away Alpha 27 from those who already have it. If this community came to the conclusion that we can't afford to release the soruce code, or else cheaters will be unstoppable, that won't stop me (or anyone) from taking the work that's already done, and spin it in a different direction. If the whole lobby were oppressed by rules telling you what mods you are allowed to use, I can start my own lobby where such rules don't apply. What I'm trying to say is that we don't have to argue about whether or not GUI mods should be allowed, or what exactly constitutes cheating, as long as people are empowered to make that call for themselves, regardless of what other people think. As much as I value software freedom, and reject nonfree software, I will say that one of the best things about technological freedom is that it enables a more diverse and inclusive Internet. Nonfree social media has a habit of forcing everyone into one box, one way of using their technology. But in a free software world, anything goes, and people with the most disparate means of interacting with technology and the Internet can more easily coexist with each other. Part of this is understanding that people are going to vary in their undertanding of the very concept of freedom, and not letting this affect how you exercise your freedom. This means that a free-as-in-freedom lobby may very well have some players who don't want other players to use any mods when playing with them. I can't change the ways of these people, nor should I have to, and they also can't force me to adopt their rules in my own matches. We can all coexist peacefully, despite our very different viewpoints, and I think this is technological freedom at its best. So, if this is the current state of the multiplayer lobby, then no changes are necessary. But if the lobby does force all players in one particular direction, this still won't stop players from starting their own lobby with their own rules. This is because freedom is not something that is given to us; it is something inherent in our being, and Wildfire games cannot take it away from us, even if they never wrote another line of free code again. 0 A.D. as more than the multiplayer mode It looks like the thread verges off from there, and now everyone is discussing the size of our community: player retention rates, proportions of lobby regulars to the (possibly) thousands of players who play privately and never interacted with the community, and a few others. I want to make it clear that this is a totally different discussion than before, but I don't want to shut it down; I do think this is worth discussing here. I think it's important to note that 0 A.D. is definitely more than a multiplayer RTS experience. Even if the network code is never fixed, and every match has at least one cheater, the game, as a whole, would not be a complete failure. People who are dissatisfied with the multiplayer experience will still find ways to have fun in 0 A.D., whether that means playing singleplayer campaings, or setting up LAN parties with trusted friends. I wholeheartedly agree that Beta 1 should definitely have most of the work done in the area of singleplayer, as this is where we are lacking the most. Practically the only thing there is to do in singleplayer is bash my head against a very dumb A.I., which is fun for a while, for a new player, but lacks replayability once a player has mastered the basic mechanics of the game. I agree with all of this. I really think we should address the information leak problem by designing the network code so that the game doesn't have to sync with all players. This is a gaping hole in the network protocol, and should be treated as such. I believe that this is possible, and it would totally fix all information cheating, leaving only ProGUI and similar mod users to complain about. I don't see how this wouldn't be a massive win for the multiplayer side of 0 A.D.. But at the same time, we also need to keep in mind that the lobby, and the multiplayer modes, are just one part of our great game, and we shouldn't get so hyper-focused on a flaw there, that we miss out on opportunities to improve the project more broadly.

Thought I wasn't going to be back until the end of the week, but I can't sleep so I guess I'll say a few more things. I don't think the measures for preventing scripted automation would be much different from the measures for preventing any other GUI change on the client side. I know about the specific examples that have been brought up as for how people were found to be using automation, but as a general principle, it's impossible to be completely sure that someone didn't use automation during a rated game, for the same reason that it's impossible to enforce a modder transparency requirement. My main thing to say about scripted automation is that I think that there is a certain point in which a mod literally becomes capable of playing the game for you. At that point, it is no longer a GUI mod, and instead becomes a new A.I. player for the game. Then it becomes the discussion of "should a robot be allowed to compete in the lobby service?". Personally, I do think that robots should be able to participate in anything that humans can, provided that they are competent enough, and that's a completely different extreme opinion that I hold, which is also based on freedom absolutism. I disagree with all captcha systems, and other anti-robot technology because I believe that at the end of the day, there are plenty of reasons to automate nearly anything one would do on the Internet. Anti-robot tech is mainly used to prevent overwhelming a network server with bogus requests, but I think that we should rely on other technologies to do this. I'm not going to go into much more detail here, because this is mainly for context. But, when it comes to automation like ProGUI's auto-trainer, I see that this blurs the line between a simple GUI mod that doesn't automate any part of the game, and a full-blown A.I. client that can play the game competitively, without any user input whatsoever (you literally click the join button and then check back in an hour to see if you won). If we suppose, for the sake of argument, that the latter technology is problematic, then there should obviously be a limit to how much automation can be done. I disagree with this, but only because I believe that even an entire lobby account that's run by an A.I. wouldn't be an issue with me. This context should help clarify my stance on automation, since I know that is the primary controversy surrounding GUI mods. But (and here's where I say once again that I haven't tried ProGUI yet), as you all have been describing, ProGUI's autotrainer works by taking as input the desired army composition, distributes the required training across all available structures, and starts each batch with a different value based on resource counts. If that is a fair assessment of ProGUI's autotrainer, then I would say that this isn't too far into the realm of automation, as it would still require significant strategic thinking and planning by the human player, in order to get the best use out of it. This is just a more in-depth analysis of an argument that I have already made more than once. I just think we need to be careful. Under that definition, it's easy to make the case that having a bigger monitor or something can be a cheat. This is why we need to draw the line somewhere, and acknowledge that not every circumstantial difference between players should be banned. I would really like a more in-depth definition of the word "micro" in order to truly understand this derivation. Previously I thought of "micro" as the smaller, more detailed choices that you make, which are not as noticeable when getting an overview of what is happening in a game. When I am constructing a stone wall, I try to keep all of my builders on one side of the wall, so I don't have some of them trapped outside of my base when the wall is complete. I do this by issuing a "push order in front" action to move the units to one side of the wall while they are building, so that they will walk around and then continue. When capturing an enemy civic center, I will use the line-drawing movement mechanic to draw a circle around the structure, and then queue the order to capture, so that the units will more quickly wrap around the structure (depending on the size of my army, I may be able to prevent garrisoning inside by covering the entire perimiter). These are the kinds of decisions that I would consider "micro", and I do think they matter. However, I don't think automating them would be considered cheating, because of a point I made earlier. I notice that even when playing in vanilla, I am not really limited by my input speed. I am limited by my ability to concentrate and think ahead, but this is different. Whether I am using a mod or not, I will still be able to draw the circle around the civic center, and this will not take away precious time for clicking on something else. The mod just makes it easier and less annoying, but I still have to think about it. Again, maybe the examples I have given are not what anyone else thinks of when they hear "micro", so I think an in-depth explanation of what that means will be helpful. I do think that this game should have more of an emphasis on tactics and strategy, and should not be based on where exactly on the ground you click, or how fast you are able to click it, based on the paragraphs of the 0 A.D. vision saying that "First click wins" is a snare that will make 0 A.D. a worse game. "Every other RTS" may be designed in such a way that the first click wins, or has much more of an advantage, but 0 A.D. treats this as a flaw and tries to avoid it by designing the game to be deeper than that. So far, I think they are succeeding. @TheCJ, I would like to say that your previous post was very enlightening. I think you have a stellar understanding of my position and the current status of this thread. I don't mean to sound dismissive by addressing your counterarguments. It's just that if someone agrees with me, then what do I have to say to that? A compromise Even I am starting to feel the frustration in this thread. It seems that some people really strongly hold the position that the individual key presses on someone else's keyboard is part of the game, and insist that we should limit how other people are allowed to play our game. I think the community would benefit from a compromise, where both viewpoints are equally respected. I don't think we are ever going to come to a complete agreement, so here's what I think we should do As far as the lobby TOS goes, the rule of no cheating should be clarified to say that cheating only happens when a player uses tools to break a game mechanic, such as fog of war. A.K.A. my definition of cheating. However: Individual hosts should be empowered to write their own rules for what should be allowed in their games, even in rated games. This could include 'no mods', or it could include 'no turtling' (i.e. never attacking the enemy and basically waiting the game out, which I think is fun but others may think is boring). It should be accepted that hosts who include their own rules should generally be responsible for enforcing their own rules. If an individual host finds out that another player broke their 'no mods' rule, they can ban that individual player from future games, but they will not be banned from the lobby. This is like saying that if you start spamming offensive memes on this forum, you get banned from the forum, but not the whole Internet. A convenience feature may be implemented in the lobby where hosts can list out what mods they allow, or even require, and clients will automatically honor those policies. Clients should not always disclose what mods are currently enabled for every host, but some hosts can require that mods be disclosed in order to connect to them, and the client can be programmed to automatically honor this. This should not be considered a security feature, as this would go against the principles of free software, but it should be a convenience feature so that the "what mods are allowed" conversation doesn't need to happen on every single match start. I don't think the no-mods policy should be the global default, enforceable with a global ban, because that would present a tricky situation for hosts who want to welcome individual mod preferences. If the other side insists that the no-mods policy should be global, then there could possibly be a further compromise where there are differnet game categories (don't use rated/unrated for this) for the different groups and whether or not they allow mods, and using mods in the wrong group could result in a ban (though, as described above, this would require using a modified engine, as the vanilla engine would have safeguards in place to prevent accidental violation). There may be a different option where different lobby services are used for the different groups and their policies, if it turns out that we're such savages that these two opinions can't coexist at all. You would need to edit your user.cfg to switch lobbies, which it is possible to do, by the way. I believe in freedom, first in foremost. I think that with this belief comes the acceptance that I cannot control what code is running on other people's computers, just like they shouldn't be able to control what code is running on my computer. But, just like all other free software supporters out there, I also accept that the vast majority of the Internet is irredeemably nonfree, and we must relegate ourselves to a small corner of the Internet in order to retain that perfect standard of freedom that we place on ourselves. But to me, the alternative, which is to accept a partially nonfree setup, is worse. So I wouldn't mind if the 0 A.D. community is fragmented even further for the people who have different standards that they hold their games to. Personally, I don't even see fragmentation as a bad thing; it's good to allow the Internet to be diverse and decentralized, precisely because that way, we don't have to all agree on the same thing. Let's just acknowledge that there is still what I would consider to be a severe critical vulnerability in 0 A.D. that allows anyone to bypass the fog of war and see the entire game state in a rated match, if they are so inclined. Can we at least all agree on that much? Please? It doesn't mean you need fiber internet just to play a 1v1, trust me.

Perhaps I have not been concise enough for you. Let me make it up to you by writing a short (ok, not really short) summary of everything that has happened in this thread so far: I open the thread with my main idea, which states that modding is not cheating, because the challenge of 0 A.D. is based on strategy, which is not easily replaced by a mod. Even if there is a measureable advantage, that is not the same as cheating. I also bring up the separate problem of revealing the map unfairly, and I think this has a technical solution. The first reply is from @wowgetoffyourcellphone, who says that the idea that mods are cheats is ubiquitous, and there is no reason for 0 A.D. to be the outliar. I said that 0 A.D. is already an outliar by being a free software project, and my original claims are tied primarily to free software idealism. I clarify one of my previous points by saying that this thread is actually about two arguments, one being about mods like ProGUI, the other being about the ability to reveal the map unfairly. Even if you believe that mods should be regulated, you can still agree with me on the point that we can do better to make the network protocol of 0 A.D. more secure. Then, @real_tabasco_sauce comes into play, saying that ProGUI makes it easier to exploit a known gameplay vulnerability where people expliot the garrison mechanics to transport units much faster than walking. I said that this is a flaw in the game design itself, and should be treated as such. @TheCJ brings up several points: The first one is that the GUI is part of the game (I still don't quite understand the logic behind this one, but that's okay). The second point is that even a small increase in input speed (a few seconds, or even milliseconds) provided by these mods is an advantage, therefore cheating. I counter this by saying that the gameplay should be designed with enough depth that it's not about who clicks the fastest by a few milliseconds, but rather who is the smartest at thinking ahead. The third point is that it's not necessary to have "checks" in place, just a general consensus of what is allowed. I say that this will become increasingly insufficient as our community grows. The fourth point is that TheCJ does personally find fast clicking to be enjoyable in gameplay. I say that while some might find this enjoyable, it is generally better, from a UX design perspective, to minimize the amount of input needed to play the game. @Boudica barges in with a highly personal insult implying that I'm just sore about not being able to cheat in video games and used Machine Learning tools to assist in writing my article, and also grossly misquotes some of the things I said. Rightfully ignored by literally everyone. @bb_ makes a comment that while changing the network protocol to be more secure may work in theory, the performance requirements of such a model would be forbiddingly costly. I clarify that the network protocol doesn't have to be implemented in the way that they are describing, in order to gain the security benefits that I described. @Seleucids makes the claim that the vulnerabilities in 0 A.D. game design are not easy to exploit and therefore low-risk, and also claims that the features provided by ProGUI are not merely GUI mods, but do change the behavior of the simulation code. I counter the latter claim by saying that, while I can't make any statements about how ProGUI actually works technically, the mod does not need to modify the simulation code in order to work as advertised. @TheCJ once again tries to claim that the best practices of general UX design should not apply to game design, and @real_tabasco_sauce affirms this notion. I reply by making the statement that the "mechanical challenge" of 0 A.D. is a necessary evil, and needing to click faster does not make the game better. I clarify one of my previous points by saying that there is a distinction between input speed and actual mental concentration capacity. Mods can help with the former by automating certain actions, but the latter cannot be helped by anything short of artificial intelligence, which becomes a totally different discssion (should robots be allowed to play video games?). @TheCJ calls out a supposed self-contradiction in my argument, which was actually a writing mistake that I later corrected. @TheCJ claims that we don't need to argue about the definition of real-time when a dictionary definition exists, and I reply by saying that a dictionary definition is not helpful because dictionaries are meant to provide the general use of a word, while this is a highly specific case. @TheCJ claims that even if concentration and input are two different things, they are both part of the challenge. I insist that the latter is not part of the challenge, and that was my original point for making that distinction. @Atrik makes a comment on the feature set of ProGUI, and claims that it was about UX improvement from the very beginning. @TheCJ affirms that this is precisely what makes it a cheat mod. @Seleucids later steps in by saying that under this metric, any circumstantial difference can be considered cheating. This is consistent with an argument I have also made previously. @Atrik then replies that there are so many GUI mods out there, and there are so many different opinions about what mods are cheating and which aren't, that it's better to stick with my more narrow and concrete definition of cheating, while also affirming that individual hosts should have the right to develop and enforce their own policies. Atrik also claims that it's important to consider intent (correct me if I misunderstood this part, because I likely did) when judging what mods should be allowed. @TheCJ states that these mods should be regarded as cheats, even if some hosts allow it. @Atrik makes a comment that the notion that these mods are "cheats" can have the lasting consequence of turning people away from using these tools, even if they would otherwise find them useful, and this is another good reason to be careful when calling these mods "cheat mods". This point proves effective against @TheCJ. @TheCJ claims that the sheer popularity of AutoCiv disqualifies it from being called a cheat, and uses yet another dictionary definition to support this argument. I covered this already, in my original claim that dictionary definitions aren't helpful in specific cases like this (I don't believe that AutoCiv is, or can be, a cheat; just for a different reason). @guerringuerrin comes in hot, with a variety of claims: The first point is that I misrepresented one key aspect of ProGUI: a feature that is much more sophisticated than I ever gave it credit for. I conceded and even apologized for this, but also claimed that it doesn't affect the actual core of my argument, which is that a GUI cheat mod cannot exist, even with automation. The second point is referencing my original claim that these mods have a small impact on performance, because what it takes to be good at this game is not input speed, but rather strategy. The second point is that the same can be said about revealing the map. I counter this by saying that revealing the map has its own reasons for being considered cheating, not necessarily tied to how it affects gameplay in practice. The third point is referenceing a previous point I made that these mods make you more predictable, therefore weaker, if you over-rely on them. The third point is that a player doesn't have to limit their unique style in order to gain an unfair advantage from these mods. Actually, I don't think I ever replied to this one, but I did say at one point that even when using these mods, a player must still keep track of everything going on in a match, to the same degree as other players, and if they fail to do so, then they are leaving themselves vulnerable, just like another player would, even if that is not as obviously apparent. The fourth point references my previous clarification of the two different kinds of "cheating" that exist". The fourth point is that other communities have come to the consensus that modding is cheating. I, once again, clarify that this doesn't mean we have to, and in fact, it would go against our stated design goals if we restricted the use of these mods. The fifth point mentions the habit of these types of threads for being unproductive and too personal, and affirms that we need tools (the kind of tools that, as I have argued, cannot exist) in order to promote fairness by regulating the use of these mods, and also something about a bug in the vanilla game. @real_tabasco_sauce claims that APM inevitably becomes part of the challenge in any RTS. @Atrik claims that the very opposite is true. I make another example claim by referencing the ability to change the simulation speed of a match in real-time, with the design of this feature implying that it has an effect on the difficulty. I claim that this effect, when used in moderation, only affects the need to concentrate, and think fast; it does not affect the need to type fast. @Atrik claims that I misquoted something from @guerringuerrin. I reply by clarifing the point I was trying to make. @Atrik doubles down by being the first to accuse me of making baseless assumptions. I address this by clarifying that my argument does not have anything to do with ProGUI, and I only ever used it as an example, and I have done my due dilligence to avoid sounding like an expert on ProGUI when I am not. @TheCJ steps in and says that other people should not be expected to thouroughly research ProGUI, given they may not have the time to. @TheCJ counters my original claim that modder transparency is impossible to enforce, based on a specific example of how ProGUI works, which is easy to detect based on the replay. I make the statement that I see this specific example clearly, but other mods may not work the same way, and generally, any attempts to control what software can run on a player's computer will be an uphill battle. @TheCJ forwards some other claims that were already sufficiently mentioned in this list, and mentions that @Seleucids thinks the game is already so fast that click rate begins to matter. I make the claim that this is a flaw in the gameplay and should be treated as such, therefore it is not a valid counterargument. I also think this is not what @Seleucids actually meant. @Atrik express a concern that too many misunderstandings can also repel someone from trying out mods such as ProGUI, if they get confused themselves. @guerringuerrin make the claim that this game is already so fast that APM matters. I counter this by giving a specific example that illustrates my point that I have never (personally) been restricted by APM, whereas I feel constantly restricted by my mental capacity at my current level. @guerringuerrin also becomes the second person to accuse me of making unfair assumptions and bigotry, and I address this promptly. @guerringuerrin also mentioned at this point that the definition of cheating is determined by the majority (can't really argue with that), and correctly repeats back my personal definition of cheating (something that breaks a game mechanic directly). I don't think that last part really needs to be said, but it's just for those who are going to try and say I'm cherry-picking my case here by ignoring the real arguments (I'll get to that soon). @MetaPhyZic complains about the unproductivity of this thread. I, personally, think that this thread has been very productive so far, but there are a few things that I need to address before we can move on, which is part of the reason why I'm writing this list. @guerringuerrin says that I have only been making assumptions so far, and nothing of substance has been said, and also says that I do not have the authority to discuss any of this until I have tried "real" competitive multiplayer. @wowgetoffyourcellphone makes a comment that kind of makes it sound like I'm only using this thread to rationalize my usage of ProGUI, which makes no sense because I don't even use it, and don't plan to use it for anything other than out of curiosity (because it's been brought up so much already), and because I have already stated why I am writing this thread, which is because I believe that this project is promising, but I am worried that too many people are working on a free software game design project despite not understanding the true values of free software, which has me worried about the future of the project. So, there you have it. Not really short at all, but better than nothing. This is a decently-sized thread, after all, and I think it has been productive. Now, @guerringuerrin, I personally dare you to write your own list of every assumption I have made in this thread, followed by the truth that I am missing. Don't just say that I am making baseless assumptions and walk away. I have said this multiple times before: if I am misunderstanding something, I want people to correct me, and not just call out my assumptions without any real opportunity for clarification. This way, we can move past the misunderstandings, and move on productively. Admittedly, even I am starting to get frustrated with the circular arguments and personal attacks, but I believe that my thread doesn't have to end this way. And if a subset of people are not being productive in the debate, the other productive members can just block them out and carry on. I'm going to be away for the computer for a week, so I won't be available to continue to participate in this discussion until about April. We'll just have to see what happens. All I'm saying is that I do think that this thread has been everything I wanted it to be, and I'm not ready to give up yet.

After some additional thought, I think I can say more about this one point. This is an example to help illustrate my point. Let's imagine the specific scenario of you conducting a raid, and you have no trouble keeping track of everything you need to. You hear the sound cue that your soldiers have come out of the barracks and are now gathering resources back at your base (or are heading to assist in the raid, whatever strategy you chose...). You didn't enable auto-queue because your food count fluctuates wildly based on hunting and fishing gains, rather than the steady flow of resources provided by a farm or whatever. But you do have enough resources to train another batch. Your raid units do not need constant input. They may be on an attack move to the enemy civic center, or they are trying to capture a fortress, or whatever. It's not hard to get the 3 seconds you need to press 9, press F3 (if that's appropriate), then use the scroll wheel or whatever input to select the batch size you think is best, and shift click to train the next batch. If you are constantly clicking on your raid units, that's a bad habit. I started beating the Hard Petra Bot when I realized that I could have a raid going while still focusing on my base and growing my economy, and I often win fights without even paying attention to them anymore. The fighting mechanics of 0 A.D. are simple enough to allow a more balanced distribution of your input and attention between attack, defense, and economy. Like I said, in all of my gameplay, I have never been limited by input speed. When my input is limited, it's because I can't keep track of everything. A mod like ProGUI, with its auto-trainer, might seem to help remedy that, but I am relying on a tool that only does simple logic based on pre-determined preferences, while the mechanics of 0 A.D. economy management are so complex that there will inevitably be cases where this is insufficient, especially in pro games where seconds matter more. EDIT: I know someone might say that I only assumed that the auto-trainer mechanics are too simple for the complex mechanics of the game, but that's not the point. My point is that it is (should be) so difficult to program a mod that always makes the "best" decision, that such a tool could be described as intelligent. Other people have said in this thread that the auto-trainer takes into account your current resource counts, a desired army composition (how many spears, swords, slingers, etc), and number of structures. But when a human decides on what batch size to train, they must take everything into account. Do you have reason to believe that a large army is headed your way? Better pick smaller batch sizes to make sure they aren't still training when the enemy arrives, just in case. Or maybe larger batch sizes, if you know more precisely how much time you have. Or maybe you have two split territories, and you only want units training on one of those bases. Or maybe you want unit training to be tied to your corrals, so that after each batch of livestock is slaughtered, a certain fraction of the proceeds go to training soldiers, and the rest goes to more livestock? That's a strategy that I have tried before, and I must admit it's actually not very good, especially in the early game, and is best used as a supplement to another food source. You can make the case that ProGUI can actually be set up to handle all of these cases with its automation, but I doubt it is so complex and sophisticated that it can automatically decide what is best to do, based on all of these external factors, without any coaching or configuration from the user. And I should be careful for @Atrik ; I don't mean to insult your mod, especially if I haven't even tried it. I don't think anyone was expecting ProGUI to literally be an A.I. that plays for you, and I don't think that's what you wanted either. I'm just trying to illustrate the point that I don't think these tools were meant to be used as a way to bypass the actual macro-strategy elements of the game, which are what ideally make the most impact in a solid RTS, and @Atrik has said this as well.

Not speaking from my own experience here (because I don't have any), but just going based on what other people say, about the heuristics used to determine if ProGUI is used. Yes, I do see now how it can be pretty easy to detect the usage of ProGUI based on replays. However, in general, my argument has nothing to do with ProGUI. My argument is that from a general, technical standpoint, it is impossible to be completely sure that a given player's in-game actions weren't automated, due to the nature of free software and the Internet. There may be another mod out there which works differently and has a different feature set, which is coded in such a way that it is much harder to tell the difference between that mod's behavior and human behavior using the vanilla client. That is what I mean when I say that it is impossible to prevent other people from modifying their client. I have said this once, and I will say it again: I am not making any claim based on a specific fact about ProGUI. I mention it often because everyone else is using those terms, and it's a neat example to help illustrate my point without actually making a claim based on it. I think I have made it very clear that I'm not an expert, and don't claim to be. And if you think I misunderstand something, please correct me by telling me exactly what was wrong with my claim. I admit that not everything I say will make sense, and this can lead to confusion. But making the claim that I am basing my argument on assumptions is a stretch. If it seems that way, let me know because I might have made a writing mistake and made it seem like I am making a logical derivation directly from a feature of ProGUI or other mod, but I am not. My core argument is based only on general technical details and free software ideals. The actual core of my argument is simply that I believe all mods should be allowed, because the skill curve of this game is based on strategy instead of click rate, and while some mods may try to emulate a good strategy, they will inevitably come up short, unless those tools are so complex that they can be described as artificial intelligence, and then that's a different story. Like I said, it's not that I don't use ProGUI, it's that whatever ProGUI can or can't do is not essential to my case. In truth, I am considering taking a look at it, just to see what all the fuss is about. But I still strongly believe that this game is about strategies more than click rate, so nothing I can possibly find out about ProGUI will convince me that I am playing a completely different game whenever I turn it on. In all of the time I have played in singleplayer, I have never once been limited by my ability to issue commands with my keyboard. But there have been plenty of times that I was limited by my ability to keep track of everything that was on screen. These are two different things. You can make the case that I just have yet to see pro gameplay, but even if there will come a point in which my strategies become so finely tuned and intense that I start wishing I could type faster, I believe that this is a flaw in the gameplay itself that could use improvement. I already explained in some detail what I mean by this, but in general, it's never fun to be limited by your typing speed, and while I believe that this game should be challenging, I think that this challenge should not come from how long it takes to issue commands to the computer. Yes, it can be part of the challenge to forget to check certain aspects of the game, which can make you a weaker player. What I have already said is that this is different from being unable to type in commands fast enough to do what you want. I can see, however, the scenario of using a mod that auto-manages the barracks (and by the way, I thought you were exaggerating when you first said this, but after you described it in more detail, I actually do think this is the right word now), which enables the player to focus more attention on another area of the map, is not something I am ignoring. This can, in fact, change how someone plays the game. In some cases, it can make you seem like a better player. But I will say that this doesn't make you a better player if you over-rely on it. You still have to think about the barracks, taking up valuable mental space (which is different from time spent clicking on stuff). If you don't, then you're completely relying on the tool to decide a crucial element of the game for you. Before I proceed, I will once again say that I do think that any decisions about what to train, and where, and what batch sizes, are all strategic decisions. This is because there is no "best" batch size for any given scenario, and different batch sizes will have different consequences. A larger batch size will take hold of your resources for a long time, which can cause you to stall in some cases, but in the long term this provides more efficient use of the barracks. A smaller batch size will provide faster short-term results, which can help your economy accelerate faster in the short term, but your population generally won't grow as fast in the long term. An automatic decision that always picks the "optimal" batch size based on resources isn't really taking everything into account. So, as I said, you can choose to use ProGUI, while still thinking about your training, even if you aren't actively clicking on it to make anything change. This would defeat the supposed advantage of having more concentration for something else, because even if you don't have to actively click on it, just thinking about it is different. To be good at the game, you still have to have the mental capacity to keep track of everything, even if you have a mod running that will make some of those choices for you. If you don't actively think about everything, then you risk making a suboptimal choice, or failing to realize where your base is most vulnerable. Just to be clear, this is all meant to be a single example to illustrate my point. If ProGUI had more or less capabilities than I am describing here, that wouldn't matter; I would just write a different example of the impacts of that different functionality. I shouldn't have to explain why we should all be able to agree that revealing the map in a competitive scenario is cheating. But you are probably making the point that the impact of revealing the map is about the same as using ProGUI, therefore ProGUI is no less of a cheat. I must say that this is a case that is yet to be determined. Now that I think about it, I really should try ProGUI, and measure my performance against a bot with and without ProGUI, just to see what kind of a difference it makes. I think there's enough reason to assume that a pro player will be affected less by such tools than a total noob (like probably me), so the effect on me will be greatly exaggerated, and might say something. But I must remain clear that my case has nothing to do with any specific mod or any specific example. I believe that there can be no such thing as a cheat mod, because 0 A.D. is a strategy game, and the only way to imitate the strategic thinking in an algorithm is by creating artificial intelligence, which is a totally different discussion. This isn't a mutually exclusive statement. Strategic decisions can have consequences which can lead to further strategy. So you can make a strategic decision (training a batch of 3 before a batch of 10), which can lead to another strategic decision (this means you get some wood faster so you can build more fishing boats earlier on). They are both strategic decisions. Yes, I do believe that the decision on what batch size to train is just as strategic as every other micro-decision you make in a normal match. A mod could be written with some simple logic to make a decision for you, but this game should be deep enough (and I believe that it is deep enough) that such simple logic won't be enough to truly replace human thinking and ingenuity. Thus, in order to make the most of these mods, you must still think about the decisions your mod is making for you, and their potential consequences. You save a few clicks, but as I described above, clicks don't matter; concentration does. And you must still use concentration to think about what your mod is doing, if you want to make the best possible use of it.

I'm not trying to make this personal, but I must say that I don't think I was making any assumptions or spreading misinformation. First of all, I have been extremely transparent from the beginning that I am not an expert on ProGUI, and that everything I have said is simply repeating what other people have said, and I have also stated multiple times that I am not arguing based on any particular fact about ProGUI, and I am only making the case that all mods should be allowed as long as they don't break the fog of war, which is a case that does not depend on any particular example. The only reason why I mention ProGUI so often is because it's a neat example that helps me to illustate my point, but my case actually has nothing to do with ProGUI specifically. I think it it safe to assume that a reasonable person would not take home any flawed information about ProGUI because of what I said, or use such information to help them decide whether they want to try ProGUI. I do think that some of my writing has been sloppy, as I am tired and busy these days, and frankly wouldn't even be here if I didn't feel the need to make my voice heard right now. I think that this has led to some confusion, and that's my bad. If you think I misinterpreted something or made a mistake, please let me know, and I'll correct it. Then we can resolve any misunderstandings and move on. I do think that this thread can be productive, and I do think it has been very productive so far. Don't give up just because someone got offended once. Personally, I use the Cambridge English Dictionary when need to quickly look up a word, and this is what that website has to say for the word "cheating": And here's the same for "real-time": But at the end of the day, words can change and have multiple meanings, and the meaning can be dependent on context as well. That's how language works. We need to establish a clear definition of what is cheating and what is not, and I personally don't think looking it up in a dictionary will be helpful, because these resources are oriented around very general definitions that can help someone who has never used the word "cheating" in natural language before and only recently heard about it. The argument of what should be allowed in a ranked 0 A.D. match has nothing to do with that. My point is that this can be improved by making the gameplay better. I'm not going to try to come up with an example on any situation in which I wish I could type faster in order to win, but I'll give a few examples for things that I think could be changed to make the game easier. And obviously, I wouldn't know whether or not these features are already implemented in ProGUI, just to be clear. Add a default control group number for a particular barracks, so that any units that come out of the barracks will automatically be assigned to that control group and can be selected by pressing that number on your keyboard Make it possible to set a rally point on a soldier or hero or other unit, so that units that come out will automatically come to guard/escort that unit, even if the unit has moved since the rally point was first set. I know that it's already possible to set a rally point on a boat, and units will automatically garrison in that boat even if the boat has moved, so I am saying we should extend this functionality to all units. Make it possible to set a rally point on a formation, and units that come out will automatically get in formation. This would allow frontline tactics to be so much easier to manage in some cases. Generally make it possible to assign any command (garrison, repair, capture, attack, gather, move, guard, etc.) to any unit or structure for a rally point, assuming the command makes sense. I know that it's already possible to choose between setting a rally point to garrison inside that structure, or repair that same structure depending on whether you use G or J (default keys) to assign it. Sometimes, I feel limited by having to rally my units manually in certain cases, which would require a lot of APM whereas this change would eliminate the need for all of that. This is just a handful of examples that I have come up with while playing at my current level. You may have more examples, and my point is that if there are any APM restrictions at 1x speed, then this is a problem with the gameplay that needs to be fixed. The better we make the gameplay, the less impactful these mods become, because the game is designed to have a greater emphasis on strategy as opposed to APM. The person who wins should be the person who can keep track of everything to implement an effective strategy, not the person who isn't limited by their click speed. If it is true that a GUI mod can provide a significant advantage by reducing the need for clicks, then I would consider this a flaw in the gameplay that needs to be addressed. And yes, I do think that 0 A.D. has done a decent job so far at keeping alignment with its stated goals. There's some way to go, and I believe that arguments like this should be about how we can change the gameplay to make mods less of a problem, not how we can ban the mods so that everyone must suffer the need for fast clicking. It might require more work, but it will make the game so much better in the long term.

I would be against implementing a summary statistic that shows the input rate of all players over time. I personally hold the opinion that this input rate is not a crucial part of a player's performance. Concentration and multitasking are important in any RTS, but this is different from how fast you can input commands, and is not something one can easily measure with a number. The reason I think this is because of the 0 A.D. Vision page that discusses potential "snares" that can make the game worse, and one of them is "Fastest click wins". It says the winner should be determined by strategy and intelligence, not APM. I think adding this statistic would make it seem like an official idea that clicking faster makes you a better player, which is contrary to the stated design goals of the project. In reality it's being able to keep track of everything, which is completely different and can't be easily measured in the same way. I think this would give new players a wrong idea of what it really takes to be good at the game. Please don't add this feature. It would be okay as a mod, but I wouldn't use it.

I think that it would be helpful to allow mod policies to be determed by each host for themselves, rather than forcing a single policy on everyone, since we all know that isn't going to make everyone happy. Here's how I think this should work: Using ProGUI or other tools should not be against the TOS, and should not result in a ban from the entire Wildfire Games Lobby, even if a player lied about using it but... Hosts should be empowered to implement and enforce their own policies for mod usage. For example, if @real_tabasco_sauce hosts a game and finds out that someone was trying to hide the usage of ProGUI, @real_tabasco_sauce can block that player from future games, but the offending player will still be able to play with other people, such as myself. I think that the Internet, in general, is best when people are allowed to form their separate communities with their own rules, rather than everyone being forced to agree on one policy. I think community fragmentation is a good thing, as players should be free to pursue fair and enjoyable gameplay, whatever that means for them. The Terms of Use should be primarily about regulating offensive behavior that is unambiguously harmful, such as posting links to pornography, or harassing individuals, or trying to hack the lobby or other players. Anything further than that should be the responsibility and authority of individual hosts to determine what is allowed in their games. I think we should stay true to the values of free software, and not include any kind of obfuscation to prevent people from modifying the game if they really want to. What I have seen above is that there are ways for people to confidently detect the usage of ProGUI or similar tools. That's great, and we should leave those players to use whatever means to see fit to enforce their rules, while people like Atrik and myself can choose not to enforce any mod policy, and focus on having a fun game regardless. I hope that this will allow us to stop fighting over this issue and move forward with the real problems, such as revealing the map.

@guerringuerrin was describing a system that automatically chooses what barracks to train from, and the batch sizes, and I think someone else mentioned that ProGUI will automatically send units to gather resources at certain proportions depending on the needed resources for the units you want to train, but please correct me if I'm wrong. I do think that these amount to strategic decisions. Batch sizes are a strategic choice because bigger isn't always better. If you are interested in growing your economy, then smaller batch sizes will give you more short-term gains, but larger batch sizes will result in more overall efficiency of your structures. Always choosing the largest batch size that you can isn't always the best strategic choice. This is what I mean when I say that these tools make strategic choices on your behalf. Please don't allow the temporary miscommunications to discourage you. Know that my main purpose for starting this thread is simply to make my voice known, and provide a space for meaningful argumentation. So far, I think I have been mostly successful, and I am very glad I was available to start this thread, and participate in the debate. If anyone thinks I mis-interpreted something, then please correct me. I am not perfect, and just because I didn't understand you the first time doesn't mean I am intentionally spreading misinformation.

Wow, I'm sorry. I created my own thread about a similar topic before I realized that this thread existed. But to be fair, both threads have been meaningful, and their purposes aren't exactly the same... I must say that anyone who is actually suggesting that an anticheat program be included with 0 A.D. is arguing that 0 A.D. should cease to be a free software project. You can say what you want about what kinds of mod checks should be implemented, but that's the facts. You can't stop people from writing code on their own computers, due to the nature of free software. Anticheat solutions inherently require obscurity to work, so there cannot be a free-as-in-freedom anticheat. And I find the idea of using Machine Learning to help cringeworthy, but I digress... After reading this thread in full, I am starting to think that we could use a compromise. I strongly believe that the use of ProGUI, AutoCiv, and similar mods is NOT cheating, and I have my own reasons that I won't dive into here (it's mostly free-software absolutism), but I understand that some people disagree with me, so I would be open to allowing game hosts to decide for themselves what mods to allow, and perhaps a way to see what mods are active on each client, just for the sake of convenience. Nothing super invasive, since it's truly impossible to stop the secret use of mods, but it would mainly serve as a convenience option to make sure people are on the same page, and so those who don't understand the dilemma will have their clients figure it out from them, assuming they haven't modified it for themselves. I, for one, would never discriminate based on mod usage in my games, but I am finally coming to terms with the realization that I can't convince those who take the opposite extreme. However, I do think that there is a separate problem that the full game state is necessarily stored on every client, which makes fog-of-war cheating much easier than it should be. I do believe that it is possible to fully eliminate the risk of this kind of cheating, by redesigning the network protocol so that the game state is stored away from untrusted players, and only partially synced with the clients (again, won't go into too much detail since I have my own thread for this). I think this should be discussed separately from the argument as to the long argument of whether changing the input/output system of the game constitutes changing the game itself (I believe it doesn't). That may allow us to actually accomplish something here.