fixed internally Helmet ACM functionality seems to be incorrect

[Geraki]

the eclipse right now, does not lock target when going in it at all.

Edited November 5, 2022 by Geraki

[Alon_D]

Hello everyone

Since the last update No lock in Dogfight when TMS UP ,No Radar works  No lock

TMS UP and continues to press TMS up I see the circle but No Radar works and  No lock

When  TMS Down Everything seems fine

Normal behavior or Bug  ?

 

[Falconeer]

you might wanna take a look at the recent patch notes

 

[MRTX]

Although this obviously seems to be correct for M3, my biggest question is if really nothing about the hotas commands and functions has changed with newer tapes up to M5.1 ?

[Hugoslav]

Today I came across the same problem, but finally found out what's going on with HMCS logic. So here is a quotation from ED's "DCS 2.8.0.32235.1 Open Beta" changelog that should explain it: 

• 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. 

-so you have to hold TMS forward when aiming and release it when aimed on your target, than radar will attempt to lock a target

I don't understand why it's like that, to me it seems very impractical and it doesn't meke sense to meke it like this IRL. But hey, it is what it is. If it's realistic now, than it's very impractical but we have to deal with it and if not then hope ED will fix it.

[NineLine]

We are doing 4.2+, not 5.1.

[MRTX]

vor 34 Minuten schrieb NineLine:

We are doing 4.2+, not 5.1.

Sorry my bad.

[nitehawkx]

55 minutes ago, Hugoslav said:

Today I came across the same problem, but finally found out what's going on with HMCS logic. So here is a quotation from ED's "DCS 2.8.0.32235.1 Open Beta" changelog that should explain it: 

• 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. 

-so you have to hold TMS forward when aiming and release it when aimed on your target, than radar will attempt to lock a target

I don't understand why it's like that, to me it seems very impractical and it doesn't meke sense to meke it like this IRL. But hey, it is what it is. If it's realistic now, than it's very impractical but we have to deal with it and if not then hope ED will fix it.

While your statement that this is the INTENDED function is true, in practise this is not what is happening in DCS at the moment. 

"Hold TMS Forward to slave radar to HMCS line-of-sight and display the ellipse"

This is the specific area that is not working properly. As stated, upon holding TMS Forward, the radar is meant to slave to the HMCS LOS. At the moment, the radar is not slaving until AFTER release of TMS Forward. This is causing a delay for us to wait for it to slave THEN search, rather than immediately searching when released as the funtion is intended to do. 

If I am interpreting this incorrectly please advise. 

 

Edited November 5, 2022 by nitehawkx

[Arctic Fox]

21 minutes ago, nitehawkx said:

While your statement that this is the INTENDED function is true, in practise this is not what is happening in DCS at the moment. 

"Hold TMS Forward to slave radar to HMCS line-of-sight and display the ellipse"

This is the specific area that is not working properly. As stated, upon holding TMS Forward, the radar is meant to slave to the HMCS LOS. At the moment, the radar is not slaving until AFTER release of TMS Forward. This is causing a delay for us to wait for it to slave THEN search, rather than immediately searching when released as the funtion is intended to do. 

If I am interpreting this incorrectly please advise.

The problem is that the radar should remain slaved to the HMCS LOS until commanded to do otherwise, rather than revert to HUD boresight at the instant the TMS is released if it can't find a target. All publicly available manuals are clear on this. The Hornet works like that as well. And it just makes sense, especially if you consider that the helmet might be slightly misaligned which would make such instantenous function useless.

If ED's M4.2+ documentation or SMEs say otherwise then I will be very surprised, but I can't challenge them. All I'm asking is that they double check they haven't missed anything, because I find it hard to believe it works like it's currently implemented in the game.

[nitehawkx]

10 minutes ago, Arctic Fox said:

The problem is that the radar should remain slaved to the HMCS LOS until commanded to do otherwise, rather than revert to HUD boresight at the instant the TMS is released if it can't find a target. All publicly available manuals are clear on this. The Hornet works like that as well. And it just makes sense, especially if you consider that the helmet might be slightly misaligned which would make such instantenous function useless.

If ED's M4.2+ documentation or SMEs say otherwise then I will be very surprised, but I can't challenge them. All I'm asking is that they double check they haven't missed anything, because I find it hard to believe it works like it's currently implemented in the game.

I'll have to do further testing then, because from what I remember the radar was staying in the boresight position that it was last in when TMS FWD was released.

[Mareno]

Am 4.11.2022 um 01:25 schrieb Hobel:

"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.

 

@NineLineHobel has it right here thats the problem in case you did not see it. Should clear up the discussions here. This is what everyone means but does not express properly Cheer

[NineLine]

1 hour ago, Mareno said:

@NineLineHobel has it right here thats the problem in case you did not see it. Should clear up the discussions here. This is what everyone means but does not express properly Cheer

Yes, that part is already reported, thanks.

2 hours ago, Arctic Fox said:

The problem is that the radar should remain slaved to the HMCS LOS until commanded to do otherwise, rather than revert to HUD boresight at the instant the TMS is released if it can't find a target. All publicly available manuals are clear on this. The Hornet works like that as well. And it just makes sense, especially if you consider that the helmet might be slightly misaligned which would make such instantenous function useless.

If ED's M4.2+ documentation or SMEs say otherwise then I will be very surprised, but I can't challenge them. All I'm asking is that they double check they haven't missed anything, because I find it hard to believe it works like it's currently implemented in the game.

Indeed out devs/SME/docs say otherwise. Thanks. 

[SparxOne]

4 hours ago, Hugoslav said:

Today I came across the same problem, but finally found out what's going on with HMCS logic. So here is a quotation from ED's "DCS 2.8.0.32235.1 Open Beta" changelog that should explain it: 

• 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. 

-so you have to hold TMS forward when aiming and release it when aimed on your target, than radar will attempt to lock a target

I don't understand why it's like that, to me it seems very impractical and it doesn't meke sense to meke it like this IRL. But hey, it is what it is. If it's realistic now, than it's very impractical but we have to deal with it and if not then hope ED will fix it.

I also feel it's very impractical, i'd love to know the reasoning behind such a thing.

The way i see it and used it before this change was basically having the ability to direct my radar in a precise beam (The ellipse) with my helmet line of sight and catch any target my eyeball wouldn't see.

It was useful when flying in the mountains and having difficulty actually spotting a target just under the 10 mile limit ACM mode, sometimes while slaving the ellipse around just looking i'd pick a target and therefore it would allow me to react instantly even if the target was 50° left or right. Now this would be impossible without using the HUD front scan or 10° vertical scan which are fixed facing forward, meaning any targets not directly in the rather small facing cone would go unnoticed by my radar. (Bold part : Who would go about constantly pressing TMS up while looking around to achieve the same result we used to have by just looking around and pressing nothing ?)

Another aspect i find impractical is the simple fact that when in a dogfight turning around each other, it just felt way more logical to only have to aim your helmet sight with the ellipse on the target and let the radar lock as soon as possible (Probably faster than what we can achieve with the normal human lag ~200ms, especially considering sometimes the target would pass in that ellipse for a split second), rather than now having to either constantly keep TMS up until target gets lined up in the ellipse, or having to manually press TMS up everytime the targets falls into the ellipse, to me that just feels like an unnecessary step the pilot has to take when it could be done automatically by only looking at the target and letting the radar do its thing.
The less  steps there is to do something, the easier it is and more convenient no ? Here we are adding a step for a reason i cannot think of.

Edited November 6, 2022 by SparxOne

[Dobbie93]

@NineLine can your SMEs confirm that the implementation changed between M3 and M4.2+? Because M3 is pretty clear that the radar remains locked to the hmd until otherwise told once cued, and whilst I know defence organisations make some weird decisions, making it harder for the aircraft designed to be a dogfighter to get a lock whilst in a dogfight makes no sense even for them. Thanks

[Hobel]

 

Am 2.11.2022 um 19:09 schrieb Arctic Fox:

TMS Forward is held down is correct, the radar should explicitly remain slaved to the helmet LOS and continue to radiate

"continue to radiate" with TMS UP held?
are you sure, check this again more closely in M3.


small hint

"BORESIGHT NO RAD
BORESIGHT RAD UPON RELEASE"

 

[Arctic Fox]

10 minutes ago, Hobel said:

"continue to radiate" with TMS UP held?
are you sure, check this again more closely in M3.


small hint

"BORESIGHT NO RAD
BORESIGHT RAD UPON RELEASE"

I literally said that NO RAD while TMS Forward is held is correct, my concern was what happens after TMS Forward is released.

Edited November 6, 2022 by Arctic Fox

[Hobel]

vor 15 Minuten schrieb Arctic Fox:

I literally said that NO RAD while TMS Forward is held is correct, my concern was what happens after TMS Forward is released.

 

yes i see my mistake.

[Arctic Fox]

Looking back at my original message my wording wasn't super clear about that, so no worries.

[bukizzzz]

I can't grasp the fact that the designers would downgrade a piece of kit in a newer block

I'm not a betting man but if I had to bet I'd say ED is wrong here 

Would love to see the source behind this logic considering that ED uses publicly available documentation so it would clear things up imho

[janitha2]

I feel like this is almost like the tms and dms logic where in earlier patches we had to guess o.5 seconds and then let go. Hopefully we can get this figured out

[bukizzzz]

Should work the same as designating mark points or vis mode with JHMCS

TMS fwd long to slave to JHMCS boresight and remain slaved

I assume that logic should apply to everything possible with the helmet by design (for simplicity/universality)

[JTFF-Marco]

Not quoting anything so hopefully my message doesn't get deleted.
I remember reading that in the later tapes (M5), the logic was the same as described earlier in this thread in the M3 docs. The FCR stays cued to the HMCS LOS and radiating after TMS fwd has been released. So It would be very surprising that they changed it only for the M4.2+ jets...
 

 

[hooti]

It seems, from my point of view, the manual got missinterpreted by ED. They concentrated on the first part of the behaviour which is clearly "correct as is" (without the reported bug) but do not pay attention to the second part (Page 77 MLU M3 Manual). And the second part describes implicitly what should happen after TMS is released -> the FCR will try to lock within the ellipse (clear part) and if there is nothing to lock, will stay slaved to the LOS as long as no event of page 77 will happen. This part would make no sense, if you always have to do TMS FWD to slave the ellipse/FCR. And I can't imagine that this behavior has changed from M3 to M4.2 and then back to M5, as mentioned the post before.

[SparxOne]

21 minutes ago, JTFF-Marco said:

Not quoting anything so hopefully my message doesn't get deleted.
I remember reading that in the later tapes (M5), the logic was the same as described earlier in this thread in the M3 docs. The FCR stays cued to the HMCS LOS and radiating after TMS fwd has been released. So It would be very surprising that they changed it only for the M4.2+ jets...
 

 

I have no official manuals what so ever, but either way, even not being a fighter pilot myself, i just can't get around the current implemented logic of this, it feels impractical at most to have to manually press TMS up while looking at your ennemy to get a lock, why add a step to the pilot, especially in a stressful situation like a dogfight, while both other ACM modes will lock automatically without pilot input ? The current method just adds a reason to fail on acquiring a lock because reasons while maneouvering in a dogfight.

It made total sence that all 3 ACM modes worked the same in terms of locking up a target, pilot selects the mode he wants to use -> Boresight slaved to the HMCS, Vertical scan or the 20° HUD scan. When one of the modes would be selected, that is all that remained to be done, now the pilot just had to fly his plane accordingly to get a target in the respective mode scan area and the radar would lock first target it found in each modes.

How does it make sense that the Boresight mode requires a manual input from the pilot to lock the target and not the 2 others, i can't find any logical reason to that.

 

[NineLine]

45 minutes ago, SparxOne said:

I have no official manuals what so ever, but either way, even not being a fighter pilot myself, i just can't get around the current implemented logic of this, it feels impractical at most to have to manually press TMS up while looking at your ennemy to get a lock, why add a step to the pilot, especially in a stressful situation like a dogfight, while both other ACM modes will lock automatically without pilot input ? The current method just adds a reason to fail on acquiring a lock because reasons while maneouvering in a dogfight.

It made total sence that all 3 ACM modes worked the same in terms of locking up a target, pilot selects the mode he wants to use -> Boresight slaved to the HMCS, Vertical scan or the 20° HUD scan. When one of the modes would be selected, that is all that remained to be done, now the pilot just had to fly his plane accordingly to get a target in the respective mode scan area and the radar would lock first target it found in each modes.

How does it make sense that the Boresight mode requires a manual input from the pilot to lock the target and not the 2 others, i can't find any logical reason to that.

 

I cant answer why it might not make sense or anything else, but this doesn't match the MLU documents according to the team, sorry.