:: Home :: Get Hosted :: PPM FAQ :: Forum FAQ :: Search :: Memberlist :: Usergroups :: Register :: Profile :: Log in to check your private messages :: Log in ::
Do you want to advertise at Project Perfect Mod. Find out how to do it HERE.

The time now is Thu Dec 14, 2017 6:24 am
All times are UTC + 0
 Forum index » Modding Central » OpenRA Editing Forums » OpenRA News
Release 20160508
Moderators: Global Moderators, OpenRA Moderators
Post new topic   Reply to topic Page 1 of 1 [14 Posts] View previous topic :: View next topic
Author Message
xanax
Vehicle Drone


Joined: 14 Nov 2013

PostPosted: Wed May 11, 2016 9:05 pm    Post subject:   Release 20160508
Subject description: New version of OpenRA
Reply with quote




We are proud to announce a new stable release of OpenRA!

Development for this release started about six months ago, and in this time 50 developers contributed a total of 1,232 commits that added more than 14,000 lines of code.

So what has changed?

A lot of work went into fixing minor bugs and omissions to make the game experience more pleasant:

   - Nod units in the Tiberian Dawn campaign finally use their original silver coloring.
   - Starting a game after installing a map no longer causes the player to be kicked from the server.
   - The lobby color validator will no longer complain as much as it used to.
   - Walls now reliably stop bullets.
   - Husks blocking refineries can now be targeted and destroyed.

We have also added the much-requested feature to restart missions and skirmish games, but this does not yet extend to multi-player games. Furthermore, the minimap radar will now also make use of team colors if those are enabled. Health bars can be set to only appear when the unit is damaged. Finally, the “Fragile Diplomacy” option has been removed.

UI-wise, issues with the left-click orders have been fixed. Additionally, it is now possible to zoom using Ctrl/Cmd+Scrollwheel (the spectator view and map editor offer two additional zoom levels). Two new modifier keys allow disabling line-building of walls (hold Shift during placement) and canceling an entire build queue (hold Ctrl when clicking).

But besides all of that, the biggest changes have been under the hood of OpenRA. We already addressed these topics in the playtest news posts [1] [2], and wiki pages covering them have been updated or written from scratch, but to summarize them again:

   1. The dedicated server is now a stand-alone executable, and dedicated servers no longer need to synchronize maps with the resource center. See the dedicated server wiki page for details.

   2. The map format has been updated, and the way that the game handles map upgrades has been changed. A wiki page has been created to describe the current map format.

   3. In order to allow for packaging mods into single “.oramod” files, it was necessary to introduce a number of changes to the mod.yaml metadata file. These changes, and the layout of the mod.yaml file in general, are now documented on the wiki as well.

If you are interested, the wiki also has the full changelog which lists all of the changes included in this release.

You can find the installer for your operating system on our download page.

We hope you will enjoy this latest installment of OpenRA!

Back to top
View user's profile Send private message
pchote
Cyborg Soldier


Joined: 06 Feb 2015

PostPosted: Wed May 11, 2016 9:46 pm    Post subject: Reply with quote

There are a few things from the Changelog that might interest modders:

  • The yaml merging bugs have finally been fixed, and the Inherits: tag can now be used in any yaml file.
  • Support for flipping artwork in sequences and enabling the horrible non-linear facing mapping used in the original TD/RA
  • Color definitions now use the standard HTML [AA]RRGGBB hex notation instead of H,S,L
  • Even more support for granting and consuming trait upgrades (search for "upgrade" in the traits list)
  • Fixed the AI doing dumb things with armed harvesters and flying MCVs
  • A new line-damage projectile for rail guns and the TS sonic tank weapon
  • Improved support for weird sound formats (VOC format and aud with non-standard sampling rates)
  • More TS-specific logic like gates, the sensor array line-circle thing, and units escaping transports when they die


The biggest technical change was pushing through a complete rewrite of our file loading code.  As well as significantly improving load times and memory usage, this let us add support for loading custom mods from '.oramod' (renamed zip) packages installed in the new custom mod directory.  This meshes well with the ability to declare dependencies on other mods, making it easy to create and ship mods that extend other mods without worrying about duplicating all the bits that you haven't changed.

There's still a few leftover bits of the filesystem cleanup that I hope to tackle for the next release, mainly related to the mod asset installation.  Once those are done we can finish moving the package and sound loaders to mod code, completing another major goal of ours (which is that the engine shouldn't care about the on-disk file formats, allowing mods to use any asset formats they want).

Back to top
View user's profile Send private message
Graion Dilach
Defense Minister


Joined: 22 Nov 2010
Location: Iszkaszentgyörgy, Hungary

PostPosted: Wed May 11, 2016 10:29 pm    Post subject: Reply with quote

It's kinda sad how ModDB bugged out with this newspost (it's associated with the OpenRA developers group, yet wasn't picked up by the group's RSS). :S

Also, this is IIRC the first release where mix content cannot be referred via IDs and must use a local mix database for additional files, iow, locked mixes will not work.
_________________



AS Discord server: https://discord.gg/7aM7Hm2

Back to top
View user's profile Send private message Skype Account
Blade
Cyborg Commando


Joined: 23 Dec 2003

PostPosted: Thu May 12, 2016 8:53 am    Post subject: Reply with quote

You mean the engine doesn't just hash the file names passed to it and then look them up in the mix file header info? That doesn't sound right to me, what benefit would you get from moving to reverse lookup from a DB instead of just hashing?

Back to top
View user's profile Send private message
Graion Dilach
Defense Minister


Joined: 22 Nov 2010
Location: Iszkaszentgyörgy, Hungary

PostPosted: Thu May 12, 2016 10:13 am    Post subject: Reply with quote

Case-sensitiveness and performance from what I remember, ask pchote, he got that through.

Also unison package handling with zips/audio.bag/idx which doesn't hash either.
_________________



AS Discord server: https://discord.gg/7aM7Hm2

Back to top
View user's profile Send private message Skype Account
pchote
Cyborg Soldier


Joined: 06 Feb 2015

PostPosted: Thu May 12, 2016 10:57 am    Post subject: Reply with quote

Blade wrote:
You mean the engine doesn't just hash the file names passed to it and then look them up in the mix file header info?


Using which hash format?  Even if we ignore all the other package formats, WW switched filename hashing algorithms between RA and TS.  At a more general level, OpenRA is moving to a model where the engine doesn't care about the specific package formats as long as they conform to the IReadOnlyPackage interface.  Mods can use whatever format they want as long as they provide a parser in their mod dll.  The engine doesn't know or care what a mix file is, and even if it was internally consistent there's no reason to promote its internal quirks over any other format.

The only requirements of a IReadOnlyPackage are that they can provide bytes for a requested filename (which could use hashing internally), and can provide a list of contained filenames (which can't).  The engine hashes these using its own package-agnostic algorithm for quick-lookup.  The mix format doesn't store filenames, so the mix database is used to recover that info.

Back to top
View user's profile Send private message
Blade
Cyborg Commando


Joined: 23 Dec 2003

PostPosted: Thu May 12, 2016 2:56 pm    Post subject: Reply with quote

Fair enough that you have an abstract interface for handling archives, that makes sense since you handle a variety of archive formats and code that needs to open a file shouldn't need to care how the file is actually stored.

What I mean is that not having an entry in the database shouldn't prevent the mix file parser from opening a file as Graion Dilach suggested you have done as a reverse lookup shouldn't be necessary. Worst case you hash the file name twice and lookup both hashes (and hope you don't have a collision). Best case you know when you load the mix file into your internal archive tracking data structures what format its hashes are and store that info so you know what hash format to use to query it.

A mix editor or viewer on the other hand obviously will need to do the reverse lookup.

Back to top
View user's profile Send private message
Graion Dilach
Defense Minister


Joined: 22 Nov 2010
Location: Iszkaszentgyörgy, Hungary

PostPosted: Thu May 12, 2016 4:17 pm    Post subject: Reply with quote

The thing is: OpenRA doesn't follow RA in terms of file management with depth-searching all possible places for a file instance when it would be used - instead of that, the package loaders just collect all filenames during loadup and the high level code is forced to use what have been found. There aren't even a place for a reverse lookup in the system.
_________________



AS Discord server: https://discord.gg/7aM7Hm2

Back to top
View user's profile Send private message Skype Account
Blade
Cyborg Commando


Joined: 23 Dec 2003

PostPosted: Thu May 12, 2016 9:18 pm    Post subject: Reply with quote

But to load the mix it is doing a reverse look up in the first place. to find the file name in the database. OpenRA is free to do whatever it wants, but requiring that the mixes have a local database isn't really supporting the mix format properly.

Back to top
View user's profile Send private message
pchote
Cyborg Soldier


Joined: 06 Feb 2015

PostPosted: Fri May 13, 2016 7:30 am    Post subject: Reply with quote

OpenRA doesn't require mixes to have a local database.  A global index is also available, and used for loading the original game mixes.

The point from above is that this is an optimization for both performance and code sanity.  Enumerating all of the package files until we find the correct parent for each load operation introduces an unpredictable runtime overhead, which is bad.  Building a flat filename -> package index at package load time (behind a loadscreen) is slightly slower up-front, but that is payed off many times over by having effectively-constant-time file resolution everywhere else. Sure this is in the margins of the performance calculations, but every bit helps. The bigger factor is in code sanity, and being able to treat mixes the same as all the other package formats.  This includes the in-game asset browser and mix-listing utility command, which need to be able to list the package contents.

Mix files from the original game are supported via the global index.  Mix files from mods are supported via the local mix database, or their own global index.  Where is the problem here, and why should that override the benefits I just listed?

Back to top
View user's profile Send private message
Blade
Cyborg Commando


Joined: 23 Dec 2003

PostPosted: Fri May 13, 2016 11:25 am    Post subject: Reply with quote

I never said anything about the search strategy used for finding where and entry is stored. Cacheing the IDs from all loaded mix files upfront vs searching each in turn really has nothing to do with if you need a name DB or not.

Anyhow, Graion Dilach was wrong which was my point, you do support mix files without an internal db, you just need the contents file names in your global DB which only places a slight overhead on modders who might want to use a mix without a DB internally.

Back to top
View user's profile Send private message
Matthias M.
Jumpjet Infantry


Joined: 15 Jun 2012
Location: Germany

PostPosted: Fri May 13, 2016 5:34 pm    Post subject: Reply with quote

I guess it doesn't matter in practice as XCC Mixer which saves a local mix db by default is the defacto standard application for creating and editing .mix files.

Back to top
View user's profile Send private message Visit poster's website
Graion Dilach
Defense Minister


Joined: 22 Nov 2010
Location: Iszkaszentgyörgy, Hungary

PostPosted: Fri May 13, 2016 5:49 pm    Post subject: Reply with quote

All mix scrambler (technique)s overwrite the lmd with noise though, leading the in-practice issues with locked mixes.
_________________



AS Discord server: https://discord.gg/7aM7Hm2

Back to top
View user's profile Send private message Skype Account
pchote
Cyborg Soldier


Joined: 06 Feb 2015

PostPosted: Fri May 13, 2016 6:59 pm    Post subject: Reply with quote

If you wanted a similar level of protection you could use / create a package format that doesn't have any public tools.  Both approaches protect you against people with XCC mixer, and both can be trivially defeated by modifying the OpenRA code to extract the files to disk when they are loaded by the engine.

Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic Page 1 of 1 [14 Posts] View previous topic :: View next topic
 Forum index » Modding Central » OpenRA Editing Forums » OpenRA News
Jump to:  
Quick Reply
Username:


If you are visually impaired or cannot otherwise play the game below please contact the Administrator for help.


 
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


Powered by phpBB © phpBB Group

Wildcard SSL Certificates
[ Time: 0.2449s ][ Queries: 12 (0.1283s) ][ Debug on ]