Missile vs Missile Accuracy

[gomker]

In guard mode the accuracy of Missile targeting is very over powered. Incoming missiles can be intercepted by other missiles with almost 100% accuracy. Perhaps a random variance introduced in targeting when the Target is a missile to restore some balance.
Certain interceptor missiles designed for shooting down other missiles should have some dependencies introduced, such as a constant radar lock to give it an edge over standard missile, i.e. PAC3 vs AIM 120

[TheDestroyer111]

But... there are no counter-missile missiles in BDA? rofl
//EDIT: Oh

[gomker]

The PAC-3 is an ABM (Anti Ballistic Missile) https://en.wikipedia.org/wiki/MIM-104_Patriot#MIM-104F_.28PAC-3.29

[SpannerMonkey]

I have to agree here, incoming missile intercept by radar guided missiles is too good, and certain missiles excel at it, generally these seem to be the smaller radar guided types, as you'd expect due to a smaller missiles agility compared to larger types,
The 57E6 that is used by the new combo turrets is extremely effective and very rarely misses incoming missiles, however it's hit rate on AI controlled aircraft is on par with other radar guided short range missiles, so it's not OP in any way, this in itself does lead one to draw the conclusion that the intercept needs de tuning a little

[gomker]

My thoughts were a phased in system, building on what we added for Guard Mode improved targeting

1. Have a new targeting type for ABM's - This will give us a flag to tie into the radar/tracking
2. If the missile does not have a dedicated Radar lock (From a Ground Radar) we start to decrease its accuracy multiplied by time
3. We would need to slave the missile to radar as the targeting is "handed off" to the missile at fire time.
4. Normal AA missiles will have their accuracy decreased against other missile targets - we already can account for target types in code

This would in effect mimic a Anti-missile system , which is far more complex, but its still a game right?

[SpannerMonkey]

but its still a game right?
Indeed it is, no need for science when gaffer tape will work, :)

[ghost]

Somehow I have the feeling that this issue automatically (?) resolved itself and actually turned into the opposite:
Missile vs missile accuracy is terrible right now.
I can fire 4 ESSM against an incoming Harpoon or tomahawk - even though these fly subsonic and are not yet terminal maneuvering, nothing is hit.
Saw some videos on YouTube where several people also stated they feel missiles are underpowered (less agile) now.
As I don't see any commits doing changes here, has something changed with ksp 1.2.2 or missile aero forces??

[SpannerMonkey]

Somehow I have the feeling that this issue automatically (?) resolved itself and actually turned into the opposite:
I agree with your findings, radar guided missiles are practically useless right now and the chance of a hit has dropped from something like 80% down to maybe 10 at best , the change is so profound that it pretty much put a halt on combo turret development as without some kind of accuracy the missile addition is pointless

[gomker]

I need to run some stock BDA tests to reconfirm but as for missiles from PEW et al , they needed some major changes to get working properly (I think Spanner has yet to release those tweaks I provided)

I'll run through some scenarios with PAC vs. RBS-15 for a baseline

[ghost]

curious about those tweaks - what can be tweaked in the part config aside from thrust and turningDPS?

[jrodrigv]

Yes, I agree too. Was this introduced with KSP 1.2 or with 1.2.1?

…

On 11 Jan 2017 18:37, "SpannerMonkey (Tony)" ***@***.***> wrote: Somehow I have the feeling that this issue automatically (?) resolved itself and actually turned into the opposite: I agree with your findings, radar guided missiles are practically useless right now and the chance of a hit has dropped from something like 80% down to maybe 10 at best , the change is so profound that it pretty much put a halt on combo turret development as without some kind of accuracy the missile addition is pointless — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#82 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH6I-0m9rVEBdip9SPeXvSQ5vh8DgTDkks5rRRM6gaJpZM4Kqq94> .

[SpannerMonkey]

I've a feeling it all changed on the release of 1.2. build 1622 which also coincided wth Kerbals being immortal and immune to BDA stuff, right up until the day of the update I recall missiles were behaving as expected and I know that the day before the update Kerbs were destructible by BDA

[gomker]

@TheDogKSP
These are the main values I tweaked

 thrust
 cruiseThrust
 cruiseTime
 maxTurnRateDPS
 steerMult
 maxTorque

[gomker]

Finished off some tests with the following vs the RBS15 at 15KM distance and a 20KM physics distance

• Malfunc - MK29
• PEW - 9m96e2
• BDA - PAC3

Firing directly at each other I found that about 1 out of 3 tries would connect. It seemed if the missile got to the RBS15 before terminal evasion it could sometimes hit it

Indirect fire at a target 100M away , they never could shoot down the RBS15

I think the main takeaway for me was shooting directly at a target that had ABM capability, I had been testing against ships armed with MK29's

[ghost]

Looking at the KSP 1.2 changelog, these might be candidates for changes which affect BDA features like missile accuracy:

• Revised how most forces and torques are applied (see note on this subject below in Moddability).
• Considerable work to Krakensbane and FloatingOrigin to improve precision and performance and lower garbage
• There is an additional drag curve whose function is to raise drag coefficient to a power based on the mach number.
• Fix a wrong rotation in Moment of Intertia calculations.
• All forces on valid parts except wheel forces are now done via Part.AddForce/Torque/AddForceAtPosition. Note that the forcemode used is Force; to use a different forcemode, convert the force to the correct amount. It is the job of the Flight Integrator to then apply all these forces to actual rigidbodies (rather than all the disparate modules' job).
• Particle systems can be registered with FloatingOrigin for handling origin/krakensbane offsetting natively.

I might have a 1.1.3 on my Linux install, gotta check, would be interesting to compare the current support branch compile on 1.1.3 vs 1.2 (if I can get it compiled on 1.1.3, that is...)

[jrodrigv]

Nice finding @thedog! It would be awesome if you can add some logging to parameters used for the AeroForces and compared the output from 1.1.3 and 1.2.2 during a specific scenario, that way we should be able to see which of them are now different. 2017-01-17 11:08 GMT+01:00 TheDog <notifications@github.com>:

…

Looking at the KSP 1.2 changelog, these might be candidates for changes which affect BDA features like missile accuracy: - Revised how most forces and torques are applied (see note on this subject below in Moddability). - Considerable work to Krakensbane and FloatingOrigin to improve precision and performance and lower garbage - There is an additional drag curve whose function is to raise drag coefficient to a power based on the mach number. - Fix a wrong rotation in Moment of Intertia calculations. - All forces on valid parts except wheel forces are now done via Part.AddForce/Torque/AddForceAtPosition. Note that the forcemode used is Force; to use a different forcemode, convert the force to the correct amount. It is the job of the Flight Integrator to then apply all these forces to actual rigidbodies (rather than all the disparate modules' job). - Particle systems can be registered with FloatingOrigin for handling origin/krakensbane offsetting natively. I might have a 1.1.3 on my Linux install, gotta check, would be interesting to compare the current support branch compile on 1.1.3 vs 1.2 (if I can get it compiled on 1.1.3, that is...) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#82 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH6I-4D_fnB_iHEPClUyKXD5VJ_IMnOkks5rTJMHgaJpZM4Kqq94> .

[ghost]

OK, good news and so-so news:
I got the current support branch version compiled against 1.1.3 with minor changes, I have setup a simple scenario and executed it severals times in 1.1.3 and 1.2.2, both with identical minimal mod configurations (only BDAc current version compiled from support branch, plus vesselswitcher plus vesselmover).

I have executed each scenario 3 times on 113/122.
Unfortunately, guard mode doesnt work for some reason on my 113 compile (doesnt radar lock anything), so my procedure was:

• switch to attacker, manually fire an RBS-15 at defender location
• switch to defender, manually radar lock incoming rbs-15
• fire PAC-3

Since it's all done manually, the exact timing and flight pathes differ slightly between each attempt, you'll see in the logs that makes quite a difference to when what torque and lift etc. are applied...

1) "Gameplay" result:

• each attempt in 113 ended in a successful intercept of the RBS-15 by the PAC-3
• 2 attempts in 122 failed, did not intercept and the defender was destroyed
• the third attempt in 122 in fact intercepted the rbs-15, BUT YOU'LL SEE SOME WEIRD BEHAVIOUR IN THE LOGS. More on that in a minute.

2) Output:
Please have a look at the files here:
https://github.com/TheDogKSP/ksp-backup

@jrodrigv : I hope you can work with that format. Each of the 3 attempts is in its own log file (KSP.log), reduced to only the relevant section.
I tried to log basically everything that happens inside the "DoAeroForces" method in missileguidance.

The 122 folder also contains:

• the SFS of the scenario
• a screenshot i took just before intercept in attempt3 in the 122 environment
• and an XLS anaylsis i started

3) XLS analysis
I have tried to compare for the RBS-15 and PAC-3 their behaviour for 3 set points in time:

• directly at launch (first call of doaeroforces)
• after 5 sec of flight
• and for the PAC-3, last call of doaeroforces just before intercept or miss

My (Preliminary) Conclusion:
the numbers for lift, drag, torque etc. for each attempt are quite different, since due to my manual execution of the scenario the exact flight path is slightly different each time.

However, nothing really looks totally weird or out-of-proportion, so I would say that the AeroForces in KSP 1.1.3 and 1.2.2 dont seem to behave differently, even though maybe for KSP 1.2.2 we shouldnt add the force to the rigidbody directly, instead calling Part.AddForceAtPosition as per KSP's changelog...

THE ONLY FINDING I HAVE COMES FROM THE "SUCCESSFUL" INTERCEPT IN ATTEMPT3 IN 122:
if you go through the log you'll see that suddenly the RBS-15 exlodes, though the PAC-3 happily flies on (presumably after hitting it) for several hundred milliseconds, and only explodes many frames later.

Thus I would conclude there is not really a problem with aeroforces, but rather with detecting and registering the hit/collision/air detonation...?

But I really hope that you can maybe take something out of these logs & data, so I am curious for your conclusion!

[jrodrigv]

Wow. Very deep investigation! Good job! I need some time to dig into this.

One question regarding 1.1.3. Are you using the current code from the support branch or the code that we had at that time? I'm thinking that we might need to do the test using the code that we had before 1.2, that way we can discard possible issues introduced by us

[ghost]

No, i really used the current state of the support branch, and "backported" it to 113.
Since it works at 113 with the current BDAc code, I guess this can pretty much exclude that this was introduced by the refactoring or other changes...

[jrodrigv]

This issue has been fixed and it will be released.