Missile Guidance

[Steve Walmsley (OP)]

The question of missile guidance has come up once or twice recently on the forum. In addition, as I have recently rewritten all of missile movement and targeting and I am now rewriting the automated missile defence code pretty much from scratch and I am finding the current guidance a little restrictive, I am now considering changing it.

At the moment, the guidance operates on a model similar to that of semi-active laser homing, where the fire control (or laser in modern warfare) paints the target and the missile homes in on that paint. If you move the fire control (or laser designator) to a new target, the missile changes target too. While this works OK for long range anti-ship combat, I think it is possibly a little too powerful in its ability to attack one target by sending waves opf missiles until the target is eliminated and then switching any remaining missiles to a new target. Planning and executing a long-range attack is perhaps too easy because of this flexibility. It causes some problems with realistic anti-missile combat because when the parent fire control needs to engage a new target, any missiles in flight will switch targets too.

I am therefore considering changing to a model where a missile salvo is launched at a specific target and will continue to home on that target as long as it is illuminated by any active sensor. In effect, the target is locked into each missile at the point of launch. The advantage of this model (from a combat perspective) is that this would free the parent fire control to engage new targets without affecting missiles in flight. The disadvantage is that you could no longer switch targets mid-fight. You would have to assign targets on launch and try to estimate the necessary weight-of-fire. In this model, those missiles with onboard sensors would attempt to find a new target by themselves if their designated target was no longer available. Those without onboard guidance would self-destruct.

This has a few programming and gameplay advantages too. From a programming perspective, the target would always be stored with the missile and I would not have to find the associated fire control and retrieve the target from it. In gameplay terms, this will likely result in more damaged ships rather than destroying ships one by one and then leaving one damaged when missiles ran out. It will also require much more careful consideration of target allocation.

One potential issue is ECM vs ECCM. At the moment, ECCM is associated with a particular fire control system and missiles benefit from that ECM. If missiles are not linked to a particular fire control, they would gain no direct benefit and would therefore suffer against ECM protected targets. There are several options to resolve this:

1) Accept this disadvantage.
2) Assume that the fire control imparts any associated ECCM benefit to the missile at the point of launching
3) Disassociate ECCM systems from fire controls and direct them against specific enemy ships to reduce their ECM
4) Make onboard EW for missiles much cheaper and less mass-intensive
5) Bring forward the whole planned EW rewrite

I am interested to hear comments and suggestions on this proposal

Steve

[Erik L]

I'd vote option 3 short term and option 5 for long term

[Steve Walmsley (OP)]

I am therefore considering changing to a model where a missile salvo is launched at a specific target and will continue to home on that target as long as it is illuminated by any active sensor. In effect, the target is locked into each missile at the point of launch. The advantage of this model (from a combat perspective) is that this would free the parent fire control to engage new targets without affecting missiles in flight. The disadvantage is that you could no longer switch targets mid-fight. You would have to assign targets on launch and try to estimate the necessary weight-of-fire. In this model, those missiles with onboard sensors would attempt to find a new target by themselves if their designated target was no longer available. Those without onboard guidance would self-destruct.

I have just thought of a slight refinement to this idea which is a little more realistic but has the same results. As above the target is locked at the time of launch but the fire control continues to provide updates on the target location (using data from any available active sensors). If that fire control is destroyed, the missiles will lose track unless they have some form of onboard guidance. While doing that, the fire control can also be launching missiles against other targets. In game terms this works almost identically to the above but provides more of a reason for the fire control to exist beyond the initial launch. In effect, a fire control gains the ability to track and engage multiple targets and loses the ability to change the target of any individual salvo mid-flight. The missile salvo still contains the target information and I still don't have to check the fire control during flight because the target doesn't change. As long as an active contact still exists I can assume the information is being passed to the missile. The only thing I need to do is unset any target information for missiles in flight if the parent fire control is destroyed.

The other advantage is that with this model any ECCM of the fire control can still be used at the point of attack if the fire control is in range.

Steve

[Steve Walmsley (OP)]

Hmm! Forget my babblings about ECCM as for missile combat it affects the range at which the fire control will function, not the chance of a successful hit

Steve

[sloanjh]

The model had always seemed more like command/data-link guidance (or wire-guided for torpedoes) to me; where the fire control uses a command channel to the missile in order to guide it to the target.  Semi-Active homing hasn't ever struck me as realistic because you'd have to have a pretty sensitive seeker head (read "big and expensive") on the missile in order for it to pick up the energy reflected from a target 40M km away.

IIRC, this model is how the Aegis system works - the system uses a datalink to navigate missiles to the vicinity of the target, then the fire-control illuminators (SPS-62???) are used for Semi-active terminal homing.  I think the system can also steer (using datalink) missiles fired from launchers on other ships.  I think the intent was that incoming missile salvos could be engaged exactly as is the current Aurora behavior - missiles that are in flight can be redirected at other targets if their initial target is destroyed.

So I guess my two observations from the above are:

A) it seems like firing at waypoints are used a lot IRL (in order to get the missile to a position where its seeker head is powerful enough to "see" the illuminated target)

B)  Missile systems seem to gravitate towards either fire-and-forget (on-board seekers) or command guidance (allowing mid-flight course corrections) IRL.  This seems like something that could have a tech sequence associated with it.

Suggestion (x3):

1)  What you've described already in this thread.  This seems like a "playability/game mechanics" shift, i.e. you think missiles are too powerful and want to weaken them a bit and/or it's easier to code up that way.  Re-reading the thread, I wonder if this might actually make missiles more powerful, since you now only need to mount a single fire control to engage multiple targets.  

2)  Add a "seeker" component(s) to missiles, which can either be inertial (only good for firing bouys, or possibly for planetary bombardment), Semi-active, active, command, .... and make a semi-active homer that can see a long way expensive in mass (so that you'd either have to have a good guess for a waypoint or a command link on board as well.  The advantage I can see here is that it breaks the scale invariance for missiles, i.e. the guidance package subtracts less of the warhead weight from a size-6 missile than from a size-2 missile.  The downsides I can see are that it would probably result in a lot of micromanagement of missile engagements, and that it would probably be a nightmare to code up all the different combination of seeker heads.  Another upside might be a "realistic" progression of guidance capabilities.

3)  Add a "switching time" tech for fire control, e.g. starting at 30 seconds, then 15 or 20 then ....  The harsh version would be that any missile that is launched before a switch and engages its target less than "switching time" after the fire control switched to that target will automatically miss (and be consumed).  This would drive players to space their missile salvos by the switching time, to give follow-on salvos time to be redirected towards survivers of an initial strike.  The upsides I see are that it gives the benefit you're looking for (in fact, I think it's probably just a refinement of #1, but without the multiple targets per fire control issue) without a lot of micromanagement, but with the ability at higher techs to get back to the current behavior.  The downside I see is that some way will need to be found to manage both anti-missile and anti-ship mechanics using the same framework (since anti-missile needs much more agile switching).  BTW, the non-harsh version would be simply to have missiles already in flight to just "freeze" onto their current course and speed for the switching time, which could cause them to overfly the target.  I don't like this one, though, 'cuz the idea of missiles that overfly turning around and chasing the target just doesn't seem right to me....

John

[sloanjh]

Hmm! Forget my babblings about ECCM as for missile combat it affects the range at which the fire control will function, not the chance of a successful hit :-)

BTW, if I put two "ECCM-1" units on a ship, does it do any better?  Is there a posting somewhere in mechanics that I've forgotten?

John

[Steve Walmsley (OP)]

The model had always seemed more like command/data-link guidance (or wire-guided for torpedoes) to me; where the fire control uses a command channel to the missile in order to guide it to the target.  Semi-Active homing hasn't ever struck me as realistic because you'd have to have a pretty sensitive seeker head (read "big and expensive") on the missile in order for it to pick up the energy reflected from a target 40M km away.

IIRC, this model is how the Aegis system works - the system uses a datalink to navigate missiles to the vicinity of the target, then the fire-control illuminators (SPS-62???) are used for Semi-active terminal homing.  I think the system can also steer (using datalink) missiles fired from launchers on other ships.  I think the intent was that incoming missile salvos could be engaged exactly as is the current Aurora behavior - missiles that are in flight can be redirected at other targets if their initial target is destroyed.

Perhaps one option is to go with what I have described above but allow a mid-course guidance correction to be issued to missiles. For that to happen, the missile itself would have to have some type of onboard system (maybe 0.2 MSP) that could accept such updates. This would be different to the existing situation because it would not affect the ability of the fire control to continue engaging different targets. However, this would restore the ability to launch a a large wave of missiles and sort them out later as targets were destroyed, which is one of the things I was trying to avoid. One of the reasons I think the too-flexible situation exists because while a Harpoon or an SS-N-19 will look for targets along a path, Aurora missiles can currently stop for a while, or turn around and come back. Maybe I need to resolve that particular problem somehow.

I have been reading through an older version of Jane's Strategic Weapon Systems, which includes a lot of information on many anti-ship missiles. As you mentioned, a lot of them use inertial guidance to reach a certain point and then active radar homing. I could implement something similar using waypoints but its a lot more difficult to make that work with the Aurora model than in modern naval combat, mainly because modern missiles can be 50x faster than their target so that target will not move that far, relatively speaking, while the missile is en route. In Aurora, the missiles may be only 4-5x faster than the ships so the ships can move a great distance while the missiles are in flight. The other difference is that on water two ships will probably not have each other on radar so some form of intertial guidance plus active homing is necessary. In space, the ships can easily see one another.

So I guess my two observations from the above are:

A) it seems like firing at waypoints are used a lot IRL (in order to get the missile to a position where its seeker head is powerful enough to "see" the illuminated target)

B)  Missile systems seem to gravitate towards either fire-and-forget (on-board seekers) or command guidance (allowing mid-flight course corrections) IRL.  This seems like something that could have a tech sequence associated with it.

Based on what I have read about modern missiles, I tend to agree. As I mentioned above, although Aurora has a lot of similarities to modern naval warfare there are one or two significant differences, so I think the key issue is to find a missile model that works within the game but has some resemblance to our own reality to make it easier for players to accept. I don't think I want to go down the waypoint/inertial + active homing route because of the potential micromanagement issues and the relatively low speed differential between ships and missiles.

Suggestion (x3):

1)  What you've described already in this thread.  This seems like a "playability/game mechanics" shift, i.e. you think missiles are too powerful and want to weaken them a bit and/or it's easier to code up that way.  Re-reading the thread, I wonder if this might actually make missiles more powerful, since you now only need to mount a single fire control to engage multiple targets.  

Well, you can do that now if you send several waves and change targets as soon as the first ship is destroyed. With the new model, you have to decide up front how to allocate missiles so I think we would see more overkill in some cases, a far higher proprtion of damaged ships to destroyed ones and a lot more caution in firing off all available missiles.

2)  Add a "seeker" component(s) to missiles, which can either be inertial (only good for firing bouys, or possibly for planetary bombardment), Semi-active, active, command, .... and make a semi-active homer that can see a long way expensive in mass (so that you'd either have to have a good guess for a waypoint or a command link on board as well.  The advantage I can see here is that it breaks the scale invariance for missiles, i.e. the guidance package subtracts less of the warhead weight from a size-6 missile than from a size-2 missile.  The downsides I can see are that it would probably result in a lot of micromanagement of missile engagements, and that it would probably be a nightmare to code up all the different combination of seeker heads.  Another upside might be a "realistic" progression of guidance capabilities.

You can do all of that now. It is possible in v4.0 to add active, thermal and EM sensors to missiles. If they lose shipboard control, they will home on any targets detected by their onboard sensors. However, what I don't want to do is add some type of super-sensor to missiles that isn't available anywhere else. If it will fit on a missile, then it has to be the same size on a ship.

3)  Add a "switching time" tech for fire control, e.g. starting at 30 seconds, then 15 or 20 then ....  The harsh version would be that any missile that is launched before a switch and engages its target less than "switching time" after the fire control switched to that target will automatically miss (and be consumed).  This would drive players to space their missile salvos by the switching time, to give follow-on salvos time to be redirected towards survivers of an initial strike.  The upsides I see are that it gives the benefit you're looking for (in fact, I think it's probably just a refinement of #1, but without the multiple targets per fire control issue) without a lot of micromanagement, but with the ability at higher techs to get back to the current behavior.  The downside I see is that some way will need to be found to manage both anti-missile and anti-ship mechanics using the same framework (since anti-missile needs much more agile switching).  BTW, the non-harsh version would be simply to have missiles already in flight to just "freeze" onto their current course and speed for the switching time, which could cause them to overfly the target.  I don't like this one, though, 'cuz the idea of missiles that overfly turning around and chasing the target just doesn't seem right to me....

While I like the principle, it would raise the question of why a missile can be assigned instantly while on board ship but takes 30 seconds to reassign while in flight. However, if we can come up with a suitable technobabble explanation, some type of a limited mid-course guidance ability with a restriction on its use could be a good addition to the proposed new model.

The more I look at the code and the implications, the more I prefer the idea of missiles launching with an assigned target, the fire control being able to engage multiple targets and the missiles being unable to change targets, or at least have a limited ability to change targets. It makes life easier in many ways, both for me and for players, and it seems more realistic. Going back to my mention of the Harpoon looking for targets along a fixed path, I will code it so that if a missile's original target can longer be found but it does have onboard sensors, it will continue on course to the last known target location. As it moves along that course, the sensors will look for potential targets. That will give it more chance of spotting a new target without the need for shipboard control and it will have some similarity to the inertial/active homing model. Also, because it's likely the missile is most of the way to its original target at this point, there is a much better chance of finding a target than if was using a inertial/active homing model from the point of launch. This could mean that many long-ranged anti-ship missiles would be built with some form of onboard sensor, even a small one, as a backup.

Here is an example using current Commonwealth missile tech and the existing v4.0 missile design code. The first missile uses a split of 2 / 1.2 / 0.8 for warhead, engine and fuel and has no onboard guidance. The second and third use 10% of the missile size for an onboard sensor, reducing the warhead size accordingly. The second has an active sensor with a resolution of 100 (5000 tons) and a range of 420,000 kilometers. The third has an EM sensor, designed to home on shields or active sensor emissions. It would detect the Voskhod MR-800 Active Search Sensor on the Peter the Great battlecruisers (Range 57m, Resolution 60, Signature 5760) from a range of 920,000 kilometers and the SGS-3 Area Search Sensor on the Athena class battlestars (Range 100m km,  Resolution 80, Signature 10080) from over 1.6 million kilometers. While that is not enough when launched from a great distance away, it is probably more than enough to find a new target when the original target is destroyed during the final approach.

Code: [Select]

Basic Missile
Missile Size: 4 MSP  (0.2 HS)     Warhead: 10    Armour: 0     Manoeuvre Rating: 10
Speed: 19200 km/s    Endurance: 52 minutes   Range: 60.0m km
Cost Per Missile: 3.78
Chance to Hit: 1k km/s 192%   3k km/s 60%   5k km/s 38.4%   10k km/s 19.2%
Materials Required:    2.5x Tritanium   1.03x Gallicite   Fuel x2000

Code: [Select]

Active Guidance Missile
Missile Size: 4 MSP  (0.2 HS)     Warhead: 8    Armour: 0     Manoeuvre Rating: 10
Speed: 19200 km/s    Endurance: 52 minutes   Range: 60.0m km
Active Sensor Strength: 0.42    Resolution: 100    Maximum Range: 420,000 km    
Cost Per Missile: 3.7
Chance to Hit: 1k km/s 192%   3k km/s 60%   5k km/s 38.4%   10k km/s 19.2%
Materials Required:    2x Tritanium   0.42x Uridium   1.03x Gallicite   Fuel x2000

Code: [Select]

EM guidance Missile
Missile Size: 4 MSP  (0.2 HS)     Warhead: 8    Armour: 0     Manoeuvre Rating: 10
Speed: 19200 km/s    Endurance: 52 minutes   Range: 60.0m km
EM Sensor Strength: 0.16    Detect Sig Strength 1000:  160,000 km
Cost Per Missile: 3.44
Chance to Hit: 1k km/s 192%   3k km/s 60%   5k km/s 38.4%   10k km/s 19.2%
Materials Required:    2x Tritanium   0.16x Uridium   1.03x Gallicite   Fuel x2000
Steve

[Steve Walmsley (OP)]

Hmm! Forget my babblings about ECCM as for missile combat it affects the range at which the fire control will function, not the chance of a successful hit :)

Aha!!!! I was wondering what ECM/ECCM did and/or how it worked. :-)

BTW, if I put two "ECCM-1" units on a ship, does it do any better?  Is there a posting somewhere in mechanics that I've forgotten? :-)

John

Each ECCM can be assigned to one fire control so if you have two fire controls that are both likely to be used at same time, you need two ECCMs. If one fire control is just a backup and will only be used if the first is destroyed, then only one ECCM is required, unless you want a backup for that too :). ECM affects the chance to hit for opposing beam fire controls and the max range of opposing missile fire controls. ECCM offsets the effects of ECM.

All of this is fairly basic at the moment and is something I added very early on. At some point I intend to create an entirely new EW system. All I have at the moment are some very general notes on a few ideas. Here is a list of the main types of EW you might eventually see.

1) Jammers that can jam active sensors and fire controls of a particular resolution within a specific area. Creates 'noise' to hide echoes. Will affect friendly ships within the same area using the same resolution.

2) Jammers that jam a specific hostile radar

3) Decoys that will attract missiles (but are obviously decoy)

4) Decoys that will appear to be ships to enemy sensors (Mark 70 MOSS)

5) Flares to distract heat-seekers

6) On-board blip enhancers to make targets appear larger

7) Some form of chaff to block hostile fire control against a specific target, leaving the missile no targets

8) Towed decoy (AN/SLQ-25 Nixie)

Steve

[Kurt]

The question of missile guidance has come up once or twice recently on the forum. In addition, as I have recently rewritten all of missile movement and targeting and I am now rewriting the automated missile defence code pretty much from scratch and I am finding the current guidance a little restrictive, I am now considering changing it.

At the moment, the guidance operates on a model similar to that of semi-active laser homing, where the fire control (or laser in modern warfare) paints the target and the missile homes in on that paint. If you move the fire control (or laser designator) to a new target, the missile changes target too. While this works OK for long range anti-ship combat, I think it is possibly a little too powerful in its ability to attack one target by sending waves opf missiles until the target is eliminated and then switching any remaining missiles to a new target. Planning and executing a long-range attack is perhaps too easy because of this flexibility. It causes some problems with realistic anti-missile combat because when the parent fire control needs to engage a new target, any missiles in flight will switch targets too.

I am therefore considering changing to a model where a missile salvo is launched at a specific target and will continue to home on that target as long as it is illuminated by any active sensor. In effect, the target is locked into each missile at the point of launch. The advantage of this model (from a combat perspective) is that this would free the parent fire control to engage new targets without affecting missiles in flight. The disadvantage is that you could no longer switch targets mid-fight. You would have to assign targets on launch and try to estimate the necessary weight-of-fire. In this model, those missiles with onboard sensors would attempt to find a new target by themselves if their designated target was no longer available. Those without onboard guidance would self-destruct.

This has a few programming and gameplay advantages too. From a programming perspective, the target would always be stored with the missile and I would not have to find the associated fire control and retrieve the target from it. In gameplay terms, this will likely result in more damaged ships rather than destroying ships one by one and then leaving one damaged when missiles ran out. It will also require much more careful consideration of target allocation.

One potential issue is ECM vs ECCM. At the moment, ECCM is associated with a particular fire control system and missiles benefit from that ECM. If missiles are not linked to a particular fire control, they would gain no direct benefit and would therefore suffer against ECM protected targets. There are several options to resolve this:

1) Accept this disadvantage.
2) Assume that the fire control imparts any associated ECCM benefit to the missile at the point of launching
3) Disassociate ECCM systems from fire controls and direct them against specific enemy ships to reduce their ECM
4) Make onboard EW for missiles much cheaper and less mass-intensive
5) Bring forward the whole planned EW rewrite

I am interested to hear comments and suggestions on this proposal

Steve

I have had quite a bit of missile combat experience lately in the 6P campaign.  In addition, with the recent release of Weber's "Storm from the Shadows", I decided to re-read the entire Honor Harrington series, and that has given me quite a bit to think about.  

The basic premise of Weber's HH stories is that on-board fire control systems control the missiles up to their terminal run, and that defenses have a significant advantage because of the light-speed delay involved in controlling offensive missiles light minutes away from the launching ships.  In the Weber-verse, the various navies have accepted the disadvantage of light-speed delay because no missile can pack in enough computing power and ECCM to defeat full-size, full-power computers and ECM on board ships.  I think this is a reasonable premise.  After all, if you can put a powerful computer in a missile that masses 1 ton, then you can put a ferociously powerful computer on a twenty thousand ton battleship (or 9 million ton waller).  Of course, in the Weber-verse, fire control systems aren't merely painting the target, they are actively guiding their missiles to the target, and directing their evasion and pen-aides, at least to a certain extent.

As for your specific points:
1.  Given the constraints you have laid out, this may be a reasonable option, but it does make ECM a very attractive option.  Hmmm...this would make ships designed as beam-engagement ships only a little more survivable, possibly, making this a more viable option.  
2.  While this would be workable, I don't know that it is reasonable.  After all, flight times for missiles can range up to several hours.  Assuming that a "snap-shot" of the target provided by ECCM at the moment of launch would still provde any benefit an hour later is more than a little dubious to me.  
3.  This sounds reasonable, but might add complexity.  A possibility, though.  Would it be possible to provide the benefits of ECCM fleet-wide?
4.  While this is certainly possible, and obviously desireable, as I noted above, there is no way that missile-borne ECCM/ECM and computers can approach the power of ship-borne installations.  Therefore, while this option could realistically be possible, and would be used, such installations shouldn't be able to approach the effectiveness of same-tech ship-borne installations.  
5.  I don't know what you are thinking for this, so I can't comment.  

As far as my own experiences lately go, I think it is fairly easy to launch massed missile attacks in Aurora.  In my experience, it is easy to launch a massed missile attack, and hard to very hard to defend against such an attack.   As you point out, this is largely because the current Aurora model, based on painting the target, favors this by granting the attacker flexibility.  

The HH/Weber-verse model is substantially different.  In this system, the quality of the fire control lock is a significant determinant of the to-hit percentage, and is based on range, quality of the FC, ECM, and the characteristics of the target (visibility, ECM, manueverability).  The characteristics of the missile itself also would affect the to-hit percentage, but in a lesser manner.  Under this model, FC's, not missiles, would be the primary determinant of the to-hit percentage, and in the HH universe, the FC's also have a number of "channels" which determines the number of missiles that they can control.  If they are controlling less the to-hit percentage goes up, if they are controlling more (at least during the final attack run) then the to-hit percentage goes down.  

I'll give this some more thought, now that you are looking at this situation.  I'm going to be leaving on vacation in a couple of days, so I'll be out of touch for a while.  I'm going to try to get the next installment of the 6P campaign up before I go, but I'm running out of time.  We'll see.

Kurt

[sloanjh]

As far as my own experiences lately go, I think it is fairly easy to launch massed missile attacks in Aurora.  In my experience, it is easy to launch a massed missile attack, and hard to very hard to defend against such an attack.   As you point out, this is largely because the current Aurora model, based on painting the target, favors this by granting the attacker flexibility.  

How much of the excessive flexibility is the "turn around and chase some more" issue that Steve mentioned upthread?  When vectoring a massive salvo onto a few ships, is the entire salvo lost in making the rubble bounce, or do the missiles stop being consumed when the ships are all gone, leaving the survivors around to attack a different ship on the next timestep?   Or is the problem multiple salvos (e.g. from different ships) that are arriving in a time-on-target manner - if the first three salvos have blown up all the ships, do the other salvos survive (and loiter) to be targetted at another ship on the the next timestep?

Maybe a quick & easy solution is to check for loss of lock after all missile attacks have been resolved, rather than as the attacks are resolved.  In other words, have ships which are destroyed marked as "zombies" which continue to take missile hits until the very end of the increments book-keeping....

John

[Steve Walmsley (OP)]

As far as my own experiences lately go, I think it is fairly easy to launch massed missile attacks in Aurora.  In my experience, it is easy to launch a massed missile attack, and hard to very hard to defend against such an attack.   As you point out, this is largely because the current Aurora model, based on painting the target, favors this by granting the attacker flexibility.  

How much of the excessive flexibility is the "turn around and chase some more" issue that Steve mentioned upthread?  When vectoring a massive salvo onto a few ships, is the entire salvo lost in making the rubble bounce, or do the missiles stop being consumed when the ships are all gone, leaving the survivors around to attack a different ship on the next timestep?   Or is the problem multiple salvos (e.g. from different ships) that are arriving in a time-on-target manner - if the first three salvos have blown up all the ships, do the other salvos survive (and loiter) to be targetted at another ship on the the next timestep?

Maybe a quick & easy solution is to check for loss of lock after all missile attacks have been resolved, rather than as the attacks are resolved.  In other words, have ships which are destroyed marked as "zombies" which continue to take missile hits until the very end of the increments book-keeping....

Something else has occured to me overnight (or overday as I slept from 8.30am to 3pm - poker plays hell with trying live normal hours ). With the new model of no mid-flight course correction, the massed salvo becomes a LOT harder to achieve. You wouldn't be able to fire at a waypoint, wait until the missiles from multiple salvos gathered and then send them all onwards at once. Firing at waypoints would be either for launching probes or as a point at which to release a second stage.

Steve

[Kurt]

As far as my own experiences lately go, I think it is fairly easy to launch massed missile attacks in Aurora.  In my experience, it is easy to launch a massed missile attack, and hard to very hard to defend against such an attack.   As you point out, this is largely because the current Aurora model, based on painting the target, favors this by granting the attacker flexibility.  

How much of the excessive flexibility is the "turn around and chase some more" issue that Steve mentioned upthread?  When vectoring a massive salvo onto a few ships, is the entire salvo lost in making the rubble bounce, or do the missiles stop being consumed when the ships are all gone, leaving the survivors around to attack a different ship on the next timestep?   Or is the problem multiple salvos (e.g. from different ships) that are arriving in a time-on-target manner - if the first three salvos have blown up all the ships, do the other salvos survive (and loiter) to be targetted at another ship on the the next timestep?

Maybe a quick & easy solution is to check for loss of lock after all missile attacks have been resolved, rather than as the attacks are resolved.  In other words, have ships which are destroyed marked as "zombies" which continue to take missile hits until the very end of the increments book-keeping....

John

I tend to underestimate the number of missiles required, so I almost never get into a "making the rubble bounce" situation.  In almost every situation the missiles left over after the initial targets are destroyed are destroyed by point defenses before they can attack the next target.  

The flexibility or ease in attack is because you can target a waypoint and accumulate as many missiles as you carry in your magazines, as long as you have the endurance, then switch targets to enemy ships.  Missile defense, against large massed salvoes, is a non-trivial exercise, both within Aurora (as the defender) and outside of Aurora (as the player).  

Please note, I am not advocating any particular change at this point, I am merely pointing out the implications of my experience.  What I, and I suspect Steve, are looking at is whether or not the actual game play matches with the underlying assumptions.

Kurt

[welchbloke]

Something else has occured to me overnight (or overday as I slept from 8.30am to 3pm - poker plays hell with trying live normal hours ). With the new model of no mid-flight course correction, the massed salvo becomes a LOT harder to achieve. You wouldn't be able to fire at a waypoint, wait until the missiles from multiple salvos gathered and then send them all onwards at once. Firing at waypoints would be either for launching probes or as a point at which to release a second stage.

Steve

I don't know why this hasn't occured to me before.  Using the semi-active model as mentioned in previous threads it would not be possible to fire at a waypoint, there is nothing to reflect energy for the missile to guide itself to.  To fire at a waypoint you would need to actively controlling the missile, this links back to Charlie Beeler's comment about control channels.  So, from my perspective, if the missile's are semi-active (or active ie onboard sensor) then firing at waypoints is not possible only command guidance missiles requiring FC control channels would be capable of launching at waypoints.

[sloanjh]

The flexibility or ease in attack is because you can target a waypoint and accumulate as many missiles as you carry in your magazines, as long as you have the endurance, then switch targets to enemy ships.  Missile defense, against large massed salvoes, is a non-trivial exercise, both within Aurora (as the defender) and outside of Aurora (as the player).  

So it sounds like the issue from your point of view comes from allowing missiles to loiter.  This seems similar to the Honorverse tactic of rolling multiple missile pod salvos before firing to increase missile count.

So maybe a solution would be to have a missile expend itself at the moment it hit its last waypoint (which would have the effect of disallowing loiter).

That or require the waypoints to be pre-programmed at launch time (without allowing loiter time)

Note that my intent is just to throw a lot of stuff out there and see what sticks....

John

[sloanjh]

Something else has occured to me overnight (or overday as I slept from 8.30am to 3pm - poker plays hell with trying live normal hours :-)