DFD: 914 vs. 392, 283 vs. 602

[Renegade]

Clearly military-grade laptops are the only platform to play RTSs on!

In all honesty, I find these issues all to be mediocre, and I expect any of them to become cannon fodder in the next round.

Fight 1

---

#392 calls itself a workaround in the issue. That's a warning signal right there. And it only goes downhill from there. Sure, it would enable the modder to hack together a credible replacement for temporal weapons, but at what price? There are reasons all of the proposed overridable flags are on the unit - outside of hacks like that, it makes no sense at all to have the weapon dictate how an object looks when it dies - at least not in a generic, one-size-fits-all way.
#392 defeats the purpose of flags like DestroyAnim and Explosion.

That, and what Alex said - adding a new feature to hack around an existing issue is not better, it's worse than before.

It took reaperrr's explanation for me to even be able to think about #914, and overall, in spirit, the issue has merit.
The problems I'm seeing are the following:

• Implementation extent: This is kind of an all-or-nothing feature. The more realistic you make this, the more visible it'll be when it's not used. So you end up in a situation where, to be 100% consistent, all weapons would have to be inaccurate. That's undesirable.
  
• It doesn't actually make sense with Inaccurate=yes: If you hit, you hit. If you don't hit, you don't hit. It doesn't make sense to reduce the damage when you hit based on the number of shots which should theoretically miss the target, when the weapon just actually did that exact same thing. Basically, if the projectile has Inaccurate=yes, you'd be simulating the effect you already simulated, and simulate additional misses in case of hit. Which makes no sense.
  
• It doesn't make sense visually with Inaccurate=no: Now, if you don't have Inaccurate on, the idea makes more sense - since no shots actually miss, you "have to" simulate the misses there should be.
  ...but there are none, really.
  A tank shoots 10 times on a GI. The tank hits 10 times because that's how the engine works. The user sees all 10 shots hitting the GI.
  ...and yet, you deduct 75% of the damage, because "the GI is too small and too quick to hit"?
  It doesn't make sense. The user just saw a 100% hit rate, so you can't tell him the shots missed.
  
• It doesn't make sense visually with Inaccurate=yes, either: Same thing, but the other way round - the user just saw the shot miss, why are you applying damage?
  
• The flag is actually superfluous: Foundation= and Size= already declare how large objects are, and have so for over a decade. Since size has been the go-to example as a justification for this flag, the flag itself is actually irrelevant. The same effect could be achieved more consistently by using Size straight, or maybe Size with a *Type coefficient. If your sole desire is to influence hit probability based on size, then it makes most sense to base hit probability on Size=, not on a random new flag that is totally detached from the size the game uses for all other purposes.
  

The idea behind this is nice. It's true - the probability that you hit a GI should be lower than that you hit an aircraft carrier.
But you are trying get the wrong thing implemented.
Write the actual request out in simple terms, and what does it become? "The damage objects receive should be altered based on this new flag."
That is the request. Yes, in some metaphysical fantasy area, in an out-of-game manual explanation, this is related to accuracy and size, but as the request is phrased and supported, nothing in it actually has to do with accuracy or size. It's more like an additional unit-side universal Verses value.
And that is why it makes little sense in practice.

What you actually want is a system that tells the game "despite this shot having missed according to the engine, count it as a hit, because the unit is fat".
A collision model, essentially. "If this impact is within Size * TypeCoefficient cells from the unit center, apply damage as usual".

But that is not what the request is. The request does something fundamentally different: It adjusts damage values no matter what, and constantly at inappropriate times.

And as such, while I agree that the problem highlighted is unfortunate, I cannot support the proposed solution, simply because it is not a solution to the problem.

Which means I'm stuck supporting cheap hacks defeating the purpose of other features. Hooray.

Kill: #914
Support: #392

Fight 2

---

I find the argumentation that "the game wasn't build to have stealth generators" rather spurious, considering the fact that there is a BuildingType-only flag called "CloakGenerator", which was put to that exact use in Tiberian Sun.
Sure, one could split hairs now and say "yes, TS was built for it, but not this game!", but whatever. The fact of the matter is, the fact that stealth lags doesn't have anything to do with whether it's supposed to be there or not. Especially not considering that subs use stealth, and that translucent SHPs lag as well - is anyone gonna argue the game wasn't built for translucent animations, simply because they lag?

Lag is not an implementation problem. It's as simple as that. Yes, giant stealth generators will lag more than small stealth generators, no matter their base level of lagginess. But that's not our problem - that's the modder's problem, or the user's problem. If the modder is aware of the problem, and still wants the feature, that's his good right.

And therein lies the problem with the argumentation against 283 - it's purely based on "they will lag". There is no actual argumentation against the concept. Some at least went one step further and asserted that the lag issue would lead to less usage, but that's not worth much, either - since we don't have any basis to judge 602's potential usage.
While it's certainly true to say "since they lag, less people will use giant cloak generators", on what grounds does one claim that turret compression on tanks will be used more?
And, hell, on what grounds are you sure making the game calculate a shitload of position changes on dozens of tanks every frame isn't going to lag?

The whole "cloak generators lag, therefore #283 will be used less" argumentation has one significant flaw: We're not talking about cloak generators themselves. We're talking about runtime radius adjustments.
If a modder has already decided he wants cloak generators, and he has already decided he wants to offer greater cloak radius for more energy, nothing stops him from simply making a second building that takes more power and provides a greater radius.
Point being: The likelihood that somebody decides cloak generators themselves are okay, but upgradeable cloak generators lag too much is very small. Especially considering that cloak size is dependent on what the user wants to cloak - if the user wants to cloak his base, the amount of cloak used will be dependent on the size of his base, not on the availability of cloak generator extra functions. If the cloak generator's radius is too small, he'll just build multiple and cover the exact same area.

Your lag-based arguments may be true for cloak generators in general, but this issue isn't about cloak generators in general. It's about a feature for people who have already decided to use cloak.
So what speaks for #283? Consistency. There are two big systems of disguise in the game (cloak and shroud), both offer a system to create area-disguise from a building, but only one offers the ability to extend the area if enough power is available.
It makes sense to add the same functionality to the other system so both are equally usable.

There's not much to say about turret compression, really.
It's a graphical feature. It'd look neat. That's about it. No functional difference in the game.
It's also limited to a small set of cases - only turreted/barreled VehicleTypes with recoil-producing weaponry could really make use of this.
How many are that? Lasher, Rhino, Apoc, Siege Chopper, Grizzly, Robot. That's about it. Destroyer doesn't have a turret, Tank Destroyer doesn't have a turret. Maybe the IFV in some modes.

Sure, mods can add more. That's not the point. The point is putting the number of usable cases in perspective. It's not like this is a super-feature that will magically improve the look of all units in the game. Out of four object classes, it's only (newly) usable in one, and even in that one class, it will only be used in a subset of cases.
So it's a neat little change on a small subset of units.

That doesn't necessarily mean it's bad or invalid, quite the opposite - I'm sure it'd look great ingame.
I'm just saying, in terms of overall change to the game, it's not any higher than #283.

#283 would be a neat little change on a small subset of mods using cloak generators.
#602 would be a neat little change on a small subset of units.

And if it's little change either way, what's tipping the scale for me is consistency - making stealth generators equal to gap generators in functionality.

Kill: #602
Support: #283