The latest installer for your operating system is available from the download page.
Ten reasons to try the new OpenRA Playtest
1. New chat lobby
The multiplayer server browser and game lobby have been redesigned around a new global
chat channel.
This will make it easier to find and talk with other players, and to organize matches without server-hopping.
The channel is available from outside the game as well, by connecting to
irc.openra.net:6667 channel #lobby using your favourite IRC client.
2. Game speed options
Do you think that the default game speed is too slow (or too fast)? This version now includes a game speed option in the lobby and campaign menus!
3. Overhauled Dune 2000 mod
Manual of Muad'Dib by the Princess Irulan wrote:
A beginning is the time for taking the most delicate care that the balances are correct. This every sister of the Bene Gesserit knows.
One of the big focuses has been completely overhauling the Dune 2000 mod to more closely match the
original game. All of the unit and building statistics have been adjusted, and
new (old) features were implemented including the thumper and spice blows.
There is a good progress towards matching the feel of the original game, but we aren't there yet.
Let us know what you think, or if you find something that still doesn't match!
4. Tiberian Dawn mod improvements
The Tiberian Dawn mod includes some incremental balance changes plus a bug fix for SAM Sites that would refuse to close. This version includes several new multiplayer maps, and two new campaign missions - including a stormy commando mission.
5. Red Alert mod improvements
The Red Alert mod finally received a much needed shock-trooper nerf, and a fix for destroyed aircraft taking far too long to crash to the ground. The Soviet Hijacker and France's fake structures have also been improved, and we include five(!) new campaign missions.
6. Joystick scrolling
Another commonly requested feature was the ability to scroll using the right mouse button like a joystick (like TS and RA2). You can now enable "Joystick" scrolling in the Input tab of the Settings dialog. The developpers are still hard at work on OpenRA's Tiberian Sun mod, but there is no release date for you yet!
7. Units "defend" by default
Players have often complained about their units chasing the enemy across the map, and OpenRA's "pro"
players know that it is best to change the stance of their units to the "defend" mode. The developers have
made this the new default for all units, streamlining the game play a little bit for everyone.
If you want to change your units back to the old "attack anything" mode, you can use the change stance hotkey (ctrl+z by default).
8. New asset installer
The he asset installation procedure has been consolidated into the mod chooser. Look out for even more
improvements in future releases!
9. Fixes and performance
A large number of bugs were fixed, including the well-known replay freeze bug when a player
disconnects, and a memory corruption bug that would cause random crashes when starting a match on a
Windows OS. There is a continuous crusade for performance, and this playtest shows significant
further improvements over the last release.
10. Improved map and mod support
There is a boatload of new features for modders and map authors: maps can now include custom music
and define particle effects for rain, snow, or sand storms. There are major changes to the
traits that control actor rendering and targeting that make them more flexible and self-consistent.
Make sure to use the automatic rule upgrader to easily port your maps and mods to the new release!
You will need to manually update your mod.yaml and UI definitions for the new version. Last edited by Matthias M. on Sat Nov 07, 2015 6:50 am; edited 2 times in total QUICK_EDIT
- Good job with the game speed setting. Fastest seems more or less equal to the most popular 60 FPS setting in Westwood classics, so I played with it, on a 6p map with 5 AIs. Didn't notice any performance issues (I have an AMD Phenom II X4 at 3.8 GHz). Makes the game far more enjoyable compared to the very slow default setting
- Right-click scrolling (or joystick scrolling, as you call it) is perfect.
- The AI has definitely improved a lot, especially the "Rush AI". While still easy, it at least takes some effort to beat. You might want to improve the other AI profiles though, because the Rush AI in my game killed 2 other AIs fairly quickly (as quickly as I killed two others), meaning that the Rush AI appears to be far stronger than the other AI types. A nice thing to see was the AI building expansion bases to boost their economy.
- Targeting infantry is still a pain compared to WW C&Cs, especially on high resolutions.
- Speaking about high resolutions, is a resolution setting planned? My desktop res is 1920x1080, but I'm used to playing classic C&C at 1600x900, meaning that pixel doubling would zoom the game too much.
I feel that the Skirmish game lobby UI is a bit inefficient at high resolutions, but that could be a design choice.
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Tue Nov 03, 2015 10:39 am Post subject:
^Rampastein wrote:
- The AI has definitely improved a lot, especially the "Rush AI". While still easy, it at least takes some effort to beat. You might want to improve the other AI profiles though, because the Rush AI in my game killed 2 other AIs fairly quickly (as quickly as I killed two others), meaning that the Rush AI appears to be far stronger than the other AI types. A nice thing to see was the AI building expansion bases to boost their economy.
- Speaking about high resolutions, is a resolution setting planned? My desktop res is 1920x1080, but I'm used to playing classic C&C at 1600x900, meaning that pixel doubling would zoom the game too much.
The AI personalities themselves weren't changed, the changes in the AI were split apart all of them.
Nonnative desktop resolutions ends up bugged in Mac which is why it's disabled in the GUI, although you can manually specify a resolution in the settings file (My Documents\OpenRA\settings.yaml). _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
- Speaking about high resolutions, is a resolution setting planned? My desktop res is 1920x1080, but I'm used to playing classic C&C at 1600x900, meaning that pixel doubling would zoom the game too much.
We have a plan for this, but I don't think it is high on any specific person's TODO list. It will happen eventually, but there is no time line for it. QUICK_EDIT
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Tue Nov 03, 2015 11:32 pm Post subject:
Similar? Yes. Fixed? Not really. _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
Also Known As: evanb90 Joined: 20 Feb 2005 Location: o kawaii koto
Posted: Thu Nov 05, 2015 3:15 am Post subject:
Had to manually update most of my mod (massive hassle for a simple gameplay mod of RA)... But after 2 hours of repeatedly crashing ORA to find what I needed to fix, I finally nailed it all. That's the bad.
The good... Love the new visualization of warheads in Debug mode, and the gameplay speed addition is wonderful. Just moving it up to Faster is a huge improvement. Movement looks more fluid and the game obviously moves at a better pace. Oh, and the change to unit stances. Great work guys! _________________ YR modder/artist, DOOM mapper, aka evanb90
Project Lead Developer, New-Star Strike (2014-)
Former Project Lead DeveloperStar Strike (2005-2012), Z-Mod (2006-2007), RA1.5 (2008-2013), The Cold War (2006-2007) QUICK_EDIT
Had to manually update most of my mod (massive hassle for a simple gameplay mod of RA)... But after 2 hours of repeatedly crashing ORA to find what I needed to fix, I finally nailed it all. That's the bad.
Do you know about the rule upgrader and validator tools?
Code:
OpenRA.Utility.exe <your mod id> --upgrade-mod 20150919
After you've updated your mod.yaml manually (unfortunately it can't do that for you) you can run this to apply a set of translations that cover 99% of the gruntwork changes (mainly dealing with renamed traits / properties, or things being split up). This is what we use to update our official mods. The date after the --upgrade-mod is the version that you are upgrading *from*.
Code:
OpenRA.Utility.exe <your mod id> --check-yaml
This will check your mod rules for a bunch of common mistakes, and should flag at least 90% of the rule issues that would crash the game. If you find some other errors that you think could be automatically checked for then please do file an issue and we may be able to add it to a future version. QUICK_EDIT
Also Known As: evanb90 Joined: 20 Feb 2005 Location: o kawaii koto
Posted: Thu Nov 05, 2015 4:13 pm Post subject:
Yes, actually. Though I didn't know the extent of what check-yaml could do for me.
Doing an upgrade from 20150919 resulted in Targetable stuff not being fixed (because the code reads if (engineVersion < 20150902) to change that stuff). Had to fool the upgrader by telling it the engine version was 20150901
I also had to do RenderBuilding related traits manually.
Regardless, it's no big mark against what you guys have done in this version, which is frankly amazing. _________________ YR modder/artist, DOOM mapper, aka evanb90
Project Lead Developer, New-Star Strike (2014-)
Former Project Lead DeveloperStar Strike (2005-2012), Z-Mod (2006-2007), RA1.5 (2008-2013), The Cold War (2006-2007) QUICK_EDIT
Had to manually update most of my mod (massive hassle for a simple gameplay mod of RA)... But after 2 hours of repeatedly crashing ORA to find what I needed to fix, I finally nailed it all. That's the bad.
Do you know about the rule upgrader and validator tools?
Code:
OpenRA.Utility.exe <your mod id> --upgrade-mod 20150919
After you've updated your mod.yaml manually (unfortunately it can't do that for you) you can run this to apply a set of translations that cover 99% of the gruntwork changes (mainly dealing with renamed traits / properties, or things being split up). This is what we use to update our official mods. The date after the --upgrade-mod is the version that you are upgrading *from*.
Code:
OpenRA.Utility.exe <your mod id> --check-yaml
This will check your mod rules for a bunch of common mistakes, and should flag at least 90% of the rule issues that would crash the game. If you find some other errors that you think could be automatically checked for then please do file an issue and we may be able to add it to a future version.
OpenRA.Utility.exe just throws errors when I try use upgrade mod function; gonna have to do it manually. QUICK_EDIT
Also Known As: banshee_revora (Steam) Joined: 15 Aug 2002 Location: Brazil
Posted: Fri Nov 06, 2015 8:14 pm Post subject:
Why is it necessary? I mean, the mod.yaml teorically informs the version. Wouldn't be easier if a final playtest build or a final release build detects if the mod version is old, shows a popup version asking if the modder wants to run the update utility? The average user won't see that in action, until it runs a mod that is no longer being updated. And if you don't want the hassle of this kind of approach to scare users, why can't you set an optional setting at mod.yaml that could allow the mod to be automatically updated when it is running in a newer version of the program? QUICK_EDIT
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Fri Nov 06, 2015 8:37 pm Post subject:
This is a bit more complicated than that.
1) The game right now does not have such a detection mechanism, although the groundwork of it has been laid out just recently as a thirdparty-mod supportive platform, to get thirdparty mods running against their dependant versions. Although I'm not convinced about the gains of such system at this point, it might does benefit in the long run.
2) The OpenRA development cycle is one source of the problem. After a series of playtests - in this case it was only this one since the summer release - the game enters into feature freeze and is being continues on a separate branch while the development continues on bleed. The playtest patches are then backported into this separate branch. Using simple dates between updates ain't helpful here because the bleed updates between the date of the feature freeze and the release will end up wrong.
3) Even if the mess of which upgrade rule should've been applied and which not problem gets dealt with, it's still not fix everything: these upgrade rules are written with the traits in mind. It's up to the modder to fix interactions, which must be remade if they end up broken by the automated process. And due to the modular approach, the number of interactions between traits can't even be guessed - especially since the introduction of the upgrade logic and getting a lot of traits upgradable via the same interface.
I could even say that the biggest issues at thirdparty modding support are coming from the fact that the game grows in an amazing rate. _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
Also Known As: banshee_revora (Steam) Joined: 15 Aug 2002 Location: Brazil
Posted: Fri Nov 06, 2015 9:55 pm Post subject:
You are correct. Maintaining mod support for a game that grows in an amazing rate is complicated. But you cannot expect that every modder will keep their mod updated at the same rate of the development of the engine.
Likewise the development of the engine, development of mods is a hobby that relies on free time and motivation, which are unstable variables for every human being. When you develop a moddable game and you want to stimulate modders to mod it, you have to take these things in mind when you design the game.
I wasn't expecting that the implementation of my suggestion to be as simple as I've suggested, even if the program 'trust' the Version: tag at the Metadata section of mod.yaml. I think you'd have to consider an exception for under-development versions, but it would be certainly better than nothing and I do think that, even at this rate, it would have gains. Third party mods for OpenRA are still under development and they may take a while to be ready for the big public, but you need to motivate their development, even at this stage.
Quote:
3) Even if the mess of which upgrade rule should've been applied and which not problem gets dealt with, it's still not fix everything: these upgrade rules are written with the traits in mind. It's up to the modder to fix interactions, which must be remade if they end up broken by the automated process. And due to the modular approach, the number of interactions between traits can't even be guessed - especially since the introduction of the upgrade logic and getting a lot of traits upgradable via the same interface.
I don't think the engine has the responsibility to keep every mod running identically in every interaction. Mods are supposed to run in newer interactions, but if the game ballance breaks for some reason, I think it should be up to the mod developer or the community to fix it. There is no reason to make things more complicated. QUICK_EDIT
The mod version is just a text field. You can add anything there like "1.0 beta 7 >>almost there<< release candidate". It doesn't need to follow the release-YYYYMMDD scheme. Adding a release date field to mod.yaml and checking against that might be a solution nobody has thought of yet. https://github.com/OpenRA/OpenRA/issues/9899 sounds similar.
You cannot post new topics in this forum You can reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum