Raptor9

I've read this thread in its entirety, I do not simply throw responses into a discussion without reading through the original process and flow of the discussion. As to the "logic" of it, just because some individuals do not think the logic of a real-world system makes sense, this does not mean that it was designed or implemented without a good reason or solid logic behind it. This argument has been used many times before to justify a change in a DCS module, that "it doesn't make sense" for whatever reason. But that statement is highly subjective and carries with it a person's own confirmation bias as to what is accurate and what is not. Without being specifically briefed on the design, purpose, and employment of such a device in real-life, or without ever using the real-life device, the definition of what is "logical" is quite subjective. To reiterate yet again:

The current logic of the TGT SEP mode, to include the logic and direction of separation and the spacing of separation, is in accordance with documentation of the function on the RWR in the variant of F-16 that is represented in DCS: F-16.

When TGT SEP is enabled in the F-16, all symbols within an overlapping cluster are separated radially, outward only, away from the highest priority threat within the cluster. However, if edge-limited against the display, further separation cannot be performed, such as is the case if the radars are only in a Search mode. To clarify, the type of display does not dictate how the RWR software is configured in response to button presses. The limitations of the installed display may dictate how the software is programmed to utilize the limited capabilities of the display (for example, no color-coding is possible), but the type of display installed in a cockpit is not directly indicative of how the RWR software should behave.

If I see an engagement that is imminent, I'll usually set my knob to the more complex chaff program just in case. But the best defense in BVR is a good offense, and I'll sometimes lob an AIM-120 early just to put the bandit on the defensive before he can even get a missile off. Then keep pushing against the bandit while he's defensive to get a second AIM-120 shot off with a higher probability of success. And sometimes the early AIM-120 takes him out precluding the second shot, but I would much rather use two AIM-120's to take down a bandit then let him force me on the defensive in which I'm trying to defeat his missile while he continues to close the range for subsequent shots against me. As for the Within Visual Range arena, I try to avoid the merge if at all possible. It doesn't matter how advanced your jet is or how many expendables you have in the buckets, letting yourself get sucked into a merge is opening yourself up to nastiness. I rarely carry more than 1x AIM-9X, because I spend most of my time avoiding the merge and putting my chips toward the BVR jousting. If I am forced into a merge, that AIM-9X is my ace in the hole to survive long enough to extend and get out of there, or to at least shoot down an enemy wingman so I only have to worry about keeping the one bandit in my forward hemisphere. I may pop off a few pre-emptive flares if I see the bandit's nose getting on me, or if I think he has off-boresight missiles and I'm in his envelope for those (sometimes you just "feel" it about to get launched at you ). But again, my strategy is to kill the enemy bandit quickly or just get out of there. The most effective countermeasures against getting shot at is to avoid needing to use them in the first place.

It's very simple. You want both pilots to be presented with the same flight instrumentation. There are differences in how symbology elements function depending on which mode you are in, and you want both crewmembers receiving the same information for the purposes of crew coordination.

I believe Floyd1212 was being sarcastic in stating to read that thread, for the very reason it was chock full of a lot of misinformation, ranging from slightly inaccurate to downright outlandish. I've unpinned that thread to prevent any confusion in the future, since Bradmick's video tutorial thread is a lot more useful, accurate, and is from someone that has thousands of hours flying and instructing the real AH-64D. @bradmick and myself flew the real AH-64D for many years, so if we are refuting another's claims about the AH-64, it comes from a place of real-world knowledge and experience. There have been a number of self-proclaimed "experts" on these forums that have made some pretty interesting statements in the past about the AH-64 (and helicopters in general), and so if you see Brad or myself refuting them, that is the reason why and the source behind our responses.

The current quick start guide, when it starts talking about the force trim breakout values, but also later in the section when it talks about the engagement logic for each hold mode. Pretty much each logic group graphic shows a force trim reference position within some axis being a factor of engagement. When violated, no hold mode. Having said that, the upcoming manual revision is quite substantial, to include more in-depth explanations of the FMC functions and logic. But most of those graphics showing the engagement logic wont change.

I really wish more players would read the quick start manual starting on page 203, especially the sections talking about the force trim breakout values and the hold mode engagement logics. They would see how the cyclic and pedal force trim reference positions make the Force Trim Release switch the linchpin as to how these FMC functions work to control the aircraft.

Because your hardware is simulating a different setup than what exists in the real helicopter. If it were the same, your stick would spring back to its last position where the Force Trim Release switch was last pressed. And since the FMC, SCAS, and Hold mode logic all revolves around the concept that the cyclic (and pedals) is spring-loaded to the force trim reference, and it uses the force trim reference positions to drive its logic, any hardware that does not simulate this setup will lead to a false impression of how the force trim works, and how the FTR is interwoven into the overall FMC logic. So, if one were to press the Force Trim Release switch any time the controls are moved, the system would be used as intended and the logic would align, even if the force gradient that exists in the real helicopter isn't manifesting on your physical control stick. Just because the force gradient isn't there, doesn't mean the remainder of the FMC logic can be ignored without creating issues. Remember, the logic of the FMC, SCAS, and Hold modes are based on the concept that the force gradient is there any time the FTR isn't pressed, and is not there any time the FTR is pressed, which is why the trim system should be used as if it were. The reason that Brad and I keep telling people to use the Force Trim Release switch isn't because people need to use it for the purposes of force trim, but for the purposes of employing the logic of the FMC, SCAS and Hold modes as they are designed. You may not physically need to apply a constant pressure to keep your physical stick in place without pressing the FTR, but the AH-64's Flight Management Computer sees this as if you do because that is how the real FMC is programmed, because in real-life the force gradient does exist. Therefore, the FTR needs to be used as it would in real-life; if the FTR switch is ignored, then the FMC will react as if the FTR were being ignored in the real aircraft as well. If you had a pilot that was intent on muscling through the entire flight in a real AH-64 without pressing the Force Trim Release switch, they too would never be able to get a hold mode to engage properly, because they would be ignoring the underlying logic of how the FMC was designed and the purpose of its existence in the first place.

Many players are making this out to be more complicated than it is. It is actually quite simple: "Press the switch, move the controls, let go of the switch". No more to it than that. Because that interferes with how the helicopter actually works. No trim = no hold modes and incorrect SCAS logic. You can surely disable it within the cockpit on the UTIL page, but you might as well turn off the FMC channels as well. In real life, the Force Trim system is only disabled if the system is malfunctioning or has had some sort of failure. There are reasons for this, because it is an integral part of the helicopter control system. As stated many times already, it isn't "just the trim system", the FTR switch itself interacts with the Flight Management Computer as well, which is why using it is necessary. If players fight against this, they will continue to experience difficulties.

The original conversation you started was about how real AH-64 pilots deal with SCAS, and you described your experiences interacting with it and how/when you use the force trim. In my initial response I was explaining the real-world reasons why the force trim is usually held down when initiating cyclic or pedal movement (instead of simply tapping it when reaching a new position) and why these substantial differences in control inputs that players see in DCS don't manifest in real life. Following my response, you made the following statement: This statement was not correct in that force trim overshoot is purely a result of a force gradient provided by the force trim system. SCAS has nothing to do with it. You can experience force trim overshoot in any helicopter that has a force trim system with a force gradient, regardless of whether it has any sort of stability assistance system like the AH-64's SCAS (and I have). My original statement was not an explanation of how anything functions in DCS, it was an explanation of why the force trim is used the way it is in the real AH-64, as well as many other real-life helicopters. However, the broader point I was making is that many players find the AH-64's SCAS system un-intuitive because they are not using the force trim system as intended; and if they had the same physical hardware that exists in the real AH-64 cockpit, it would be very apparent why that is. If the SAS sleeves within the flight control servos are offset within their respective authorities, when the force trim is pressed these SAS sleeves return to center. This requires that the physical controls be adjusted to maintain the current attitude. However, if the force trim had been depressed before any substantial control inputs were made and then released when those inputs had stopped, the SAS sleeves would already be very close to center so that when the force trim is pressed the next time, there will not be substantial SAS sleeve travel because the SAS sleeves will rarely be very far from center. (This is why I stated in my original response that it is rare to encounter SAS SATURATED if the force trim is used correctly) So to reiterate my point, force trim overshoot is not the cause of the DCS AH-64 to incur a significant deviation from its attitude when the force trim is depressed. The cause of this is improper use of the force trim release itself, which is why you hear Bradmick or myself encouraging players to stop ignoring the force trim when making adjustments to the flight controls. The very fact that players are not experiencing force trim overshoot when their physical hardware does not simulate the same force gradient of the real force trim system leads to many of these misconceptions as to the role that the FTR switch plays in controlling the helicopter and interacting with the SCAS system; which is why these effects do not occur in the DCS Huey since it doesn't have a SCAS system. Force trim and SCAS are two separate systems, but the Force Trim Release switch position interacts with both systems at the same time. Therefore if you are improperly using the FTR switch due to a misconception of how it is used in real-life (which is the reason for my original comments about force trim overshoot), this will lead to a misconception of how the SCAS should work in conjunction with the pilot's desired control inputs.

Because the controls in a real helicopter are exposed to many external forces that do not exist next to your computer, such as vibrations, shock, g-forces, mechanical feedback from the linkages/servos, etc. It helps to have a resistance force that keeps the cyclic from flopping over if the pilot doesn't have a firm grip on it. For example, the AH-64's collective (which does not have a force trim) is under significant tension that normally keeps it from moving when not held in place by the pilot, but when pulling out of a dive, the pilots need to ensure they hold on to the collective to prevent the g-forces from slamming it to the floor and causing a crash, despite the tension that holds it in place under normal flight conditions. And in some cases where the AH-64 is experiencing significant vibrations, the collective can still creep up or down, depending on how the tension is set in that particular airframe. In that case, you can also add additional friction using a sleeve on the collective itself, but then that increases the force required to move the collective. It's sort of like asking why fixed-wing aircraft have trim tabs since the pilots can simply hold the controls in place, or make the controls stiff enough that they won't move under external forces but then requires significant muscular endurance to fly for several hours. You don't want to have the controls so loose they move around under external forces, but the alternative is requiring significant muscular exertion simply to move the controls at all.

Force trim overshoot is possible in any helicopter that has a force trim system with a force gradient, it is not a product of SCAS but the very fact that you are applying a muscular force against a resistance that is suddenly removed. Have a friend hold up their hand against yours to apply resistance as you try to move it. Tell them to stop resisting against your pressure and then try to keep your hand at its precise location without moving it when they simply stop resisting. Unless your timing is absolutely perfect, your hand will overshoot its position. It may not manifest the same way in the UH-1 due to the different rotor system and relative responsiveness to control inputs compared to the AH-64. That's how I would do it in real-life. However in DCS, I may let go of the FTR a few times during a deceleration to a hover, simply to regain some aft authority of my physical stick on my desk. I don't have a force-feedback stick so as I progressively accelerate forward in the DCS AH-64D (or any helo in DCS), I will intermittently let go of the force trim and let it spring back to center and resume my acceleration. When decelerating I do the same thing but in reverse.

@skypickle, one needs to realize that the real cyclic and pedals in the AH-64 have force gradients holding them in place when the force trim is not being pressed. Trying to hold the cyclic or pedals in a very precise position against the pressure of this force gradient is difficult, and over a period of time would become tiring, which is the entire reason for having the force trim release. I think many players, depending on their hardware, develop a false impression of how the force trim is used if their hardware isn't simulating this force gradient. I've seen many videos online of players flying the DCS AH-64D without using the force trim, with the force trim reference remaining at the original locations and never updating. I can infer that these players are using hardware that does not simulate the force gradient of the real AH-64 cyclic and pedals, or at the very least nowhere near the levels of resistance that exists in the real aircraft. If they did, it is highly unlikely those players would be playing for so long without pressing the force trim. As AlphaOneSix said, when the cyclic or pedals are moved, the force trim is almost always pressed at the onset of such movement. This practice is especially important when making large magnitude movements of the controls to avoid what is called "force trim overshoot". This occurs when the pilot has moved the controls a significant distance from their force trimmed state, and is applying pressure against the force gradient to hold the controls in place. When the force trim release is pressed, this force gradient is immediately removed, which may cause the pilot to inadvertently jerk the cyclic and pedals beyond the intended position when the resistance against the pilot's muscular tension is suddenly removed. This can cause the aircraft attitude to deviate in a somewhat violent manner, as would be the case any other time a sudden and aggressive input were applied to the flight controls. There are exceptions to this practice of course, in the case where the pilot intends to return the controls to the force trimmed state. The best example would be flying along a route at a constant airspeed and altitude, with the aircraft trimmed in straight and level flight. Without pressing the force trim, the pilot applies cyclic pressure against the force gradient to initiate a turn toward the next leg along the route. This cyclic input is applied and maintained against the force gradient throughout the turn, and then when the pilot intends to roll out on the intended heading, relaxes pressure on the cyclic and lets the force gradient return the cyclic back to the original location, which causes the aircraft to naturally return to the same straight and level flight condition prior to the turn. If one is properly using the force trim, SAS SATURATED should almost never occur. In real-life, about the only time this would happen is due to atmospheric changes such as sustained wind gusts that cause the aircraft SCAS to flight against unintended attitude or position changes.

Just as the main rotor becomes less efficient as you slow below ETL (16-24 knots), the tail rotor experiences the same drop in efficiency for the same reason. The need to apply anti-torque input to counter the increase in collective performed to maintain altitude as the aircraft comes to a hover is correctly exacerbated by the fact the tail rotor is also becoming less efficient.

Just to prevent any confusion or mixed information out there, the flight model received no updates on this most recent patch, nor did the SCAS or hold mode logics. If anyone is seeing anything different, I recommend examining your control options to see if anything has changed. The last time the flight model received an update was in the mid-May Open Beta update.

Casmo's claims that these are wrong behaviors are not accurate. The Apache experiences translating tendency to the right in real life as well, as it will also rotate in place on the ground if the tail wheel is unlocked and tail rotor thrust is applied in an unbalanced fashion. As was stated on the previous page, the tail rotor is producing positive thrust when the pedals are centered in the yaw axis, and must be applied slightly to the right in an offset manner to actually zeroize the tail rotor thrust. If left cyclic is properly applied to counter the right rolling motion and the right translating tendency from the high-mounted tail rotor, the aircraft will lift straight up. In a no winds situation and with a symmetric loadout, the AH-64 will always lift the right wheel off the ground before the left if the takeoff is performed properly. Just as is the case with any other maneuver or flight condition in a helicopter, if the forces that are being applied to the helicopter are out of balance, the aircraft will respond in an unbalanced manner. If translating tendency is not countered by the pilot, the aircraft will start to slide to the right as it gets very light on the wheels and continue drifting right after liftoff. Although this typically results in the main landing gear tires sort of skipping across the ground if the aircraft is light enough to lift up without inducing a dynamic rollover. EDIT: "Light on the wheels" is typically described as approximately 20% torque below IGE hover power. Once you start increasing power above this, you will be in a weird region where the aircraft is essentially flying, but has not fully cleared the landing gear from the ground due to the shock struts extending as the aircraft weight comes off the landing gear. This is the prime region for inducing dynamic rollover and should be avoided by continuing to increase power to IGE hover power or reducing the power to fully land and compress the landing struts. You do not want to "dance" around on the ground in this region in real-life nor in DCS.

I submit exhibit A: It may be a matter of how the control hardware is set up and tuned. And the ground friction may be looked at as well, but I really wish he would have had his Control Indicator displayed to see the actual control inputs and input magnitudes during the video.

@450Devil I am very familiar with the tactical reasons for maximizing the use of terrain masking. But in the context of employing the AGM-114L missile, there is no tactical advantage to holding on to a missile and firing it at a later time and from a different location when it could have been fired immediately following target handover. If anything, the missile could be coming off the rail as the collective is reduced to initiate the descent back into the masked location. However, if you wish to use the AGM-114L in such a manner, I would recommend waiting until the FCR is released later in Early Access. The AGM-114L was not intended to be employed as an indirect fire weapon when the TADS is being used for target designation.

I've seen this scenario being used and discussed quite often, about handing off a target location to the missile and then not firing immediately. So the question I have is: why? Such a scenario is something that is illogical because if you have line of sight on the target to lase for 3 seconds, why would you not simply take 1 additional second to fire the missile immediately after the target location is received? I understand the desire to mask to avoid getting shot at, but the intent is to fire the missile immediately upon sending the target data to the missile. To put it another way, if the difference between death and survival was down to 1 second, the engagement strategy in such a scenario would probably be re-evaluated. The procedure you are describing is akin to using ADF to locate ground troops requesting CAS. It is something that I see used quite often in DCS but it is not something that would ever be performed in real life.

In the scenario you described, the Hellfire seeker cannot lock onto a target that is not in front of the aircraft, which will cause him to attempt another lock-on. The point I was making was in response to the earlier posts about why he keeps trying to lase, in that it is related to how the missiles function. George behavior may certainly need some adjustments to cover the numerous possible scenarios that may prevent him from performing the intended task, especially when he needs to recognize when the player is directing him to do something illogical.

In the next revision of the DCS AH-64D manual, the George AI chapter will have more thorough explanations of what precisely the Player is ordering George to do with each AI command/key press that is used, and why the AI is implemented in the manner it is.

These behaviors are already present in the game. If George lases a target and the AGM-114L missile attempts to acquire the target in LOBL mode but fails to acquire anything, George will de-action the missiles to cancel the target handover, action the missiles again, and lase again to attempt a subsequent lock-on. This is correct and intended behavior. If you direct George to action a weapon system while he is tracking a target, it is implied that you want him to engage the target. Alternatively, if you direct George to track a target while he already has a weapon system actioned, it is likewise implied that you want him to engage that target (as is the case when rapidly engaging multiple targets). In either instance if George is 1) tracking a target and 2) has a weapon system actioned, he will perform all the steps necessary to engage that target with his assigned weapon right up to the point of actually pulling the trigger. At this stage he will wait for Consent to Fire if his ROE is set to Weapons Hold, or he will pull the trigger at will if his ROE is set to Weapons Free. In other words, if you don't want George to engage a target with a weapon system, direct him to de-action weapons. _________________________________________________ Using George should not be thought of as a command-based AI crewmember (which requires significant micromanagement and many keypresses to accomplish a given task), but rather a task-based AI crewmember. When he is given a directive, the directive is in the format of an directed task, and he may accomplish multiple individual steps to perform the directed task. For example, if the aircraft is SAFE when George is directed to slave the TADS to the Pilot's helmet sight, the implied task is that the Player sees something from the Pilot's seat that he wants George to track with the TADS. As part of this process, George will set the aircraft to an ARM state in preparation of using the laser rangefinder/designator, which cannot be fired while the aircraft is SAFE. An appropriate flow would look like this: Step 1: Player directs George to track a target. Step 2: When a target is being tracked, the Player may direct George to lase/stop lasing the target if no weapon is assigned, in order to a) measure range, b) designate to hand over the target via a laser spot tracker being used by another aircraft, or c) designate for a laser-guided munition released by another aircraft. Step 3: If desired to engage the target with your own weapons, direct George to action the intended weapon system and configure the weapon accordingly for firing. Step 4: Ensure the aircraft is maneuvered appropriately to satisfy weapon release constraints and (if necessary) give Consent to Fire.

Fair enough.

ChatGPT may be able to pull "information" from the internet, but it is far from reliable. ChatGPT has no way of knowing what is fact or fiction, it just filters and parrots what it finds on the internet. As an example, websites like Wikipedia, globalsecurity.org, fas.org, and deagel.com are all "circular reporters." Meaning they post the same crowd-sourced answers that are aggregated from various places; and then when each of these sites have the same "facts", it appears to be corroborated by multiple sources when it really is just a bunch of websites repeating the same thing that the other is saying. An AI program looks at this and sees corroborated sources as evidence and then outputs it as fact, when in reality it is nothing more than a really fast internet search engine that aggregates and filters data. But like any other computer program, if the data that is input is wrong, so is the output. I bring this up because there have been several occasions recently where users have quoted ChatGPT as evidence. But caution should be used before any information on the internet is treated as fact, regardless of whether it comes from a human or an AI program.