Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
DFD: 708 vs. 404, 334 vs. 947
#1
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 and the schedule.

Fight 1

[0000708] Make YR use all cores of a QUAD processor vs. [0000404] Make the AI deploy stuff other than con yards

Fight 2

[0000334] Veteran ammo vs. [0000947] Allow addition, removal and configuration of theaters

By the end of the 48 hour period, 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".
A decision will be made either way, so 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! Dual M16

End: ~ 19:00, 16.07.2010.
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.
#2
Fight 1:
Can anyone guarantee that Quad-Threading would really improve performance significantly? If not, then it's too much of a "shot in the dark" to be worth pursuing. The lag under Vista/7 is annoying, but unless there's a guarantee that this would fix it, I say kill #708, support #404, since #404 would actually useful for things like Firestorm-style mobile war factories.

Fight 2: Uh, isn't #947 already implemented in the betas and just needs some testing (and potential bug-fixing)?
Anyway, #947 isn't important to me (and may be of little use without a map editor that supports this), so I say support #334, because that could actually be useful. I'm not sure if a Multiplier under [General] is the best solution, but basically it would be nice to have let's say a normal Orca with 6 missiles that is upgraded to 8 when it becomes Elite.
#3
Kill #708. The amount of shit it would take to even come close to this working would be insurmountable. If you want that, play another RTS. Being that #708 is the worst possible feature request, I support #404. Extending the AI is infinitely better than multi-core threading. Oh god, imagine debugging those IEs.

#947 would pose serious issues. If it makes it in, lovely, but I don't honestly see the need. YR already has six theaters; just extend one of those if you need one that badly. I support #334 on the grounds that it makes Ammo a more useful logic to implement.
I'm what Willis was talkin' about.
#4
Fight 1

#708 is only a dream, it would be nice, but way to complicated to add, I dont even think it would be possible to add to this engine at all. I dont know why that request is not closed yet. I want AlexB comment on this one.
So, support #404

Fight 2
Support #334
Java student.
#5
[0000404] fixes bugs in the vanilla game, making the siege chopper half useful for the AI.

With [0000947] I support the addition of theatres, removing theatres is stupid and would cause no end of problems with downloaded maps, configuring existing and new theatres is a good idea though.
[Image: MRMIdAS2k.jpg]
MRMIdAS: No longer allowed to criticise Westwood on PPM
#6
Personally, I don't have a quad core processor so I don't care about the first issue, besides, 404 seems to be a lot more useful.

Support 404. Kill 408.

Now the second one is an actual challenge, the problem is that people are overlooking the possibilities of new theaters, and really if ammo was on weapons, couldn't you just have normal and elite weapons? So all this is asking for is can we make weapons have more ammo when veteran.

Issue 334 is a joke for the reason in the above paragraph.

Support 947. Kill 334.
[Image: darkstormsmall.png]
#7
Fight 1
I think that [0000404] will help the AI a lot to use units like the commented siege chopper. [0000708] sound very laborious if it was possible. So, I support [0000404] and kill [0000708].
Fight 2
Both are good suggestions but currently exist a delevopment branch in progress about new theaters. I don't know if the DFD can affect it so by precaution I support [0000947] because is very useful to not mix multiple theaters in one single. What happens if you want add theaters that not use the same palettes of the original game? mixing multiple theaters extending one of the original theaters sounds caotic depending of the complexity of the new parts of the terrains. I preffer support [0000947] and kill [0000334].
[Image: cncr_beta_download_2.png]
5 different armies: GDI, Nod, Allies, Soviets & Yuri... & converted TS Terrain!!
#8
I think we all know where fight 1 is heading so I won't comment further on that one.

Fight 2, for 947, I agree that if what you want to add is out of the pallets of the existing theatres and you happen to want to keep them all (a stretch, I know) then yes, it would be useful. Beyond that I say extending is the way to go, so long as support for additional high bridges and possibly tunnels slots gets added at some point. Additionally, how are we going to make maps for the new terrain, anyone coding up a new map editor to address the shortcomings of FA2 any time soon? That said, I'm not too enthused about the veteran ammo concept and the new terrain configs solve the problem of no rmgmd.ini settings for desert.
#9
Fight 1
Multi-core support is hard to add to an application that is not designed with multi-core support in mind. And it should be up to impossible to add it afterwards via a bunch of hooks (and gain from it). It needs careful planning to even support doing the most simplistic things concurrently. The order things are done is not defined. Imagine two units shooting at each other. In scenario one A is destroyed by B first and B doesn't have a chance to fire in the same time because it's dead. In scenario two B shoots first. A may be destroyed by B and even if not, these scenarios are not the same, their outcome is entirely different yet equally possible. The propability to see a out-of-sync dialog approaches 1 quickly. But let's assume we're talking about campaigns and skirmish.

While it is a good idea to actually use the power of the entire processor, multi-threading will never be able to overcome shitty design. It's not supposed to do that. If you got four shovels, you just quarter the time needed (provided, you got four arms), but if you need to move a mountain, better get yourself a fricking big excavator instead. And don't even try to call for more cores as it deferres the limit of shitty design merely by a factor even though it has to be changed by magnitudes to make a difference.

Simple example (factually not 100% correct, as not every unit checks for targets every frame): For every unit (out of n) to auto-aquire a target, every enemy unit (out of n) has to be checked whether it is in range, resulting in up to n² tests. (Math guys expect 0.5n required tests for each run but that is only a factor.) Let's say n=8 (this could also easily be hundreds), then n²=64 tests. With four cores, every core gets 16 tests. If we only double the number of units (n=16, n²=256) every processor core again will get 64 tests. Instead of actually quadrupling the speed, we only accellerated it a bit. Mathematically spoken: for larger N, factors aren't worth shit if there are squares involved.

If the game runs slow with 30 units, for dual cores if will do so for about 42, for quads the limit will be 60. Ideally. Large amounts of processor power will have to be used to sync the cores. And not everything can be optimized, merely the tiniest parts. You wouldn't make your car run faster by choosing a much cooler fender sticker either. It's just not worth the hassle. While it might be hard to come up with a system to actually AI deploy stuff in reasonable places and not just once right after a unit has been created, i vote for the second issue.

Fight 2
Indeed, the custom foundations are implemented already to some degree, but I don't know what's working and what's not. And I don't know what it needs to fully support new terrain types (and to create maps for them), but as pd should have a way better grasp of Ares in general, this issue specifically and what he is capable of, the difficulty of this issue doesn't bother me. The veteran ammo issue seems rather limited and every case named so far might be sort-of resolved by having either Ammo on specific weapons (wouldn't support Veteran) or switching unit types on promotion (would support Veteran). Thus, new terrain types.
#10
Fight 1

Not much of a contest here, since I share Beowulf's assessment that it'd take a shitload of work to get #708 to work, and, more importantly, I find reaperrr's question of whether anyone can actually guarantee it'll make a difference very valid.
Alex said it well: While it is a good idea to actually use the power of the entire processor, multi-threading will never be able to overcome shitty design.

There's no proof #708 will lead to a performance improvement that warrants the work invested into it, and the work that would have to be invested is enormous.

Therefore,
Kill #708
Support #404 Feature not found?

Fight 2

Yeah...#947 is one of pd's drive-by additions. He has worked on it, there is code checked in, but I have no idea what state it is in.
While I would, on principle, be inclined to say "we already have that partially coded, no point in suspending it now", I have to admit, Blade's point is concerning me...between all the happy crying for features and the support, has anyone actually thought about how to work with these new theaters?
I don't know how FA2's support for additional theaters is...I suspect non-existent. And the only other way I can come up with right now to create a map in a new theater would be setting it up exactly like an old one, create the map in, say, temperate, and then manually switch the map over to the new theater outside of FA2.
Possible, but not exactly elegant, and a rather huge flaw in this concept.
Add to that MRMIdAS's objection that removing theaters would lead to incompatibility with a large number of existing maps, both stock and custom, and, existing code or not, while the feature itself sounds neat, it just doesn't seem to fit into the environment.

On the other hand, just as Alex said, the first thing I thought when I saw the VeteranAmmo thing was "wouldn't that make more sense on the weapon?". If #316 survives, it should be able to emulate #334 just fine, and on its own, #334 sounds rather weak, especially compared to new theaters.

So, while I do think there are severe flaws in 947's concept, I simply don't think #334 is strong enough of an issue to kill #947 for, especially considering it's supposedly already half-coded.

Kill #334
Support #947
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.
#11
Result:

Fight 1

Loser #708
Victor #404

Fight 2

Loser #334
Victor #947
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.




Users browsing this thread: 1 Guest(s)