Posts: 1 921
Threads: 273
Joined: 21 Nov 2004
Reputation:
DFD: Daily Feature Deathmatch
The Cruel Fight For Implementation
This is a Daily Feature Deathmatch post. If you are unfamiliar with the background of this event, please read the announcement, the adjustment and the schedule.
Fight 1
[715] Extending Upgrades to include documented limits vs. [725] Single-click Chrono Sphere
Fight 2
[757] Deployer Stat Changes vs. [607] Enable Storage= on buildings.
After the fight is over, two of these issues will be suspended, while the other two move on to the next round.
Remember that the coders will not take part in the discussion, so make your arguments complete, concise and convincing - when it's over, it's over.
Part of that is clearly marking what outcome you support for which issue.
There should be no ambiguity in the issue you're talking about, and it should be clear what outcome you support. Feel free to put your stance in bold, and use simple terminology like "kill #69" or "I want #42 to survive".
This use of simple terminology should be part of a larger argumentation - if this is all your post consists of, it will be ignored. We are interested in argumentations and details to consider, not votes.
A decision will be made either way, a lack of discussion will not cause all issues to live.
Be friendly, be civil, be logical.
You are allowed to try to deconstruct the arguments of those arguing against your candidate, but remember that they don't make the call - there is really no point in getting personal.
The discussion should be contained in this thread, argumentations elsewhere will be ignored, but you are allowed to transfer and adapt points made elsewhere in the past.
We want a good, clean fight.
Let's get it on!
These fights are largely automatically generated - if an issue turns out to be unfit for combat, it will be disqualified and the opponent will go into the queue.
Forum Rules
(01.06.2011, 05:43:25)kenosis Wrote: Oh damn don't be disgraced again!
(25.06.2011, 20:42:59)Nighthawk Wrote: The proverbial bearded omni-bug may be dead, but the containment campaign is still being waged in the desert.
Posts: 89
Threads: 0
Joined: 19 Oct 2009
Reputation:
11.08.2010, 05:41:22
(This post was last modified: 11.08.2010, 05:42:04 by Orac.)
725 seems like a really tiny change to the Chronosphere, admittedly with interesting results. But still, easily ignored.
On the other hand, the upgrade expansion in 715 would make upgrades a lot more attractive to modders - a Spy Sat. upgrade, or oil derrick upgrade are especially interesting to me.
In conclusion: Kill 725
757 gets my vote, because I've lived with the lack of silos in RA2 up until now, so it isn't a real game changer. On the other hand, having massive control over how strong a unit becomes when deployed would become a much more useful feature - especially where the GI is concerned.
In conclusion: Kill 607
Posts: 135
Threads: 11
Joined: 2 Sep 2009
Reputation:
Well this sucks. I actually like all four of these issues, and personally would like to see all of them survive.
I guess it comes down to which ones would have a bigger impact on the modding community, and the patch's appeal to other modders.
For fight one, I have to go with 715. Upgrades have been a long-standing, major subject for modders across the community for years, and the limits have been made obvious. Many modders have attempted workarounds for some of the upgrades' limits, but expanding the basic upgrade logic so these workarounds are no longer necessary would definitely take more of a priority than the Single Click Chronosphere.
I like the idea of the single click chronosphere, but I just don't think it will change very many mods.
For what it's worth, many/most YR players play with superweapons turned off, and this has been so for quite some time.
Now fight 2 is even harder of a call. I'm split between something I personally would like to use, but I don't know if many other mods would use it, and something I won't be using, but something that has been wanted by lots and lots of modders, especially modders who make total conversions and YR -> TS mods.
I have to say that, for now at least, tiberium silos can wait. All in all, players don't typically have so much cash on their hands that they need many silos to begin with, because players usually spend their cash at about the same rate they gather it. This is, of course, by design.
On the other hand, having infantry gain or lose strength, firepower, abilities, immunities, armor types, etc. etc. would be a major gameplay changer, and could make the decision of "to deploy or not to deploy" for certain units an important strategic decision, instead of the current "simply deploy and your infantry will get more powerful" idea that's in place. You could make a unit that, when mobile, is fast but weak, and has a long ranged weapon that does good damage, but when deployed, becomes a great tank-unit (RPG-style tank; damage absorber. Not THAT kind of tank!) with lots of health and a short ranged weapon that doesn't exactly do great damage. Or you could replace that weapon and give him a medkit while deployed, or perhaps some kind of stat-boosting aura (because I am fairly certain some kind of feature like that was requested awhile ago).
Honestly, the possibilities with this feature are nearly endless, depending on just how far we want to go with implementing this.
Posts: 82
Threads: 0
Joined: 26 May 2010
Reputation:
11.08.2010, 12:35:02
(This post was last modified: 11.08.2010, 12:43:28 by reaperrr.)
Fight 1:
support #715
kill #725
For the reasons Orac and WoRm gave.
Fight 2:
support #607
kill #757
I changed my mind on this one. Storage= is needed for any TD/RA1/TS total conversion. Furthermore, if the Storage system can be enabled/disabled on a per-country or at least a per-side basis instead of being global, we can have factions that need silos and factions that don't, which would allow for more differentiated resource systems. Otherwise I agree with Blade.
Posts: 453
Threads: 11
Joined: 26 Jan 2005
Reputation:
Fight 1 I agree with the posters so far
Fight 2 I say prioritise the restoration of an old feature that has high demand rather than a new feature of unproven desirability and that could be accomplished in a much better way by deploys into logic. There are many modders doing RA1 or TS mods that would benefit from the storage restoration. I've seen lots of feature subset requests for Spawns and Deploys logics during the DFD and I think really they should just all have been rolled into two large feature issues and confirmed for implementation given the diffuse but large support all the subsets seem to have had. Would have simplified the DFD a large amount too.
Posts: 573
Threads: 26
Joined: 14 Oct 2005
Reputation:
Bah, I don't like this DFD, all the issues are good ones.
For fight one:
While I did argue in favour of the single-click Chrono Sphere logic in its previous DFD, compared to the upgrades issue, it's just not as big. I made similar arguments on another Round 3 DFD issue that upgrades are severely limited in their capacity to upgrade stuff. Power, weapons and super weapons. That's basically all they do. Now, personally I prefer this upgrade issue to the one in the other DFD, which had an irritating requested implementation. Knowing my luck both will win their respective DFDs.
Very reluctantly, I'm going to have to say support #715, kill #725.
For fight two:
Blade poses a very good point for the first issue - such a thing is better done through expanding the DeploysInto logic than the suggested implementation here. That said, it makes sense for a GI to become more armoured when deployed, or a Desolator to become more vulnerable when deployed.
However, the second issue is definitely my preferred one of the two. People have been wanting the ability to add ore silos back for years, and this would finally do it. It would add more strategy to gameplay - players would have to defend their silos or risk losing a good proportion of their funds, additionally players would have their resources capped without building more silos, potentially limiting the irritating "mash Grizzly button thirty times, wait, repeat" strategy. It would shift gameplay back towards a resource-oriented dynamic rather than a spam-oriented one.
Therefore, my stance is support #607, kill #757.
Ares Project Manager.
Open Ares positions: Documentation Maintainer, Active Testers.
PM if interested.
Posts: 66
Threads: 8
Joined: 17 Aug 2005
Reputation:
11.08.2010, 19:02:44
(This post was last modified: 11.08.2010, 19:03:36 by eva-251.)
Kill 725
725 isn't that great of a suggestion. As said in the request's discussion, it's essentially a gimped Chronosphere that is clumsier to use as you have to actually bring your units to the device to get them to their destinations. Perhaps if you're going for something Stargate like or specifically desire an inferior superweapon to the Chronosphere...it's not that useful.
Support 715
I can remember the disappointment I had when I found out spy-sat, among many other things, cannot be inherited as an upgrade ability. Being able to use these for upgrades should be a given.
Fight 2
Kill 607
Support 757
Nighthawk, that's hardly true. Silos did nothing to stop spamming- if anything, they enforced it as the rule of CNC. Nobody wanted to build silos, let's be real here. They wasted build-queue time, money, power and build space (and the EVA nagged you non-stop about them).
The reason people would "mash Grizzly button thirty times, wait, repeat" is because they had the income to do so. They had the harvesters and the income-per-second to buy their tanks non-stop. If you were limited to say, the typical 2000 credits per refinery as older CNCs had it, it wouldn't do anything still! Even if their income outpaced their tank production, this wouldn't lead to the need for silos, but rather for another War Factory to speed production, or perhaps a go-ahead to expanding and teching up their base.
TBQH whenever I played RA1 or TS (and mods for each), I'd would build silos only when facing the AI- because the AI doesn't understand the importance of silos and you need to have a credit reserve, because it's going to hit you repeatedly and non-stop, instead of the precise, critical blows a human will deal.
This should be implemented eventually, but when faced with being able to customize unit attributes when deployed, it can wait, I say.
Posts: 379
Threads: 23
Joined: 29 May 2008
Reputation:
[715] the upgrade system needs improving.
[607] as the only use most people want to see from stat changes when deployed is already implemented.
MRMIdAS: No longer allowed to criticise Westwood on PPM
Posts: 322
Threads: 14
Joined: 31 Jan 2005
Reputation:
Kill #725. Ever after reviewing the idea, I still dislike it. I like my two-click Chronospheres, thank you. As such, I wholeheartedly support #725. Lifting ridiculous limits on upgrades is a far sight more useful than a Chronoshift that only needs one click. I'd say use the generic unit spawn superweapon for that if you really want it.
Support #757. I'm keen on the idea of deploying changing statistics. It's a really nifty idea that would play out well for units that change forms. People could create units reminiscent of the Jet Tengu from RA3 or the Viking from SC2. I really like that over Storage on buildings. However, I do still like #607 for that classic-style projects.
I'm what Willis was talkin' about.
Posts: 1 033
Threads: 38
Joined: 23 Jan 2005
Reputation:
I agree that Upgrades could do with improvements, certainly a far better request than single-click Chrono Sphere. If we could have a working Stargate superweapon instead (which I believe we have a request for now?) then that would rock!
Ever wondered what the hell is going on?
Believe me friend you're not the only one.
--Lysdexia
Check out Launch Base for RA2/YR - http://marshall.strategy-x.com
Also home to the Purple Alert mod, 1.002 UMP, and the YR Playlist Manager.
Posts: 55
Threads: 2
Joined: 4 Aug 2009
Reputation:
Once again, why don't we restore the old logics rather than implement a totally new feature that is going to see limited use for like 1 or 2 units in 3 or 4 mods. I say storage.
Posts: 1 921
Threads: 273
Joined: 21 Nov 2004
Reputation:
Administrative Notice:Since the last post in this discussion was three days ago, it is assumed to be over. We will proceed to judgement.
Forum Rules
(01.06.2011, 05:43:25)kenosis Wrote: Oh damn don't be disgraced again!
(25.06.2011, 20:42:59)Nighthawk Wrote: The proverbial bearded omni-bug may be dead, but the containment campaign is still being waged in the desert.
Posts: 222
Threads: 9
Joined: 16 Feb 2010
Reputation:
Fight 1
This fight is rather easy, considered we are in round 3 already. The Chronosphere is useful for several people, but the upgrades are far more important and definitely more versatile. Upgrades are rather uninteresting right now, as they were only used to provide power, a weapon or super weapon. Extending this to remove upgrade limitations is by far the better choice.
Fight 2
This one is hard. The proposed way deployer stat changes should be implemented is not the best, but rather the worst thing to achieve the effect. Every tag has to be duplicated and every occurrence in the game has to be altered. I'd rather see this implemented like a versatile DeploysInto= type change.
Silos are annoying. Yes, all previous C&C games had them. And no, they didn't help to reduce rushing at all. The first C&C games even favoured rushers: It was easier for them to destroy an enemy bases if player's concentrated on building silos instead of tanks. EVA nags people who didn't care every few seconds to build silos.
Seeing the supporters the Storage= tag has and the crappy implementation proposition of the deployer stat changes, i'd say: Silos needed.
Posts: 1 921
Threads: 273
Joined: 21 Nov 2004
Reputation:
Fight 1
I maintain what I said last time: Anyone calling the #725 Chronosphere "inferior" clearly hasn't played Space Marines in DoW.
This fight is problematic for a simple reason: Both requests are for bad versions of logic requested better or more comprehensively elsewhere.
I will code a long-range building to building transport system for tunnels anyway. iow, there will be a system where units enter a building and get transported around the map anyway. Making it so they can appear anywhere and not just at a second building is a comparatively minor change. Sure, it would lack the super weapon icon, and it might need a rate limiter for the "free" version, but it'd essentially be the same.
Upgrades, on the other hand, are far better extended through a variant of #596 than through #715. If you're extending upgrades anyway, why limit yourself to the previous limits? Allowing everything flag to be overridden makes way more sense, and is how it should have been all along.
So which one to choose? I'll just pretend I don't know what I just said.
Pretending that neither issue has "alternative options", #715 is by far the more important request, and far more likely to be used by the community at large.
Thus, it wins.
However, should #715 ultimately survive and/or be the only upgrade-improval-issue, it should really be replaced by/merged into #596.
We shouldn't pick the dumb version of doing this just because the smart way accidentally got killed.
Kill: #725
Support: #715
Fight 2
Actually, I found this one rather easy to judge - just hit the [End] key on your keyboard.
#757 Deployer Stat Changes has exactly 1 supporter right now.
#607 Enable Storage= on buildings has 11.
Even if you were completely evil and divided support by the number of opponents (2), #607 would still have five times as much community support as #757.
Add to that that I prefer the #440-style "allow anything to deploy to anything" variant anyway, as it would allow to override pretty much any value, and there really wasn't much of a fight here.
Kill: #757
Support: #607
Forum Rules
(01.06.2011, 05:43:25)kenosis Wrote: Oh damn don't be disgraced again!
(25.06.2011, 20:42:59)Nighthawk Wrote: The proverbial bearded omni-bug may be dead, but the containment campaign is still being waged in the desert.
|