Renegade
07.07.2010, 20:21:51
I don't "hate democracy" in these matters or any other, kthx. Pure polling just simply doesn't work to decide which features to implement - as recent DFDs have proven.
Every feature is wanted. If they weren't, they wouldn't have been requested. And all features are different. So to make inclusion dependent on how many people turn up to write "I can haz feature X?" at a given time-frame is insane.
Especially if the voters utterly fail at reading the requests or thinking about the changes in practice...not that that happened in the past two DFDs...
Also, "meritocracy" is the wrong word. Geniocracy might apply.
Either way, to judgement!
Fight 1
Unfortunately, it seems wishing and planning is preferred over reading and arguing this time around. The fact of the matter is, while Marshall's suggestions are interesting and certainly a possible way to implement this, they are not part of the request.
So both of albrecht's argumentations as well as any other in that direction are moot, because they hinge on one particular implementation that is neither requested nor guaranteed in the request.
We could easily implement #757 without Marshall's suggestion, satisfying the request to the letter without providing any of the features used to argue for it here.
Unfortunately, the other argumentations for the issue are kind of thin - "allowing a unit to selfheal when deployed would be pretty cool", "#757 seems to be the only one to get my attention", "#757 has a much more practical application", "757 has IMO more modding potential".
No argumentation based on the actual request, only one example that is actually founded in the request itself, and that's just a random statement of opinion about it.
The arguments for or against #681 are of similar nature. "Kill #681. Implementation would be absurd". Really? Well alright then.
So yeah. Given that neither side is ultimately giving a good reason for choosing its issue, I'll choose this one on projected complexity and potential:
#681 would need entirely new attributes, movement states, pathfinding, etc., only to ultimately achieve a shortcut that a carryall gives just as well.
#757, as it is requested, should be comparatively easy to implement.
Kill #681
Support #757
Fight 2
While I have pretty good reasons to believe #358 isn't quite as complicated as it's made out to be, and I don't see any basis for the random claims that it's mostly a graphical thing, once again, there aren't any deep arguments for either issue, so I'm left to make up my own mind again.
Size= for units would provide exactly that - fat units. The same tanks with the same abilities as before, just larger.
Phased units will create a new variety of units with new tactical abilities, which increases the number of ways modders can change the game and gameplay.
Kill #358
Support #526
Every feature is wanted. If they weren't, they wouldn't have been requested. And all features are different. So to make inclusion dependent on how many people turn up to write "I can haz feature X?" at a given time-frame is insane.
Especially if the voters utterly fail at reading the requests or thinking about the changes in practice...not that that happened in the past two DFDs...
Also, "meritocracy" is the wrong word. Geniocracy might apply.
Either way, to judgement!
Fight 1
Unfortunately, it seems wishing and planning is preferred over reading and arguing this time around. The fact of the matter is, while Marshall's suggestions are interesting and certainly a possible way to implement this, they are not part of the request.
So both of albrecht's argumentations as well as any other in that direction are moot, because they hinge on one particular implementation that is neither requested nor guaranteed in the request.
We could easily implement #757 without Marshall's suggestion, satisfying the request to the letter without providing any of the features used to argue for it here.
Unfortunately, the other argumentations for the issue are kind of thin - "allowing a unit to selfheal when deployed would be pretty cool", "#757 seems to be the only one to get my attention", "#757 has a much more practical application", "757 has IMO more modding potential".
No argumentation based on the actual request, only one example that is actually founded in the request itself, and that's just a random statement of opinion about it.
The arguments for or against #681 are of similar nature. "Kill #681. Implementation would be absurd". Really? Well alright then.
So yeah. Given that neither side is ultimately giving a good reason for choosing its issue, I'll choose this one on projected complexity and potential:
#681 would need entirely new attributes, movement states, pathfinding, etc., only to ultimately achieve a shortcut that a carryall gives just as well.
#757, as it is requested, should be comparatively easy to implement.
Kill #681
Support #757
Fight 2
While I have pretty good reasons to believe #358 isn't quite as complicated as it's made out to be, and I don't see any basis for the random claims that it's mostly a graphical thing, once again, there aren't any deep arguments for either issue, so I'm left to make up my own mind again.
Size= for units would provide exactly that - fat units. The same tanks with the same abilities as before, just larger.
Phased units will create a new variety of units with new tactical abilities, which increases the number of ways modders can change the game and gameplay.
Kill #358
Support #526
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.