Forums

Especially considering what AFistfulofDollars (Geriatrix) just said about me in the gamesetup page of Barcodes TG. You saw that. He also claimed that this @WiseKind is my smurf (clearly wrong). @WiseKind maybe you and @Dunedan should address this.  Atrik I consider you to be one of the most intelligent players in the lobby, please stay calm and carry on with your valuable work. Let's not be distracted by haters nor fall prey to Geriatrix trolling. 

The majority of comments here are coming from SP players afaik giving opinion on what MP should be. It is... puzzling. They also post elsewhere that MP community have too much influence on game development (??!!). So this is definitely a troll topic that cannot be taken even the slightest seriously. As for fun, MP players also play for fun. There will never be 'pros' players on a free game, they are just designated this way when they are regular players.

Unless you can provide some evidence supporting this claim, I don't think this will convince many (I for one highly doubt this statement). In my experience, this is not true. In fact, they seem to be interlinked to an astonishing degree. Whenever I play a 4v4 teamgame and it starts to lag, I stop being able to concentrate on many things at once; I literally start waiting for my units to execute the orders I gave them and my APM drops significantly. While playing 1v1 I have no problem micro-managing 3 different armies and my economy simultaneously, because it doesn't lag. Atleast in my case, being able to click fast is a necessity for me to be able to think fast. Accessibility tools in this context are inherently just accepted advantages to mitigate disadvantages a person has that hes not responsible for. So it is a performance tool, otherwise it can't be an accessibility tool (what good would a tool for a disabled person be if it didnt help him?).

Are we playing "the philosopher's game" here? I was explicitly talking about the in-game tools. And those should be the same for all players. For multiplayer, at least. I don't care what you do in SP, that's your fun time.

@Seleucids, "llvm" is a binary package in Debian. What you need to check for is llvm-dev https://packages.debian.org/search?keywords=llvm-dev "-dev" packages are for building stuff from source.

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.

A good example of how to defend against double rush in a TG: I foiled all of the rusher's sneaky attacks until he rage quitted ! @AInur  thanks for the op save and carry! General tips to defend against cav rush: Position woodlines at the front of your base - you can see incoming cav and start damaging them.  Start mining early, with just a few infantry on stone and metal. They will protect your farms Always have houses near your women. Make sure there is enough garrison space for all nearby women.  Always mix melee inf and ranged inf. Take hunt between you and your enemy - food income while spying. Invest in outposts if the enemy is very aggressive.