The browser you have chosen to use does not support current web standards or other common features of the modern web.
You will not get the intended viewing experience.
For your own safety and in order to view this page as intended, we strongly recommend you upgrade to a modern browser:
Ares
A Yuri's Revenge Expansion DLL
What is Ares?
Ares is the next generation of binary-based Command & Conquer modding.
Following the path paved by pd's famous RockPatch, Ares fixes and enhances the Yuri's Revenge game engine in a variety of ways, allowing modders to expand the game with never before seen custom units.
However, unlike RockPatch and other exe patches, Ares does not modify the game's exe. Instead, Ares uses Syringe to inject its code into the game during runtime, leaving the original game unchanged, thus eliminating the need for backup exes or un-patchers.
Download Ares
If, for whatever reason, you wish to download Ares independently anyway, click below.
DOWNLOAD ARES
Launch Base
Ares can be downloaded to the right, however, for ease of distribution and regular updates, it is strongly recommended that all mods using Ares use Launch Base instead.
Launch Base is the next generation mod creator/launcher developed by Marshall, offering one-stop integration and management of mods, plugins and tools for Red Alert 2 and Yuri's Revenge. It has inbuilt Syringe and Ares support including automated updates, making it the cleanest and easiest way to obtain and use Ares.
News
| Bi-Annual Sluggard Purge | |
| Posted by: Renegade - Mon, 2010 Aug 23 - Comments: 8 | Views: 175 | |
 |
Since the new testers are just as worthless as the old ones¹, it's time to do the fun tester replacement game again. Out with the old, in with the new. For further details on how to apply and what will be asked of you, read the previous thread. Bear in mind that, without testers, we cannot release public versions of Ares, since we could not guarantee the versions are working. ¹ with a few shining exceptions |
| Posted in: News from the Battlefield | |
| DFD: Round III | |
| Posted by: Renegade - Wed, 2010 Aug 11 - Comments: 5 | Views: 209 | |
| |
With 15 new threads, our Daily Feature Deathmatch goes into the third round! The Ultimate Smackdown has reduced the field to 60 issues, meaning we'll reach the target group size one round earlier than expected, and will end the DFD after Round 4. Given that, after the DFD, we will start rescheduling and planning both for the smaller releases as well as to align the schedule more with community demand, you should also go and use the ICS system to voice your stance on existing confirmed and assigned issues, so we know which issues to give priority, and which issues to put at the end of the queue for now. To make this clear: Community support will be key in future scheduling - so if you don't go and submit your stances, you have no basis for complaint if the schedule isn't to your liking.  |
| Posted in: News from the Battlefield | |
| Feature Requests Suspended | |
| Posted by: Renegade - Sat, 2010 Aug 07 - Comments: 0 | Views: 63 | |
| |
In our ongoing quest to bring down the flood of feature requests to a manageable level, we have decided to take the logical next step and suspend all accepted new feature requests for the moment. With DFD tackling the accumulated existing feature requests, and Accelerated Feature Fate introducing quicker vetting of new requests, this ensures that even those requests which are newly selected for implementation by us and the community don't clutter the tracker and compete with already scheduled issues for attention. Ideally, with this last measure in place, after the DFD, we will achieve a situation on the tracker where all open issues are either being worked on, or scheduled to be worked on, with no "zombie-issues" cluttering it. Let me emphasize that this measure is temporary. Given the volume of requests, it will likely be in place for a while, but ultimately, we hope the workload will allow us to schedule accepted new requests immediately again. So for the time being, a feature request will run through the following stages:
You will notice that the only difference is that the request gets suspended for a while in the middle - other than that, everything stays as it was before. Think of it as being placed on hold. By tomorrow, we'll have a warning up on the submission page to inform users of this decision. As usual, we'd be happy if we didn't have to do this, but until we get more coders to share the workload with, there's simply no point in adding more and more and more issues to the queue while we have a hundred issues still scheduled for implementation. On the bright side, however, with all these recent request management events and process changes, we should have tamed the vast amount of feature requests very soon, and will launch into a period of strong focus on a long chain of requests the community truly wants, with frequent, small releases produced with little distraction from garbage issues. And I believe we can all look forward to that.  In related news, Rounds 1 and 2 of the DFD are almost all judged, and the Ultimate Smackdown will commence next week at the latest. |
| Posted in: News from the Battlefield | |
| DFD: Ultimate Smackdown - Prelude | |
| Posted by: Renegade - Fri, 2010 Aug 06 - Comments: 3 | Views: 119 | |
| |
Update: The Ultimate Smackdown has begun! As we are nearing the end of the judgement period for Rounds 1 and 2 of our Daily Feature Deathmatch, it is time to prepare for our recently decided Ultimate Smackdown. The situation, as we imagine it so far, will be as follows:
Post format In the DFDs, each of you had his own formatting of his posts, some of you more ordered, some of you less. In order to ensure this event gets sorted out quickly, we are mandating a certain format, designed to ease our work:
Example Code 42 displayed as --- 42 436 1111 436 This issue is a waste of time, Visceroids aren't supposed to fly, and it violates the spirit of C&C to add that. 69 This feature would increase Ares's appeal to female modders and should therefore be saved at all cost. --- Be aware that we will copy the issue ID lists as they are and have a computer count the votes. If your votes are not marked up correctly, the computer will not recognize them. We will search the paragraph headers to determine which issues have additional argumentations. If your header does not have the described look, it will be ignored, and your argumentation will never be read. This may sound draconian, but given that we'll be looking at something like 70 issues, and potentially a dozen voters, we could, theoretically, end up with hundreds of votes and thousands of lines of argumentation. We most certainly don't intend to play scavenger hunt for opinions in that volume of data. Even if we don't get that much data, standardization will make it much easier and quicker to parse. With that all being said, are there any further questions or suggestions? |
| Posted in: News from the Battlefield | |
| Accelerated Feature Fate/"Why not?" Requests/Release Speed | |
| Posted by: Renegade - Thu, 2010 Jul 29 - Comments: 12 | Views: 285 | |
| |
Accelerated Feature Fate Who frequents either the tracker, the DFDs, or this news section has heard by now that we're dealing with a high number of issues that are best described as "crappy". In addition, there are a number of issues, both old and new, which are valid feature suggestions, but either find no echo in the community, don't seem worth the effort, or quite simply find no one willing to code them. In the past, a certain sense of diplomacy led to such issues quietly dwelling at the bottom of the tracker, in a sort of limbo - not closed, but not acknowledged, either. This will now end. With DFD Round 2 having started, no new features will enter DFD anymore, and any issue with an ID higher than 1158 will be judged on the tracker again. However, we have no desire to just start the cycle over and accumulate a new year of issue-cruft. From now on, all feature requests will be judged swiftly and decisively. We will do assessments of the features as soon as we can, and if we determine that they are either unrealistic or that no one will be there to code them, we will close them immediately. Those who are left open are to be vetted by the community - we will look at the argumentations in the comments and the expressed community support in the ICS, and will then make a decision on whether to implement the feature or not. If we decide not to implement the feature, the request will be closed. If we decide to implement it, the feature will be promoted to confirmed status. This will be drastic in some cases. As with DFD, there will be issues the community may want that still get closed. This sucks, and we all wish we'd had an army of magic elves to help us code, but the fact of the matter is -as has been said multiple times during DFD- we simply cannot implement all requests, and to pretend we can by keeping issues open indefinitely serves neither side of this. "Why not?" Requests We will also increasingly close "would be nice" kind of issues. With 142 issues set to be implemented at some point right now, and probably another 20-30 coming in through DFD, we simply cannot afford to implement features just because someday, somewhere, some unspecified mod might, perhaps, use the requested feature. We understand that there are many features that might have potential uses, which sound interesting, which modders might play around with if we added them, but there are simply too many requests to implement dozens of features only to have them be played around with by two people and then dropped forever. From now on, we will put a stronger emphasis on community demand, usage cases, et cetera. The mere fact that something "has potential" will only be enough if it sparks an individual developer's interest. Again, this will be harsh, this will be drastic, but it simply wastes both our and the community's time to implement features just because someone may want them sometime in the future, while there are requests in the tracker that the community demonstrably wants now. As usual, of course, requests can be reopened, we're open to having our opinion changed, but we simply can't continue the way feature requests were handled so far. Leaving all requests open indefinitely on the off chance they might gather support was the diplomatic thing to do, but as the DFDs have shown, all that did was create a collection of crappy and meh features that not even the community thinks are worth spending time on. On a related note, it would also be appreciated if the tracker population went through the already scheduled features on the roadmap and used ICS and comments to voice their opinions. I have no doubt there are features scheduled on there that the community would rather have delayed because there are more important and desirable features requested. To make this perfectly clear: The idea is not to kill as much as possible for killing's sake, or because we're lazy. The idea is to filter out the issues that are a waste of time anyway, and to instead focus on the most wanted features of the community, to ensure future releases are packed with features the community actually wants asap, and not just ones it's kinda happy about while it's waiting for others. A "less is more" approach, essentially. Release Speed On a similar topic, there is something I want your opinions on: Currently, Ares versions start scheduled with a dozen or two requests and bugs, and then accumulate another dozen or two bugs and small requests over time. This makes for nice, big Ares-releases with loads of features and bugfixes, but it also means release intervals of several months. What we can offer, instead, is to cut down the features per version significantly, but to release stable versions with those features more often in turn. If each developer only did one big feature and one small feature each version, plus bugfixes from the version(s) before, we could release stable versions much quicker and more often, and development would be much more focused - for 0.3, for example, D could focus on the random map generator, I could focus on the morale system, and Alex could focus on some other bigger improvement, and then that would be that - modders would know the themes of the next release, testers would know what specifically to test, and the release would come much quicker and more polished, since we only had to focus on getting three big systems to work, not a dozen. The price, of course, is features - only a fraction of those currently scheduled per version. On the other hand, it's not like it actually makes a difference, time-wise. Sure, you might only get three features per release rather than twelve, but if we release four versions in the time it'd usually take for one, you still get all twelve features at the same date as before. It's an offer, it's food for thought, I'd just like to hear your opinions about it - do you prefer big, loaded releases with long release intervals, or small releases with few features and short release intervals? |
| Posted in: News from the Battlefield | |
Powered by DCoder's News System (DcNS) 0.5, © DCoder 2006 - 2008.
Contact
For general contact, please use the forum. Guest posting is enabled, so registration is not necessary.
Alternatively, or if you need immediate contact, use chat.
If the matter you wish to discuss requires privacy, both chat and the forums offer private messaging functions (the latter requires registration for that).
Do not contact developers personally to make feature requests. Feature requests received that way will be ignored. Instead, file a proper feature request.
Return to Top