Jump to content

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


darkman222

Recommended Posts

On 4/27/2021 at 2:11 PM, 104th_Blaze said:

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. 

 

I have the problem in the HUD as well though. Not only HMD.

Lincoln said: “Nearly all men can stand adversity, but if you want to test a man's character, give him power."

Do not expect a reply to any questions, 30.06.2021 - Silenced by Nineline

Link to comment
Share on other sites

1 hour ago, deadpool said:

I have the problem in the HUD as well though. Not only HMD.

 

Interesting. To be honest this is not a huge issue to get me into detailed testing, and atm I don't feel confident anymore about what the root cause might be. but I would appreciate it if it was faster for sure. 🙂

Link to comment
Share on other sites

When I started this thread I was also mislead by the assumption it just happens when using JHMCS. So I guess the title is wrong. I spent a whole session on a dogfight server not using JMCS but just the HUD boresight modes and it turns out to be as unreliable as locking with JHMCS. You'd just not notice as much, because the over all amount of target locks is less with HUD boresight modes.

I was even willing to revert DCS to a version when the F16 was initially released to test it with a previous version. Because I am sure that behavior emerged just after JHMCS for the DCS F16 was introduced. But unfortunately I could not revert to a DCS version old enough to prove my point.

Link to comment
Share on other sites

Just my two cents.

As I dabble into the dogfight servers every now and then I've found ways to work around this.

 

When offered the opportunity in combat I make sure to STT in the CRM mode. This issue has never manifested itself in a STT acquisition in CRM.

 

However, as stated its always there in a ACM acquisition. I'd like to know why this is.

 

If the issue was inherently linked to the nature of a mechanical pulse doppler wouldn't it be manifesting across all types of STT locks? Heck, even a TWS track gives a better and more reliable HMD transposition.

 

Looking forward to any insight offered.

 

Sincerely

mobua

  • Like 2
Link to comment
Share on other sites

  • 3 weeks later...

/bump

 

One can see in my videos that it's not JHMCS alone, but lagging / losing lock in HUD as well.

This happens just in the Viper, not in the Hornet. This is also not connected to line of sight change as can also clearly be seen in the videos.

  • Like 4

Lincoln said: “Nearly all men can stand adversity, but if you want to test a man's character, give him power."

Do not expect a reply to any questions, 30.06.2021 - Silenced by Nineline

Link to comment
Share on other sites

  • 3 months later...

Time to bring attention to this topic again:

After being on a guns only dogfight server, I edited the first 20 locks in a row together. I did just cut out the time in between these locks. I did not skip any locking attempts or removed successful locks to fake the outcome. This is what a random session gives locking bandits 20 times. Watch the 1:20 minutes video. The fail ratio is 35 % which does not look like too much, but in fact its huge considering the F16 to be an aircraft with a radar known for its capabilites. If you see that in a cut down video you can imagine how frustrating that is:

 

 

Furthermore I can not stress enough that there seems to be an offset between the boresight egg and where the target designator box appears looking at first. It corrects itself quite often. But does not manage every time. Even if you think that was good intial lock, there was a barely noticeable jump of the target designator box from the wrong starting position to the correct one.

It seems like the radar starts  to try to lock offset and then corrects. Why wouldnt it be looking for a lock in the exact position you are pointing your JHMCS to?

 

 

Its along one hour session and an older DCS version, but here is the log anyway:

https://www.dropbox.com/s/6fimohr0t768gc3/mobettameta's Dogfight Arena v1.20-20210508-142341 failed lock compilation.trk?dl=0

 

 

 


Edited by darkman222
  • Like 2
  • Thanks 1
Link to comment
Share on other sites

On 8/25/2021 at 8:13 AM, darkman222 said:

Time to bring attention to this topic again:

After being on a guns only dogfight server, I edited the first 20 locks in a row together. I did just cut out the time in between these locks. I did not skip any locking attempts or removed successful locks to fake the outcome. This is what a random session gives locking bandits 20 times. Watch the 1:20 minutes video. The fail ratio is 35 % which does not look like too much, but in fact its huge considering the F16 to be an aircraft with a radar known for its capabilites. If you see that in a cut down video you can imagine how frustrating that is:

 

 

Furthermore I can not stress enough that there seems to be an offset between the boresight egg and where the target designator box appears looking at first. It corrects itself quite often. But does not manage every time. Even if you think that was good intial lock, there was a barely noticeable jump of the target designator box from the wrong starting position to the correct one.

It seems like the radar starts  to try to lock offset and then corrects. Why wouldnt it be looking for a lock in the exact position you are pointing your JHMCS to?

 

 

Its along one hour session and an older DCS version, but here is the log anyway:

 

https://www.dropbox.com/s/6fimohr0t768gc3/mobettameta's Dogfight Arena v1.20-20210508-142341 failed lock compilation.trk?dl=0

 

 

 

 

I can confirm. With the most recent update, this behavior has gotten even worse. Now it's not only the JHMCS box falling behind the target. If you try to lock the target with HUD boresight, the lock circle will sometimes fall behind the target and then drop lock, even though the target is just flying straight right in front of your eyes within 1 mile. Worse thing is, when the lock is dropped, if you try to use either JHMCS, HUD boresight, vertical scan, and HUD scan mode to lock the target, the ACM modes just refuses to lock on. 

 

Hornet ACM modes are much easier to use in comparison with Viper's. It's a difference of night and day. 

 

ED really should fix this as soon as possible. 


Edited by SCPanda
Link to comment
Share on other sites

It does not make sense to compare the F18 radar with the F16 radar. This is not how to argue here. But I can confirm the behavior you describe, that the F16 ACM modes are unreliable too.

Sure there must be a  certain failure rate of the radar, you can dodge it of course. Nobody expects a perfect system, so these failures have to be modelled too. If developers do "vanilla" locks while testing, sure it will work. But to see if the modelling is correct, that can be only tested in a harsh environment like a dogfight server, where you need to get the lock for the guns solution, otherwise you end up playing with the funnel, which is a major disadvantage.

 

So what I would like the team at ED or @BIGNEWY kindly ask for is, to show that video someone who can really judge that in these situations shown the radar will have that high failure rate and why it will have that high failure rate in that situation. Why is the target designator box starting to look way off the boresight egg sometimes? In one case in the video its 10 degrees off.

I am just I player and cant judge. It just feels wrong. So if ED showed that video to, for example one of the consultants ED has, who have actually flown the F16 and he is like: Sure that is what you will experience in that situation because.... that'll be fair enough. Tell us why that is, and just dont put " correct as is" on the thread.

 

Link to comment
Share on other sites

  • ED Team

What we have is two separate issues in the thread. 

 

The box falling behind / lagging is correct. 

 

the dropped locks in the "egg" is already reported  

 

I have updated the thread tags to reflect this

 

  • Like 1

smallCATPILOT.PNG.04bbece1b27ff1b2c193b174ec410fc0.PNG

Forum rules - DCS Crashing? Try this first - Cleanup and Repair - Discord BIGNEWY#8703 - Youtube - Patch Status

Windows 11, NVIDIA MSI RTX 3090, Intel® i9-10900K 3.70GHz, 5.30GHz Turbo, Corsair Hydro Series H150i Pro, 64GB DDR @3200, ASUS ROG Strix Z490-F Gaming, HP Reverb G2

Link to comment
Share on other sites

  • 2 weeks later...
On 8/27/2021 at 7:21 AM, BIGNEWY said:

What we have is two separate issues in the thread. 

 

The box falling behind / lagging is correct. 

 

the dropped locks in the "egg" is already reported  

 

I have updated the thread tags to reflect this

 

 

 

My question will be. Is the lagging that big ? Big enough to force the pilot TMS down and re-attempt to lock it up again ?

  • Like 1

[sIGPIC][/sIGPIC]

I9-9900K-Gigabyte 2080Ti Gaming OC, 32G DDR4000 RAM,

Track IR5, HOTAS Cougar + über Nxt Hall Sensor Mod, Slaw Device RX Viper

Link to comment
Share on other sites

If you are referring to the JHCMS "egg" its bugged. I have started two bug reports about two issues which are related. Locking the wrong aircraft and the target designator box being offset when trying to lock a target.

Both issues are being investigated. As long that is what you mean, I am afraid we cant do anything about it until ED adresses the bugs..

 

  • Like 1
Link to comment
Share on other sites

Okay, threads being merged. Thats fine. But it was my orignal thread I started months ago in the bug section being merged into this new one, and the orginal title and tags got lost. So it has now a very undescriptive and misleading  title like "egg mode" but it was about difficult locking behavior of the  ACM modes including JHCMS. Maybe that should be corrected.

Like I said , the tags are misleading now too, there are a lot of track files and videos about the issue and it also was moved out of the bug section that way.

 

EDIT: I changed the topic back to the original one, as I was the thread starter


Edited by darkman222
  • Like 1
Link to comment
Share on other sites

On 9/12/2021 at 8:50 AM, darkman222 said:

Okay, threads being merged. Thats fine. But it was my orignal thread I started months ago in the bug section being merged into this new one, and the orginal title and tags got lost. So it has now a very undescriptive and misleading  title like "egg mode" but it was about difficult locking behavior of the  ACM modes including JHCMS. Maybe that should be corrected.

Like I said , the tags are misleading now too, there are a lot of track files and videos about the issue and it also was moved out of the bug section that way.

 

Yeah, vest misleading, and they do that a lot. They love moving and deleting stuff. Even though some posts never broke the forum rule... It seems they just want to shape the dialogues to their favor. 

 

Edit: this post will probably also get deleted LOL. 


Edited by SCPanda
  • Like 2
Link to comment
Share on other sites

  • darkman222 changed the title to Target lock with HMCS - target designation box keeps falling behind target, losing lock (video +track)
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...