pchote

I suggest some caution dealing with this person. He has been permanently banned from OpenRA's services and community discord for ongoing abusive behaviour, and continues to cause trouble by evading bans to post content on our map repository and post drive-by threats to our IRC channel (even as recently as this morning). We had to escalate matters to the Freenode and Discord staff after he started harrassing people via private message, which I assume is why they shut down his Discord channel. We're not the first community to have trouble with him; a community member found a similar situation with VRChat via his steam profile, and a suspended reddit account. I'm not sure whether posting those links is allowed – the forum rules here don't explicitly cover linking to outside accounts that may be considered personal information. A moderator should remove the links (and clarify the rules) if they are not.

The video author confirmed what I surmised above: From: https://www.youtube.com/watch?v=IGtrJaiUZaA&lc=z12ailag3zicelhvz22fjh3p0lehyv3tm.1478852598280291

OpenRA is extremely modular so it would be straightforward for someone who knows what they are doing (as he clearly does) to import the code (UE4 can support C#) or link against it as a library and use the gameplay code without the renderer. If he has written a new top-level game loop, renderer, and UI using unreal code then "RA2 on Unreal Engine" is valid – OpenRA is just another third party library. It is disappointing that he credited OpenRA and the RA2 mod in an ambiguous way, but such is life. Some OpenRA-specific unit behaviours are quite obvious in the video: the two engineers capturing the tech airfield, and the way units line up outside the war factory before being nudged to make room. I also spotted familiar bugs with units sliding around corners (finally fixed in the latest OpenRA release), and infantry glitching a frame of their stand animation in the middle of an L turn. The hand paddle is also quite clearly based on the ra2 mod's sidebar layout and artwork.

This is a great example of OpenRA's modding capabilities It appears that they have imported our gameplay code and RA2 mod rules into UE4 and then written an impressive set of 3d rendering traits plus the VR-friendly UI on top. If you look closely you can spot several OpenRAisms / bugs that have carried through to this demo.

If you replace all the `./mods/ra-classic/` path prefixes with `ra-classic|` in your mod.yaml and add `$ra-classic: ra-classic` to the Packages section (note: this is all described in the Mod manifest documentation) you can package an oramod that can be installed and run from the support directory instead of modifying the main game install. This is our new and best supported way of shipping OpenRA mods. Here's a fixed version for you: https://www.dropbox.com/s/lur20sxwikzy034/ra-classic.oramod?dl=0 Just copy it to My Documents\OpenRA\Mods\ra-classic.oramod under windows and pick it from the mod chooser.

No, "noob friendly" is quite far down the list. A few of the more interesting advantages are: Reflection: Code is just another type of data, and this is the heart of the OpenRA engine. Mods can write their own actor traits, file format parsers, UI Widgets, Lua API actions, and a few other object types in C#. The engine inspects itself and the mod dlls at runtime and makes these objects available for use by the mod yaml. It then parses the yaml and constructs the objects that represent actors, the game UI, the Lua<->C# bridge, and other things... all without the piles of boilerplate that would be needed in other languages to register factory objects, define external type metadata, or parse data files. This also makes it very easy to write static analysers and lint checkers that verify correctness in the core code and mod rules. Dynamic code generation: The engine automatically generates some performance-sensitive code for error and cheat-detection at runtime. This again saves a bunch of unnecessary boilerplate and gives significant performance improvements over manually enumerating the relevant data. Cross-platform binary compatibility: We compile the code once on Ubuntu, and then ship the same binaries (wrapped with platform-specific installation fluff) on Windows, OSX, and Linux. We don't need to jump between a bunch of different OSes to build our installers or mess with cross-compilers. If you were writing an OpenRA mod with custom code, would you really want to have to compile it for 10 different operating systems? Or just the one that you use for development? Unsafe code operations (but only when we need them): The majority of mod-level code gets to take advantage of the flexibility and friendlyness of the high-level "safe" parts of C#. When we need extra performance or to interop with native code it is simple to drop into an unsafe{} context and hack around with the raw memory and pointers as much as we please.

I guess we should take it as a compliment if the worst thing you comment on is the use of C# over C++. That has an insignificant impact on OpenRA as a game, and some significant advantages as a modding and development platform.

Work never completely stopped. Progress is slow because it is a massive job with very few people working towards it. If you want to see it happen faster, then come and help! Despite that, a quick skim of our changelog and pull queue shows a bunch of changes related to the 'gen2' mods since the last release: #11058, #11091, #11120, #11124, #11211, #11216, #11291, #11299, #11356, #11375, #11380, #11426, #11445, #11483, #11498, #11522, #11558, #11565, #11441, #11484, #11501, #11536, #11572.

Op is not an OpenRA developer, just a (very valued) community member. He had absolutely no idea what he was getting himself in to when he posted this topic. Your response nicely summarizes why your previous suggestion was so ridiculous. The only way "we" (the openra developers AND the cnc-comm forum admins) could stop people from posting OpenRA related topics would be to publicly announce that this community does not accept discussion on OpenRA. The dotted points and comment about community relations should have been self-evidently sarcastic, because nobody sensible would seriously consider them.

Lets assume for a moment that you had a valid point. How would you expect this to be enforced? OpenRA developers post website and social media annoucements warning all our community members to avoid CnCNet, or risk being abused? The forum admins here add a word filter to block any posts related to OpenRA? They would do wonders for community relations, I'm sure. The wider C&C community is too small to be able to deal with that kind of bullshit. There is no reason why people can't follow, play, and enjoy both sets of CnCNet and OpenRA games.

Sorry, that was there for context only, and I didn't mean to imply anything about you (you are one of the most reasonable people in this community). I thought it was appropriate to quote because it feels like the "don't advertise OpenRA here" arguments always end being driven by resentment over those specific old posts.

Did, please. There was one person on our dev team who thought it was appropriate to aggressively evangelize here without discussing it with others first. He got a bollocking about it from both communities and stopped. It is rather unfair to hold a grudge against the project for something that one person did years ago, and says more about your community than ours.

The "official dev team clarification" is available at http://www.openra.net/about/. It's not our job to stalk everybody on the internet who has an opinion on OpenRA and post corrections if they write something wrong. I do sometimes, but only as a hobby (you wrote something wrong, by the way ). OpenRA's RA and TD mods are modernized remakes, whether you like it or not. Feel free to argue about the semantics of the word "remake", but i'll point out that the definition I use (which allows for changes to make it suit a modern audience) is wide-spread enough to have its own wikipedia article https://en.wikipedia.org/wiki/Video_game_remake

Not really. Removing the mod name would imply that this was a cross-mod league, which it isn't.

fir3w0rx: We've just overhauled our low-level OpenGL integration on our development branch, and it's possible that this has fixed your GL problems. Is there any chance that you could give this test build a go? https://ci.appveyor.com/api/buildjobs/y2vqr6aic0quiev6/artifacts/OpenRA-.exe