Missile API

[Slant]

We've had various missile problems within the last half year, if not longer. It's been pointed out time and again that much of that is due to ED reworking the missile API/logic. I'm not sure what exactly is being worked on and how long it's going to take.

 

And that is the reason for this post: Can ED give us more details on what is being worked on and how much longer we're going to have to wait for missiles to actually function properly again? This is the Digital Combat Simulator, but right now it feels like the Digital A2G Simulator. It's not fun, A2A isn't happening as it should. This is across the board for Fox-3s, Fox-1s and Fox-2s...

 

Some info would be appreciated.

Edited December 6, 2020 by Slant

[Northstar98]

Agreed, and it seems that there's still some funny business with missiles (namely the AIM-54) not having all their modes simulated. Though personally not aware of any big issues with Fox 2s (apart from HMCS locked to horizon).

Edited December 6, 2020 by Northstar98

[wilbur81]

These posts/threads are going to be near-useless without tracks and many many details. Missiles are so complex and have so many factors at play affecting them in the sim (speed at launch, altitude, air temp, target maneuvering, countermeasures, etc.)  In my recent experience (yesterday) I scored some great Aim-120 kills in MP from high altitude and high speed (in the Hornet, ironically). I also miss WAY more than I connect.

 

As the real guys say all the time, "they don't call them 'hittiles" for a reason."

Edited December 6, 2020 by wilbur81

[Slant]

You know, I would be willing to do all the work they rightly should pay me for, but this forum has a 5MB file upload limit, these trackfiles and tacview logs have been posted up and down the internet already and it is a very commonly and broadly known issue to which 3rd party developes have already responded. We are aware that ED is doing funky stuff with the missile API, and I have been patient for the past six months or so. I'm not asking ED to fix anything specific right now, I am asking what are they doing with the missile API and when can we expect them to be done with it?

 

These are two questions that are not too much to ask. And certainly a trackfile won't change the response to these questions. Pay attention. This isn't me whining about "Fix bug XY", this is me asking about the state of known development projects. Your post es entirely unwarranted and spamming this thread.

Edited December 6, 2020 by Slant

[wilbur81]

13 hours ago, Slant said:

it feels like the Digital A2G Simulator. It's not fun, A2A isn't happening as it should. This is across the board for Fox-3s, Fox-1s and Fox-2s...

 

I disagree with everything you've said in the above quote. But you could argue your case and upload a track to show us what you are talking about. Are you upset that the Phoenix is no longer getting 60-70nm kills against an aggressively maneuvering/chaffing, low-altitude, small RCS target? What are the various lack of modes/problems that you're seeing and with what missiles/platforms? Seriously asking as I'm pretty much an A2A guy as well.

Edited December 7, 2020 by wilbur81

[Slant]

No. No, I don't think I will confirm any of that. If you're not aware of the problems, I have zero interest at discussing it with you. It's a known, confirmed problem that hinges on ED working on the missile API, which is confirmed as well. All I want is a timeframe and maybe an insight into what it is they're actually doing. For an explanation of the bug, refer to the other threads in this very forum that already have filed bugreports on the topic.

[wilbur81]

Fair enough.

[Nealius]

What I want to know is why this missile rework is a constant work-in-progress on the customer's build? Wait until the thing is finished instead of pushing incremental tweaks that break things in every update. 

Edited December 21, 2020 by Nealius

[DCS FIGHTER PILOT]

On 12/6/2020 at 8:35 PM, wilbur81 said:

I disagree with everything you've said in the above quote. But you could argue your case and upload a track to show us what you are talking about. Are you upset that the Phoenix is no longer getting 60-70nm kills against an aggressively maneuvering/chaffing, low-altitude, small RCS target? What are the various lack of modes/problems that you're seeing and with what missiles/platforms? Seriously asking as I'm pretty much an A2A guy as well.

 

No, we are upset at the fact that the Phoenix will go stupid fired at any range just so long as the target pops one piece of chaff and puts the missile on the beam. If you want proof of this, see my new post regarding this issue. 

[das Rindvieh]

This +100

Absolutely right. Can't understand that to, why this little changes are made in the consumer version and breaks the whole A2A...

On 12/6/2020 at 9:16 PM, Slant said:

You know, I would be willing to do all the work they rightly should pay me for, but this forum has a 5MB file upload limit, these trackfiles and tacview logs have been posted up and down the internet already and it is a very commonly and broadly known issue to which 3rd party developes have already responded. We are aware that ED is doing funky stuff with the missile API, and I have been patient for the past six months or so. I'm not asking ED to fix anything specific right now, I am asking what are they doing with the missile API and when can we expect them to be done with it?

 

These are two questions that are not too much to ask. And certainly a trackfile won't change the response to these questions. Pay attention. This isn't me whining about "Fix bug XY", this is me asking about the state of known development projects. Your post es entirely unwarranted and spamming this thread.

 

 

On 12/21/2020 at 3:41 AM, Nealius said:

What I want to know is why this missile rework is a constant work-in-progress on the customer's build? Wait until the thing is finished instead of pushing incremental tweaks that break things in every update. 

 

 

Edited January 2, 2021 by das Rindvieh

[fmedges]

Yeah, it’s quite frustrating from a user experience standpoint. There is both a beta build and stable build but both are a mess in terms of consistency with regards to the missile behavior. 

[SgtPappy]

On 12/6/2020 at 8:35 PM, wilbur81 said:

I disagree with everything you've said in the above quote. But you could argue your case and upload a track to show us what you are talking about. Are you upset that the Phoenix is no longer getting 60-70nm kills against an aggressively maneuvering/chaffing, low-altitude, small RCS target? What are the various lack of modes/problems that you're seeing and with what missiles/platforms? Seriously asking as I'm pretty much an A2A guy as well.

 

I'll take this opportunity to shove my thread on missile guidance vs the tomcat jammer

 

Check out this thread, one of more than one example of the difficulty that is quite frustrating online: F-14 Jammer renders new API missiles almost useless

 

It has tacviews and videos showing my testing online with a friend. We even switched alternatively flew the tomcat to make sure it wasn't only on my end.

[Cmptohocah]

On 12/24/2020 at 9:39 PM, DCS FIGHTER PILOT said:

No, we are upset at the fact that the Phoenix will go stupid fired at any range just so long as the target pops one piece of chaff and puts the missile on the beam. If you want proof of this, see my new post regarding this issue. 

All missiles utilizing pulse-doppler radar will loose track once the relative speed of the target is bellow the minimum value required for a valid lock. It's just physics. This is called a "notch".

[SgtPappy]

37 minutes ago, Cmptohocah said:

All missiles utilizing pulse-doppler radar will loose track once the relative speed of the target is bellow the minimum value required for a valid lock. It's just physics. This is called a "notch".

While you are correct, there is much more to this than you imply. Most people in these forums already know this.

 

For one thing, the resolution cell size is a big factor in whether the chaff will truly shift the RCS centroid by enough to create the angle tracking error needed to break lock. As you get closer, the resolution cell becomes smaller and it becomes less likely for chaff to expand in time while within the same cell as the aircraft for the radar lock to see the chaff return as a part of the aircraft return. 

 

Furthermore, the closer you get, the easier it is to come out of the notch since the defending aircraft more quickly has an angle off the attacking radar to no longer offer a below minimum Doppler return. In this case, even old radars will attempt to look for you again by scanning in the direction of your last known trajectory to pick you up once there is strong enough of a return. This is why it is necessary to maneuver, so as to throw off any predictive scan. 

 

Finally, though DCS does not model this directly, newer radars (like those in the AIM-120 most likely, I'd be surprised if not) can perform chaff rejection using things like FFT's to discern the wide broadband return that chaff gives among other techniques that lead to better CCM. In game, this is modeled by simple chaff rejection probability. 

 

So while it is *possible* that something like an AIM-54A is very similar to the analog AWG-9 which, according to reputable sources does not have such FFT capability or fine azimuth resolution and therefore has worse CCM, it is also not extremely likely that a single bundle of chaff will shift the RCS centroid by enough at close ranges to force a break-lock per the reasons above. 

 

For what it's worth, I have been unable to spoof an AIM-54A with 1 piece of chaff in the beam in recent tests - maybe only others are having this issue. I always have to pull at least 5G while in the beaming plane and popping more than 1 piece of chaff (maybe only 3 or 4). 

[Cmptohocah]

4 minutes ago, SgtPappy said:

While you are correct, there is much more to this than you imply. Most people in these forums already know this.

 

For one thing, the resolution cell size is a big factor in whether the chaff will truly shift the RCS centroid by enough to create the angle tracking error needed to break lock. As you get closer, the resolution cell becomes smaller and it becomes less likely for chaff to expand in time while within the same cell as the aircraft for the radar lock to see the chaff return as a part of the aircraft return. 

 

Furthermore, the closer you get, the easier it is to come out of the notch since the defending aircraft more quickly has an angle off the attacking radar to no longer offer a below minimum Doppler return. In this case, even old radars will attempt to look for you again by scanning in the direction of your last known trajectory to pick you up once there is strong enough of a return. This is why it is necessary to maneuver, so as to throw off any predictive scan. 

 

Finally, though DCS does not model this directly, newer radars (like those in the AIM-120 most likely, I'd be surprised if not) can perform chaff rejection using things like FFT's to discern the wide broadband return that chaff gives among other techniques that lead to better CCM. In game, this is modeled by simple chaff rejection probability. 

 

So while it is *possible* that something like an AIM-54A is very similar to the analog AWG-9 which, according to reputable sources does not have such FFT capability or fine azimuth resolution and therefore has worse CCM, it is also not extremely likely that a single bundle of chaff will shift the RCS centroid by enough at close ranges to force a break-lock per the reasons above. 

 

For what it's worth, I have been unable to spoof an AIM-54A with 1 piece of chaff in the beam in recent tests - maybe only others are having this issue. I always have to pull at least 5G while in the beaming plane and popping more than 1 piece of chaff (maybe only 3 or 4). 

I appreciate a very detail and informative explanation, I learned some new things, but I never mentioned chaff.

[SgtPappy]

2 minutes ago, Cmptohocah said:

I appreciate a very detail and informative explanation, I learned some new things, but I never mentioned chaff.

Ah you're right, sorry, ECM is all I think about these days   You did however quote DCS Fighter Pilot above who is complaining about 1 chaff with beaming which is probably not too accurate. 

 

Without sufficient clutter, (ground or chaff), beaming shouldn't do a thing for a valid lock since lock-on sets up range, azimuth and in PD radars, Doppler gates. The Tomcat will use Pulse mode when its Doppler mode loses sufficient return. Clutter outside these gates will be rejected which is why you need to introduce clutter into your res cell by being very close to the ground while beaming and/or introducing chaff.

 

The issue here IIRC, is that some people are having the issue where a simple beam and 1 chaff pop will break AIM-54 lock within visual range, even far from ground clutter (which needs to be only tens of metres away from a plane, not thousands of feet looking down).