Raptor9

Dear all, In today's Open Beta update, a few additional control options were added that were not listed in the changelog. As we continue to improve the behavior of the TADS, specifically when using Linear Motion Compensation (LMC), we've added a few additional input commands and an additional option under the Special tab. Four new input commands have been added to the TEDAC right handgrip category to allow the Manual Track (MAN TRK) controller to be moved diagonally to adjust the pitch and yaw of the TADS turret with a single input. For players that are using an 8-way hat switch to control the TADS slew inputs, these four additional commands will allow you use all 8 direction positions of the switch. In addition to the new commands above, a slider has been added to the AH-64D options under the Special tab for those users using 4-way or 8-way hat switches to control the TADS slew. When applying a slew input using a hat switch, the MAN TRK controller on the right handgrip will increase in magnitude as the input is held, allowing a short tap to make a small magnitude slew input, and a continuous press to make a large magnitude slew input. By adjusting this slider, you can control the rate that the MAN TRK input magnitude increases, or "ramps up", to further fine-tune your input device as you prefer.

@Silvester.E, ensure you have set your sight selection to TADS.

Yep, this has been reported. It is happening during manual start sequences and auto-start sequences. George is switching it to AUTO during his start-up checklist. It's been reported.

If you have GEORGE AI AUTO HANDOVER de-selected in the Special options, you will need to press C to give him the controls any time you switch to the CPG seat, since George can only respond to AI flight commands if he has aircraft control. If you enable the auto handover in the Special options, George will automatically take the flight controls when you jump into the front seat.

Understood, this is reported. Just to summarize what has been reported for everyone's awareness: 1) George is setting LST to AUTO during a manual start sequence from a cold start. 2) George is setting LST to AUTO during an auto start sequence from a cold start. 3) George should switch LST to OFF any time the Player leaves the CPG seat. Thanks everyone.

Thank you, please post it in this thread when you get it.

This only occurs during an auto-start sequence, which is why it was missed. If anyone finds other instances in which the LST switch is moved to the Auto or Man positions without player deliberately setting it to those positions, please report it in the Bugs section of the AH-64D forum.

This has only been seen to occur following an auto-start sequence. Until the auto-start sequence is adjusted, you will have to manually set it to Off if you wish for George to use TADS as intended. If you find other instances that cause this switch to be set to Auto (or Man) without player action, please report it in the Bug reporting section. Thanks.

Of course, they are always tested prior to release. But sometimes things can be missed, which is why we have the public, open beta. And we appreciate reports such as this since it helps make the module(s) better.

Position Hold (and Velocity Hold) are based on ground speed, not airspeed.

Ensure the LT switch on the TEDAC right handgrip is set to the center "O" position. This will set the Laser Spot Tracker to Off. When set to Auto, the LST will cause the TADS to enter a 4-bar scan looking for a laser designation. The switch is moved from "O"/Off to "A"/Auto during auto-start. This has already been reported, as well as reporting that George should set the switch to Off if the Player leaves the CPG seat. Also, everyone please keep reports to one bug per thread. This helps our team track individual bugs and which ones are reported and such. When multiple issues are included in the same thread, they will often be missed.

Wags was in the widest TADS field-of-view when he engaged LST, which has a faster slew rate and only required a small transit time to the target. The videos you linked are under different circumstances with more narrow fields-of-view and greater slew distances. Not an apt comparison, and this is really splitting hairs.

Not all helicopters are equal. Some helicopters have high-inertia rotor systems, like the UH-1H, in which the rotor tends to spool up or down slowly. Others have low-inertia rotor systems, like the AH-64, in which the rotor can spool up or down quite quickly. Some helicopters have analog or limited engine fuel controllers where aggressive collective movements cannot be compensated quickly enough by the engine to maintain a constant rotor RPM, while other helicopters have sophisticated digital engine controllers that adjust the engine throttle in advance of detected collective inputs to ensure the response does not lag. Due to its low-inertia rotor system, the AH-64's rotor RPMs can rapidly spool up and spool down during aggressive maneuvers that are not compensated for by collective adjustment, even with its digital engine controllers compensating for most rotor transients. Even with its advanced engine controllers, it is still possible to create a rotor overspeed and underspeed and then overspeed again within a few moments, if you know how to move the controls in such a way to get ahead of the engine responses. And these effects are not always due to the precision or accuracy of the engine controls, some of these are purely due to aerodynamic effects on the rotor system itself. Effects such as rotor coning, conservation of angular momentum, mushing, upflows, etc. Having said that, the engine response to moderate to extreme collective or pedal applications in the AH-64D is a work-in-progress (sounding like a broken record), but the real AH-64 does have a low-inertia rotor system that can result in rapid transients of rotor RPMs during combat maneuvers if not compensated for by the pilot. Real aviators receive specific training in how to perform aggressive maneuvers without causing overspeed/underspeed events of the main rotor or causing an overtorque of the transmission. Such training isn't isolated to AH-64 aircrews either. Other combat aircrews in the UH-60, CH-47 and OH-58 (before it was retired) are trained in combat maneuvering flight so that they understand how their unique aircraft characteristics will behave when performing aggressive maneuvers in a combat situation.

This is not true at all. The flight model and FMC logic has been perhaps the highest priority in terms of the "feedback->adjustment->feedback" cycle even prior to the initial release of the module. However, it is the most difficult aspect to simulate accurately. It is relatively quite simple to quantify the logic of say the TSD page, which is fairly complex with a lot of depth, compared to modeling the flight characteristics of the AH-64D. When you couple all the aspects of the powertrain, moments of inertia, FMC logic, and SCAS response, some of which are quite ambiguous topics to quantify, this is the most difficult aspect of the DCS AH-64D. However, just because it isn't as finalized as some of the other aspects of the DCS AH-64D does not mean it is a lower priority to get right (quite the opposite in fact); it is simply the most difficult, the degree of which cannot be understated.

Short answer, they are known and are being worked on. Long answer: it's not so much the trim ball as much as the flight model itself that needs adjustment, which is still ongoing. Specifically, the yaw offset to the left in forward flight and the adverse yaw when rolling the aircraft require adjustment. Those are what are contributing to the behavior you are seeing that is creating the uncoordinated flight when rolling into and out of a turn without collective and pedal movements, and are known. Also keep in mind the electronic trim ball indication in the AH-64D is derived from inertial data, which makes it behave more reliably and promptly, but it won't behave the exact same way as the skid/slip indicator in an analog gauge, so I caution against making those direct comparisons. The other side of it is Turn Coordination. When the force trim isn't pressed and ground speed is >40 knots, SAS Turn Coordination logic will attempt to keep the trim ball at its current reference (which is updated when the force trim is released). However, its current correction rate is much too slow which is why you see it slowly fade in the input after the fact, unless the roll is accomplished very slowly. The Turn Coordination input rate is also a known factor that needs adjustment, coupled with the factors of the exaggerated yaw offset and adverse yaw effect.

CMWS control can only be performed by the pilot, because the panel for it is only in the aft crewstation, but both crewmembers should hear the audio alerts over the ADF audio channel. If one person hears it and the other does not, it's a bug (assuming they both have their ADF volume knobs turned up of course). I've submitted an additional report regarding this issue, regarding RLWR audio, the CMWS audio, and to ensure the state of the ADF audio channel itself is being synced between clients. (ie, ensuring that one player doesn't hear NDB morse code audio over the ADF channel when the other is hearing CMWS audio over the ADF channel).

My replies were to Floyd1212 (which is why I quoted his posts in mine) and to clarify where a few of work-in-progress areas are. They were not directed toward the problem GremlinIV described, and so are not related at all. The official advice is to press and hold the FTR as @Sandman1330 stated above. Besides Sandman1330, I'm also saying it, @bradmick is saying it (on the forums and in his Youtube videos), and I think even Casmo has mentioned it a few times on his Youtube channel videos. The intermittent clicking of the force trim leads to problems, both in DCS AH-64D and the real aircraft, as this is the logic of the real aircraft. The SAS sleeves cannot center themselves unless the force trim is pressed and held for 3-5 seconds, it's simply how they work, there is no getting around it. I think where some of the "semi-official" advice is coming in is from individuals that either haven't flown a real helicopter that are operating off of assumptions, hearsay, or a random internet article on the topic; or those that have flown a helicopter but have flown a type that has a different control system and behavior, and it is lost in translation. For example, one distinction I want to make is the difference between the term "stabilization" and the different functions of the SCAS (Stability Command Augmentation System). I've heard "stabilization" used to describe the AH-64D's Hold modes, but in the context of the AH-64D, this can lead to confusion. The SCAS functionality of the FMC consists of three "functional areas": CAS, SAS, and Hold modes. The SAS (Stability Augmentation System) provides stability in the pitch, roll, and yaw axes via rate damping when the force trim is not pressed. The Hold modes on the other hand (Heading Hold, Attitude Hold, Velocity Hold, Position Hold) maintain specific reference values of pitch, roll, yaw, velocity, or position when the force trim is not pressed. All three FMC functions (CAS, SAS, Hold modes) use the SAS sleeves within each flight control servo to move the swashplates in accordance with their specific function, but the difference between SAS and the Hold modes is that SAS dampens rotational movement to increase overall attitude stability of the aircraft, but the Hold modes attempt to reach and maintain specific reference values in attitude, velocity and position.

Yes. In the end, fly the aircraft how it works best for you. However, the reason that myself or BradMick keep harping on using the force trim more is because the hold modes are only effective when employed after the helicopter is properly trimmed (stable attitude, SAS sleeves centered after several seconds of holding the force trim). If the hold modes are applied with the SAS sleeves biased to one side or the other, it is limiting the authority for the hold modes to operate, which may lead to oscillations or a SAS SATURATE message/tone. But this can also lead to the excursions some are describing when they press the force trim or disengage the hold modes. (Not to mention that the hold modes won't even engage if the controls are not returned to their force trim reference positions anyway) If I am heavily reliant on the hold modes to keep myself in a stable hover, that means the SAS sleeves are biased to one side simply to keep the aircraft in a stable attitude. As soon as I press the force trim or disengage the hold mode, then yes, those SAS sleeves are going to start working back to center as they should. The issue isn't the hold modes or the SAS sleeve logic, the issue is that the aircraft wasn't set into a stable hover to begin with. If I get the aircraft into a hover myself, so that I am only applying a slight and occasional pressure here and there against the cyclic to maintain the hover, when I engage the Position Hold, all I am doing is telling the hold mode to do those small corrections for me. If I disengage the hold mode (whether that be by turning it off or by pressing the force trim to interrupt it), the SAS sleeves will return to center, but they would only move a very small amount because the aircraft is already trimmed for and in a stable hover. So the issue isn't that the hold modes or the SAS sleeves are making the pilot's job harder, it's that the pilot is making the pilot's job harder. This is not a criticism on anyone's abilities. Flying helicopters is difficult; even before you add on all the other tasks of navigation, radios, sensors, weapons, making tactical decisions, getting shot at, etc. Future improvements to the flight model will of course help with the predictability of the aircraft, but the underlying logic of how the force trim interacts with the SAS sleeves won't really change. It takes practice, there is no way around it. Heck, when the DCS Black Shark first came out, even as a professional helicopter pilot I struggled to understand its flight computer and autopilot systems. But once I learned the underlying logic behind its automation, it became a joy to fly. We'll get there with the DCS AH-64D.

Yes and no. This may have been caused by previous posts from myself that weren't as explicit as they should be (differentiating between SAS sleeves and SAS logic), coupled with a personal misunderstanding of the green indicator marks and what they represent. To start off, the green indicator marks are not a direct indicator of the positions of each SAS sleeve within the flight control servos (that's what I thought they were at first as well). The green indicators represent the real-time positions of the swashplates on each rotor system in each respective axis. So they may serve as an indirect indication as to what the SAS sleeves are doing within each flight control servo, but they don't represent the SAS sleeves themselves. For example, if the green line in the yaw axis is to the left of the white line, then I can see the tail rotor swashplate has been moved an additional amount by the SAS sleeve in the Directional servo. When the force trim is not being pressed, rate damping is in play, which can be detected by the swashplate (green cross) moving independently of the cyclic position (white diamond). When force trim is pressed, the rate damping is removed, which causes the FMC to keep the swashplate aligned with the control positions. To do this, the FMC uses the SAS sleeve positions to remove any mechanical lag in the system to ensure the swashplate is perfectly synced with the controls (part of the CAS logic in the FMC). So in this instance, while the force trim is pressed, the SAS sleeves are still active, but they are only performing CAS functions. So the SAS sleeves themselves do move a little while the force trim is pressed, but only to remove the mechanical lag in the system as part of the CAS logic; not rate damping, which is a SAS logic. What is still work-in-progress is 1) the CAS logic when the force trim is not pressed, causing some swashplate overshoot when a significant input is applied, 2) the swashplate behavior when the FMC channels are turned off, no mechanical lag applied yet, and 3) the overall stability of the aircraft itself, which is why the aircraft is wobbly when the force trim is pressed. (There are other aspects of the flight model, SCAS, and hold modes that are still work-in-progress as well, but these are the three relevant points in this case)

Yes, pressing and holding the force trim is the preferred technique when applying any significant adjustment to the cyclic or pedals, and then releasing it when the controls are set where desired. Tapping or "bumping" the force trim is ok for very small adjustments (say, a centimeter or less with the real cyclic), for the reasons you outlined in the comment above. After years flying the DCS Black Shark with the same simulation of force trim with my X52 spring-centered stick and Saitek spring-centered pedals, as I decelerate I will let go of the force trim and let my physical stick spring back to center, and I will do this two or three times during the deceleration to ensure I don't run out of aft stick authority with my physical stick. I only ever hit the "Trim reset" when on the ground with the collective bottomed out. The biggest thing to remember for those unfamiliar with helicopter aerodynamics is that, due to dissymmetry of lift, the faster you fly the more forward cyclic you will need to maintain your pitch attitude. This is why the nose rises as you accelerate. This requires a maintained forward cyclic position to maintain attitude. But when you decelerate, the reverse is true. You will need to progressively move your stick back to center(ish) to keep the nose from dropping as the aircraft slows and dissymmetry of lift becomes less and less. These discussions on proper use of the force trim ("trimmer" button) are nothing new. You can find endless threads about it going back to the original release of DCS Black Shark in 2009. This isn't something unique to the AH-64, as Sandman1330 mentioned the 412. However, the key difference with the AH-64D compared to other helicopters like the DCS UH-1H (which only has a force trim and no flight computer augmentation) is that the force trim also interacts with the FMC's SCAS and Hold mode logics (as outlined in the Quickstart manual). (FYI, the entire Quickstart manual is getting a comprehensive revision that will hopefully improve the structure and presentation of many chapters, such as the FMC and force trim)

@misu, please provide a track file and ensure you are not using any mods. This should not be a requirement. Every time the aircraft A/S button on the Armament panel is toggled from SAFE to ARM, it sends a command to the missile launchers to arm as well. I just tested this myself. If for some reason the player sets GND ORIDE to On and leaves the A/S button set to ARM during the rearm process, then yes, either the launchers must be manually armed on the WPN UTIL page or the A/S button needs to be cycled to SAFE and then back to ARM to send the arming command to the launchers. George isn't programmed to do this because it is not correct procedure to leave the aircraft armed during rearming.

There are several improvements being made to the F-16's sighting point logic to fix some existing bugs. These improvements affect not only the various sighting points themselves but how the cursor behaves in various sighting modes, to include Snowplow, VIP/VRP, and the various master modes. The Snowplow logic was updated in the most recent Open Beta update as you saw, but there are some additional system logics that are still being worked on incrementally to close the remainder of these logics. This behavior has been noted and we will look into it as the devs improve the overall system logic. Thank you for the feedback, but please try to keep different bug reports regarding Snowplow in separate threads. This makes it easier to manage them for bug-tracking, otherwise some may get missed if multiple issues are in the same thread. Thanks.

Ensure you've set the Signal lights to Night mode by taking it to the RST position. Also, the Flood knob must be <50% and Primary knob must be in any position except OFF, otherwise the Signal lighting will revert to and remain in Day mode (Fixed brightness)

I understand perfectly. You are diverting and misconstruing factual statements that have been made by myself and other members of the ED team about what went into the recent patches. We are stating what occurred in the update, we are not saying people are not experiencing what they are experiencing. These are two separate concepts, of which we have stated facts about the former, but you are inferring something else entirely about the latter. The facts will not change, nor is it cause for such emotional responses on the matter. I said nothing of the sort. Absurd and unreasonable accusations like this are attempts to gaslight the conversation. If you cannot have a reasonable conversation on the matter and what was said, there is no point in continuing this discussion.

The request that was made by macedk was to include flight model changes in the changelog, to which I confirmed that we do, and would. Every time that someone asks us if changes were made in the flight model, we will respond truthfully and accurately. This does not mean we are dismissing anyone's concerns or experiences, we are stating facts about what has occurred in the development. If someone claims something that is factually incorrect or inaccurate, countering that statement with our own does not constitute dismissal of their entire viewpoint or opinion, it is a correction of fact, nothing more. Some of you seem intent on turning this into something it is not. If you read through the flight model discussion thread, you will see that no one is being dismissed; in fact @bradmick (one of our content creators and SMEs) even put together a specific instruction video to address some of these comments in recent weeks, and several of us have tried to address the issue with some of our replies.