[General Battuta]

It'd be good to make sure that +target lead scalar works properly with hornets and tornadoes then, overriding default behaviors as necessary.

For instance Diaspora uses tornado flags on a bunch of weapons to give that slight trail jerkiness seen in the show on some weapons. So it'd be nice to have trailing tornadoes for some cases.

The technical terms are 'swarm' and 'corkscrew' for Hornet behavior and Tornado behavior respectively.

[X3N0-Life-Form]

As for how to go about incorporating my fix, one solution might be to add a weapons.tbl flag to swarm missiles that we want to have lead their targets. However, I personally would also like to be able to turn on or off swarm missile leading at-will via a command-line switch. So before I go off implementing one or both of these solutions, what would the SCP programmers prefer I do?

Well, I think that's the sort of things you'll want to place in ai_profiles or game_settings tables.
Something like: $Swarm_missiles_always_lead:    YES ;; default: NO

[Qent]

After a quick test, I could distinguish no difference among lead 0.0, 1.0, and 10.0 for modified Hornets, so thank you for that.

A global flag would probably belong in ai_profiles yes, but I (am not an SCP programmer) really don't like having a global flag at all. It's redundant (unlike the Treb flag) because you will also be able to set the lead scalar to 1.0.

[The E]

This flag, by necessity, needs to be a per-weapon flag.

[Sushi]

Do we really need a flag for this? What exactly will break if the lead scaler setting suddenly works as advertised for Hornets?

This seems like a straightforward fix of an oversight in the lead scaler feature. I'm pretty sure it's a 3.6.13/3.6.14 feature anyway, so we have no obligations of backwards compatibility to make us introduce yet another flag.

[Dragon]

My thoughts exactly. Just implement it as a fix to the lead scaler instead of messing around with flags.

[The E]

Do we really need a flag for this? What exactly will break if the lead scaler setting suddenly works as advertised for Hornets?

This seems like a straightforward fix of an oversight in the lead scaler feature. I'm pretty sure it's a 3.6.13/3.6.14 feature anyway, so we have no obligations of backwards compatibility to make us introduce yet another flag.

Flag, option, straight fix, whatever. As long as it is neither a global flag nor commandline option, I am happy.

[Mastadon]

Do we really need a flag for this? What exactly will break if the lead scaler setting suddenly works as advertised for Hornets?

This seems like a straightforward fix of an oversight in the lead scaler feature. I'm pretty sure it's a 3.6.13/3.6.14 feature anyway, so we have no obligations of backwards compatibility to make us introduce yet another flag.

Theoretically, a mission whose difficulty is balanced partially on the basis of Swarm-type missiles (namely, the Hornet, Hornet D, Hornet#Weak, and MX-52) not leading their targets. In practice, however, I have found in my somewhat limited testing that having swarm missiles lead their target tend to increase the combat effectiveness of the missiles from almost completely useless against anything smaller than a cruiser to being effective against anything at least as big as a heavy fighter but smaller than a corvette, with a swarm missile having limited usefulness against space superiority and interceptor class fighters.

In fact, leading swarm missiles are still largely ineffective against space superiority and interceptor class fighters due to the simple fact that swarm missiles, well, swarm rather than fly directly towards the target's lead point. Using the Hornet as an example, I estimate that with swarmers set to lead to their target, the hit rate of swarm missiles against anything smaller than a heavy fighter, outside of a head-on engagement, is roughly 10% -- 20% verses an AI opponent. In head-on engagements, the hit rate is closer to 70% -- 80%.

In summary, even with swarm missiles leading to their target, they shouldn't have too great an effect on the balance of missions...especially since enemy swarmers will lead towards you as well.

To help illustrate these changes, I've attached a couple of tbm files that use the +swarmLeadTarget sub-flag as well as a mission I designed for the explicit purpose of testing changes to swarm missile homing. I would also encourage you to test out these changes against a mission that utilizes swarm missiles heavily, such as "Into the Lion's den" (Freespace 2, 1st Shivan mission). You will of course also need to apply my swarmer patch patch and recompile FSO to do any testing.

[attachment deleted by a ninja]

[Dragon]

Sorry, but even if it doesn't change balance all that much, it's still against FSO policy. It's up to mods if the decide to make Hornets lead their target, and you can enable them to do that by simply fixing +Target Lead Scaler: for swarmers. Something that affects default behavior like that will never get into trunk.

[Goober5000]

Dragon, please stop making yourself annoying by carping on an issue that everyone is aware of.

Has anyone besides Mastadon actually applied the patch and played some tests?  I'll plan on looking at this later today, as Mastadon's latest attachments are intriguing.  At this time I think a weapons.tbl flag would be the best option.

[karajorma]

I'll see Goober's "we know about it" and raise you a "He's just plain wrong"

Sorry, but even if it doesn't change balance all that much, it's still against FSO policy. It's up to mods if the decide to make Hornets lead their target, and you can enable them to do that by simply fixing +Target Lead Scaler: for swarmers. Something that affects default behavior like that will never get into trunk.

Bollocks. Seriously Dragon, stop talking about things you know nothing about. Given that several SCP coders have already commented on how this might simply be added as a fix without any extra flags I really don't know why you think you have the authority to tell us all that we're wrong and you're right.

[NGTM-1R]

I really don't know why you think you have the authority to tell us all that we're wrong and you're right.

'cuz he's, uh, right, and you're wrong. Changing the fundamental gameplay like this has traditionally been verboten; beam fade as default got sunk over this sort of thing. Has that changed?

[karajorma]

Seriously?

You're going to contradict myself, The_E and Sushi? Even after Sushi flat out stated exactly why?

[jr2]

I think everyone needs to re-state what they are trying to say.  In very clear, concise, explaining it with triple-redundancy terms.  'Cause I think there's a misunderstanding here.  Although it might just be me...

[NGTM-1R]

Seriously?

You're going to contradict myself, The_E and Sushi? Even after Sushi flat out stated exactly why?

Yeah, though actually, I'm just contradicting you. Just like I contradicted a bunch of coders on the beam fade issue, which didn't actually break a single retail mission, but which had the potential to break missions designed for retail. In the end I was judged right there too.

The lag-pursuit curve on the Hornet is not a bug, Karaj. It's a feature of the engine. Simply because you/Mastadon/whoever doesn't like it does not change this fact.

Or are you still castigating Dragon for something that everyone was agreeing to on the first page and which the discussion has shifted away from? He's still correct here as he was, but apparently you're not paying attention to what he's actually talking about and assume it's all on this page because you can't be bothered to read.

Granted he can't be bothered to read (I think, we do seem to have moved to fixing lead scalar and away from altering classic behavior of swarm missiles, although it's hard to tell) either, but you could try perhaps explaining that to him and everyone else instead of acting like a jackass.

[karajorma]

NGTM-1R, you're wrong. The coders know you're wrong. Frankly, I don't see the need to explain why again.

I think everyone needs to re-state what they are trying to say.  In very clear, concise, explaining it with triple-redundancy terms.  'Cause I think there's a misunderstanding here.  Although it might just be me...

There's no misunderstanding. Just people who know nothing about the subject trying to act as if they do.

Dragon has argued both in favour of fixing it without any other flags and then 2 posts later argued that such a patch is impossible as soon as someone else said the same thing. NGTM-1R is just being NGTM-1R and butting in on a subject he knows **** all about after it's been it's been clearly stated that the SCP reserve the right to alter features that were added in this cycle.

[NGTM-1R]

It might help if you, you know, learned to read.

[NGTM-1R]

Because it's really sad when Goober has a better grasp of what various people are discussing than you and you feel a need to insult random people because of it.

[Zacam]

Okay, here is a nice tall frosted glass of "Everybody Chill"

Things got a bit muddled somewhere and context got lost. Dragons response of altering code not being in SCP alignment is correctly attributable to Mastadons multi-patch post that would also have deviated the behaviour of retail missiles, not just the SCP affected flag under discussion.

However: There are also many an instance where coders (and potential coder candidates) conversations get skewed by non-coders attempting to contribute in a "backseat coding" manner that usually causes frustration, -even when they may be right- by nature of them not being coders or contributors. And while we do appreciate feedback and collaboration, we don't need a non-SCP member declaring what the SCP's basic tenants are. We know what they are, we are a part of enforcing them.

Before I decide to go about with a split-lock, I'm just going to let things stand as they are. What I would like to see is the conversation retuning to a more on-Topic conversation on the related and listed patches and feedback to Mastadon on the review process of them.

[Mastadon]