fixed internally Helmet ACM functionality seems to be incorrect

[Arctic Fox]

The latest changes to the Viper's HMCS ACM acquisition function in today's OB patch are inconsistent with publicly available documentation on Viper helmet functionality (such as the MLU M3 handbook, for example): While the radar being commanded to slave to the helmet LOS and remaining silent as long as TMS Forward is held down is correct, the radar should explicitly remain slaved to the helmet LOS and continue to radiate until a target is acquired, a different mode is commanded or the LOS becomes invalid. The current behaviour in-game is that the radar will only attempt a HMCS acquisition at the moment TMS Forward is released, then revert to regular boresight acquisition immediately if a target is not acquired, which doesn't seem to make a lot of sense. The previous implementation of this feature seems to have been more in-line with what's described in the documentation.

[NineLine]

Based on our current information, we believe this is correct as is. If you have evidence otherwise, feel free to PM it to one of us.

Thanks!

 

[desolunatic]

1 hour ago, NineLine said:

Based on our current information, we believe this is correct as is. If you have evidence otherwise, feel free to PM it to one of us.

Thanks!

 

Might be correct but the radar in-game does not acquire the target inside the elipse when releasing TMS forward.

[Martinbulldog]

Yes, it is not locking correctly for me to after fix update.

Edited November 2, 2022 by Martinbulldog

[Vortex225]

Now that we have the correct ACM BORE HMCS behavior in the latest hotfix, which works just fine for me, I have two questions (not a bug report):

 

1) I'm noticing that I have no reference for when the ellipse is outside of the valid LOS range for the FCR. However, how are we supposed to know when we've moved the HMCS LOS too far to allow TMS Up (long press) to lock the target? Should the ellipse be dashed or crossed out or something to tell us the HMCS LOS is out of gimbal limits for the FCR?

2) Why does NO RAD show above the ACM BORE ellipse in the HMCS when we press and hold TMS up? Is this correct/intended?

 

Thanks in advance!

[0Leary10]

All 6 guys in our ACM training night were not able to use this functionality. Despite holding TMS forward short it and letting it go over a bandit within the helmets line of sight it did not give us a radar lock.

[NineLine]

We need tracks guys. If you feel you have an issue, a short track showing what you think is wrong and the expected behavior is needed. Thanks.

[Blinky.ben]

39 minutes ago, NineLine said:

We need tracks guys. If you feel you have an issue, a short track showing what you think is wrong and the expected behavior is needed. Thanks.

As soon as you press TMS forward it instantly shows NO RAD. I’m not having any luck locking in this mode either. It does seem as soon as TMS forward is pressed the Radar is set to quiet mode or similar effect. I will post a trk later today but the Devs will easily replicate this.

Edited November 3, 2022 by Blinky.ben

[Furiz]

4 minutes ago, Blinky.ben said:

As soon as you press TMS forward it instantly shows NO RAD. I’m not having any luck locking in this mode either. It does seem as soon as TMS forward is pressed the Radar is set to quiet mode or similar effect.

 

It shows NO RAD cause it waits for you to release TMS Forward, as soon as you release it it should snap the closest target in the ellipse and lock it.

Haven't tested yet tho.

Edited November 3, 2022 by Furiz

[Furiz]

4 hours ago, Vortex225 said:

1) I'm noticing that I have no reference for when the ellipse is outside of the valid LOS range for the FCR. However, how are we supposed to know when we've moved the HMCS LOS too far to allow TMS Up (long press) to lock the target? Should the ellipse be dashed or crossed out or something to tell us the HMCS LOS is out of gimbal limits for the FCR?

Out of limits reference will be added, work in progress.

 

4 hours ago, Vortex225 said:

2) Why does NO RAD show above the ACM BORE ellipse in the HMCS when we press and hold TMS up? Is this correct/intended?

When you release TMS forward it will attempt to lock the target in the ellipse.

[nickos86]

11 hours ago, NineLine said:

Based on our current information, we believe this is correct as is. If you have evidence otherwise, feel free to PM it to one of us.

Thanks!

 

Please check MLU3 for example. Honestly, I can't understand how you interpreted the text to the behavior you've implemented - it doesn't make any operational sense. 

[Blinky.ben]

47 minutes ago, Furiz said:

It shows NO RAD cause it waits for you to release TMS Forward, as soon as you release it it should snap the closest target in the ellipse and lock it.

Haven't tested yet tho.

 

Ok thanks for the info

Edited November 3, 2022 by Blinky.ben

[BIGNEWY]

To be clear, when TMS forward is held, only then will the radar be slaved to the HMD LOS as indicated by the ellipse.

Until TMS is held forward, the radar will not LOS slave.

Then releasing TMS forward commands the radar to auto-track the best target it detects within the ellipse


We are aware of the ellipse position and X based on radar gimbal and it will come in a future patch

Thank you

[desolunatic]

9 hours ago, NineLine said:

We need tracks guys. If you feel you have an issue, a short track showing what you think is wrong and the expected behavior is needed. Thanks.

Here you go - hope it helps. At first was able to get a lock or two, but after getting closer was unable to lock the F18. Before the update pointing with the helmet felt super consistent in situations like these.

f16jmcs.trk

Edited November 3, 2022 by desolunatic

[BIGNEWY]

55 minutes ago, desolunatic said:

Here you go - hope it helps. At first was able to get a lock or two, but after getting closer was unable to lock the F18. Before the update pointing with the helmet felt super consistent in situations like these.

f16jmcs.trk 1.04 MB · 0 downloads

 

Hi, 

thanks for the track, but this is a different issue and has already been reported, it happens with very close targets and the radar not keeping up with the quick close in changes. Will be fixed in a future update.

The HMCS functionality is correct based on the information we have. 

thank you

[Burner_]

48 minutes ago, BIGNEWY said:

Hi, 

thanks for the track, but this is a different issue and has already been reported, it happens with very close targets and the radar not keeping up with the quick close in changes. Will be fixed in a future update.

The HMCS functionality is correct based on the information we have. 

thank you

Its now harder to get a lock in boresight now. Especially in a close dogfight because it seems that the radar doesn't slave to the hmd when tms up is held so whenever its released it must take a second or two to slew over and that misses the target. It also continues to scan in that area off boresight despite having the boresight cross in the hud. 

Track files show the behavior where you cannot get a lock while rolling (or a moving target) and tracking the target because of the delay. Usually you would have the radar follow the hmd so you could track the target and have time to search.

https://we.tl/t-1RCKguVmOa 

[Martinbulldog]

1 hour ago, Burner_ said:

Its now harder to get a lock in boresight now. Especially in a close dogfight because it seems that the radar doesn't slave to the hmd when tms up is held so whenever its released it must take a second or two to slew over and that misses the target. It also continues to scan in that area off boresight despite having the boresight cross in the hud. 

Track files show the behavior where you cannot get a lock while rolling (or a moving target) and tracking the target because of the delay. Usually you would have the radar follow the hmd so you could track the target and have time to search.

https://we.tl/t-1RCKguVmOa 

Yes, I agree the bore mode feels awful now. I only fly on dogfighting gun servers, and I cannot get locks or its very slow. Back to the 60 Scan for me.

Edited November 3, 2022 by Martinbulldog

[BIGNEWY]

1 hour ago, Burner_ said:

Especially in a close dogfight

Yes as mentioned we have an issue that is more noticeable at close ranges. its a different issue and the team will be working on it soon

7 minutes ago, Martinbulldog said:

the bore mode feels awful now

it may do but it is correct. 

 

[Hobel]

Zitat

DCS: F-16C Viper by Eagle Dynamics

• Updated ACM BORE HMCS logic. Hold TMS Forward to slave radar to HMCS line-of-sight and display the ellipse. When TMS Forward is released, the radar will attempt to lock the nearest contact within the ellipse out to 10 nm.

"slave radar" only this is not the case at the moment the radar does not slave but waits at the old position until you release TMS Forward, this is a bug.

Edited November 4, 2022 by Hobel

[Brody]

20 hours ago, NineLine said:

We need tracks guys. If you feel you have an issue, a short track showing what you think is wrong and the expected behavior is needed. Thanks.

was able to figure out how the bug is working atm. it seems initially you cant get brst acq to work and the HSD shows a wider scan zone than it should be, and the tms up release acquisition wont work no matter how many times you attempt, but if you switch to any other ACM mode and then go BACK to tms up boresight acquisition, then it works, and this is also reflected by the little pencil beam radar scan zone on the hsd (which moves every time you release tms up to that position and stays static until tms released again). you can see this in the track file. 

so for players an easy workaround the bug in the meantime is to hit dogfight mode and quickly to like, tms right for hud scan for instance, then immediately hit tms up and the new tms up and release mechanic works as intended, however if you go back to bvr scope and move the radar cursor around and adjust the antennae a bit, youre able to replicate the bug when going back into dogfight mode

tldr theres something wrong with getting the mode to actually start working initially, fix is toggle acm modes for a quick second, then it works, and im sure this is easy fix on ED side (i hope). all of this demonstrated in the track file

F16brstacqbug.trk

Edited November 4, 2022 by BrodyZ_ch

[Mysty]

12 hours ago, BIGNEWY said:

To be clear, when TMS forward is held, only then will the radar be slaved to the HMD LOS as indicated by the ellipse.

Until TMS is held forward, the radar will not LOS slave.

Then releasing TMS forward commands the radar to auto-track the best target it detects within the ellipse


We are aware of the ellipse position and X based on radar gimbal and it will come in a future patch

Thank you

Ok, but to answer the initial question, should the NO RAD be shown above the elipse when holding TMS forward?  

[BIGNEWY]

3 hours ago, Mysty said:

Ok, but to answer the initial question, should the NO RAD be shown above the elipse when holding TMS forward?  

yes, its not until you release that the radar will try to snag the target 

 

[Hobel]

vor 8 Stunden schrieb BrodyZ_ch:

was able to figure out how the bug is working atm. it seems initially you cant get brst acq to work and the HSD shows a wider scan zone than it should be, and the tms up release acquisition wont work no matter how many times you attempt, but if you switch to any other ACM mode and then go BACK to tms up boresight acquisition, then it works, and this is also reflected by the little pencil beam radar scan zone on the hsd (which moves every time you release tms up to that position and stays static until tms released again). you can see this in the track file. 

so for players an easy workaround the bug in the meantime is to hit dogfight mode and quickly to like, tms right for hud scan for instance, then immediately hit tms up and the new tms up and release mechanic works as intended, however if you go back to bvr scope and move the radar cursor around and adjust the antennae a bit, youre able to replicate the bug when going back into dogfight mode

tldr theres something wrong with getting the mode to actually start working initially, fix is toggle acm modes for a quick second, then it works, and im sure this is easy fix on ED side (i hope). all of this demonstrated in the track file

F16brstacqbug.trk 442.79 kB · 1 Download

 

Unfortunately, this is not a work around.

The radar should follow TMS UP held, but it doesn't, it slews to the new position only after releasing, which can also lead to unwanted effects

[Sacarino111]

Hi. After some trys,I found that the first atempt to get the elipse do not work, but after the second TMS up, the thing works "normal"; the elipse apears, and If I manage to place the elipse over the target and release TMS the radar will lock, although it take some time, so much that sometimes I think it did not work so I repeat the procedure  another time, or many times until lock.

Can't tell if that is a correct behaviour, but that is what I found.

Saludos.

Saca111

[Dobbie93]

Looking at the MLU_M3 document, the following is stated:

"Slaving FCR ACM BORE without a TOI (FCR Not Locked On) When ACM BORE is selected and TMS-forward is held, the radar is slaved to the HMCS Aiming Cross LOS in a non-radiating state. The FCR ACM BORE ellipse is displayed on the HMCS at the FCR LOS. The radar is commanded to radiate when TMS-forward is released (Figure 6-33). The radar automatically attempts to acquire a target in the ACM BORE ellipse when TMS-forward is released.

The FCR is slaved to the HMCS LOS until one of the following occur: 1. The radar acquires a target. 2. The radar transitions out of ACM BORE mode. 3. TMS-right with TGP tracking an A-A target. 4. The radar stops communicating on the Mux. 5. The HMCS LOS becomes invalid. 6. The HMCS stops communicating on the Mux. 7. A TMS-aft occurs.

Note that if the HMCS LOS is moved past the FCR gimbal limits, the avionic system continues to try to slave the FCR LOS to the HMCS LOS even though the FCR gimbal limits have been reached."

Current implementation appears to respect the first paragraph but ignores the second paragraph on the following page (pages 76+77)