[Mastadon]

Hi SCP coders!

I've been following the Source Code Project for a while now and have decided that I'd like to join in on the fun.

For my first contribution to the SCP community, I present to you a patch that causes swarm missiles to lead to their target.

[attachment deleted by a ninja]

[niffiwan]

Thanks for the patch, however this would change balance fairly significantly - why use harpoons when you've got lead-tracking hornets?   This would be more useful as a weapon flag that could modify the behaviour of swarm missiles.  Having said that, there is the corkscrew flag which effectively gives lead-tracking "swarmers", albeit with slightly different launch characteristics.

If you're keen on joining the SCP, we like bugfixes, some of these would be useful to look at   

http://scp.indiegames.us/mantis/view.php?id=2649
http://scp.indiegames.us/mantis/view.php?id=2637
http://scp.indiegames.us/mantis/view.php?id=2605

[Dragon]

Actually, this has already been implemented. +Target Lead Scaler: controls whether a missile leads it's targets, lags behind or just uses pure pursuit path.

[General Battuta]

I think there's a more general note to be made about the aims of the SCP here - it's a core rule of the project that nothing should ever change retail behavior by default.

Creating a system that would allow modders to make Hornets fly lead pursuit if they wanted is, of course, totally cool. It just shouldn't be on by default.

[Dragon]

Agreed. Though you should also check if the system you're trying to implement doesn't already exist (which is the case here, since +Target Lead Scaler: does exactly the same thing as this, except it allows more customization).

[General Battuta]

Agreed. Though you should also check if the system you're trying to implement doesn't already exist (which is the case here, since +Target Lead Scaler: does exactly the same thing as this, except it allows more customization).

I'm sure that's a really encouraging thing for a new coder to hear. Please be more considerate.

[Goober5000]

Welcome Mastadon!

For my first contribution to the SCP community

Ooh, you have more?

[Mastadon]

Thanks for the patch, however this would change balance fairly significantly - why use harpoons when you've got lead-tracking hornets?   This would be more useful as a weapon flag that could modify the behaviour of swarm missiles.  Having said that, there is the corkscrew flag which effectively gives lead-tracking "swarmers", albeit with slightly different launch characteristics.

If you're keen on joining the SCP, we like bugfixes, some of these would be useful to look at   

http://scp.indiegames.us/mantis/view.php?id=2649
http://scp.indiegames.us/mantis/view.php?id=2637
http://scp.indiegames.us/mantis/view.php?id=2605

The biggest reason you would still want to use harpoons over hornets are when you are dogfighting fast and maneuverable targets, such as Manticores and Maras. Another reason why Harpoons still remain an essential part of a fighter pilot's missile diet is that even with hornet's "leading" their target, they are still inherently inaccurate due to the fact that the swarming code has the swarm missile turn towards the homing position plus certain vector offsets from the homing position as determined in the swarm_update_direction(*objp, frametime) function. In my field testing of the new swarm tracking code, hornets still routinely miss fast and maneuverable targets such as Manticores due to the fact that the swarm missile is never truly turning towards the intended homing position. The fact that swarm missiles are never fully turning towards the homing position also causes it to occasionally miss larger targets, such as moving freighters and possibly moving light cruisers.

In short, if you load up a heavy assault fighter with nothing but hornets thinking you'll never need the fast, nimble, and accurate punch of a harpoon missile, you'll be in for an unpleasant surprise when you try and dogfight anything faster than a Basilisk.

I'll respond to some of the other comments in separate posts.

[Dragon]

Still, it alters the way gameplay works, and this is generally what SCP tries not to do. None of SCP modifications actually alter retail behavior by default, only add options for mods to enable. To think of it, this could come in handy as AIProfiles flag. It'd certainly save people some hassle with defining the lead scaler for a large number of different missiles, in case of TC mods which are not constrained like SCP is.

[The E]

If this is going to be a flag, weapons.tbl is the logical place to put it in.

[Mastadon]

Actually, this has already been implemented. +Target Lead Scaler: controls whether a missile leads it's targets, lags behind or just uses pure pursuit path.

I did some checking on how the +Target Lead Scalar flag is implemented and discovered that the parse_weapon(subtype, replace) indeed processes the +Target Lead Scalar flag at line 1605 of weapon.cpp (as of r8789):

Code: [Select]

if (optional_string("+Target Lead Scaler:"))
{
stuff_float(&wip->target_lead_scaler);
if (wip->target_lead_scaler == 1.0f)
wip->wi_flags2 &= ~WIF2_VARIABLE_LEAD_HOMING;
else {
wip->wi_flags2 |= WIF2_VARIABLE_LEAD_HOMING;
wi_flags2 |= WIF2_VARIABLE_LEAD_HOMING;
}
}


The variable the target lead scalar gets stored to (wip->target_lead_scalar, I think) is utilized at exactly one point in the weapon_home( *obj, num frame_time) function: at line 4277 (again, as of r8789):

Code: [Select]

// Only lead target if more than one second away.  Otherwise can miss target.  I think this
// is what's causing Harbingers to miss the super destroyer. -- MK, 4/15/98
if ((old_dot > 0.1f) && (time_to_target > 0.1f)) {
if (wip->wi_flags2 & WIF2_VARIABLE_LEAD_HOMING) {
vm_vec_scale_add2(&target_pos, &hobjp->phys_info.vel, (0.33f * wip->target_lead_scaler * MIN(time_to_target, 6.0f)));
} else if (wip->wi_flags & WIF_LOCKED_HOMING) {
vm_vec_scale_add2(&target_pos, &hobjp->phys_info.vel, MIN(time_to_target, 2.0f));
}
}


The wip->target_lead_scalar variable is used to modify a local, l-valued vec3d called target_pos, which is later used at line line 4324 (again, r8789) to turn the missile to the leaded target:

Code: [Select]

if ( wp->swarm_index < 0 ) {
ai_turn_towards_vector(&target_pos, obj, frame_time, wip->turn_time, NULL, NULL, 0.0f, 0, NULL);
vel = vm_vec_mag(&obj->phys_info.desired_vel);

vm_vec_copy_scale(&obj->phys_info.desired_vel, &obj->orient.vec.fvec, vel);

}

However, in the unpatched code, the target_lead_scalar is never used again anywhere else in the codebase---I know because I used grep -n 'target_lead_scaler' $(find . -type f) inside the code directory of the project to find all usages of the target_lead_scalar attribute. This would mean that even if a swarm missile supplied this flag it would never actually be leaded towards the target. That's what my patch fixes:

Code: [Select]

if ( wp->swarm_index < 0 ) {
// ...

}
    else {
        // Mastadon: store target_pos back to wp->homing_pos so that the swarm_update_direction(*objp, frametime) code does it's
        //           magic on the _leaded_ values for the target, not the _actual_ target, since we want the swarm missile to
        //           actually lead into the target, not vainly aim directly at the ship.
      wp->homing_pos = target_pos;
    }


[Mastadon]

I think there's a more general note to be made about the aims of the SCP here - it's a core rule of the project that nothing should ever change retail behavior by default.

Creating a system that would allow modders to make Hornets fly lead pursuit if they wanted is, of course, totally cool. It just shouldn't be on by default.

I read The cardinal rule and other "read me first" posts too, but in this case I always felt that swarm missiles not even trying to lead their targets to be a bug in Freespace since FS1, and therefore felt that my patch would be fixing a fundamental flaw in how the retail engine treats swarm missiles rather than merely changing an intended behavior of FS2 retail.

But the more I think about it and the more I read comments from other members, the more I tend to agree with the critics: this sort of fix should only be turned on via a command-line flag, since it, even though arguably fixes a bug in the FS2 retail engine, results in significant gameplay changes from FS2 retail.

[Kolgena]

Remember that what we think is a fundamental flaw can massively change game balance, probably making certain campaign missions literally impossible to complete.

Think of how Trebuchets are utterly broken in that AI can't use them against any targets. However, someone in the past "fixed" this, at the cost of making shivan fighters (most of which pack trebs by default) insanely overpowered. That "fix" didn't last very long.

[headdie]

Though there are others, there are 2 key reasons why the rule exists.

1st the retail campaign was balanced with these bugs in place so by fixing them you start unbalancing the campaign and with things like missiles where the AI uses the same missiles it wont always be in the player's favour.

2nd if you allow "bug fixes" to affect retail, where do you draw the line between fundamental flaw and minor irritation?

By abiding by the rule you change nothing in the campaign so when we all replay it it is as we remember it and when new players find the game they have the same experience we all did.

edit:

and as Kolgena says you dont risk breaking the campaign

[General Battuta]

You might even be right about swarm behavior being a bug, but unfortunately there are a lot of weird behaviors in FreeSpace that might well be bugs, but which we still can't just out-and-out fix because they might alter gameplay balance. For example, at one point I believe it was concluded that beams piercing shields was a bug - but this 'fix' was quickly reverted because it altered the balance of many missions.

Fortunately we aren't in the completely idiotic position of being unable to fix anything; we just allow the fixes to be swapped on by modders. We try to avoid command-line flags that are set on the user side. Instead, flags set in weapons.tbl entries (for an individual weapon), AI profile entries (for global mission behavior), or mod.tbl (for an entire mod) allow content designers to control these features without worrying about whether a user has entered the right command line flag.

[Dragon]

However, in the unpatched code, the target_lead_scalar is never used again anywhere else in the codebase---I know because I used grep -n 'target_lead_scaler' $(find . -type f) inside the code directory of the project to find all usages of the target_lead_scalar attribute. This would mean that even if a swarm missile supplied this flag it would never actually be leaded towards the target. That's what my patch fixes:

Ah, so you mean that your patch makes +Target Lead Scaler: apply to swarm missiles, which it didn't do before? That part is definitely worth implementing, if I understood it right.

[Legate Damar]

Why can't the ai use Trebuchets?

[Kolgena]

Indeed. I can see mods enjoying the ability to have swarm missiles lead without doing funky corkscrew acrobatics.

AI can't use trebs because the missile has conflicting flags telling AI to:
1.Only use it on cap ships. (more accurately described as never using it against anything fighter or bomber-sized)
2. Only use it on bombers.

[Mastadon]

However, in the unpatched code, the target_lead_scalar is never used again anywhere else in the codebase---I know because I used grep -n 'target_lead_scaler' $(find . -type f) inside the code directory of the project to find all usages of the target_lead_scalar attribute. This would mean that even if a swarm missile supplied this flag it would never actually be leaded towards the target. That's what my patch fixes:

Ah, so you mean that your patch makes +Target Lead Scaler: apply to swarm missiles, which it didn't do before? That part is definitely worth implementing, if I understood it right.

If I understand the codebase properly---and that's a big if---yes, my patch causes the +Target Lead Scalar to apply to swarm missiles, which are currently not applied to swarm missiles.

However, before doing an "svn ci" on this patch, I think that we should consider what Kolgena, headdie, and General Battuta are saying here: that by fixing this apparent bug, we may wind up completely destroying the balance of both 's campaigns and community campaigns that implicitly rely on swarm missiles not being able to reliably hit a target moving faster than a cruiser.

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?

[Kolgena]

I'm not a coder, but from what I know, the table option is vastly preferred over launcher flags, which are never used for gameplay-changing variables (unless camera FOV counts).