DFD: 914 vs. 392, 283 vs. 602

[Black Shadow 750]

Umm, it might be because i never play online then. I just got an ordinary, single core laptop for £4000 that I liked the look of. It "wasn't recommended for gaming" either.

[WoRmINaToR]

holy jesus bawls, 4000?

That thing must be freakin military grade.

(Average laptops go for around 1000-1500, AFAIK)

Do you have ANY specs for it though? Can't you right click your "my computer" icon and click properties? At least give me the processor speed and RAM?

Also, playing online has nothing to do with it. Cloak generators lag even in single player. Granted my example with the player quitting involved multiplayer, that was simply for a basic comparison.

EDIT: This is starting to go off topic. Continue in PMs?

[Black Shadow 750]

*£400 sorry, reduced from 500.
Actually this is on topic since it's against the agruement of cloak generator = lag.

Windows Home 7
Inspiron 1545
Processor: Pentium® Dual-Core CPU T4400 @ 2.20GHz 2.20 GHz
Ram: 3 GB
64-bit Operating System

So yeah, no lag as of yet.

EDIT: and this is my latest, the Windows XP ran it fine as well.

[WoRmINaToR]

Okay, that is a slightly more reasonable price...

Anyways, your laptop is dual core in case you didn't already realise that, and all the other specs (RAM, Clock speed, 64bit) are normal, or even slightly below the current standard.

I honestly don't see how you could possibly get NO slowdown AT ALL from using a cloak generator.

Remember that when using the cloak generator it ONLY lags when you are viewing the transparent buildings being cloaked.

IDK man, film me a video or it didn't happen.

[AlexB]

Fight 1
I'm no friend of half-baked solutions and I rather get it right the first time. Though this isn't always possible and, for people get experience, one doesn't always have all needed information available. Issue 392 is proposed to encounter temporals not being able to support CellSpread. If we would chose this and fix it, perhaps we would later decide to create a new Temporal system that allows CellSpread. Then we still would carry a system around that is obsolete. Ok, we had freezing and chrono-erase, but what else?

On the other hand, issue 914 describes the passive version of Inaccurate=yes, how easy a unit is to hit. Of course, some sorts of damage must be exempt from this, otherwise several game functions will break (for example, Iron Curtaining infantry also deals deadly damage, if the chance is multiplied with something < 1, the unit may survive). And it doesn't make sense with CellSpread. But implementation details aside, the issue makes sense for Brutes are easier to hit than dogs. And this isn't about the weapon's spray (that will always be the same), it is about how the aiming abilities of the firer are taken into account. If a gunner shoots at a car, it will most likely be hit. If he shoots at a tin can, same distance and even with equal spray, it is harder to hit. The one with the overly complicated title.

Fight 2
This one is hard to decide for issue 602 is described weirdly and 282 might cause lag so nobody will use it. If 602 is about tank turrets shaking back when firing and slowly moving back into position, this would indeed look great. The Super Gap Range might be easy to implement and there are people saying there is no lag with others saying it is there and severely obvious. DeturretCompressOnTanks for Frames, because it potentially benefits more.

[DCoder]

For what it's worth, I'm pretty sure the cloak lag is caused by the GPU, not by e-viagra^HCPU speed.

[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

[DCoder]

#914 and #392 are both silly IMO, so I'll choose the one that's less work.

#602 appears to be user error and I want to fix the lagging crap anyway, so #283 gets my vote.

[Renegade]

Result:
[0000914] it will be ok to add a coeficient of accuarcy as default to the unit type and also an option to change it for a specific unit and [0000602] TurretDecompressFramesOn Tanks! die.