pchote

This looks to be a combination of a validation bug (I have filed #5595) and driver issue on your end (or a second bug on our end - what does your card report for its OpenGL version string?). http://www.sleipnirstuff.com/forum/viewforum.php?f=80

Harvesting speed, build speeds (both as cost multipliers or override values), etc, are all defined in the actor rules. They can be changed as easily as anything else. Projectile inaccuracy is implemented in OpenRA by adding a random offset to the target position. The maximum-offset at maximum-range is set in the weapon definition, and the game will choose a value within this limit by sampling a triangular probability density function (so the inaccuracy is more likely to be small than large). I suspect that the original game probably uses an unbiased sample (flat PDF) instead, which would give a different feel. I wouldn't be opposed to adding a "classic inaccuracy" option, but I would need to know the details of the original calculation, and know that it would actually be used by someone (either our own mods -- we aren't opposed to making things more like the original if it makes sense), or by other mods. The RA rules.ini keys map directly into properties of our traits. If there were a demand for it, then it would be a relatively simple task for somebody to create a converter that parses rules.ini (modded or vanilla), and exports an OpenRA mod. I'm far from convinced that this demand exists.

OpenRA was originally developed along these lines, and this is where the name originated. We chose to abandon original-rule compatibility in ~2010 and migrate to our current actor/trait system because we (the developers at the time) were more interested in exploring ideas relating to RTS game design than at creating a bit-compatible recreation of somebody else's game. The key-value system of rule definitions used by the original games was too restrictive for what we wanted (and in any case, it would have been infeasible to remain rule-compatible with multiple games at the same time), and so we adopted a modular system strongly inspired by the 3D-era C&C games. This split has increased further over time as we have generalized parts of the engine to support multiple file formats (we can use sprites from Dune 2 through to RA2), multiple tiles sizes (24x24 px for TD/RA, 32x32 px D2K, 48x24 px for TS), multiple perspectives (rectangular vs isometric for TS), voxels, dynamic palette changes (for the arbitrary player colors), etc, etc... Time has shown this to be the right choice, because OpenRA is still alive (with a larger player and developer base than we have ever had), while all the "pure" RA/C&C clones have died out from lack of developer interest.

This is certainly true. Both sides are misinterpreting the statements of one or a small number people as the opinion of the community as a whole, and this is counterproductive for everyone. I expect that much of this misunderstanding comes from cultural differences: in a closed source project (like the original games or cncnet) the feature list is controlled by a small group of people, and if those people don't want to spend time adding a feature then it won't be included. In a project like OpenRA, just because we (the main developers, who each have their own plans and goals and may not be speaking for the project as a whole) don't want to spend time on something doesn't mean that it will never happen. It is important to distinguish between "We don't like this, and don't want it in our project" versus "we don't plan on adding this, but will accept a patch that adds it". The latter is a statement of fact rather than a rejection. Saying "do it yourself" is very much not the same as no to us. Would you prefer that we said "Yeah, sure... we'll add that eventually" while knowing that we had no plans to actually do it? The left-click mouse orders is a good example of this: while I expect that the original responses to this request may have been harsher than necessary, it reflects the fact that we consider the left-click scheme to be outdated and less useable than the now-standard RTS right-click scheme. We were stating a harsh truth that we had no plans on adding a feature that we would never ourselves use, but I don't think anyone ever said that we would reject left-click orders completely. Somebody eventually took up our offer of adding this feature themselves, and it was merged into the main project (#2579). There were unfortunately a few usability issues (#3153) which really should have been caught during the code review (we are stricter with code reviews now, and work with the author to help resolve these kind of problems before their patch is merged). These haven't been fixed by the main team because we ourselves don't use this scheme, and again nobody wants to spend time fixing something that doesn't affect them personally (remember, we are all volunteering our time and effort). We started using bountysource a while back, which gives non-developers a way to help incentivise features that they would really like to see included. I hesitated before mentioning this, because I don't want this to be interpreted as "we will only add X if you pay us". The bounties were introduced as a way for people to constructively donate towards the people actively working on the project, while sidestepping some of the issues about receiving money from another company's intellectual property. It also means that a developer or outside contributor might decide to implement feature X with a bounty instead of feature Y that they would have otherwise worked on.

Wow. This response sums up, better than anything I could write myself, why we consider this community to be so unreasonable / crazy. Wow (i'm honestly shocked). I'm happy to engage in a logical discussion about OpenRA, if anyone has any specific points they would like to me to comment on.

All this talk of high ground and high horses really misses the point, and IMO just makes people come across as assholes (including me, with this statement). The primary objective for OpenRA is to build a cross-platform, open source, and extremely moddable RTS game engine. The primary objective of cncnet is to preserve and promote the original games. I find the suggestion that we "drop what we are doing" to join cncnet to be pretty insulting, because it completely ignores this distinction and casually dismisses the hard work that around 100 people have put in to OpenRA over the last 6 years. The (close) secondary objective of OpenRA is to build a set of games that live inside the C&C universes on top of our game engine. The guiding philosophy is "what would Westwood have done, if they knew everything that we know now". This is convolved with the opinions of our active player and developer base, however. The gameplay of our C&C and RA mods have evolved over time (and will continue to evolve) based on feedback and discussion. Our community is mainly filled with players who have played more than just the early C&C's, and so this evolution has invariably been towards adding improvements to the UI and gameplay inspired by these other games. The majority of these gameplay changes are intentional. If people honestly wanted an OpenRA mod that was a faithful recreation of the original games, then that is completely doable. There remain a few quirks that would need to be implemented in the engine or mod code, but the majority of it can be done in the yaml mod rules. Our experience when Matt tried to start up "classic" RA and C&C mods was that the bitching and hate from this part of the community only intensified. What we took from that was that these requests are not genuine, but only a convenient vehicle to carry "it's not the original, so it will never be good enough" sentiment. If we were to restart these projects then they would detract from our main efforts, and we expect that the hardcore original players would just find another reason to dislike it. We are unlikely to restart these projects in the foreseeable future, but we would welcome any modders who would like to work on this.