can not reproduce AGM-88 : cage/uncage doesnot work

[condor64]

Hello

Trying to use Harm in Too mode, cage/uncage doesn't work despite the sensor of interest is setting up into the good DDI ...

Anybody with the same problem ? Thanks

[razo+r]

No, worked for me two days ago. 

[BIGNEWY]

Not seeing a problem here, please include a short track replay showing the problem 

 

thanks

[tech_op2000]

6 hours ago, condor64 said:

Hello

Trying to use Harm in Too mode, cage/uncage doesn't work despite the sensor of interest is setting up into the good DDI ...

Anybody with the same problem ? Thanks

What behavior are you expecting or attempting with the cage/uncage button. Knowing that may help us identify the problem.

[antiload]

I had the same problem. I was going to send a TRK file, however, today it works.

Remember to make the screen SOI.

set RWR up.

I did all this yesterday but working today. Maybe just needed a restart? 

[Razor18]

I would maybe look up in the Controls, if pressing the Cage/Uncage button on your (I guess) joystick jumps onto the Cage/Uncage line in the controls list... ?

[Rongor]

On 10/14/2021 at 10:26 AM, condor64 said:

Hello

Trying to use Harm in Too mode, cage/uncage doesn't work despite the sensor of interest is setting up into the good DDI ...

Anybody with the same problem ? Thanks

I think from the wording he used it's obvious he expected to have cycling through emitters and handoff available without directing the SCS to the respective DDI showing the HARM page before.

So either the answer is, he just has to SCS to the HARM DDI before or if it is indeed a bug as expected by him.

I would be curious as well as I often stumbled about not being able to designate and handoff because I forgot to SCS to the HARM DDI. Seems a bit counterintuitive and inconvenient to have this mandatory SCS input as it's unclear how the cage/uncage and the RAID/FLIR FOV buttons could possibly bound elsewhere and be misinterpreted by the system in such situation.

 

In other words: why do we have to unlock handoff and cycling emitters by use of the SCS first?

 

I don't understand how this can be seriously tagged with

can not reproduce 

need track replay

Simply use the HARM and you can't prevent to notice. It's impossible to miss.

Edited November 11, 2021 by Rongor
I like editing stuff

[tech_op2000]

2 hours ago, Rongor said:

I would be curious as well as I often stumbled about not being able to designate and handoff because I forgot to SCS to the HARM DDI. Seems a bit counterintuitive and inconvenient to have this mandatory SCS input as it's unclear how the cage/uncage and the RAID/FLIR FOV buttons could possibly bound elsewhere and be misinterpreted by the system in such situation.

 

In other words: why do we have to unlock handoff and cycling emitters by use of the SCS first?

Raid/Flir FOV and Cage Uncage do all sorts of functions based on what sensor is sensor of interest. Lets assume for example you have the harm display on one screen and the Targeting pod display on the other. Both of these buttons have functions on the targeting pod. 
The aircraft needs a sensor of interest to be determined so it could determine what action the button should perform. SCS to the Harm display tells the system, "use these buttons to do harm actions instead of other actions these buttons can do"

 

 

2 hours ago, Rongor said:

I don't understand how this can be seriously tagged with

can not reproduce 

need track replay

Simply use the HARM and you can't prevent to notice. It's impossible to miss.

This specific forum thread was marked as such because the original poster has not yet provided any further information to help determine the exact cause of his bug. It cannot be reproduced with out further instruction from the O.P. about what conditions the O.P. was in when his Harms failed to uncage. In response to his question multiple users tested the Harms and did not encounter an issue like the O.P. stated. They do this because it is always possible that an update caused the system to start malfunctioning for everyone. Unless the original poster or another user can consistently reproduce an actual bug, the developers can not investigate the bug further. 

A track file is the best way to help users reproduce and identify a bug. It allows anyone who views the track to actually see the positions of every switch and button in the users cockpit. and what button presses were performed. It then allows a viewer to take over at any point and try something else to make it work. Its very helpful. 

That would be why it was marked accordingly.

If you are having issues with the current implementation or questions about why it is the way that it is, It may be helpful to start your own thread for it.

[Rongor]

2 minutes ago, tech_op2000 said:

Raid/Flir FOV and Cage Uncage do all sorts of functions based on what sensor is sensor of interest. Lets assume for example you have the harm display on one screen and the Targeting pod display on the other. Both of these buttons have functions on the targeting pod. 
The aircraft needs a sensor of interest to be determined so it could determine what action the button should perform. SCS to the Harm display tells the system, "use these buttons to do harm actions instead of other actions these buttons can do"

This may be very much so, yet the manual doesn't exactly tell what you claim here. The manual says the SCS decides on which DDI the TDC is working. Since you don't need the TDC on the HARM page AND the HARM section in the manual also doesn't mention the need of putting SCS onto the HARM DDI, the OP has every right to be curious.

 

6 minutes ago, tech_op2000 said:

This specific forum thread was marked as such because the original poster has not yet provided any further information to help determine the exact cause of his bug. It cannot be reproduced with out further instruction from the O.P. about what conditions the O.P. was in when his Harms failed to uncage. In response to his question multiple users tested the Harms and did not encounter an issue like the O.P. stated. They do this because it is always possible that an update caused the system to start malfunctioning for everyone. Unless the original poster or another user can consistently reproduce an actual bug, the developers can not investigate the bug further.

Maybe you should get better at reading what the OP described. He explicitly told us that it does work UNLESS he doesn't SCS to the HARM DDI. As we all know (and that is what you correctly mentioned above) this is exactly how it works in the current state of the Hornet. Why would we need a track file to follow a description of something that you and me can confirm? We don't.

A track file wouldn't have helped you understand the OP's instruction. Luckily I understood him much better and could explain it to you.

The OP asks for confirmation that SCS is needed to have the HARM controls work. The answer is probably yes. Do we know if it maybe should work without SCS if there is no current active TDC role on another sensor? The answer is no.

 

[tech_op2000]

2 minutes ago, Rongor said:

Maybe you should get better at reading what the OP described.

 

On 10/14/2021 at 3:26 AM, condor64 said:

Trying to use Harm in Too mode, cage/uncage doesn't work despite the sensor of interest is setting up into the good DDI

Sounds to me like he believed his sensor of interest was indeed on the harm display and the function of cage/uncage was not functional. specifically "sensor of interest is setting up into the good DDI"

 

4 minutes ago, Rongor said:

He explicitly told us that it does work UNLESS he doesn't SCS to the HARM DDI.

So, I would disagree with you about this statement.

[Rongor]

21 minutes ago, tech_op2000 said:

If you are having issues with the current implementation or questions about why it is the way that it is, It may be helpful to start your own thread for it.

Thanks for lecturing me.

[tech_op2000]

6 minutes ago, Rongor said:

Thanks for lecturing me.

I am sorry you feel that way. I guess I can cover it here then:

 

 

12 minutes ago, Rongor said:

This may be very much so, yet the manual doesn't exactly tell what you claim here. The manual says the SCS decides on which DDI the TDC is working. Since you don't need the TDC on the HARM page AND the HARM section in the manual also doesn't mention the need of putting SCS onto the HARM DDI, the OP has every right to be curious.

This is from the "DCS FA-18C Early Access Guide EN.pdf" Located in the install location, .../Mods/aircraft/FA-18C/Doc

Page 89:
RAID/FLIR FOV select button [I]. Depending on the controlled sensor or weapon, this button has multiple functions:
• Selects the RAID mode when the radar set operating mode is Track While Scan (TWS) or Single Target Track (STT).
• When HARM is selected, cycles HARM targets from center outwards.
• When ATFLIR or TGP is active, cycles between FOV settings.
• When in Maverick mode, toggles FOV.

 

To be fair, there is not a section for the NWS/Undesignate button that expressly says "depending on the controlled sensor or weapon" followed by "When HARM is selected, Hands-off target to Harm"

 

Page 287:
How to Employ the AGM-88C HARM in TOO Mode
1. Master Arm to ARM and Master Mode switch to A/G
2. Select HARM from the SMS page
***3. Set TDC to the HARM format page***
4. Press [I] to select / cycle detected radar emitters
5. Hand-off target to HARM by pressing Cage/Uncage button or [C]
6. With threat emitter boxed on EW Page or EW HUD with H-OFF indication, press weapon release button or [RAlt] + [Space] to launch the missile

 

[Razor18]

I think if we rather say SCS switch does not (just) sets the TDC to whichever DDI, but rather puts the Focus Diamond there (to show hich DDI is ready for any "action" on it), then we are a bit closer to a consensus?

[Nealius]

Quick switchology check: Is HARM override boxed? I’ve been having a lot of trouble with HARMS recently in all modes because of certain settings, like HARM override, being boxed by default and inhibiting launch or cage/uncage. I have to button-mash to unbox and box things before I can get handoff, or launch, to work.