Merci Seleucids À chaque fois vous me surprenez de voir à quelle point vous êtes une communauté forte Thank you. Yall impress me when I see the strengh of the community

Exactly @real_tabasco_sauce. OP, I think you are missing the point on several issues. First and foremost, a game should be easy to pick up and play. Automation tools introduce unnecessary complexity. Second, the game should be hard to master. Skilled and experienced players should be able to play better than new players. That rewards effort put into the game. Third, any game can be played casually. It's up to you how seriously you want to play. If you just want to relax, hop on a team game with all Easy AIs, for example. But, RTS game should be a game, not a job. If you want a job instead of a game, try playing Supreme Commander: Forged Alliance (in addition to StarCraft 1 that I've already recommended )

This is a false dichotomy. We can and should have both these aspects of gameplay. The skill curve comes from strategy and multitasking ability, it has never been and nor should it be exclusively be one or the other. Skill curves/learning curves are important for a game's long term enjoyability. The vision also states this: This should disqualify macros and large-scale automation scripts from being compatible with the vision since these are very unintuitive. One of these automation mods has an added GUI panel and additional settings slots for configurations. Compare this to simply clicking a building and then clicking a unit.

I think you'd love StarCraft. The original one, I mean. No, really. Try it. The best RTS ever, for a reason.

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.  

@Outis, Alpha 27 won't work with Windows 7 and earlier. If you have Windows 7, you're out of luck until you either upgrade or switch to a recent version of Linux.

replacing the diff file in libraries/source/spidermonkey/patches/ with the one in the link you provided allows the 32bit version of 0ad to build (and run) ok. thanks. (the existing diff file fails to patch properly, whereas the updated one from debian is ok).