Raptor9

Hello @GAJ52. You can find several resources on the main DCS AH-64D forum section, which includes a link to Wags's youtube playlist. However, as with many of his videos, keep in mind he normally shows a video of features in early access so they may not precisely represent their final state, but they just provide a broad overview of module features. And of course you've already seen Chuck's Guide which provides a very illustrative format for instruction. There is also the official DCS Early Access Guide which can be found on your computer if you've installed the DCS AH-64D module, located below next to the red arrow; or it can be manually downloaded from this link. The DCS AH-64D Early Access Guide includes a more thorough description of the aircraft, systems, sensors, and weapons. Each chapter is iterative, in that it begins with a broad overview of the chapter topic, followed by explanations and graphics of each MPD page or aspect of the chapter topic, and then (when applicable), provides a step-by-step procedure with accompanying illustrations that explain how to accomplish each step of the procedure. Finally, Appendix A in the back provides abbreviated checklist procedures without the illustrations which may be more conducive to use when actually playing a mission, and is optimized for use on electronic devices such as tablets with hyperlink navigation. You can also find this thread by BradMick (who has spent many years as a professional AH-64 instructor pilot) pinned to the main AH-64D forum section, in which he provides various video tutorials regarding flight maneuvers and procedures, using the force trim, navigation systems, and a little bit on using the TADS. Hope you enjoy yourself.

A lot of this is already in the DCS AH-64D Early Access Guide, along with a lot of other useful information about using these various settings and the corresponding symbology.

The factors that drive where the seeker is positioned and how the missile constraints box symbology behaves is all pre-launch logic to 1) acquire a laser designation prior to launch if employing LOBL and/or 2) direct the pilot to maneuver into proper launch constraints prior to firing to ensure the missile can maintain track on a laser designation after launch (LOBL) or to ensure it can acquire a laser designation after launch (LOAL). None of the seeker slave or constraints box positioning applies once the missile is off the rail, meaning it doesn't remain slaved left, right, up, or down based on the selected sight of the crewmember that fired the missile because the umbilical to the aircraft has been disconnected. After launch, if the missile doesn't see a laser designation, it will just fly straight ahead along the same azimuth the aircraft was pointed at the moment of launch, regardless of where the crewmember's selected sight was pointed prior to launch, while performing a loft trajectory in accordance with the TRAJ setting on the WPN page, until it sees a matching laser designation or loses kinematic energy and impacts the ground. If I've actioned missiles with the sight set to HMD (which defaults to SAL type) with the trajectory set to DIR, as I move my head around the missile constraints box will move as well, which represents the seeker moving around based on where I am looking, with the assumption that the aircraft has line-of-sight to the target and can acquire a laser designating the target (from the ownship or someone else). If I am looking away from the laser designation, the missile won't see it. If I look in the direction of the laser designation, the missile will see it and begin tracking, and the missile constraints box will become large and indicate PRI CHAN TRK. At that point, I can then look away or back inside the cockpit since the seeker is now tracking the laser designation and no longer slaved to my head. But if the missile loses sight of the laser designation or if the laser stops emitting, the seeker will exit track mode and then slave back to my helmet line-of-sight. It works the same if using TADS as the sight. But again, after launch it no longer follows slaving directions since there is no sight to slave to, which is why the size of missile launch constraints box represents how close to the aircraft heading the target must be prior to launch. If the missile is already tracking a laser, the missile launch constraints are wide and more permissive because the missile will be immediately maneuvering to the target after launch, so the constraints box symbology is wide. If SKR LIMIT appears in the symbology, it is warning the crew the missile seeker is reaching the edge of its gimbal limit and so the laser spot may exit the seeker field-of-view after launch before the missile can physically maneuver toward its direction. If the missile is not tracking a laser, the missile launch constraints are narrow and restrictive because the missile must fly close enough to the laser designation to capture it within the seeker field-of-view, so the constraints box symbology is narrow. If YAW LIMIT appears in the symbology, it is warning the crew the azimuth to the target is too far left or right of the aircraft centerline, and the missile may not see the laser designation along its flight path after launch if the laser designating the target is outside the seeker field-of-view as it flies past.

Just to be clear to prevent any misinterpretation or misunderstanding in anything that was said, we were only addressing the specific items you had stated in an earlier post. We weren't stating the flight model as a whole is perfect. There are indeed inaccuracies with the flight model and some aspects of the SCAS behavior, which are being addressed internally. It just takes time. This is something I've been intent on being as transparent and open about from the beginning so that when I say something is representative of the real AH-64D's flight behavior or handling, you can be sure I'm not blowing smoke. However, on occasion, this requires that we push back on some user claims if they are not accurate to prevent misunderstanding amongst the community.

I am not sure what you mean about the first point, but if you offset the lift vector away from the vertical without a corresponding collective increase or aft cyclic input (if in forward flight), the aircraft will descend. I assume by "variometer" you are referring to the Vertical Speed Indicator (VSI). The AH-64D VSI incorporates inertial velocities from the EGI along with static air sensors to provide instantaneous vertical speed indication. There should not be a delay with the VSI as you claim. As stated above, the CAS provides instantaneous control inputs to mitigate the mechanical play in the flight control linkages and bellcranks, so that the AH-64D responds immediately. It also provides proportional response at low speeds to produce the same angular rates across all longitudinal airspeeds. The AH-64 was designed for maneuvering at low speed among obstacles at low altitudes, which is why the aircraft is as responsive as it is. If the FMC channels are disabled, there should indeed be some delay and "sloppiness" in the control response, especially at low speeds; but when the FMC channels are enabled, the CAS provides a "power steering" effect. As PilotMi8 stated, there is a new rotor model rework in progress, but some of your claims or assumptions seem to be based on experiences with other helicopters rather than the AH-64D.

Solo_Turk is correct in his statements. The AGM-114K does not have a fixed field-of-view; the seeker is slaved to the TADS when in LOAL and trajectory is set to DIR (shown below on page 481 of the Early Access Guide). All three LOAL trajectories will cause the missile to loft after launch, even DIR, as illustrated on page 477. But DIR has the minimum loft of the three; and regardless of the selected trajectory, the missile does not know where the target is when fired in LOAL mode, so it will continue to fly along the same azimuth from the moment of launch. This is why all LOAL trajectories have the same launch constraint of 7.5 degrees. The only difference between each trajectory is the amount of loft post-launch.

@SeeYouAtTheMerge, thank you for the feedback and the correction.

From my understanding, the anti-ice elements powered by the ANTI-ICE panel are intended to help the pilots maintain visibility and accurate flight instrumentation in trace or light icing conditions, not moderate or worse conditions. However, icing conditions pose a threat to any helicopter that does not have heating elements installed on the leading edges of the rotor blades. When ice accumulates on the rotor blades, this can degrade the lifting properties of the rotor blade airfoils themselves, but the real danger comes from asymmetric ice shedding when chunks of ice detach from the rotor systems. These chunks of ice can cause damage to other rotors that impact them and will alter the mass of the spinning rotor systems asymmetrically, like when a wheel on a vehicle is unbalanced, and can cause severe vibrations and damage to the entire rotor system.

If you have the latest DCS version (2.9.11.4686), it is already present on your computer. The location is listed under this forum section.

@dmatt76, what you are asking is not feasible. It would create a conflict with regard to how the logic within the AH-64D's Flight Management Computer functions. If the force trim release was just a force trim release and nothing more, it may be feasible. However, the force trim in the AH-64D interacts with the FMC in several ways that would make your suggestion invalid. This would not be isolated to the AH-64D; other helicopters that include flight control systems based on the interaction with force trim, such as the Ka-50 or CH-47, would likewise encounter conflicts within their logic. To be clear, these logic conflicts are not based on DCS gameplay or hardware interaction, but rather how the real-life flight control systems function.

Please be mindful of the forum rules when making gameplay wishlist threads or posts. Thanks.

It is no different than sending a markpoint from one's own SPI. Transmitting this does not simultaneously generate a markpoint in the ownship. But this does not prevent storing an ownship markpoint separately for later use if that is what you intend to do. The idea is that the transmitting aircraft is letting others know what he is doing or what/where his sensors, weapons, or attention is focused for coordination amongst the flight. Would it be nice if the HSD dynamcally updated threat locations and plotted corresponding threat rings as air defense locations are discovered like a dedicated ELINT-recon aircraft? Sure. But there is no such capability described in public documents.

There are some conflicting details in this thread so I'll attempt to clarify to sort out any confusion When TDOA is performed with several flight members, the HTS pods work cooperatively with one master pulling in sensor data from the remaining HTS pods in the flight to precisely locate a radar. Regardless of whether TDOA achieves PGM1 or not, when TDOA ends no SEAD target points (symbol with a slash) are transmitted across the datalink. If any flight member designates a radar symbol on the HARM Attack Display (HAD) MFD format and applies a long press of the VHF-UHF Comm switch to the inboard position, a SEAD target point (symbol with a slash) is transmitted to other flight members, which appears on their HSD and is stored within the steerpoint range of 107-127. The claim by the original poster that TDOA should generate a threat ring is not supported by documentation for the version of F-16 simulated by DCS F-16C. Further, after careful review of available documentation, we have determined that the fact a threat ring is being displayed on the HSD after receiving a SEAD target via a datalink is actually an error. The only symbols on the HSD that should have threat rings drawn around them are pre-planned threat locations, which are uploaded automatically to the HSD at mission start. The HSD should not display threat rings around SEAD targets received via datalink (which will need to be corrected), and the HAD should not display threat rings at all. We appreciate bringing this error to our attention.

It certainly can accept Lat/Long input. Please refer to the Navigation chapter (Adding a Point) in the Early Access Guide.

A new version of the F-16 Early Access Guide will be published very soon, with over 100 pages receiving updates/revisions and an additional 100 pages of new information added.

Thank you very much for the additional data, @Floyd1212. I'll look into this further today. It might be some issues on Syria specifically, but too soon to tell.

This is not an issue with George being able to see through terrain. It is an issue of the unit itself having some sort of unseen dimensions beyond what is visible. In the image below, I took control of the track and attempted to IAT on the S-60 gun. The IAT gates are registering additional unit dimensions that are not visible to the player. What those are, I don't know. But this is not an issue with George, but that specific unit, the S-60. When I attempted to do the same with the Ural-375 nearby, as soon as the truck was no longer visible, precisely when the bracing over the back of the truck bed went below the ridgeline, George could no longer see the target. So again, this is not an issue of George being able to see through terrain, but of some DCS units that apparently need some sort of correction to their dimensions within the simulation. I'll report this. Thanks. EDIT: As for those screenshots above, we need to know what scenery objects may need corrections, and where on the map those are located. But this is looking like an issue of unit or scenery object dimensions (hit box, collision mesh, whatever you want to call it), not the George AI logic.

As this is a wishlist thread, post bug reports in the bug report section. On that note, as there is no longer any point in continuing a wishlist thread about a feature that is already in development for implementation, I'll close this thread to prevent confusion.

Some of the claims being made in this thread are categorically not true. George cannot see through buildings or hills, neither in singleplayer nor multiplayer. I've never seen a single instance of this, up to and including the past several days playing on Gray Flag for many hours. If you have seen something resembling this behavior, provide a track file like any bug report. Having said that, like a human crewmember, George can see partially obscured vehicles; and he is capable of being aware of a target that has exited his TADS slew range (like if the Pilot turned outbound momentarily). Again, just like a human crewmember. As for trees, George may give the appearance of seeing through trees, but as someone that spent the better part of the past two days playing online with him, this can lead to mixed results where his line-of-sight is intermittently broken and reacquired. The trees and thicker branches (the portions that also block the FCR or cause your helicopter to take damage on impact), will obscure portions of the target while other portions may still be visible, especially if behind a thin tree-line. Again, not outside the realm of possibilities of a human crewmember, especially with thermal sensors. Let me clarify one thing that many people seem to be overlooking. George does not have instant detection and identification capabilities if he is set to a Realistic setting. DCS provides many settings that scale the realism within the game to suit personal preferences. Realistic G effects as an example, or the presence of labels (which quite unrealistically allows players to detect and/or identify all DCS units instantly as well). There are also settings that affect how realistic George behaves in this regard. So, if you want George to be as unrealistic and infallible as player labels or spotting dots, or as realistic as possible, set his options accordingly as described below in the Early Access Guide. If a player does not want to use George at all, he can also be disabled entirely. If a player thinks one type of AI CPG search method is unrealistic over another, then no one is forcing them to use that type of search. It seems that the complaints being stated in this thread is that George's ability to detect and acquire targets is simultaneously too realistic and not realistic enough. All this hand-wringing over this feature request is rather amusing, since a lot of it is based on false premises, and the rest can be solved by selecting the appropriate game settings to suit a player's preferred gameplay.

If you go beyond page 3, there were paragraphs added to provide additional context and details about the F-16C's INS configuration.

I believe you misunderstood the point I was trying to make. Gathering feedback from the community is important since it not only helps improve DCS itself, but it shapes how we present DCS as a whole. I was not stating that the presence of feedback was to be avoided entirely at the risk of some of it being negative. Rather, what I was pointing out was that if a method or depth of communication has not been received favorably by the community in the past, it should not be surprising if we do not do so in the future. We welcome feedback since, again, that is how we shape the product to suit the community. We may not be as revealing regarding our day-to-day internal developments, but I think we do make considerable effort through our community managers and other staff to engage with the community. But ED is a small company, with a large customer base across many languages and social media channels, with a fairly broad set of products to which any number could be the topic of community feedback. You are certainly free to express your thoughts (within the confines of the forum rules of course), but I disagree with the premise of some of the statements that were made last night, which is why I replied to them in the manner I did.

This thread has been tagged as "in development" for quite some time now. Everyone knows that Early Access means a product is still in development, and everyone has their own wishes and priorities for what features they wish to see completed over others. It is unfortunate that features have not been developed in the order you personally prefer, but that is the nature of Early Access, and Early Access is completely voluntary and optional. Further, if you have already purchased the DCS AH-64D, you have not in fact paid full price for the module, but a discounted Early Access price. There has been an AH-64D roadmap for quite some time, it is pinned near the top of the main AH-64D section. Sure, it would be nice to share more play-by-play details about what is being worked on or what is planned, but we've clearly seen in the past, and present, that providing more details in the roadmap have been met with more community complaints. If providing such detail in the roadmap receives negative feedback, there really isn't a good reason to continue such practices.

@beacon, as Floyd1212 already mentioned, you cannot fire an AGM-114L simply by creating a target point on the TSD. As he stated above, the AGM-114L can only be fired using one of the three methods: Scan with the FCR to generate target data for the missile. Lase a location using the TADS to generate target data for the missile. Receive an RFHO datalink message from an FCR-equipped AH-64D, which contains target data for the missile. Again, a target point (or any TSD point) cannot be used to fire an AGM-114L missile. It is not like a JDAM.

If you are referring to the fact you are still getting an RWR indication of the radar while hovering in that picture, that is not necessarily incorrect. Radio emissions can propagate in all sorts of ways through the atmosphere and even the ground, depending on the waveform, they aren't like laser beams (Even though laser beams can be affected by the atmosphere and the environment as well). The difference being is that an RWR simply needs to detect the emissions. A radar needs to be able to analyze and process the radio waves that are reflecting back at them, and do it in such a way that it can discriminate a target amongst the noise of the environment.