Joined: 26 Apr 2003 Location: Somewhere in Germany
Posted: Sat Sep 02, 2017 10:28 pm Post subject:
Playtest 20170902
A bit over a month after the previous playtest, we’re pleased to announce the new release candidate, playtest-20170902.
In addition to all the new features and improvements the previous playtest brought along, in this new playtest we fixed over 40 issues that were identified through feedback from players and modders. Among the more noticable ones were the movement ‘stuttering’ that ground units were showing, air units sporadically returning to base as well as some issues with the new command bar and some other UI hiccups.
Furthermore, the Red Alert mod in particular received a larger balance overhaul, along with a new map (Agenda). ‘Agenda’ and the updated ‘Great Sahara 2’ now serve as examples of more prominent use of civilian ‘tech’ structures that provide various benefits when captured.
The new capturable civilian tech structures, displayed on the new map Agenda. Forward Command provides build space, Communications Center reveals terrain.
Tiberian Dawn’s balance received some further polishing as well, making bridges more robust (in particular to light weapons and flames) as well as making Orcas and rocket infantry less effective versus infantry in general.
A new version of the Mod SDK is also now available with a few improvements and bug fixes. The big new feature is the ability to automatically create installers for your mod “in the cloud”. We encourage everyone who is working on mods for the last release to try out the Mod SDK and report back any issues you find or suggestions that you may have, so that we can iron out any remaining issues before the legacy oramod infrastructure is removed.
Just like with the last playtest, we ask you to give this a try and report any bugs or balance issues you might come across, as this will likely be the last playtest before the next release. The changelog for this playtest (as well as the previous one) can be found here: changelog QUICK_EDIT
the installer gave me several exceptions. unfortunately is it impossible to copy the log text from the installer (only a single line can be selected and ctrl+c doesn't copy it).
last line before the exceptions start
Create Folder:C:\Documents Settings\AllUsers\Application Data\OpenRA\ModMetaData
then the exception
after that several more of these exceptions.
In addition was there no question asked where i want to install OpenRA. I don't want any gaming stuff in C:\Program Files.
\Edit
none of the exes work. I guess .NET 4.0 and winXP is too old.
Well, screw you for not supporting the greatest WinXP and accepting MicroBrains' Win10. _________________ One and only developer of the Command & Conquer Dune "C&C D" mod.
m7 wrote:
I tend to release things I create so that assets are never lost to hard drive problems, accidental deletion, or me having to pretend to care about rippers taking things from my project when it is done.
Also Known As: evanb90 Joined: 20 Feb 2005 Location: o kawaii koto
Posted: Tue Sep 05, 2017 5:09 am Post subject:
because bending over backwards to support a 16 year old OS is a smart decision...
besides Win7 is the master race
Back on topic though (and a dumb question)
ORA will continue to support mods being distributed as folders in the mods/ directory, and launched via Game.Mod=[mod folder], right?
Have no desire whatsoever in using GitHub or the like for a mod. _________________ 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
Also Known As: banshee_revora (Steam) Joined: 15 Aug 2002 Location: Brazil
Posted: Tue Sep 05, 2017 5:54 am Post subject:
Support an old OS is not necessarily smart or dumb. If you can allow more people to use your software, that's a good reason to support older O.S.s. However, if supporting older OS prevents you from having a proper multiplayer, support for certain Linux distros and few other disadvantages, you may have to think carefully about it.
Anwyay, the drop of Windows XP support happened because of this and that's a set of valid reasons.... at least some of them, to be honest. QUICK_EDIT
Back on topic though (and a dumb question)
ORA will continue to support mods being distributed as folders in the mods/ directory, and launched via Game.Mod=[mod folder], right?
Have no desire whatsoever in using GitHub or the like for a mod.
No, this will no longer be supported.
Supporting that kind of modding causes a lot of problems, both in terms of wasted time (on your and our part) and in terms of fundamental technical / feature limitations that would never realistically be fixed. The only way to give modders the treatment and flexibility they deserve was to switch completely to the SDK approach.
A few specific points about the old approach (mods distributed as folders):
All mods break whenever we release a new OpenRA version. There is no technical solution to this (aside from forever stopping development of the engine), and quite a few nice mods have been abandoned and left unusable because of this.
Asking users to manually copy files to run a mod sucks. It really sucks on macOS and Linux where the mod installation directories are hidden by the operating system, and where modifying installed program files is severely frowned on.
We have to support people coming to our IRC channel asking for help when they can't get someone elses mod to work. This is usually because the mod doesn't support the current stable release, and so we have to tell them that it isn't possible. This is a big waste of our time, and gives the player a bad impression of OpenRA in general.
Asking users to manually copy and run arbitrary executable code in the context of a trusted application is an absolute security nightmare. If somebody installs a harmless looking oramod file that encrypts or deletes all their personal files then they would quite reasonably be mad at us for their data loss. This again hurts the reputation of OpenRA in general.
We can't add auto-updating to the default OpenRA mods without first implementing a system to handle custom mods. Some effort went into planning this, but it was going to be an absolutely massive amount of work that was never realistically going to happen.
Mods are limited in what they can do: it is not possible to change core engine behaviour, and is a huge and ugly task (although technically possible) to change the common trait logic.
The Mod SDK fixes these problems by upgrading custom mods to the same level as our default mods. You manage your own copy of the engine and build installers that players install in exactly the same way as our default mods.
You don't need to worry about us breaking your mod because now you choose when to update your engine / common mod files. We don't need to worry about designing and implementing complicated features to support mods as second-class special cases. Users don't need to worry about complicated installation procedures, and are encouraged by the installation dialogs to consider the security implications of installing random software from the internet.
You don't have to use GitHub or Travis CI for developing a SDK based mod. We put a lot of effort into guaranteeing that. The only tricky part is building your installers, because that relies on software that isn't available on Windows. GitHub and Travis CI provide a stable platform that let us do the fiddly bits of configuring Linux and running the scripts so that you don't have to. If you are comfortable with that kind of thing then you can do it all yourself locally and ignore them completely. QUICK_EDIT
Also Known As: evanb90 Joined: 20 Feb 2005 Location: o kawaii koto
Posted: Tue Sep 05, 2017 2:11 pm Post subject:
First, are we discussing the same thing? I've never used the "oramod" format. I'm more basic than that.
I mean just taking a mod's folder, putting that in a ZIP/RAR and giving that to my buddies to extract into the mods/ folder.
And taking the follow up answer to be "this won't work either":
this new method seems like it would create a lot of hassle for small-scale mods like my own, that just make alterations to the gameplay of one of the base mods. _________________ 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
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Tue Sep 05, 2017 3:33 pm Post subject:
The idea of adding mods via simply copying their folders into a base game's mods folder will still work but in order to launch such, you will need a custom shortcut (either in the form of a precompiled OpenRA.exe like the playtest's three launchers, either a customized OpenRA.Game.exe Game.Mod=modid one) and you will need to launch it once in order for the MP server switching to work.
Sure, this will work, but it's not the method which is officially propagated, as pchote's post implied. The new idea is that mods should provide their own engine versions, which this SDK is about to help on (via generating installers mostly). Basically modders are encouraged to create standalone mods which they can update in their own pace to prevent losses like Holloweye's WW1 mod which is basically unplayable now because of being on an outdated release.
Another sideeffect of this is that 3rd party soft-forks are as useable for such base versions, allowing people like forcecore/BoolBada to do their own things without conflicts with the base mods or complicated installation methods. (Read OPMod's install instructions for it's current release to understand what I mean.) _________________ "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
First, are we discussing the same thing? I've never used the "oramod" format. I'm more basic than that.
I mean just taking a mod's folder, putting that in a ZIP/RAR and giving that to my buddies to extract into the mods/ folder.
An oramod is just a renamed zip of the mod folder. The game can load them directly, saving you a step when sharing your mod.
EVA-251 wrote:
this new method seems like it would create a lot of hassle for small-scale mods like my own, that just make alterations to the gameplay of one of the base mods.
It shouldn't be that much more hassle: you just need to copy the base mod into a copy of the SDK before you start, and then zip the whole SDK folder when you want to share it. You then run the mod using `launch-game.cmd`/`launch-game.sh` instead of using a custom shortcut to `OpenRA.Game.exe`. The SDK's Getting Started gives a step by step tutorial on exactly how to do this. QUICK_EDIT
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
Playtest 20170902
