Project Perfect Mod

Home   Forum   Site Menu   C&C 1: Tiberian Dawn   C&C Red Alert 1   C&C 2: Tiberian Sun   C&C: Red Alert 2   C&C Renegade   C&C: Generals   C&C 3: Tiberium Wars   C&C: Red Alert 3   C&C 4: Tiberian Twilight   Fallout 3   OpenRA   Starcraft 1   Starcraft 2   Warcraft 3   Editing Tools   PPM Network   Affiliates   Community Links   Official Game Links   Browse Classic Site

OpenRA Release 20170421
April 21, 2017 - 21:06

Almost to the day half a year after our last stable release, the OpenRA dev team is proud to finally present to you their latest work - OpenRA Release 20170421!

With 43 developers producing just shy of 800 commits and touching almost 1800 files, this has very likely been one of our slowest release cycles ever. As such, the list of user-visible changes is not as long as you've come to expect in earlier years. However, behind the scenes, preparations for a fundamental transformation of the OpenRA engine are in the works. But more on that later.

As usual, this new release brings with it changes to the balance of both the Red Alert and Tiberian Dawn mods, as well as a huge number of new and overhauled multiplayer maps. In addition, it contains the following major fixes and features:
  • HiDPI font rendering for players with high resolution displays.
  • Fixes for several multiplayer bugs that could stall or crash games when a player disconnects.
  • The Red Alert "shell map" background is now muted.
  • New behaviour for the Red Alert Gap Generator and Tiberian Dawn Obelisk.
  • Fixes for asset installation on 32 bit operating systems and from the original RA95 CDs.
The Dune 2000 mod in particular has many changes to make it better match the gameplay and graphical polish of the original game, plus seven(!) new campaign missions.

Comparing regular and high resolution UI rendering in the Tiberian Dawn map browser.

Dune 2000 now comes with 13 campaign missions.

The re-written shroud-generating behaviour of the gap generator in action.

The biggest changes in this release are behind the scenes; technical improvements that are not visible to players, but important for our development and modding community:
  • A new trait conditions system provides much better control over trait interactions.
  • Actor vision has been overhauled, adding support for features like the RA active gap generators, D2K actors revealing themselves when attacking, and cliffs blocking vision in heightmap-enabled mods.
  • Simplified weapon definitions using inherited yaml templates.
  • Some initial steps towards removing code patterns that are not compatible with save game support.
OpenRA grew out of the C&C modding community, and one of our major goals is to provide a flexible game engine that the community can use for their own projects.  Unfortunately, this goal has been hurt by OpenRA's single-engine approach, meaning that every new release would unavoidably break community mods.

After many discussions, we have developed a new mod support strategy that we will implement over the next two OpenRA releases.  This release starts by adding support for parallel OpenRA installs, and we have started developing a mod template that includes instructions and scripts to simplify mod development and packaging.  Mods built using this template will be self contained games that function independently from our official mod installs.

The in-game multiplayer server list will now list games for all the mods that a player has installed (even across multiple installations), and will allow players to directly switch to another mod when joining one.  This applies across versions as well as mods, meaning that future OpenRA releases will be able to coexist, and switching between release and playtest servers will be just as easy as switching between RA and TD servers today.

The multiplayer server list is now smarter about multiple OpenRA installations.

The next release (later this year) will complete the mod-support transition by removing the in-game mod chooser and support for manually installed mod packages: all mods (both official and community) will be listed individually with their own names and icons in your Start Menu / Dock / Launcher.

We hope these measures will give more visibility to third-party mods, and establish OpenRA as a viable and stable real-time strategy platform even for games not connected to the Command & Conquer universe.

For the complete list of changes please see the full changelog. You can find installers for all our supported operating systems on our download page.

We hope you'll enjoy this newest installment of OpenRA!

Posted by pchote
Comments (0)

MapTool has been released.
April 13, 2017 - 02:18

Tiberian Sun and Red Alert 2 map makers behold! The Map Tool has been released by our friend Starkku. Ok, I'm overreacting here, but nonetheless, it is an interesting news for TS and RA2 map makers who wished to convert their maps to use different theaters and overlays.

MapTool is a small open-source tool designed to apply changes to tile, overlay and object data of map files of Command & Conquer: Tiberian Sun & Red Alert 2 based on pre-defined conversion profiles. It is capable of performing operations such as converting maps from one terrain theater or another.

Anyway, head to this topic to download the tool and its future updates. Be aware that you need Microsoft .NET Framework 4.0 to run it.

Posted by Banshee
Comment (1)

Next Ares version needs your feedback!
April 07, 2017 - 05:10

Hello everyone! If you've been browsing our forums recently, you might have seen this topic at Ares forum, which was recently started by AlexB, who is maintaining Ares for the last... God knows how many years. Anyway, he has recovered his motivation to add some interesting features for Ares, such as allowing you to choose how many of which buildings AI will build, customizable fall rates, customizable build times, etc. But his motivation willl vanish again if no one provides feedback. Here's the long essay that he has written about it:

AlexB wrote:
Long time no updates.... After 0.C's release, I went on to work on its successor, which was scheduled in three months from then. I didn't hear back much from the community until late 2016 or so, though, so I lost interest to publicly work on Ares further.

If there's community interest (and not just interest to get something from me), this shall be a double-release. First, there will be the features I already completed, preferrably released around June (that is a full year after the last one). This is for keeping up with the current state of Ares compared to the last released version. An intermezzo to catch up. The other one will be three months later, in September. I'll stick to my plan this time, that is, there will be a fixed date, and what's done until then is done, and what's not done won't be released.

So, here are some new features. There are more finished ones, but that would be a bit too much to include them all in one unstable build, so this isn't all there is. As always, some work went into updating the inner workings of Ares, but as adding more and more features means more things need to be checked and more time has to be spent doing that, is there anything to say about performance? How is the startup and game speed compared to Ares 0.C?

Fixes and Minor Additions
  • Allow CloningFacility buildings to set waypoints. (#1616741)
  • Fixed a problem with Hunter Seekers
  • Foundations with negative cell offsets are now supported
  • Fixed SidebarMixFileIndex also changing TooltipColor. (#1655347)
  • Emit a developer warning if a custom foundation does not include the cell 0,0.
  • Only objects that are currently visible to the player show the money amounts as text.
  • Damage delivery in Iron Curtain warheads had a bug.
  • Hijackers and Drivers cannot enter objects that are currently under the effect of the Iron Curtain.
  • KillDriver now respects AffectsAllies and AffectsEnemies. (#1619631)
  • Fixed iterator chars sometimes messing up type lists. (#913570)
  • Firestorm Walls can no longer be sold when the Firestorm is active
  • Several performance improvements

Potentially Breaking Changes to ArmorTypes
The ArmorTypes feature has some issues, which stem from the the order of initializing new types with a default value and reading the corresponding tag from the INI. This is a bit abstract and hard to describe. Setting all the defaults always took place before the values were read, thus, one default value could only ever be another ArmorType's default value. If a type at the beginning of the list defaulted to a type after it, then the default value was still uninitialized but was used anyhow.

Now the order has been changed, thus the parsed values now could be different, but I can't tell you what to watch out for without writing a novel.

There was also an inconsistency with parsing verses data. If using non-percentage values (like 0.01), the special flags could be cleared for small values, but they wouldn't be set again once a higher value was parsed. Now, the verses and flags are always updated to reflect the state represented by the value of the parsed tag. This is a breaking change, which affects non-percentage verses values. Commonly, percentages like 30% are used, so the impact should be limited.

Ares no longer tries to parse ArmorTypes if a tag is not defined. This is another breaking change: Previously, parsing non-existing tags in game mode and map files reset verses to 0%. Thus, newly defined warheads in maps would use the wrong values as default. Now, ArmorTypes that aren't defined aren't reset.

Let the AI build more than one building of each type
This should help to get rid of War Factory clones with all their shortcomings and ugly workarounds. Additional buildings are not build one after another as a block right after the original building, but instead mix randomly with the structures planned to be built later in the build list.

[BuildingType]AIBuildCounts= (list of integers, defaults to 1,1,1)
The number of buildings the AI will build of this type depending on the difficulty. Order is hard to easy. Each value must be equal to or greater than 1.

[BuildingType]AIExtraCounts= (list of integers, defaults to 0,0,0)
The maximum number of extra buildings the AI can build of this type depending on the difficulty. Order is hard to easy. A random number of buildings will be build in addition to the ones from the normal build count. Each value must be equal to or greater than 0.

A way to combine Abduction weapons with Temporal warheads
[Weapon]Abductor.Temporal= (boolean, defaults to no)
Instead of abducting target units right away, abduct them only after they have been temporally erased. When the target unit would warp away, it will be placed inside the abductor unit as passenger, given it suffices all other abductor checks like having enough free space. If abduction fails, the target is erased normally.

Optionally Consider Health for Temporal Weapons
[Warhead]Temporal.HealthFactor= (multiplier, defaults to 0.0)
How much the health is factored in when calculating the remaining warp value of the target. Valid range is 0.0 to 1.0 inclusive. 0.0 means health plays no role. 1.0 means the remaining warp is reduced proportionally to the target's health, down to 0.

Another way to look at it is that the remaining warp value is linearly decreased from full for completely healthy targets down by this value for a target that has no health left.

Turn off the Iron Curtain nullify flash per warhead
[Warhead]IronCurtain.Flash= (boolean, defaults to [AudioVisual]IronCurtainFlash=)
Whether units and structures will flash black or blue if hit with this warhead while under the effect of an Iron Curtain or Force Shield respectively.

[AudioVisual]IronCurtainFlash= (boolean, defaults to true)
Whether units and structures will by default flash black or blue if hit with this warhead while under the effect of an Iron Curtain or Force Shield respectively.

Customizable Fall Rates
[TechnoType]FallRate.Parachute= (integer, defaults to 1)
The acceleration towards the ground applied each frame a parachuted unit is falling.

[TechnoType]FallRate.NoParachute= (integer, defaults to 1)
The acceleration towards the ground applied each frame a unit without parachute is falling.

[TechnoType]FallRate.ParachuteMax= (integer, defaults to [General]ParachuteMaxFallRate)
The maximum speed a parachuted unit is falling with. Value has to be negative.

[TechnoType]FallRate.NoParachuteMax= (integer, defaults to [General]NoParachuteMaxFallRate)
The maximum speed a unit without parachute is falling with. Value has to be negative.

Attached Effects no longer count as parachute and thus won't reduce the fall rate.

Customizable BuildupTime
[BuildingType]BuildupTime= (double - minutes, defaults to [General]BuildupTime)
The time the buildup animation runs regardless of the number of frames.

Disable drivers entering units by owner country
[Country]CanBeDriven= (boolean, defaults to MultiplayPassive)
Whether units owned by this county can be captured by CanDrive=yes infantry.

So, what are you waiting for? If you have a Yuri's Revenge mod that makes use of Ares, give it a try and post your feedback at Ares forum. Do it for Yuri. Yuri is life. Yuri is master. My life for Yuri.

Posted by Banshee
Comments (26)

Upcoming plans for PPM future.
April 01, 2017 - 21:49

Hello everyone! We've been slow on news posting in these recent.... weeks at this site, I am aware of it. We've been relying on your news posts and announcements to keep this place alive. So, if you have something interesting to announce and spread the word, please do it by posting at our Community News Forum. But, this doesn't mean the death of this place. I am very passionate about this place and I wouldn't be crazy to just throw it away out of no where.The current situation happens because of a bet for a better future. You know? Sometimes big steps ahead demands big sacrifices.

The current sacrifice is directly related to my doctorate, which I'm having a hard time to finish it. While it is obviously more important for my real life, it will certainly have a great influence at this site as well, mostly at our future modeling tools. Doctorate candidates are obligated to research things that were not covered before, so if you have a plan to make one doctorate, PhD, etc, you should be very careful at revealing your research plans around. It's possible that someone at the other side of the world publish the same thing that you are researching, which may possibly ruin your situation. So, I've been quiet about my research for all these years, at least in the internet. But right now, I'm forced to finish it in a couple of months and, to be very honest, I don't think anyone will be able to finish it in such time, so I can talk a little about it.

As a visual computing scientist, I think it's amusing how most techniques (if not all) applied in my area to handle visual objects or solve problems with it doesn't really know what kind of objects they are dealing with. It's actually kinda ironic, in a certain way. Many of these techniques are based on local approaches. Imagine someone who is blind and deaf at the same time trying to know a place or trying to figure out how to go somewhere. While this person could use their hands and body to know what is around it, he can't know what is going on in the whole scene and use it in his advantage. For you guys at PPM, samples of such approach is the autonormals detection at the Voxel Section Editor III, image filters and even the 3D reconstruction techniques in the 3D Modelizer feature of VXLSE III. Other techniques may subdivide the space into smaller parts and treat them as local neighbors. I.e.: Octrees, Wavelets, skeletons and most if not all known hierarquical structures, etc. It's smarter, but you are still influenced by how your object is sampled in first place, which may generate noise in the solution.

You don't need to be acquainted to computer graphics to know that humans doesn't view objects like that, as we pay much more attention to its contents rather than how it is discretized, since there are far too many points for our eyes, isn't it? Objects are subdivided independently of the space metric, but mostly based on our semantic knowledge of them. And that's how we understand objects, languages and any kind of information in the end of the day. And that's what I'm trying to approach with my doctorate research, a graph language that allows me to understand objects and that is far more insensible to noises (bad sampling) than any existing graphic data structure out there.

By understanding objects, we could do a lot of things with them:

- Reconstruct them (zoom in, increase sample resolution, polygonize graphics, etc)
- Parametrize them (so, you can lately add some textures, or you could also use it to compare different objects and move information from one to another)
- Recognize them (and catalog them without using existing heavy brute force methods, and then using existing objects to add details to new objects of the kind... or even finding out how to automatically edit certain objects to make them fit into new contexts).
- Distinguish objects and different contexts where they belong, as well as allowing some of them to be auto-completed.
- Pathfinding (it could even be used in RTS games to fix some of the existing pathfinding problems, allow AI to know the best places where to set its defensive buildings or to find the weakest spots of the enemy and send its army in a path where it could exploit it).

It's worth mentioning that I don't have any of these things working at the moment and, in the best of the situations, I may have reconstruction working by the end of my thesis restricted to 2D objects. Coding my proposal is complicated because I have to deal with a bunch of complicated computer graphics and compiler problems at once. And that's what is cracking me so much. But still, this is the first step to Skynet a better understanding of visual objects as we know and a huge set of modeling tools that could make use of it.

Posted by Banshee
Comments (6)

eXTReMe Tracker