reaperrr
292
326
333
345
376
640
916
947
972
978
1044
1075
1147
953
392
475
625
979
915
292
I know that there might be several people that hold a different opinion on this, but IMO the deformable terrain was one of the most crappy and annoying features of TS. There are too few height levels and the cells are too big to make it a worthwhile addition. Also: AFAIK RA2/YR terrain lacks some of the ramp tiles TS had, so it may not even work properly without them.
326
This just adds needless complexity to the grinder logic. Just not worth the time, IMO.
333
Only survived round 1 because its opponent was even more crappy.
345
I think it's crap, and it's apparently so uninteresting that nobody has bothered voting for or against it in the community ranking, which IMO is an indicator nobody really cares.
376
As darkstorm pointed out, this can be emulated already, furthermore #957 would be able to simulate some types of weather as well.
640
I voted for this myself in round 1 because I disliked its opponent, but in all honesty, I think it has too little value to justify any of the time spent on it.
916
In my opinion, some of the arguments Ren and Alex used against SubjectToUnits ("adding realism reduces fun", for example) apply here, too. Also, it was in C&C3 and I barely noticed it there, and on top of that iirc it mostly won because its round 1 opponent was even worse.
947
In my personal opinion, this shouldn't have been part of DFD. I mean afaik, it already IS programmed and implemented by pd, just not tested (because apparently nobody seems to care that much). In any case, I think DFD should be about deciding which features should be implemented, not which implemented features should be tested (& potentially fixed). It may actually work just fine already, so it really shouldn't be allowed to progress and potentially kill other issues (not that I think it really would, but anyway).
972
What darkstorm said. Just implementing something because it makes something that is already possible a little bit more easy? Nah.
978
I think a feature that has twice as many opponents as it has supporters in the com. ranking shouldn't be considered (unless BTG decides to program this himself).
1044
In light of some of his arguments, I kinda agree with nighthawk here.
1075
are observers in network games worth as much as features that help improve mods? IMO not even remotely.
1147
I think it's just crappy, has no community support (quite the contrary, in fact) and only won because the programmers liked SubjectTo- even less.
953
As several people mentioned already, we don't need another way to alter build speeds.
392
As I wrote in Round 1 already: Except for that one scenario in the description, I don't think it's very useful.
475
Another issue that only survived Round 1 because it was up against an even weaker opponent.
625
What Renegade said.
979
What Renegade said.
915
This is a mixed bag for me. The best SHPs will always look better than the best voxels, and 32 facings would help a lot to make them look even better.
But there are two problems with this request. First, as Renegade pointed out, very few mods would actually use it, because there aren't that many skilled SHP artists who make their SHPs by rendering from 3D models (and about half of these few work on TS mods, as far as I can tell).
The 2nd problem is that the request in its submitted form is just crap. The only sensible way to implement this would be a Facings= tag in art(md).ini that can be set to 8 or 32 and defaults to 8 (obviously). But forcing people to use a certain number of facings other than 8 is completely out of question.
I wouldn't mind if it was implemented one day in the form I suggested, but by DFD standards I think it shouldn't be considered right now.
336
This an argument in support of cameo text. As Renegade said, it makes translation easier, and you don't need to edit the cameo whenever the name of the unit changes. Also, from my experience depending on how you make your cameos text editing is actually amongst the more tedious aspects. Cameo text through strings like in TS would definitely save modders a bit of work, so while it might not be the most useful request taking part in the DFD, it's definitely not crappy enough to kill it here in the Smackdown, IMO. Those who don't like will still get enough chances to kill it in the next rounds.
326
333
345
376
640
916
947
972
978
1044
1075
1147
953
392
475
625
979
915
292
I know that there might be several people that hold a different opinion on this, but IMO the deformable terrain was one of the most crappy and annoying features of TS. There are too few height levels and the cells are too big to make it a worthwhile addition. Also: AFAIK RA2/YR terrain lacks some of the ramp tiles TS had, so it may not even work properly without them.
326
This just adds needless complexity to the grinder logic. Just not worth the time, IMO.
333
Only survived round 1 because its opponent was even more crappy.
345
I think it's crap, and it's apparently so uninteresting that nobody has bothered voting for or against it in the community ranking, which IMO is an indicator nobody really cares.
376
As darkstorm pointed out, this can be emulated already, furthermore #957 would be able to simulate some types of weather as well.
640
I voted for this myself in round 1 because I disliked its opponent, but in all honesty, I think it has too little value to justify any of the time spent on it.
916
In my opinion, some of the arguments Ren and Alex used against SubjectToUnits ("adding realism reduces fun", for example) apply here, too. Also, it was in C&C3 and I barely noticed it there, and on top of that iirc it mostly won because its round 1 opponent was even worse.
947
In my personal opinion, this shouldn't have been part of DFD. I mean afaik, it already IS programmed and implemented by pd, just not tested (because apparently nobody seems to care that much). In any case, I think DFD should be about deciding which features should be implemented, not which implemented features should be tested (& potentially fixed). It may actually work just fine already, so it really shouldn't be allowed to progress and potentially kill other issues (not that I think it really would, but anyway).
972
What darkstorm said. Just implementing something because it makes something that is already possible a little bit more easy? Nah.
978
I think a feature that has twice as many opponents as it has supporters in the com. ranking shouldn't be considered (unless BTG decides to program this himself).
1044
In light of some of his arguments, I kinda agree with nighthawk here.
1075
are observers in network games worth as much as features that help improve mods? IMO not even remotely.
1147
I think it's just crappy, has no community support (quite the contrary, in fact) and only won because the programmers liked SubjectTo- even less.
953
As several people mentioned already, we don't need another way to alter build speeds.
392
As I wrote in Round 1 already: Except for that one scenario in the description, I don't think it's very useful.
475
Another issue that only survived Round 1 because it was up against an even weaker opponent.
625
What Renegade said.
979
What Renegade said.
915
This is a mixed bag for me. The best SHPs will always look better than the best voxels, and 32 facings would help a lot to make them look even better.
But there are two problems with this request. First, as Renegade pointed out, very few mods would actually use it, because there aren't that many skilled SHP artists who make their SHPs by rendering from 3D models (and about half of these few work on TS mods, as far as I can tell).
The 2nd problem is that the request in its submitted form is just crap. The only sensible way to implement this would be a Facings= tag in art(md).ini that can be set to 8 or 32 and defaults to 8 (obviously). But forcing people to use a certain number of facings other than 8 is completely out of question.
I wouldn't mind if it was implemented one day in the form I suggested, but by DFD standards I think it shouldn't be considered right now.
336
This an argument in support of cameo text. As Renegade said, it makes translation easier, and you don't need to edit the cameo whenever the name of the unit changes. Also, from my experience depending on how you make your cameos text editing is actually amongst the more tedious aspects. Cameo text through strings like in TS would definitely save modders a bit of work, so while it might not be the most useful request taking part in the DFD, it's definitely not crappy enough to kill it here in the Smackdown, IMO. Those who don't like will still get enough chances to kill it in the next rounds.