missing evidence HTS/HAD Steerpoint Bug

[Vortex225]

I believe I found a bug with the HTS/HAD and how it changes the steerpoint diamond location in the HMCS after producing a SPI with the HAD as SOI. A trackfile is provided to demonstrate the incorrect behavior against an SA-2 site on the Syria map. 2x Harms are loaded on stations 3 and 7.

 

After slewing the HAD cursor to a surface radar-emitter on the HAD, TMS Forward/Up will designate the emitter (e.g., an SA-2 in the trackfile) and perform a handoff to a HARM. This all works as intended, including the creation of a SPI; however, the trackfile also shows how this process currently changes the location of the steerpoint diamond in the HMCS as well. This is demonstrated in the trackfile by the steerpoint diamond symbol switching positions to the location of the new SPI (i.e., the box) set by the HTS/HAD. I believe the correct behavior would keep the steerpoint diamond at the location of the current steerpoint as indicated on the DED.

 

To further demonstrate the bug, I cycle the current steerpoint from STP 1 up to STP 2 and back to STP 1 to show how the steerpoint diamond in the HMCS should be in a different location than the SPI set by the HTS/HAD. Doing this in the trackfile resets the steerpoint diamond to the correct location (i.e., the current steerpoint) with the SPI remaining in place based on the data from the HTS/HAD. I then repeat the process again after cycling the current steerpoint, at which point TMS Forward/UP on an emitter causes the steerpoint diamond to again change to the location of the SPI.

 

Thank you in advance!

hts_stp_spi_bug.trk

Edited August 22, 2022 by Vortex225

[Vortex225]

I just noticed the missing evidence tag. Thank you for taking a look. However, I'm not sure exactly what this means. Could a moderator explain so I could make another attempt?

 

I thought the trackfile did a good job of showing the HTS/HAD designation action changing the Steerpoint diamond, which doesn't make any sense. It should create or move the SPI, just like the TGP or FCR --not update the steerpoint diamond.

 

Please let me know how I can improve the bug report. Thanks again for your consideration. 

[rob10]

On 8/21/2022 at 10:25 PM, Vortex225 said:

I believe the correct behavior would keep the steerpoint diamond at the location of the current steerpoint as indicated on the DED.

Typically that tag would mean they are looking for you to provide evidence to support your belief of what the correct behaviour is (i.e. evidence to show it should be the way you think, rather than you just thinking it should be that way).

Edited August 23, 2022 by rob10

[Frederf]

I'd watch the track but I don't have Syria installed.

HARM delivery POS/DL is an A-G preplanned mode (like CCRP) which should mean that the TD box and the steerpoint are one and the same (except HRMVRP/HRMVIP which can have the TDB and diamond displaced). In preplanned AG modes it's normally the case that slewing TD to a target also moves the steerpoint. It's basically the reason "CZ" function exists. If the system is modeling HARM POS like CCRP then the steerpoint moving to the target is correct behavior. HARM-HAS is a visual delivery mode so you should see the diamond in there (similar CCIP).

Seeing the diamond and TD box at the same time in a preplanned mode at any time* is a bug. In a simple test I had diamond in HUD FOV and designated HAD which deleted the diamond and put TD box on HAD threat. The initial pre-HAD-designation is (I think) wrong. System is in HARM POS delivery mode which would be directed toward steerpoint. Designating on HAD isn't its own mode or anything. It's just a way to get the steerpoint moved. HAD is an optional sensor for HARM POS just like TGP is an optional sensor for CCRP. TD box should exist before HAD designation. And in both cases TD box covers up the diamond because steerpoint is target is SPI. Also "STP" in sighting point rotary should say "TGT" because this isn't a NAV or FIX mode.

Parts that are wrong is that HAD (POS) designation should break on steerpoint reset/change. You cannot have a HAD designation and change steerpoint. By changing or CZing or switching visual AG, etc. will cause the designation to drop.

*The only time diamond and TD should both be displayed at the same time is VIP/VRP such that diamond and TD box are not coincident.

 

[Furiz]

@Frederf I think this is what he means, that STP rectangle moves with the HTS created SPI. Noticed this a week ago too.

second HAD designation on the SA6 emitter

Caucasus map

HTS - STP.trk

[Vortex225]

4 hours ago, Furiz said:

@Frederf I think this is what he means, that STP rectangle moves with the HTS created SPI. Noticed this a week ago too.

second HAD designation on the SA6 emitter

Caucasus map

HTS - STP.trk 121.56 kB · 1 download

@Furiz Appreciate the assist with the additional trackfile on the Caucasus map. That is exactly the issue; the STP diamond is repositioned to the SPI produced by the HTS/HAD system. I don't understand why this would happen, as the diamond should always be associated with the active steerpoint. While it's possible to use CZ to force the SPI to return to the STP diamond location, I don't understand why it would make sense for a target designation to force the reverse behavior (save for markpoints, which are a different story). 

 

@Frederf Thanks for your input. I think most of your comments go beyond the scope of the bug report, but I may have misunderstood your line of thinking (which is probably more advanced than mine). I chose a simple test with HARMs in EOM mode using the HTS/HAD system to produce a SPI. The bug, or what I think is a bug, is that the STP diamond changes to the position of the SPI as set by the HTS/HAD system. Hopefully this better explains what I perceive as the problem or allows you to see the flaw in my reasoning. 

 

  

Edited August 23, 2022 by Vortex225

[Frederf]

There are some subtleties to the language regarding F-16 locations that's not quite right. In an A-G preplanned mode with direct aimpoint sighting the steerpoint and target are coincident. The steerpoint does and should move. What's confusing is that HUD (HMCS) symbols are layered with occlusion priority so sometimes  the diamond can't be seen because it's "under" or occluded by the TD box. The situation we get in DCS where you can see the "diamond in the box with dot" should never happen because if TD and diamond are together then diamond is not visible. No diamonds are displayed in preplanned modes except when they denote the RP (VRP) and is not a steerpoint or when it denotes IP (VIP) when it is a steerpoint. In VIP case the diamond will be steerpoint but TD box won't be so they can co-exist. The TD box will still occlude IP/STPT diamond if they overlap in the HUD. If you are in an A-G preplanned mode and don't have VIP or VRP enabled and see a diamond in your HUD/HMCS it is a bug.

Because DCS has an error where you see the diamond in the wrong spot in CCRP I'm using CCRP VIP to demonstrate symbol occlusion.

I have placed TGT (TD box) between me and the diamond (1nm closer) but since it is at 0' and I have altitude diamond and TD are not overlapping. Next I will raise up the target by a few hundred feet so it overlaps (lies along same LOS) and you'll see TD occlude diamond. Note that it doesn't matter which symbol is physically closer. Even if TD is physically farther away than diamond it will have higher priority.

null Raised 150', half of diamond occluded

Raised 300', all of diamond occluded.

This is what should happen at all times when TD and diamond are in the same place. Now I'll show how normal CCRP is wrong by slewing TD box around and seeing that diamond remains in one place (it should move and always be "under" the TD box). It does occlude correctly though.

See how slewing steerpoint doesn't move diamond? This is wrong behavior. In CCRP you are absolutely moving the steerpoint (well you're not actually moving it but you're adding cursor corrections and the diamond is placed at steerpoint plus cursor correction, same result) and thus the diamond. Because in direct sighting the TGT is the STPT the TD box will be where the steerpoint is so TD box and diamond will always perfectly align and diamond will never be visible.

Anyway, look at HARM symbology. First we look at normal HARM POS (EOM) HUD which is designated without HAD (simply current STPT)

Steerpoint = target so TD box is right over steerpoint ahead, perfectly normal. You should be able to slew the STPT/TD using HUD SOI or FCR SOI just like CCRP and we can't in this version. Now we try designating using HAD...

This is nonsense. Diamond doesn't belong on HUD at all here in any position (well, it should be under TD box thus invisible). Steerpoint has been moved by HAD/HTS in a similar way that it would be moved by TGP/Litening with normal bombs. Notice how designating with HAD will change the bearing to NAV destination on HSI between your knees, again because it is moving the steerpoint so make sure to CZ after using HARMs in this way.

Edited August 24, 2022 by Frederf