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
[0000479] New tag, Target.IronCurtain= vs. [0000766] Fix so SHP errors
Fight 2
[0000286] Transform building into an other building after firering it's SW vs. [0000715] Extending Upgrades to include documented limits
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: 82
Threads: 0
Joined: 26 May 2010
Reputation:
Fight 1:
This is a no-brainer to me, kill #766. Not that I really care about #479, but:
a) #766 could be caused by some ini code
b) #766 could be caused by using the wrong SHP compression
c) even if it's something that is caused by the engine, the problem could be so deep-rooted that it requires some serious rvamping of the SHP drawing code
d) I can't remember seeing that kind of error very often (read: I never noticed it), so no matter what the cause, I don't think it's worth the effort.
Fight 2:
To me #715 sounds more useful, especially making BuildLimit and the OilDerrick function apply to upgrades. So kill #286.
Posts: 322
Threads: 14
Joined: 31 Jan 2005
Reputation:
I'd rather see both from the Fight 1 be implemented, but I have to lean towards #766 as the winner. But it's not clear cut since both have merit. Just feels like #766 would be a little better since it would at least help with preventing stupid glitchy bullshit from happening.
Kill #286. It's not really that great... but #715 is. And I think we all know why it's great. Money production via upgrades, FactoryPlant logic through upgrades, Radar, Cloning... that would be awesome.
I'm what Willis was talkin' about.
Posts: 28
Threads: 0
Joined: 19 Jul 2010
Reputation:
Posts: 453
Threads: 11
Joined: 26 Jan 2005
Reputation:
I'd consider #766 a bug fix rather than a feature request and so shouldn't really be getting pitted against features IMO.
Upgrades all teh way in the second fight, so many things that would be nice to be able to add as upgrade but can't.
Posts: 379
Threads: 23
Joined: 29 May 2008
Reputation:
23.07.2010, 21:02:15
(This post was last modified: 23.07.2010, 21:16:04 by MRMIdAS.)
[0000479] as explained in the request, if a weapon can reduce the iron curtain effect, the AI should know not to ignore the curtained unit and to fire upon it, if it goes hand in hand with the reduction tag, so be it, but a separate tag would allow stuff that doesn't reduce iron curtain time, but may apply other effects to the unit.
[0000715] would go a long way to restoring yuri to what his side was intended to be, it would also open the door to a more advanced upgrade system in the future.
MRMIdAS: No longer allowed to criticise Westwood on PPM
Posts: 573
Threads: 26
Joined: 14 Oct 2005
Reputation:
For fight one:
The first issue is a bit odd. Yes, the AI should probably keep an eye on Iron Curtained units, but I can see an issue already. If there's an Iron Curtained unit with a much higher ThreatValue in among a group of un-curtained units, the AI's going to focus all its energy on the futile effort of gleefully shooting the lone invulnerable tank while all the little surrounding tanks subsequently rip it a new one. Even if iron curtain durations are set on some weapons to be miniscule, is it really that much of a loss that the AI will stop shooting at the invulnerable unit for a mere number of seconds to focus on what it can kill?
The second issue on the other hand. If it is indeed an error with the engine, and not a problem with art code or SHP compression, I'd say it definitely should have a higher priority. While both issues are technically game bugs, it basically comes down to what's the more noticeable bug? The fact that an enemy tank will change target for a few seconds while its original is invulnerable? Or there being a large brick wall plastered across the face of your tech centre?
As such, my stance is support #766, kill #479.
For fight two:
Now, the first issue. I read a very similar issue in an earlier DFD about an hour or so ago, where the request was for a super weapon that turns its host building into a vehicle. Would it not make sense to combine the two, and merely have a super weapon that changes its host into something else of any TechnoType? As with the other issue, I can see some uses, however with this one involving buildings, the uses increase. Additionally, if such a thing were a super weapon option rather than being a type of its own (i.e. a normal super weapon could have this a side effect), then the uses go on even further. Example, if you have a building with some sort of super weapon on it. You use the super weapon once, building changes (image stays the same, but bear with me here), "new" building has a "new" super weapon - a weaker version of the original one. This in turn changes the building into another one with a weaker-still version. This goes on until eventually, you get to one with no super-weapon at all. You're then forced to find another avenue of attack rather than sit back and SW-spam all day.
Now, despite my glorifying ramble above on the merits of issue #286, the DFD in all its wonderfulness has gone and put it up against an issue of even greater merit - actually making upgrades proper upgrades. However, I think I remember a very similar issue being in a DFD not that long ago and making it through. Anyway, upgrades are something that go drastically underused because of their limitations. They can provide power, change weapons, and add another super weapon. That's it. There's no ability to have your side's radar work by upgrade (Generals China style), no way to upgrade your radar to have spysat map reveal (which would make logical sense as well as make radar structures more valuable), no way to turn your nuclear power plant into a co-dependent structure for your nuclear missile silo (which could add a new layer of strategy to base defense). Upgrades are sadly missing out on many features that would make them proper upgrades.
So with some difficulty, I'm going to have to go against my usual "I like super weapon logics" stance and say support #715, and very reluctantly kill #286.
Ares Project Manager.
Open Ares positions: Documentation Maintainer, Active Testers.
PM if interested.
Posts: 1 921
Threads: 273
Joined: 21 Nov 2004
Reputation:
Administrative Notice:Given that there have been no new posts in the past three days, it is assumed this discussion is finished; we will proceed to consider the arguments.
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
The Iron Curtain for weapons logic is not complete if the AI won't try to reduce the amount of protection time remaining for a unit. Why shouldn't a unit try to counter IC protection? If this is not implemented, even if there unit that reduce IC they won't even try.
The SHP error is unfortunate but not that important as it doesn't affect the game or its balance. Usually I vote for fixing bugs rather than adding new stuff. This time it is different for I think the IC logic doesn't work right and it could do better. This helps the player if units automatically target IC'd tanks and lets the AI act more intelligently. Thus, Iron Curtain enchancements.
Fight 2
The SW issue sounds like requesting another hack instead of fixing the original problem. Yes, it is possible to re-create the RA1 style spy sat if the building fires a missile and then turns into a building with Radar=yes and SpySat=yes. If it is destroyed, you will have to wait until it is charged again. If you build the original building, start the satellite and the building changes, you can build another original building, even if it has a build limit. No one stops you from building two buildings in the first place, only converting one. Bad.
Extending upgrades is the better alternative in this case. Several things are broken and seem hackish. The game might run a little slower as it has to check all possible upgrade slots to find what it is looking for. On the pro side it opens many possibilities to have radar and other upgrades, creating buildable oil derrics/other money generators that can be upgraded to earn more money but make an even better target for the enemies. And having upgradable tech centers that qualify as prerequisite would just be cool. Upgrades.
Posts: 1 921
Threads: 273
Joined: 21 Nov 2004
Reputation:
Fight 1
While I agree #766 is more of a bug than a feature, it comes down to what I've been telling people again and again and again and again: File your issues properly or they end up in the wrong selections.
The requester decided to file this thing as a feature request, so it'll be treated as one - and as a feature request, it's worthless.
#479 is sporting annoying dot-abuse in a flag that shouldn't exist, but ignoring the silly idea of having a flag for something that should be the normal case, the request makes sense, is narrow, has a clear, defined outcome and results in a direct improvement of the game.
It is clearly the superior choice.
Kill: #766
Support: #479
Fight 2
Oh look, more upgrade requests - since we have so few of them! I dislike voting for yet another "Improve upgrades" issue, but Alex is right - #286 is a hack and nothing more.
Kill: #286
Support: #715
Since Alex voted the same way, this is the result.
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.
|