Swift.

Yeah NATOPS doesn't mention anything about the stick having to be centred for AP engagement. All it specifies is that roll angle must be less than or equal to 70 degrees and pitch angle less than or equal to 45 degrees. But regardless of what the real jet does (although I still maintain the above), in DCS we dont have the real jets stick. So compensations must be made, and the required compensation here is to allow an AFCS engagement deadzone, separate to that of the normal stick.

Best bet would just be to leave FD alone I think

In my experience it works alright for level med to high altitude delivery. There was an odd thing with climbing deliveries, where the LAR was changing shape but not accurately representing the actual capabilities but I can't quite remember the bug. Additionally it's possible (I wish) that the low altitude LAR inaccuracies have been modelled properly

Can we have some single action bindings for the Parking Brake and Emergency Brake? So that instead of for example: CCW and Pull. We can just bind Parking Brake ON, or Parking Brake ON else OFF, or similar? Would be super helpful to those with physical cockpits built up, who don't have the complicated Parking Brake handle mech that the real hornet has.

Is that LUU-2 or LUU-19 that will be detected by a heat seeker? LUU-19 should also be carried by our hornet, but would require a bit more 3d art work, than the LUU-2.

That'll be because FD mode (not yet implemented) can be used with the AP via the same CPL. Does it return to normal when you select MAN or AUTO?

Related aswell

Your stick has to be perfectly centred for it to engage. I've been asking ED for an option to loosen this engagement zone, but what we have is what we have.

Alright thanks for trying, maybe the root cause will be eventually be uncovered organically anyway. Its not like its a major impact on the day to day.

I had a little bit more trouble reproducing it today, took more than 2 attempts for it to fail. See 1:13 in the video for the failure mode. I'm fairly confident its not my undesignate button as the pressing of that button will remove the TGT symbology from all displays other than the HSI. If the button was broken I'd expect it to do nothing. The track still works and shows the error state after 2 attempts.

I'll create an accompanying video tonight, to help demonstrate things. Thanks

And not just that, but whether or not the pod drifts is dependent on whether the pilot attempts to slew before pressing TDC. This is not a report for an inaccuracy in the modelling, but simply a report of a breakdown of logic. Having the behaviour change due to unrelated inputs prior to a sequence of events is a good and proper bug in the code.

That is correct, what I'm seeing is it staying as TGT

How fast are you when you are trying to trim? If you try to trim onspeed at 200 kts, you are going to nose up to the moon

It must be, considering how all the SMEs are saying the rotor doesnt have enough inertia