FalcoGer

I got thrustmaster pedals and they work just fine. They did change the heading hold logic though.

The control measure with ident "BR" is mislabeled as "Brigade or Gap" when it should be "Bridge or Gap" Evidence for this can be found in appendix C of the forbidden book. And also in your own manual.

When selecting Quick Action mission and select "Tblisi Guard" the VHF radio starts with 305MHz. But that's a UHF frequency that the VHF radio can not be tuned to.

I altered the mission and added a group disable trigger. I now get the ERR! to show, but it doesn't crash the game. Ah64Issues.miz target_deactivated_while_list_open.trk

There is a grammar error in the tooltip for Full Screen in the options menu. It reads But it should probably be Also the tooltip for sharpening is it probably isn't supposed to do that.

Right now it's nearly impossible to kill units in the woods. They're nearly impossible to spot and even if you know exactly where they are, you can't hit them with anything but penetrating bombs. Even bullets from the M230 just get caught on the impenetrable canopy with not even a probability of passing through the leaves and branches. This is a problem particularly with dynamically generated enemy units. I thereby propose that some weapons will be able to destroy trees and/or set them on fire. Alternatively small caliber weapons should have a chance to pass through the branches, depending on the tree type and the weapon diameter in question. The more a tree is hit, the higher the probability of any subsequent shots (as the branches get destroyed)

How do you get a track if the game crashes? couldn't reproduce... Maybe it's deactivation and not destruction? target_destroyed_while_list_open.trk but feel free to try it yourself Ah64Issues.miz

It was never sold. It's free for everyone.

I've found when trying to set autohover, the aircraft will bank too much to arrest the tiniest movement and overshoot. This repeats 3 or 4 times before it eventually comes to a hover. The PID needs tuning.

Is this planned? I'm not sure how the F10 altitude maps are generated, but the same data the F10 altitude maps are generated from could be used to render FFD features directly or generate an overlay to turn on or off separately from the background map. It's a lot of data, so it's probably best to have a rasterized, per-rendered version for each map

But why is this in wish list?

In the mission editor there is an option for "Aircraft control priority", which allows one, both or no pilot to take controls without a pop up happening to ask for permission on the other pilot's screen. This option should be decided by each pilot individually, not the mission maker, who already has enough other things to configure and will likely not ask every pilot who wants to fly their mission what their preference is. This is a pilot preference, not a mission parameter and so it should be an option for each person flying, and not a setting in the mission. Either Add one option "Permission pop up if other crew member wants control: yes / no", or Add the same aircraft priority options and then use the pilot's preference in the actual aircraft and ignore the CPG's setting

What the title says. I have bound the "KU Key - T" keybind to LCTRL + LALT + T. When I press that combination in the control options, it jumps to the correct key bind, but when I press it in the game, nothing happens. The default key bind of LCTRL + LWIN + T works correctly.

I've noticed similar issues where it would go quickly to one side and when i gently tried to correct it, it would wildly swing to the other side without slowing down. The range was correct, it wasn't a ranging issue.

Also curiously for the PLT track, no rotor RPM audio warning.

@Lord Vader Just confirmed it with the engine page. But it also happens with the TSD/ASE autopaging. To reproduce: PLT joins hot AH64 CPG joins same aircraft CPG brings up A/C -> Utility on the left MFD PLT causes engine autopage by pulling collective too fast or other faults CPG presses buttons where FMC toggles used to be PLT gets FMC disengaged, CPG does not Sever track is me, CPG, self hosted. server-20231021-053740.trk Client track is my buddy causing the engine autopage. Ah64Issues-20231020-214022.trk

I removed all the mods from current hill. Now it works properly. Or at least that's what I think fixed it maybe? In any case I can't reproduce this anymore.

I believe I finally figured out why there are certain desyncs happening. I was flying with someone, as CPG, and was on the A/C -> UTIL page when a new emitter popped up and set the right MFD to TSD via autopaging. I then went into UTIL (on the TSD page) and hit L1 for an INU1 Reset. At the same time my copilot complained about an "FMC disengaged" message and sure enough on his end the Pitch FMC channel was disengaged (L1 on the A/C -> UTIL page), but it was not on my end. Whenever he switched it on henceforth would turn it off for me and vice versa. I believe the bug results from the back seat client not knowing that autopaging has occurred in the front seat. Will provide a track as soon as I reproduced this.

When loading a mission (2.9.0.46801), all the mission triggers fire at the start of the mission, regardless of their condition. Before the update they worked fine. For example when loading the hunting grounds mission ( https://www.digitalcombatsimulator.com/en/files/3321127/ ) or operation vetka ( https://www.digitalcombatsimulator.com/en/files/99420/ ), all the triggers fire at once, even before entering an aircraft. single player and self hosted. May or may not be related to hidden units not being considered alive (where previously they would be). To reproduce the issue: Load one of the missions mentioned above Unpause Get bombarded with all the voice messages for arriving at locations and having destroyed units at once I tried loading the mission in the mission editor and re-saving it, but that didn't do anything to fix the issue.

from what I can tell, the missile goes after what the CPG shoots at, even if there is a desync in the TADS display. I've had shots hit with desynced TADS and shots miss with everything being proper. Also I don't think the INS confidence has anything to do with the actual drift, I believe it's just random values that simply change once alignment is done, but otherwise don't mean anything. INS reset and then waiting always seems to help, no matter what the displayed confidence is. INS should not drift as much with a modern laser ring gyro set and constant GPS corrections. It's constantly correcting and keeping track with the doppler ground radar. Also INS shouldn't be apart in any of this, but it somehow is. The missile should get the direction from the TADS angle and laser range, build it's DBS picture of the area, acquire and then track the point. And even if it were INS related, it would have to have it's own independent INS, not being fed any information from the helicopter about it's current position, then the helicopter would tell it to shoot at some coordinates (which are wrong, due to drife), but the missile is properly aligned while the helicopter is not. Then the missile would go correctly (according to it's own, perfect INS) to the wrong coordinates (from the bad helicopter sent coordinates) and miss. That's the only scenario i can think of where that could possibly happen. But I don't think the missile has a full INS on board, an accelerometer at best, to know the difference in locations after being launched. Could be wrong though. Also with INS misaligned, when the TADS is slaved to a point, the cued line of sight indicator (the dashed cross) is not centered in the display. The TADS is pointing offset according to the bad INS data, but the indicator somehow knows the exact position of the point. And that's when the hellfires miss. I don't feel like making a bug report with the next update being around the corner, which might fix this or break it in a different way, but this is a complicated mess.

I made a similar report a while back, TV vs FLIR when looking into forests at shallow angles. I since got a new graphics card, which makes things playable again, but it's still dropping frames considerably. Maybe it's related, or maybe it's not.

I just tested it in singleplayer. The CPG station can not move the throttle levers. When taking control it just twitches and jumps straight back to the fly position. I don't think this is multicrew related after all. cpg-no-throttle-ctl.trk cpg-no-throttle-ctl2.trk I also double checked that nothing is bound to the throttle controls, only the keyboard is and I wasn't pressing any buttons.

What are the graphics settings? Is that using the MT build?

There is no button to set the acquisition source. It can only be done with the MFDs. George is a mess. Use a human. He's so bad, I never fly the apache without someone in the other seat. But he mostly just undoes targeting stuff. Any other settings are mostly persistent, at least it was last time I checked.

@Lord Vader We did some more testing. It seems like the CPG station always sets full throttle. Keyboard controls from the CPG station make the throttle wiggle, but it always jumps to fly. Mouse controls can make the throttles move more, but again it jumps to fly. The pilot moving the throttles causes temporary twitches to the pilot's position and then back to full for the CPG. Here are the tracks. I hope you look at them, cause it would be really... discouraging to be requested to make tracks and then not have anyone look at them for a year or so, that's also plain rude. CPG was me, hosting a server. PLT was my buddy as a client. server-20231003-012016.trkAh64Issues-20231002-172428.trk