0.3 Features

[Renegade]

With only 9 "serious" issues left on 0.2's roadmap, we are slowly crawling towards 0.2's release, and therefore, inevitably, towards 0.3's development.

As mentioned multiple times before, 0.3 will start a new, accelerated development pace, in which we focus only on a handful of issues per version, in order to release each particular version as quickly as possible.

However, this poses a particular problem: All previous scheduling is void.
Everything currently on the roadmap after 0.2 is irrelevant. Scheduling starts over.

Undoubtedly, you are noticing a slight clash at this point: If all scheduling after 0.2 is void, and we're slowly crawling toward's 0.2's release...what the hell are we gonna do after that?

That is the question I would like to settle in this thread.

In the future, we'll likely have this kind of discussion on the tracker, largely based on ICS ratings and comments, however, since this is the first time, and the tracker is still arranged for the previous release model, that kind of wouldn't work out.

Parameters
Let's start with the basic framework: What do we have, and what are we looking for?
We currently have three "full time" developers (D, Alex and me), plus Marsh focused on #340. Since #340 is targeted for 1.0, and even if it weren't, it'd likely need an additional round of bugfixing after it was publicly released (it's quite complex), I'm assuming Marsh would be busy either way, even if he were, on principle, interested in tackling more issues. Thus, we'll be loading work on 3 developers only.

Now, what will we load onto these developers? 1 small feature and 1 big feature each, or, alternatively, 1 system - where "system" would be a conglomerate of multiple issues on the same topic. EMP would be such an example, or a collection of RMG improvements, things like that.

While selecting issues, always remember that those few feature requests are not the only things we'll work on. There are hundreds of bugs already in the system, and a public release of 0.2 will lead to a spike in new reports. These six issues will not be the only issues we work on - it will just be the only features.
So when you pick what you'd like, don't assume "oh well, if he's only gonna do one system anyway, I guess it doesn't matter if it's 6 issues big".
Unwritten features don't cause harm.
Bugs do.
Your selections will compete for attention and development time with necessary changes that we cannot ignore. Remember that when proposing your selections.

With that being said, you're pretty much free to choose from any unresolved issue on the tracker, including bugs, if you wish so.
That explicitly and emphatically includes all issues currently targeted for 0.3 and upwards.
Their targeting is void. The fact that they are currently still systematically targeted is irrelevant and has no meaning. The fact that an issue is currently targeted does not mean we plan on putting it in a future version.
I will purge these listings as soon as possible, but currently, that would lead to chaos on the tracker.

It would likely be wisest to start from the top of the Issue Community Support ranking, but you don't have to.
As usual, feel free to support your pick with arguments for or against yours or other issues.

Also keep in mind that certain issues have been postponed for a reason - while we will focus on what the community wants, shouting for fixed savegames in 0.3 is a futile exercise. It's just not gonna happen.

Proposing
Proposing a feature set is simple: Just do it. Pick up to six issues you'd like to see tackled in 0.3, and support them with arguments if you want to. Make sure to include the issue numbers, and make them bold, so we can easily find the features you want, and adhere to the parameters given above in terms of pairing.
If you underestimate the work a feature will require, we'll tell you quickly enough.

As said: On principle, you're free to choose from everything. We'll check where the community leans to, and we'll try our best to pick a feature set that will make as many of you as possible happy.
As usual, however, it's always possible that a feature simply doesn't find a developer, or that it's too complicated to implement at the moment. The mere fact that an issue has broad support will not guarantee its implementation.

With that all being said...go ahead and talk! What do you want to see targeted for Ares 0.3?

[Modder666]

http://bugs.renegadeprojects.com/view.php?id=204 - Custom Radiation
Used in many mods on NPatch, custom radiation has allowed for more diverse weapon options. With Ares, the logic could also be combined with many of the new weapon effects and more diverse weapon systems could be included.

http://bugs.renegadeprojects.com/view.php?id=982 - Rewriting TechnoClass::SelectWeapon
Another feature requested by many users, this would give modders many ways to diversify combat. Multiple weapons could be given to heavier vehicles, allowing for the ability to target multiple targets dealing different damage with more control than warheads. Total conversions could use this for special units, or in combination with other Ares features to increase their mod environment.

http://bugs.renegadeprojects.com/view.php?id=1037 - Custom Palettes for Animations
An NPatch feature used heavily in total conversion mods, the ability to give animations custom palettes could get more support for Ares and more testers who could use Ares in different ways, allowing for more diverse tests. This would also knock off a feature that's limited to NPatch.

[Renegade]

Heh, I'm pretty sure that's a little too big already. Given the vast amount of things SelectWeapon will touch, you should consider that a big feature.
I suspect Custom Palettes for Animations could be done as a quick extension of the previous work, but I have absolutely no idea.

[WoRmINaToR]

For the first 3 issues M666 suggested, I completely agree. If one coder each worked on those 3 issues for 0.3, that would be a really great release. I definitely see Air Patrol / Guard mode being the hardest of the bunch to implement (seconded closely by the active protection systems), but I think it would be a good idea to finally implement the single most wanted feature in the entire tracker.

Now for some smaller-scale issues, I think this one would be a good one to tackle:
http://bugs.renegadeprojects.com/view.php?id=634 - Factories producing different units.

This doesn't appear on the surface to be a complicated issue, and since the "kennel hack" was fixed early on in Ares' life, we need a replacement.

Another good one to take care of would be this one:
http://bugs.renegadeprojects.com/view.php?id=314 - Multiple types considered as one class to selection and BuildLimit

This one might have some complications but, I would imagine, not nearly as many as Rewriting TechnoClass::SelectWeapon, for example. But it has, for a very long time, been a dream for modders to be able to do "infantry linking" for tanks, etc.

[Professor_Tesla]

Issue 204: http://bugs.renegadeprojects.com/view.php?id=204 - Custom Radiation
I support this one (and not just because "must haev tihs becuase npatch has this featuer!!1!"). I think that different radiation colours and warheads would open up a lot more possibilities for weapons (such as a bio-weapon that poisons the ground in a certain area, killing infantry like the Virus's weapon, or liquid nitrogen, or something that causes an area to be extremely "hot").

Issue 1037: http://bugs.renegadeprojects.com/view.php?id=1037 - Custom palettes for animations
While one palette may be good for general animation making, some modders may want to make animations with hugely different colours than are in the standard animation palette.

Issue 634: http://bugs.renegadeprojects.com/view.php?id=634 - Factories producing different units
I would really like this to be done. This would allow the possibility to create separate factories for normal vehicles and VTOLs/helicopters, or light vehicles and heavy vehicles, etc. It would also be nice if we could eventually get different build queues for the different kinds of factories, but that's another matter.

Issue 314: http://bugs.renegadeprojects.com/view.php?id=314 - Multiple types considered as one class to selection and BuildLimit
I don't know how complex this would be to do, but I think it needs to be done, if only for the sake of not needing a hack to make all engineers the same "type" or all dogs be the same "type". It would also, as Worm mentioned, enable multiple VehicleTypes, etc. to be considered the same "type" which could be useful for some modders.

[reaperrr]

EDIT2:
Ah what the heck, I can only make guesses about complexity of certain issues anyway, so I'll simply name the 6 features I want most (which is equal to 'the sooner, the better').


Issue 981: http://bugs.renegadeprojects.com/view.php?id=981 - More than two weapons on a unit
Even if it's complex, DCoder is right, 2 weapons is a ridiculous limit. There's a reason why it's so popular.

Issue 504: http://bugs.renegadeprojects.com/view.php?id=504 - Make the units fire two weapons at same time
This is amongst the most popular issues as well, would complement #981 quite well and probably requires changes to the SelectWeapon logic anyway, so it might make sense to put them into the same release.

Note: I don't really have (much) use for one of these without the other, so if possible, I'd like to see them in the same release.

My other personal favorites:

Issue 316: http://bugs.renegadeprojects.com/view.php?id=316 - Ammo= on weapons
This is currently in the Top 10 of ICS as well, and would complement #981 and #504 quite well too.

Issue 634: http://bugs.renegadeprojects.com/view.php?id=634 - Factories producing different units
I would really like this to be done. This would allow the possibility to create separate factories for normal vehicles and VTOLs/helicopters, or light vehicles and heavy vehicles, etc. It would also be nice if we could eventually get different build queues for the different kinds of factories, but that's another matter.

Agreed.

Issue 623: http://bugs.renegadeprojects.com/view.php?id=623 - Decentralisation of projectile tags
BallisticScatter is not that important to me right now, but Gravity is. I might be wrong of course, but de-centralising two flags sounds not all that complicated compared to some other stuff.

Issue 1203: http://bugs.renegadeprojects.com/view.php?id=1203 - Allow modders to disable the "toggle between left & right" behavior for weapons with Burst>=2
I know it most likely won't make it into 0.3 or any of the immediate following releases, but I still want to lobby for it right now, because it actually is a rather important issue for me and doesn't look too complicated either when compared to many other requests.

[Nighthawk]

Issue 255 - Attribute Modifiers on Weapons: Link.
This would allow the creation of proper hero units that can grant leadership buffs. Alternatively, it could allow for weapons that incur other effects upon units aside from just damage. E.g. a Tesla weapon could cause problems with a vehicle's controls and thus reduce its speed. If applied to a warhead and used with the GenericWarhead super weapon, it could allow for a variety of new effect-based super weapons.

Issue 634 - Factories Producing Different Units: Link.
With the Kennel trick being fixed, this would be incredibly useful for re-emulating it again. Not much more to say on that one...

Issue 609 - Researches: Link.
I know it's currently in the DFD cycle, but in the event that it doesn't make it through, it'd still be a great thing to implement. It'd finally remove the need for using the somewhat hackish 0x0 foundation structures, allowing for proper "upgrades" that don't have to be placed to impart their effects.

Issue 204 - Allow the creation of custom radiation types: Link.
I know this issue is probably rather big, and I'd prioritise the previous ones I've mentioned over this, but anyway. Simply, it would allow players to create greater variation in radiation effects. After all, who's to say that every nuclear powered thing uses the same fuel source? You could even with a different colour and some kind of ingame explanation use it for other things as well (napalm, for instance). It could also work incredibly well when combined with issue 255.

Issue 376 - Weather Effects:: Link.
Something that could save modders a lot of work. Setting up weather on a map using waypoints and triggers can take a lot of time and is somewhat irritating. If the weather effect could be assigned a warhead and/or damage, it could add to the variety of things that could be created, especially if issue 255 is factored in.

Issue 215 - Additional Unit Cursors: Link.
Something that could make use of the many unused cursors within mouse.sha. It may only be a small graphical gimmick, but it'd add an element of uniqueness to units. For example, there's the GI and Desolator's custom deploy cursors which go unused, and the Chrono Legionnaire's custom move cursor which goes unused. If custom cursors were also addable to weapons, that would make a complete set of changeable unit cursors for all eventualities. Though under Ares' current system of defining cursors, at several flags per cursor, it might make unit entries a little bulky. A system similar to the old RockPatch method of a [MousePointers] section might be useful there, but I think I mentioned that in the comments somewhere anyway.

---

Edit: Alternatively, instead of weather effects (which would probably be somewhat cumbersome):
Issue 179 - Allow units to turn into other units upon promotion: Link.
Could allow for much more variance and expansion in the veterancy system. Combined with the custom insignia feature that's already in there, you could have a theoretically limitless veterancy chain. Still though, it would allow units to upgrade themselves over time in much better ways than simply just a new weapon.

[Renegade]

Sidenote here: I wouldn't implement #376 cell-based, and even if I did, I do think applying a warhead to every cell of the map on every frame would be problematic, performance-wise. So while I understand the desire, I don't think the warhead thing is gonna happen.

And well...you picked a heavy set.

[Blade]

Issue 322 - Restore NonVehicle= Function:Link
This will fix a number of limitations with controlling hijacking and carryall logics and limiting what they can and cannot be used on.

Issue 250 - Allow sensors on buildings:link
This feature is languishing away unloved, but I can't see it being particularly hard to implement compared to some of what is being requested and practically all mods make use of at least one stealth unit (subs which as also part of stock). I'd argue that WW broke this unintentionally since I believe it worked in RA2 and was present on the psychic sensor so really its almost a bug with the existing game.

Issue 762 - Hijacker mindcontrol interactions:link
A lot of mods make use of a Vehicle hijacker and because they also use mind control as well, things get weird when the two inderact and don't behave as you might assume they should. It doesn't add any fancy new in your face effects, but any mod that uses ares and hijacking will instantly benefit from this.

Issue 432 - Savegames don't work in skirmish mode. Saving is ok, but loading a savegame always results in an IE.link
This appears to be a big complicated issue judging by the devs responses when ever this is mentioned, but I would like to see saving working properly again for both skirmish and campaign.

Issue 1086 - Allow Player@X functionality for more script related functionslink
Another potentially time consuming feature to implement, but it would allow a large increase with what is possible on multiplayer maps regarding scripting, including new game modes along the lines of how the assault mode works (specially customised maps).

Also, like nighthawk I suport extensions to what cursors can be customised.

[Renegade]

... -_-

[Modder666]

Big lists, guys. Big lists. That's what we're avoiding for smaller releases.

[Orac]

Issue 432 - Savegames don't work in skirmish mode. Saving is ok, but loading a savegame always results in an IE.
This appears to be a big complicated issue judging by the devs responses when ever this is mentioned, but I would like to see saving working properly again for both skirmish and campaign.

Fix that alone and release it. I'd call that a big improvement.

Its big, its important, and its broken. I think it fills all the needed boxes for a thing to fix before releasing 0.3 or whatever.

EDIT: But after it was made clear that this bug is a little on the large side, I would prefer to relocate my support to a primarily aircraft focussed release, with:
Ammo on Weapons, with the possibilities that are brought with this
Combat Air Patrol, with the ability to make aircraft useful in support instead of relegating as an afterthought behind tanks and infantry
and
Waypoints for Aircraft, because this should really have been there in YR and was oddly missing...

[Modder666]

But it's gonna just break again, as I'm fairly sure the game has to know where all the code is when it loads a savegame. If the code isn't saved in the appropriate places, or the code in question has been modified since the save was made, it'd be broken the next minute feature x modified the way the game ran. Save games don't need to be fixed til version 1.0, as is planned on the roadmap.

Unless I'm wrong, in which case a developer should explain why Save games are being held last.

[Blade]

LOL, Sorry Renegade, your post was TLDNR... I figured I'd got the gist of it before I got to the part about save games

[tmapm]

Issue 1086 - Allow Player@X functionality for more script related functionslink
Another potentially time consuming feature to implement, but it would allow a large increase with what is possible on multiplayer maps regarding scripting, including new game modes along the lines of how the assault mode works (specially customised maps).

I would love to see this.