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
| Accelerated Feature Fate/"Why not?" Requests/Release Speed | |
| Posted by: Renegade - Thu, 2010 Jul 29 - Comments: 8 | Views: 88 | |
 |
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 | |
| DFD: Round II | |
| Posted by: Renegade - Thu, 2010 Jul 29 - Comments: 4 | Views: 72 | |
| |
While we judge another 50 fights of Round 1, you can continue to kill in Round 2 of the Daily Feature Deathmatch. Since Round 2 consists only of issues filed since the beginning of DFD, it's only 5 threads/10 fights. Question: There have been a number of times where the majority of you sat in DFDs and didn't want either of the issues in a fight - would you like an Ultimate Smackdown before Round 3, with the purpose of killing all issues that are complete bullcrap and/or shouldn't even be considered? That way, we'd go into Round 3 with only issues that are at least somewhat sensible. Your call, I can set it up either way. For now, go kill in Round 2. |
| Posted in: News from the Battlefield | |
| Daily Feature... Massacre? | |
| Posted by: Renegade - Thu, 2010 Jul 22 - Comments: 2 | Views: 92 | |
| |
Good day...after a few weeks of DFDs, the strengths and weaknesses of the system become apparent, and we'll adjust accordingly. The concept itself seems to work quite well...while the tracker is quickly filling up with new issues to replace the fallen ones, the DFDs reliably show which issues are most important to the community, and bring up issues that otherwise wouldn't have been thought about. On the other hand, there's a slight pacing issue - most DFDs, despite having 48 hours allotted, end after a few hours without big discussion, and on some days, we simply aren't all that motivated to go through the whole closing, judging & new posting process. Also, I assume by now anyone interested has noticed the DFDs, so there's no need doing them in the news anymore. Therefore, we'll do the following changes to the system today:
You may wonder about how you're supposed to judge all of the issues at once - welcome to our world! Just kidding.  You don't have to. As said in item 2, we'll judge when the fight is obviously over - if the fight hasn't even started yet, then obviously there's nothing to judge. So don't panic about posting in every thread immediately. Go to the schedule, look up the issue numbers of the fights you're interested in, and start with those. We will ultimately even judge fights that no one commented on, but only when it becomes apparent that nobody's commenting 'cause nobody gives a shit. So don't panic, just go and kill as many crappy issues as you can. With the commenting pace the community had so far, this should cut down the total period of DFDs significantly, and we'll soon be able to move on to a more permanent method of issue control. Update 1: The previous DFDs have been moved to the new section. |
| Posted in: News from the Battlefield | |
| Anonymous submissions disabled | |
| Posted by: Renegade - Sun, 2010 Jul 18 - Comments: 14 | Views: 163 | |
| |
Gather round, children, and thank chief moron 95.66.15.208 from Kuwait for submitting his worthless duplicate to #378 for the third time, thus forcing me to turn off anonymous submissions on the tracker. Anonymous morons have submitted a shitload of worthless crap recently, but his submissions were the pinnacle of worthlessness and disregard of the search functions. Thank him you have to log in now. |
| Posted in: News from the Battlefield | |
| Proper filing of a feature request | |
| Posted by: Renegade - Fri, 2010 Jul 16 - Comments: 0 | Views: 47 | |
| |
In light of recent developments I have decided to start actively enforcing the feature request submission rules which have been public for two and a half years now, and still continuously get ignored. For the last time, this is how a proper feature request looks like: The submission rules Wrote How to request a Feature Go to bugs.renegadeprojects.com. Click on Login. If you have an account, log into it. If not and you want to be informed about your request's outcome, plan to request several features, or want to report bugs later, click Signup for a new account and register; if not, click Login Anonymously. Once you are logged in, either normally or anonymously, click on Report Issue. If you didn't do so already, the system will ask you to select a project. Choose Ares and click Select Project. Now set:
Afterwards, click Submit Report. Congratulations, you just requested a feature.In addition, the Priority must not exceed "normal". If it does, the feature will not count as properly filed. Also, as anyone who has followed tracker discussions knows, an actual usage case for your request is vital. We don't implement features just because someday, somewhere, an unknown modder might perhaps eventually have a good idea that your request could possibly be absolutely essential for. Either you can show what your request is good for and that it'll be interesting to the community at large, or its priority will dwindle significantly. As of 30 minutes ago, every feature request not adhering to these guidelines will be suspended immediately. Duplicating it will only make it worse, duplicating it improperly will pretty much guarantee it'll be ignored forever. If the system allows you to, you can re-open/edit and fix the issue, but rest assured, reopening and leaving an issue improper will not increase our goodwill. I would like to stress that these rules aren't new. These have been the submission rules ever since the tracker was installed. In the past, we just didn't actively enforce them. Due to the increasing amount of crappy, improperly filed requests we're getting, this time is now over. In addition, I would like to point out that we're kind of tired of getting spammed with bullshit issues, and that we will employ additional measures to counteract them if necessary - this can range from enforcing registration before request, to an increased number of immediate closings, to an all-out referral of all new issues to a committee of trusted community members who weed out issues and decide what we'll look at in the first place. We're not doing that just yet, but rest assured, the options are there, and we're ready to make use of them if necessary. For the curious: 37% of feature requests in the past 16 days have been closed immediately, and out of those, 43.75% were duplicates. |
| 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