Raptor9

@Mantikor, I understand perfectly the applicabilty and uses of being able to command George to reacquire a previously stored target. That is a feature we have discussed internally as I stated in my previous comments in this very thread. But that is not what is at issue here. This thread is about the method of achieving it, using the Pilot ACQ selection to command George to perform this function, which makes it needlessly redundant given the existing logic and can be disruptive to the pilot's own cockpit flow. Again, I'm not saying that a method for reacquiring a previously stored target is not planned. The OP's requested method of achieving this is not planned.

The flight model was not changed in this update. The last time any aspect of the flight model as a whole was changed was in December when the hold mode logics were adjusted.

To be clear, this behavior is documented in the Early Access Guide under the descriptions for both Weapon Action Switches on the TEDAC and Cyclic grips, as well as the Weapon Employment chapter which details the procedures for employing Cooperative rockets (both Direct and Indirect).

It's not a duplicate key binding or an error, that's how it is in the real aircraft. If the CPG actions rockets on the TEDAC, he clearly isn't flying so he cannot align the aircraft with the rocket steering, so COOP mode is entered if the Pilot actions rockets as well. If the CPG actions rockets on the Cyclic, it is assumed he is flying the aircraft and therefore is the one aligning the aircraft with the rocket steering, using the HMD, instead of the pilot. Since only one person should be flying, it takes the rocket control away from the Pilot.

Is the player in the CPG slot actioning rockets on the Cyclic or the left TEDAC grip? If actioned on the Cyclic, COOP cannot be entered.

The next update should include improvements to the FCR elevation control that restores the FCR detection capability at shallow scan angles, so you can adequately mask the aircraft behind cover and detect/engage targets (flat terrain or otherwise).

@Floyd1212, yes, this is certainly similar to one of the ideas we have. However, the thread was about leveraging the Pilot's selected ACQ source to cue George where to search for a target. In which case this doesn't add anything, since if the player were to select a TSD point as the ACQ source to cue George where to look, that is no different than the current behavior that exists now, with the exception the Player just looks at the cross and presses the command to search. I understand that other methods for George to search for targets are desired; and again, we have ideas for how we could potentially improve this. But basing the search location off the Pilot's ACQ source is not a worthwhile method to implement when it can already be done using the existing logic.

If the suggested wishlist item was implemented, in which George is commanded to slave to the Pilot's ACQ source and search in that area, how is this any different than what is done already with Up-Short while looking at the broken cross located at your ACQ source? I fail to see how this would be a worthwhile implementation. We do have other ideas for how to improve George CPG's behavior and features, but adding another command that essentially duplicates an existing command (Up-Short) seems very redundant.

Well, where some of the interpretations run afoul, is that this is all simulated in computer code. In many instances, things that would seem logical in the physical world, don't really come into play in a simulated world that is being manifested by code. To be honest, it doesn't necessarily help being a real pilot vs a sofa pilot in many cases. When I first joined the team, on more than one occasion the devs had to explain to me why things happen the way they do, when I was looking at an issue from a "physical world" perspective. The way I like to think of it is that there is no simulated hydraulic fluid actually moving through the simulated hydraulic system. But rather a series of calculations, based a range of conditional values, that are performed to determine hydraulic pressure outputs to various systems.

I didn't give anyone any hell, I told him he was stating incorrect information, and it still is incorrect. Hobel, and anyone else making this claim, are mistaken. The mathematical calculations that determine when a target is visible to the radome need corrections (and have been corrected internally for a future patch). These calculations are based on the aircraft height over terrain and the antenna elevation setting. The emissions are not coming from the nose, but it is a happy coincidence that the incorrect calculations are manifesting to give the appearance of this. Hobel does not have access to the debug tools the devs use to determine this. But I have personally seen and tested these things. Is there an issue with the elevation control calculations? Yes, I have said this already multiple times in multiple threads. But the cause is not "the radar is coming from the nose". I'm not going to show you the trignometry that is involved, since it wouldn't mean much anyway, so I figured I would break it down as best I could to inform to you all the real cause. You all can tell yourselves whatever you want or make me out to be the villian for telling you what is actually going on under the hood. I don't care; and it's threads like this that make me question why I bother interacting with or communicating with the players when this is the response. It is not my job to do so, but I try to be as transparent as I can be to keep players informed. Perhaps it isn't worth the effort.

@Danguard, the temperature in this mission is 40 degrees C, which is 104 degrees F. In other words, with the payload you are carrying your aircraft does not have a sufficient power margin to hover at the altitude you were commanding George to maintain. If you look at the PERF page, you will see that you do not have sufficient power to hover OGE (out-of-ground effect), which is calculated at 80 feet AGL; let alone several hundred feet. Another clue you can see at the very beginning is that the temperatures of your engine turbine temperatures are already in the yellow in forward flight. If your engine turbine temperature indications are already in the yellow in forward flight, it is very unlikely you will be able to hover, which takes significantly more power.

The OP posted this thread in the main section to ask questions about what might be causing his/her issues. A month later, others have added their own issues to the discussion. If the OP wishes for it to be moved to the Bugs section, that is his/her decision if they want to file a bug report to address his/her specific situation.

Ok.

I am not denying there is an issue, you are falsely claiming the cause of the issue is the radar is emitted from the nose, and that I had acknowledged that it was the cause. Neither of which is correct. In any case, this has become yet another debate about the debate itself, rather than the facts of the issue, which I have already stated multiple times. Believe me or not, it makes no difference, but please do not twist my words into a narrative that is not true.

As stated in the other thread, this is not true, so I don't know why this is still being repeated as if it is true or being claimed it has been acknowledged as such since I specifically said that it is not. So I will say it again; the FCR beam is coming from the mast, but the way the elevation control calculations are currently implemented it is leading to unintended behavior. Long story short, due to the environment the AH-64D operates (extremely low altitudes), the calculations needed to ensure the FCR consistently scans a fixed range between 500-8000 meters had to be revisited to ensure the antenna angles for a given scan volume were properly calculated at various altitudes. The good news is, this has been fixed internally and we should expect to see the improved elevation control soon in a future public update. And as a side note, the development of the DCS OH-58D by Polychop has no bearing on the DCS AH-64D by Eagle Dynamics. These are two separate projects with separate development teams, and the two aircraft are completely different in function.

As a follow-up to this thread, I wanted to update you all that we were finally able to identify and reliably reproduce a few issues with the datalink, and these have been fixed internally. We appreciate your patience and hopefully these fixes can be sent to the public builds as soon as possible.

As a follow-up to this thread, I wanted to update you all that we were finally able to identify and reliably reproduce a few issues with the datalink, and these have been fixed internally. We appreciate your patience and hopefully these fixes can be sent to the public builds as soon as possible.

I'm going to address this thread in a very direct, matter-of-fact manner to ensure there is no misunderstanding, because I am trusting that we can all discuss this as adults. I know DCS is available to all ages of course, but I know several of the individuals in this thread (to include the OP) are in fact adults and so I will treat them as such, instead of beating around the bush. There is no malice in my response below, it is simply expressing the facts of the situation before this thread snowballs out of hand, since it has already been linked elsewhere as an indictment against DCS as a whole. In January, Lord Vader linked this thread to me and asked for my feedback regarding the OP's claim that the front windshield panels should have a blue tint, and asked if it was realistic. My reply to him is below: "I would like to clarify that the real aircraft has no tint on the canopy. The reported issue was that the external model seems to have a tint to it, but that there should not be any tint at all. It is a little strange that the same user that posted the original bug report about the external model having tint when it shouldn't, subsequently created a mod with tint in it. The ballistic glass that occupies the forward windscreens as shown in the image above do reflect light a little differently than the side plexiglass, which can lead some to believe there is tint to it depending on viewing angle. But none of the cockpit windows actually have any tint to them." The interpreted intent behind the thread was a claim that the front windshields needed to have a noticeable blue tint that contrasted the side and overhead windows. This is why Lord Vader marked the thread "correct as is", and that is why he responded the way he did, because I personally told him that the front windshields should NOT have any special blue tint to them as the OP seemed to be claiming in his second post. Granted, the OP did also claim that none of the windows should have any tint to them at all, which is what likely contributed to confusion within the thread. But that is irrelevant. Regardless of how we got here, the answer to the question of whether the AH-64D has any tint to any of the windows whatsoever is that it should not, but the current external model in DCS does in fact have a slight blue shading to it. This is acknowledged; however, I will tell you that this is a very low priority to be changed by the devs. When it comes down to it, it does not impact gameplay in any way, and there is no noticeable tint effects as seen from within the internal cockpit view. The ED artists have other priorities that they must be focused toward. This is the reality of the situation, therefore I have changed the tag on the thread to "intended as is" to hopefully encourage everyone to put away their pitchforks. [By the way, before any replies are posted insisting that I defer to SMEs on this topic, I spent 20 years in US Army Aviation, the majority of which was spent flying AH-64Ds.]

@ThorBrasil, I have never seen anyone from ED make any official statement other than that of a "US Army CH-47F" variant, so I don't understand what lack of respect you are referring to or where you are inferring that promises or announcements were made otherwise. There are some clear exterior and interior differences between the original teaser in the 2023 and Beyond video, but those were obviously corrected following research to ensure the product was accurately reflecting the configuration of a CH-47F in the US Army, the level of authenticity of which is what ED strives for when making aircraft modules. Such corrections in the interest of authenticity are not new in DCS nor are they isolated to the DCS CH-47F.

The crewmember's selected sight (HMD, FCR, TADS) determines where the weapon is pointed. If FCR is your sight, the gun will be pointed toward the FCR target with the diamond around it (if there is one). If the HMD is your sight, the gun will be pointed to where your helmet is pointed. If TADS is your sight, the gun will be pointed to where the TADS is pointed. If you action the gun while the FCR is your sight and there is no FCR target, LOS INVALID is indicating to you there is no line-of-sight for the gun to reference for targeting. The same logic applies to each weapon system, regardless of crewstation.

@Fakum, if you have a TSD point set as ACQ, the Cued LOS Reticle (broken cross) in the symbology is superimposed over that TSD point in the same manner that the Nav Fly-To Cue (homeplate) symbol is superimposed over your current navigation destination. Further, the Cued LOS Dots around the LOS Reticle are indicating where to look to see the Cued LOS Reticle within your symbology, and the Cued LOS Dot in the Field Of Regard serves the same function as the Command Heading chevron on the heading tape, by showing how far away from your nose the ACQ is located. Note that all of this is explained in the Early Access Guide.

The most efficient way is to either A) observe the TADS video when you store a target as the CPG (or command George CPG to store the target location) to see which target number is displayed when stored, or B) reference the FCR page TGT window when you store from the FCR page itself. Then on the TSD press RTE, select DIR, select POINT>, and type in T01 (or whatever the number is), and press ENTER like NeedzWD40 mentioned. Besides direct KU entry of the point index or cursor-selecting on the TSD with your MPD cursor, there are no other ways of setting a direct route to any TSD point. Having said that, I personally find it easier just to use it as the acquisition source (ACQ) instead of setting it as the navigation destination. This provides the same range and direction data in the bottom of the symbology, and it is very easy to select your last target point by simply selecting COORD on the TSD, and press the left paging arrow to go to the last page of Target/Threats, and press the button directly left of the last target in the list.

Locked at OP's request.

LMC is almost always used when intending to employ the TSE, because LMC (or IAT) helps ensure a stable TADS line-of-sight on the intended target. If LMC is not used, it is likely the TADS line-of-sight will be jerking around the target to some extent (unless the CPG has really fine motor skills in his right thumb, like George), which creates variations in the ballistic solution. LMC does not enable TSE, but LMC (when manual tracking) or IAT (when automatic tracking) ensures the TADS position is stable and consistent for better TSE calculations. I don't know precisely what Bradmick has stated, but yes it is normal to need to compensate by slightly offsetting the aimpoint and re-stabilizing to shift the rounds onto target. It won't always be uniform since the variables that affect all of this are varied and numerous. However, off-axis gun shots while in forward flight are more ideal for suppression, even when using the fancy calculations performed by TADS. If you want to increase the chances of a tight grouping on a target in forward flight, put the target in front of the helicopter to minimize the impact all of these variables have on the gun solution. The dispersion of the gun aside (since it is an area effect weapon after all), the bottom line is there is a lot of math being done to shoot these rounds from a moving helicopter and ensure they land on or around a target that is over a mile away, whether it is in real-life or in DCS; and the values that are being input into these calculations are constantly changing every fraction of a second. You should always be doing whatever you can to minimize the variation and magnitude of these variables to increase the effectiveness of the weapon. However, as a ballistic munition, it will never be a fool-proof, super-accurate weapon system.

This is not correct. When firing the gun, George uses continuous laser designation, which activates TSE. He does not use LMC, but that does not preclude the use of TSE, which is solely reliant on laser designation.