Target lock with HMCS - target designation box keeps falling behind target, losing lock (video +track)

[darkman222]

Using the HMCS in DGFT mode to lock targets is difficult and unpredictable at the moment.

When I try to lock up a target , the target designation box falls behind, and continues to fall behind until the (invalid) lock is finally dropped anyway.

I have uploaded a video and the corresponding track, where you can clearly see that the HMCS egg is pointing perfectly on and around the target, but the radar does not manage to create a stable lock.

See the track file here: https://www.dropbox.com/s/8evzfbncjn33u27/f16 lock falling behind.trk?dl=0

See the video here:

 

Edited September 16, 2021 by darkman222
original topic got lost due to merging threads

[BIGNEWY]

Hi, 

 

I will check with the team but I believe this is correct, there is a delay and at closer ranges it is more pronounced.

 

thanks 

[darkman222]

Thank you. Compared to any other DCS aircraft this behavior happens 30% to 50 % of every lock attempt in close air combat, which feels to me way too unreliable for a highly advanced aircraft like the F16.

Fot that video above it was the third locking attempt to show the behavior. You can see in the track file I was just a little more than one minute in this dogfight and the 3rd lock for it to happen.

 

Here is another video I have but without track file. This is extremely common to happen right now:

 

Edited March 5, 2021 by darkman222

[SCPanda]

On 3/5/2021 at 5:32 PM, darkman222 said:

Thank you. Compared to any other DCS aircraft this behavior happens 30% to 50 % of every lock attempt in close air combat, which feels to me way too unreliable for a highly advanced aircraft like the F16.

Fot that video above it was the third locking attempt to show the behavior. You can see in the track file I was just a little more than one minute in this dogfight and the 3rd lock for it to happen.

 

Here is another video I have but without track file. This is extremely common to happen right now:

 

 

Yep. Almost every time I try to lock a target using JHMCS. I have to unlock and relock the target for multiple times to get a solid track. 

 

I doubt this is the correct behavior on the real F-16. In DCS, F-18's JHMCS lock is far more reliable (always achieves a perfect lock actually) compare to F-16.  

[deadpool]

If this: 

 

is indeed as intended, then I don't see a radar lock as help in gunfights .. as you will continously battle with the radar and not the opponent and also the lagged perception gives you all the wrong shooting cues.

 

Just googling F-16 dogfight HUD gives me several videos where this behaviour is not at all like this. Instead the lag that is visible there stems from HUD rendering during abrupt maneuvering and not from the radar update rate.

 

BR,

Deadpool

[BIGNEWY]

Please understand I am not a viper pilot, I ask the dev team, we have access to viper pilot SME's, if I am told it is correct as is I mark it accordingly.

 

But I will ask the team to check again. 

 

thanks

 

 

[Comrade Doge]

+1 for this issue, you can't eve reliably use the HMCS with this bug, and I doubt this is acceptable in real life, if it were correct as is. Hoping ED will check with SMEs or pilots about this

[Tango3B]

On 3/19/2021 at 10:28 AM, BIGNEWY said:

Please understand I am not a viper pilot, I ask the dev team, we have access to viper pilot SME's, if I am told it is correct as is I mark it accordingly.

 

But I will ask the team to check again. 

 

thanks

 

 

Hey, BN! That "delay" that you mentioned above when locking a target in any of the dogfight modes is there, that's true. The radar needs a short time to process the things it sees. But this delay is only a fraction of a second and it is such a short delay that it is barely perceptible. We are surely not talking about 25 seconds or more as this would screw over any serious attempt to perform well in a dogfight. And this goes for all modern jets. You can understand that yourself with logic, I guess. Again, I do not want to be rude but you do not need SMEs to see that this is completely wrong. Personally, I have a Typhoon background as you might know and I can tell you for sure I never ever observed such behavior in any aircraft I flew.

And the same goes for the issue with the TD box falling ("lagging") slowly behind the target which leads to the pilot losing the lock. Did you ever hear of a jet doing such things in combat. Would such radar behavior pass these rigorous military testing procedures? Right, it would not. Seeing this issue even labeled as "correct as is" and implying ED's SME feedback has backed this behavior as correct when you developed it is seriously concerning to me and it raises a few questions, actually. I need to say this again, I do not want to be rude because I know you guys do great work but I must say I am a little bit shocked here.

Edited March 25, 2021 by Tango3B

[Geraki]

It is a bug ..needs to  following SOLID, the  target ..

 

The Missile head diamond possible could be little behind due target movement...or slave misslock due IR signature loss during tracking........ BUT 

THE TD BOX   is SOLID RADAR lock in the bugged/targeted contact

same TD RADAR BOX  is availibale during NAV master mode. in HUD when we have radar lock the contact.

 

 

Edited March 25, 2021 by Geraki

[Spectre1-1]

On 3/25/2021 at 3:13 PM, Tango3B said:

Hey, BN! That "delay" that you mentioned above when locking a target in any of the dogfight modes is there, that's true. The radar needs a short time to process the things it sees. But this delay is only a fraction of a second and it is such a short delay that it is barely perceptible. We are surely not talking about 25 seconds or more as this would screw over any serious attempt to perform well in a dogfight. And this goes for all modern jets. You can understand that yourself with logic, I guess. Again, I do not want to be rude but you do not need SMEs to see that this is completely wrong. Personally, I have a Typhoon background as you might know and I can tell you for sure I never ever observed such behavior in any aircraft I flew.

And the same goes for the issue with the TD box falling ("lagging") slowly behind the target which leads to the pilot losing the lock. Did you ever hear of a jet doing such things in combat. Would such radar behavior pass these rigorous military testing procedures? Right, it would not. Seeing this issue even labeled as "correct as is" and implying ED's SME feedback has backed this behavior as correct when you developed it is seriously concerning to me and it raises a few questions, actually. I need to say this again, I do not want to be rude because I know you guys do great work but I must say I am a little bit shocked here.

 

with an AESA, I'd agree, but a mech radar will be moving much slower than that
I think there is a bug where it does it too often, but I doubt that it is a bug that it does loose lock sometimes

[Tango3B]

7 hours ago, Spectre1-1 said:

with an AESA, I'd agree, but a mech radar will be moving much slower than that
I think there is a bug where it does it too often, but I doubt that it is a bug that it does loose lock sometimes

Hi, Spectre1-1! No, the above issue has absolutely nothing to do with wether it is an AESA or a non-AESA radar or your assumption that "mech radars" might be slower in ACM modes. These non-AESA radars that we have in the F-16C and the F/A-18C are actually pretty advanced radars and should be reasonably fast in any of the ACM modes and they should give you a pretty quick lock in almost any situation. That´s what they were designed for, after all. Processing power and scan speed are more than adequate for the given task. And it certainly won´t take these two radars up to 25 (!!!) seconds to finally give you a lock on a bandit that is directly on your nose and about a mile away. This just doesn´t happen.

Concerning the OP losing lock in his video clips: did you even watch those three videos and the situations that lead to the OP losing the lock? If the observed behavior is supposed to be correct I am happy to trade in my wings...

[deadpool]

On 3/27/2021 at 12:29 PM, Spectre1-1 said:

with an AESA, I'd agree, but a mech radar will be moving much slower than that
I think there is a bug where it does it too often, but I doubt that it is a bug that it does loose lock sometimes

Please have a look at 53seconds into this video 

 

The upwards jolt when the radar (an older ANAPG66) scans a new bar gives you an indication of the servo speed/acceleration these things have.

 

 

Edited March 29, 2021 by deadpool

[Spectre1-1]

On 3/27/2021 at 8:58 PM, Tango3B said:

Hi, Spectre1-1! No, the above issue has absolutely nothing to do with wether it is an AESA or a non-AESA radar or your assumption that "mech radars" might be slower in ACM modes. These non-AESA radars that we have in the F-16C and the F/A-18C are actually pretty advanced radars and should be reasonably fast in any of the ACM modes and they should give you a pretty quick lock in almost any situation. That´s what they were designed for, after all. Processing power and scan speed are more than adequate for the given task. And it certainly won´t take these two radars up to 25 (!!!) seconds to finally give you a lock on a bandit that is directly on your nose and about a mile away. This just doesn´t happen.

Concerning the OP losing lock in his video clips: did you even watch those three videos and the situations that lead to the OP losing the lock? If the observed behavior is supposed to be correct I am happy to trade in my wings...

I watched the vid, my mistake was to assign the cause of the target walking off on to antenna movements, I stand corrected there, thanks for the info

[Gianlc]

Maybe a stupid question, but, is this a consistent bug? Could it be the bandit using Chaff? The first two videos look like the radar is locking chaffs. Don't know if DCS correctly simulates this.

[Comrade Doge]

It is a consistent bug against any plane no matter if they are dropping chaff or not. For me 4/5 lock attempts with the HMCS fail, very frustrating bug, yet this is marked with "correct as is" once again, just like the AMRAAM reports, until a large amount of users spoke up...

Edited April 17, 2021 by Comrade Doge

[deadpool]

On 4/16/2021 at 11:30 PM, Gianlc said:

Maybe a stupid question, but, is this a consistent bug? Could it be the bandit using Chaff? The first two videos look like the radar is locking chaffs. Don't know if DCS correctly simulates this.

no chaff in my video. 

[SCPanda]

On 4/17/2021 at 5:30 AM, Gianlc said:

Maybe a stupid question, but, is this a consistent bug? Could it be the bandit using Chaff? The first two videos look like the radar is locking chaffs. Don't know if DCS correctly simulates this.

I believe he was fighting an AI, AI does not chaff unless you fire a radar guided missile toward it. 

[darkman222]

Watch the video deadpool posted earlier in this thread. This thread is not about: One time I was flying the F16 and lost lock. What was that, maybe chaff?

This is about flying on a dogfight server, where you'd lock with bore sight or JHMCS all the time, up to 4 times per minute, ending up fighting the radar first, then the opponent, hoping to get  a lock and level 5 gunsight will be computed before the opponent passes the HUD. Just one word: Frustrating.

[SCPanda]

1 hour ago, darkman222 said:

Watch the video deadpool posted earlier in this thread. This thread is not about: One time I was flying the F16 and lost lock. What was that, maybe chaff?

This is about flying on a dogfight server, where you'd lock with bore sight or JHMCS all the time, up to 4 times per minute, ending up fighting the radar first, then the opponent, hoping to get  a lock and level 5 gunsight will be computed before the opponent passes the HUD. Just one word: Frustrating.

Yep. I have the same experience as well. It's even more frustrating if it's a Fox 2 fight and your JHMCS just can't lock the target.... Worst thing is, this happens literally every time...

 

I guess ED's testing team don't really do dogfighting. 

[TobiasA]

Boys, it is marked as correct-as-is. Note that this is a high aspect track at a very close target. All this happens in high aspect locks.

This is the reason why I always uncage at lock.

 

@BIGNEWY: It would be cool if you would post a little explanation as to why this is correct. As someone interested in the technical background of such things, I'd really like to know.
If you don't, then you don't.

Thanks in advance for that!

[Comrade Doge]

1 hour ago, TobiasA said:

Boys, it is marked as correct-as-is. Note that this is a high aspect track at a very close target. All this happens in high aspect locks.

This is the reason why I always uncage at lock.

 

@BIGNEWY: It would be cool if you would post a little explanation as to why this is correct. As someone interested in the technical background of such things, I'd really like to know.
If you don't, then you don't.

Thanks in advance for that!

Being marked as correct as is doesn't mean much, as previous topics have shown, that have been retitled when the community insisted to show ED the issues in their game. If they say the HMCS being a joke of a system is realistic, with it barely locking, I find it laughable. Take a look at the Hornet for example, the HMCS has no issues in that one, this is obviously a Viper bug that for some reason no one wants to fix

[darkman222]

Okay, people might argue, nobody here is a fighter pilot, so how'd you know about the correct F16 radar behavior? Well thats right.

But if the F16 had a such unreliable radar then it would be commonly known. And if so, that radar would have been replaced in no time by the air force.

Other example: It is known by public about compressor stalls in the F14A. So its modelled in DCS then and nobody complains.

But have you ever heard or read about F16 pilots talking like: Well the F16 is a great manoverable aircraft, but man, due to the bad radar, as always, I lost 1 of 2 locks again and could not employ my weapons. Man that would be great if we had such a reliable radar for close air combat like the Mirage, or the F15 or even the F14. I guess that rumor does not exist. So people have the right to be suspicous about it, when locks fail over and over again, in an aircraft that is not known for that to happen.

The radar even fails to lock the desired aircraft if they fly in formation. I highly doubt thats correct and still is being investigated anyway. I guess both radar issues might be related. See this thread below:

Nobody doubts that the data and numbers ED has modelled the radar and the JHMCS from is incorrect. But on the one hand there is numbers, the modelling is based on, and on the other hand there is a logic being driven by that numbers. And the logic that works under the hood seems to have an error, which becomes obvious if you take the DCS F16 to a dogfight server and put it to a stress test.

 

As Bignewy stated he will bring the issue up again, we will wait and see what happens and better not blow up that thread with discussions that might have been unecessary until Bignewy hopefully gets back to this thread again, telling us about the outcome.

Edited April 24, 2021 by darkman222

[deadpool]

I have not flown a F-16 for real, but any interview with people that flew it you will find will tell you one thing:

- It was/is a damn good dogfighter

 

Now let's leave out that currently in DCS the FM doesn't really seem to do that justice.

 

I don't think having to fight the FCR before you get to fight the opponent is true. I don't think those people in the interviews praising the F-16 had these sorts of problems this frequent.

 

And I do not think that how it's modelled in DCS is correct. No other airframe has these problems with their dogfight radar modes.

 

And I will keep adding my opinion and add more arguments to this side of the story to this thread until:

- someone makes it technically impossible (e.g. by closing it. (which would be a slap in the face until this is fixed))

- or that humiliating, slap-in-the-face keyword "correct as is" is taken of this thread.

Edited April 24, 2021 by deadpool

[TAW_Blaze]

I think this is a problem of the HMD refresh rate for some reason. If you lock someone, even at long ranges ( 30 nm+ ) and the target dives aggressively you will see roughly up to date target designation on your HUD. However if you do the same thing while in a crank, monitoring visually the target designation box on the HMD he will lag behind.

 

I can double check later on but I'm about 90% sure that I looked into this in the near past and this is what I found and it is rather odd. If the radar mech was so slow to not keep up with the target maneuvers you would alltogether lose lock much more likely than just have a lag, especially for such extended periods.

 

Edit: hmm, looks like it's actually struggling the most when you're also maneuvering hard.. at longer ranges the HMD seems fairly stable, but when you pull hard the HMD will get pretty jumpy and can be off the location too. 

Edited April 27, 2021 by 104th_Blaze

[Comrade Doge]

@BIGNEWY Hello sir, any update regarding this issue? The last communication from you was that you will ask the team. Any new answer from them? This bug is plaguing pretty much every dogfight. Thanks in advance