Raptor9

Neither the AH-64, nor the F-18, are capable of "just knowing" where targets are. They are required to be detected. The F-18 can only display airborne targets that are either detected by its radar or received by Link16. The AH-64D has neither Link16 nor radar (for the time being). If you have the TADS as the ACQ source in the back seat, it will show you where the IAT target is, or the target George is tracking, or where the TADS is pointing in general, just like if the the F18 targeting pod was pointed at a target. But setting the ACQ source to a target point like T01 is like setting it to a markpoint. Markpoints don't move with ground targets either. In real-life, ground targets are almost always located visually as well, either optically using the eyes or electro-optically with sensor turrets. This is true regardless of what aircraft is being flown.

The Snowplow mode has been receiving some refinements by the dev team.

The manual is still undergoing revision. The FCR chapter hasn't received the required updates yet.

Offsets are not used the same way in different aircraft types. I think what may be leading to confusion amongst the responses this thread has received is the fact that the F-16's Offset Aimpoints are used for ground attack, not air-to-air engagements or navigation. As such, what you are asking is not possible, since navigation can be performed to steerpoints but not offset aimpoints. The primary cockpit methods for coordinating air-to-air engagements against hostile aircraft would be using the FCR cursor in addition to the HSD cursor and graphics. You can see examples of this in the manual in the Tactical Systems chapter under "Bullseye" Reference Point. However, like Offset Aimpoints, Bullseye is used for broad situational awareness or for cueing long range radar scans to geographical areas, not for navigation. If you are looking for some sort of navigational reference to a fixed position relative to Bullseye, the best solution you can use is set your selected steerpoint to the Bullseye steerpoint (typically 25), and then use the Course knob on the EHSI (in NAV mode) to set the azimuth from Bullseye. This can be used in a similar fashion to a TACAN radial, in that you can see when you are at the appropriate distance from the Bullseye steerpoint along the bearing from Bullseye, but you won't be able to get direct navigation to that precise location. You can get a much better idea of where you need to go by using the HSD cursor, and compare its position relative to other HSD graphics like the range rings, cardinal directions, and the Bullseye symbol. But if you are doing air-to-air intercepts, the primary focus should be to simply move your FCR cursor to the corresponding bullseye location and search for targets there. If the location is not within range of your radar, simply fly toward that location on your FCR or HSD until it is.

It was a reminder that if a claim is made that something isn't modelled correctly in game, there needs to be evidence to back it up. There were multiple posts following the OP's that were claiming how these systems should function compared to real-life, and too often these claims are made based on personal opinions, assumptions, and interpretations. Certain individuals on the forum have been known to repeatedly demand that things need to be changed without any evidence to back up their claim, or evidence that applies to the version of aircraft being modelled. The original post stated that something seemed to have changed, and then the thread was quickly diverted into claims that other aspects of the game needed changed entirely, as stated within the 2nd and 3rd posts. Was it a little unclear as to how we got here? Sure. Is it really so unexpected given how quickly these threads delve into wild assertions about how broad concepts "should be"? Given how the thread progressed, is it so surprising?

So everyone can put away the pitchforks now?...

The purpose of employing active radar-homing (ARH) missiles is to ensure a higher probability of hit against a target and to facilitate a higher tempo of engagements when faced with multiple opponents. Whether or not the target aircraft receives a launch warning when an ARH missile is initially fired is subject to how the launch platform's radar functions when employing that type of missile, and how the target aircraft's radar-warning equipment is programmed to interpret such emissions from that type of threat. If you have public and unrestricted evidence stating how these events should occur, then please PM them to @BIGNEWY. But if this data is somehow gleaned from restricted documentation (even if it has been somehow leaked online), this cannot be shared or posted anywhere.

Removed some off-topic posts. This has been reported and fixed internally. Thank you for the report.

@Proteuswave, skin updated in the latest Open Beta update this week. Assigned to ISR country as well.

@itn, this is the difference between MAN and AUTO modes. In AUTO, the Maverick will automatically lock the target when handoff occurs. In MAN, the Maverick will receive a handoff from the TGP, but you need to manually initiate a track by selecting the WPN format and press TMS Up.

These systems are not the same.

From what I understand, the DCS laser beam does have a hard upper limit for simulation purposes, but I am not sure what that limit is currently. And the DCS laser doesn't simulate all the other minute factors that affect laser emissions in real life, like atmospherics. Simulating that degree of optical disturbances wouldn't just affect the laser beam, it would affect electro-optical sensors as well. My comment wasn't necessarily directed at what you specifically typed (if that is what you were inferring), I was just commenting that the many threads that debate how far the DCS laser should go rarely take into account the litany of real-life physics that are far beyond the scope of a video game. If you are asking for real-life range capabilities and limitations of real-world equipment, that gets into potentially sensitive topics and I won't go there, nor should anyone else. It's neither necessary for gaming nor relevant to DCS given the nature of how DCS simulates laser designations.

Master Warning light issue reported. The Master Caution light should not flash.

@ShuRugal that is a very good point. Thanks for adding that.

Just to bring some additional context to the discussion, laser energy also needs to reflect at the correct angles for detectors to see the designation spot as well. If the laser designator is directly north of a target and an F-18 is coming from the south looking for that designation reflection, they might not see it. There are some other factors in play that affect this as well, such the shape, surface characteristics, and specific contours of the target, the angle it is being lased from, and how much of the laser beam is actually striking the target. I believe what the OP's intent was is to bring awareness to some of the debates regarding how far lasers in DCS travel, and what a given laser should be capable of achieving in game with respect to designations, laser spot trackers, weapon guidance, etc. Some may desire a specific and universal real-world number for comparison, where everything works fine below and nothing works beyond it. But the point is that there is no universal number; because lasers are not a perfect targeting device. Add to that the fact that no two lasers are exactly the same. A laser designator carried by an individual is not going to have the same power and range as one carried on an aircraft or mounted on a vehicle, just as a laser onboard a LITENING pod is different than one carried in the AH-64D's TADS. The real numbers and performance of these items are usually not available to the public, or the specific tactics and techniques to employ them under various circumstances. Players can still employ reasonably authentic scenarios within DCS, but there may be situations where a DCS laser designation slightly overperforms or underperforms compared to real-world equivalents; characteristics of which are often not available due to security reasons.

Meaning that in DCS, regardless of how far the simulated laser beam actually goes, the intended behavior of the DCS AH-64D is that it should only display a laser range out to 9999 meters on the TSD.

I will respond to this one instance alone, for the sake of making a broader point. Just because someone reads a document, does not mean they understand the real-world context. This happens quite often, and it is a prime example of why so many debates happen on these forums, discord channels, or elsewhere. The Fire Support protocol was intended to be used with the EPLRS system. However, the EPLRS was removed in the avionics version that is being simulated in DCS AH-64D. Therefore, what you think should exist in it was actually removed and replaced by a different system altogether, rendering the Fire Support protocol defunct and not usable in the aircraft, despite what you read. Reading about something on the internet does not equate to inherent knowledge on the topic. The reason such topics are often avoided, and the reason I gave such a pithy response on the matter, is because these things can easily go down the slippery slope of touching on sensitive information about such systems and their evolution in these aircraft, which I will not do. However, inevitably, someone else might decide to post something on the forums about it to move the conversation along. Then that can lead to forum members posting excerpts from restricted documents on the matter (which you yourself have done on multiple occasions, despite multiple warnings not to). Then the thread needs to be moderated and cleaned because people are distributing documents in violation of the forum rules, which are there to protect not just ED but the community as well. This is just a video game. I am not going to debate the validity of these rules or policies, because they are there for a good reason. Some may not agree with them or even like them, but that doesn't change the fact they are necessary.

If that is occurring, that is a bug. The 9999 isn't just a display limit, that is the maximum range that laser energy is processed. Not to say that the light beam itself doesn't continue on, but if the TSD page is showing the TADS line further than 9999 meters when lasing, that needs to get resolved.

First off, let me begin by saying that I am not a community manager, so I don't speak for them as individuals or for their department. However, their job is far beyond simply "looking at a few bug reports for a few aircraft." They monitor, moderate and manage the entire forum to ensure individuals are not abusing the rules, attacking each other, or posting slander, restricted information, or forbidden topics. On top of all of that on the forum, they also do the same for the other social media channels: Discord, Youtube, Facebook, and interact with the community in other ways like on Reddit. Of course, the community managers are not the only ones checking bug reports or interacting with the community. You also have ED internal testers that do the same, as well as other ED employees that do as well; to include translators, manual writers, and I'm sure some dev members. Admittedly, I'm still a newcomer so I'm not familiar with the forum screenames of all the ED team members, this is just from what I've observed. Switching gears, another thing that can be seen is that whenever a feature is announced for one product, the players that use other products that are subject to contemporary features often immediately demand to know when their favorite module is getting the same treatment. When it was mentioned the F-18's radar was being re-factored, the F-16 players wanted to know when the F-16 would get it, despite already announced it would be. When it was mentioned the F-16's DTC was in progress, the F-18 players wanted to know when the F-18 would get it, despite already announced they would be. Despite the fact that it was announced multiple times that each of these respective aircraft would get these features, everyone wants the features in their preferred aircraft first and as soon as possible above any others. Following that, if any newsletter does not talk about an upcoming feature for a specific module, there is often times the inevitable thread that starts where players assume the feature might have been cancelled, shelved, or delayed, even if a previous newsletter mentioned it as still being worked on. This starts a long cycle of debate back and forth until the community managers are forced to lock a thread and assure everyone that nothing has changed, there just isn't news to share. What does all of this have to do with how bug reports are managed? Well, nothing; at least in itself. The reason I am typing out this short novel is to articulate not only how busy the community managers are in trying to keep fires from starting or putting out existing fires across the various channels (some of which continuously progress in real-time, like Discord), but that communication itself between the community and the ED team members can be a significant challenge. To many players, they only see their little slice of the forums, whether it be their wishlist or bug report, or they only see what is (or isn't) happening for their favorite DCS module. But to the community managers and other ED employees, it is everything, all the time. What the vast majority of the player-base sees is only the tip of the iceberg of the amount of effort that it takes to manage the interactions with the community, or the development time that is being spent to produce such complex aircraft and environments. I myself am taking a good slice out of my workflow today to read this thread, consider the appropriate response, compose this message, and then proof-read it several times to ensure that it is a measured and appropriate response. I do this in a methodical way because, as an ED team member, I do not have the luxury of posting whatever I please whenever I want, or respond in a half-cocked manner. It is my responsibility to ensure that what I say is accurate, level-headed and not driven by an emotional response, and does not reveal or state anything that has not been approved for public consumption. Forum members are under no such obligations outside of the forum rules and guidelines. Regarding bug reports, they could post anything that could be caused by interference from user-mods, hardware input issues, user error, a misconception to how something should work, or any number of reasons why something "doesn't seem right". If it seems like some bug reports are missed, some in fact are. Some get missed, some get overlooked, some sound very similar to the one that was looked at last week, etc. We are human, with much more work tasked to us each work day than many realize. Many of us work more hours than we are required, to include the weekends. We do this because, like you, we are passionate about DCS World and we want it to not just succeed and grow, but we want it to be fun as well. Unfortunately, quite often the absolute worst case is assumed; that ED team members or our 3rd party dev team partners are lazy, evasive, incompetent, don't know what we are doing, only care about sales, don't respect the community, blame players for issues, don't like to communicate with the community, ignore bugs because we don't want to fix them, etc. When these statements are repeated endlessly on the forum and other channels, even though it is borne of false hyperbole, kneejerk reactions to announcements, or community members with an ax to grind, this is not just disheartening to ED team members, it also creates discontent among the community itself and makes it very difficult to consider how we should communicate in the future. Everything we do is met with both positive and negative reactions, but more often than not the negative reactions are the loudest and most promulgated statements on these community channels. Even when information is provided in a very honest and facts-based manner, it may still be met with a negative reaction or blowback from other players. This could be because they do not get the answer they expected, there may be a cultural or language difference, or because they don't like it because they don't like it. Again, we are all human, and I'm pretty sure we all want the same thing, which is to have a fun and engaging form of entertainment that caters to our fascination of high-performance aircraft and their place in history. But please keep in mind, to use an analogy a second time, only the very tip of the iceberg is seen. I cannot stop anyone from basing their opinions on limited knowledge of what is happening behind the scenes, but we purposely avoid posting information that we do not know to be accurate, that does not reflect a known solution to an issue or bug, or is not a future development plan that is both set in stone and already publicly announced. We are not always perfect at this, but if a change occurs, we always let the community know; even when it may result in backlash. Honesty is important, but is only useful if it is based in facts, not speculation or assumption. But speaking honesty based on fact is a two-way street, just as respect is a two-way street. Bug-reporting standards are there to ensure efficiency in handling of such reports, it is not there to serve as a "gateway" criteria before a bug is considered, nor does it serve as a "guarantee" that a bug can be reproduced, reported, or fixed. If a bug report is provided with a simple paragraph with no track file but still marked as "reported", this does not constitute a break in the bug-reporting standards. It may have been seen by a member of the volunteer closed beta testers or another ED team member, and is already known and reported. If a bug report is still marked as "investigating" for months, the bug may have simply been moved to a back burner due to higher priorities. Yes, I can see how this might support the idea of a public bug tracker, but as already mentioned in the above paragraphs, or in the post below, the manpower requirements in maintaining this would be astronomically high, much more than many realize. It is very easy to cast stones when, due to lack of information, there is nothing to contradict or refute personal biases or assumptions. If a player sees a lack of communication as disrespect, neglect, or lack of appreciation for their bug-reporting efforts, that is certainly not our intent nor is that what is happening. We cannot, and will not, simply mark every single public bug report with a blanket cookie-cutter tag to make it look like every bug report has been utilized in the development of DCS products, but we also have no control over what any player tells themselves or the community to fill a vacuum of information.

@Tincan2424, the DCS Lunar Sale is ongoing until the end of the month, with some modules such as the F-16 and F/A-18 included at a 30% reduced price. The AH-64D is not part of this sale, but has been available at a 20% reduced price since it was released into Early Access in the Spring of 2021.

Everyone is entitled to their own opinion, so please keep it civil. Having said that, the AH-64D's FCR is like an optional external sensor pod. Removing it is simply removing a sensor option, nothing more. It would be like saying the F-16C is only iconic because of its HTS pod, and removing it somehow detracts from the aircraft in other ways aside from removing a sensor. I think that for many fans and advocates of the AH-64, its performance in Desert Storm prior to the FCR even existing, as well as its use in several conflicts in the past 20 years (such as Iraq, Afghanistan and Syria, 98% of which was without FCR's), is what has made this aircraft iconic and legendary in its own right.

Duplicate AH-64 wishlist threads merged. I'll leave this in the AH-64 wishlist thread for now, but understand that you all are asking for the entire DCS multicrew system to be re-vamped, not just for the DCS AH-64D. These may seem like preferable ways of implementing such logic to some players in some scenarios, but such drastic changes to the multicrew system would need to be applied to all multicrew-capable DCS aircraft that have flight controls present in more than one crewstation. This would mean re-writing how DCS World handles multicrew logic across multiplayer servers, and there are several 3rd party dev teams with multicrew-capable aircraft that would also be subject to these changes. This is a wishlist thread after all, and you all are free to brainstorm alternative methods of simulating cooperative flight controls in the multiplayer environment, but I bring this up as an advisory to accordingly temper expectations for such a drastic change to occur in the multiplayer system.

As Brad stated, this is not correct behavior in the real aircraft and is being addressed. Using the behavior of the Huey is not a worthwhile comparison. The two aircraft have very different rotor systems subject to different control behaviors under low-G conditions.

Binocular NVG's don't expand the field-of-view beyond the round aperture, they simply add depth perception. And just to be clear, the NVG's modeled in game are AN/AVS-6.

I have no knowledge on what is planned in that regard. I was just refuting false claims about what is or isn't simulated when equipping the F-16 with ECM pods.