Raptor9

Such information will be included in the next version of the DCS AH-64D Early Access Guide, which is planned for inclusion in the next update to DCS itself.

The FCR has not been implemented for multicrew yet and this is still in development. Please reference the AH-64D roadmap.

The most current ALIC tables at the time of me writing this are in the Appendices of the F-16 (and F/A-18) Early Access Guides. Regarding the 1L13, 5G66, and FPS-117 early warning radar systems, these fall outside the AGM-88 engagement capabilities and do not have corresponding ALIC codes.

I've been playing DCS since Black Shark first came out in 2009, and only recently came onboard with Eagle Dynamics, so I totally understand where you're coming from, and your frustrations. After joining the ED team, it has been a major learning experience for me in seeing the other side of it all. In that sense, I would kindly ask to consider it from our perspective as well. Another aspect of this sort of thing is whether the user has mods installed, or whether a given MP server is running some sort of script (or combination of scripts) that is causing the issue. I cannot tell you how many times that a user assures us they have no mods installed, and when they do post a track file or a crash log it turns out they do in fact have mods installed. Or when a server incorporates some scripted behavior or process that plays havoc with the DCS game processing. I am not saying this is what is happening here or that the OP has installed any mods, but in most cases these things need to be considered by the community managers and others that assist with bug reporting and testing. Otherwise the limited number of devs we have would spend all their time chasing down reported bugs that are from extraneous factors that they have no control over, and then development as a whole would grind to a halt. If some of the ED team that interact on the forums like BigNewy, NineLine, Lord Vader, and myself, seem like we are being a little restrictive with how we filter bug reports, then you would be right. We try to do our due dilligence before sending this stuff to the developers because with limited time and resources, for every hour or day a dev is spending to resolve an existing bug, that is time and resources taken away from progressing the module as a whole toward completion. Bugs absolutely need to get resolved, but before we commit devs to a bug, we need to be sure that the bug is not only legitimate but that we also have as much accurate information as possible as to the nature of that bug so that the devs can fix it as quickly and efficiently as possible. That was a long diatribe, and it isn't my intent to go off topic in this thread, but I think it is important to understand why we say or do the things we do, or don't do. EDIT: I also want to clarify that the last paragraph in my previous post wasn't directed at you specifically, @Floyd1212, just in general. I know you spend a lot of your own time not only reporting bugs but interacting with other players in trying to help them troubleshoot potential issues. So I appreciate that.

The devs have the ability to replay multiplayer tracks from clients. This is how many of the datalink issues that were found in development were ironed out in multiplayer testing before such features were released. It is of course preferable to have short tracks since the time of the devs are a valuable resource that would otherwise be spent on the module itself versus running through a set of extremely long tracks trying to figure out what specific variable is causing the issue and when it occurred in the mission. @Floyd1212, on several occasions we have spent several hours in multiplayer testing amongst ourselves trying to reproduce this erroneous NAK behavior without success; this is why we are asking for tracks in the hope that we can find some yet-to-be-discovered variable that may have been inserted into the simulation that is causing this issue for the original poster of the thread. We understand that a persistent bug can be frustrating when players want to play the game and enjoy themselves. However, the implication that ED does not perform our own testing to seek reproduction and resolution of issues, or that we ignore bug reports altogether, is also personally frustrating given the amount of investment in testing that does in fact occur.

This was reported during internal testing and is already fixed internally. However, thank you for the report.

If the FCR is not available for targeting, such as if it has been damaged, it is being used by the Pilot for another purpose at that moment, or the FCR simply isn't installed on the aircraft. The FCR has many uses beyond just sending AGM-114L missiles toward targets on the battlefield, so it may not always be dedicated to targeting.

MMA = Mast Mounted Assembly, which includes multiple components besides the FCR itself.

This was a deliberate change. The DTOS, VIS, and EO-VIS sub-modes will no longer incur a slew to the Navigation cursor. Meaning that entering post-designate in these weapon delivery sub-modes should no longer cause the steerpoints to become offset. After further research and seeking some SME feedback, it became apparent that designating the "Target" location with the TD Box did not mean the TGT sighting point (like in CCRP or other Pre-planned sub-modes), but rather it was simply designating a physical target location on the ground, since sighting points are not used in Visual sub-modes like DTOS, VIS, etc. This small but significant distinction is what led to the correction of this behavior, and is what the following entry in the changelog was referring to.

Threads merged. Please refer to the changelog thread for any changes in each DCS update.

@mchighlander73, please review the recent posts in this thread or the DCS AH-64D Frequently Asked Questions. Threads merged.

I never flew the OH-58D. In any case, anyone will have plenty of opportunity to see for themselves when the module is released.

There are several improvements to the EO sub-modes as a whole that are planned in the next patch. Please stay tuned for more information.

FFD, 3D View, and Contours are not planned. Vis shading is still TBD.

Correct. When the GPS is turned on it takes a couple minutes to get the time and location. Once this is accomplished, then you can turn on the datalink by rotating the MIDS LVT knob to ON.

Reproduced and reported. Thanks.

I would say you have a misunderstanding of how the accumulators and JFS work. When you engage the JFS switch to START 1 or START 2, the hydraulic accumulators are used to the start the JFS, which is a small gas turbine like an APU. START 1/START 2 are essentially start switches for the JFS, and once the JFS gets up to speed the JFS Run light turns on. However, once the JFS is spooled up and is self-sustaining, it no longer needs pressure from the accumulator to maintain speed because it is burning jet fuel. The difference being that unlike a separate APU, operation of the JFS is mechanically linked to the engine and starts spooling the main engine as well. This is what drives the RPM gauge on the right side of the instrument panel. Running the JFS with the engine turning without moving the throttle to idle does not mean the accumulators have infinite pressure. In fact they don't. You can actually deplete the accumulators to the point that the JFS cannot even start. Try moving the JFS START switch to START 1 but moving it back to OFF a few moments later, prior to the RUN light coming on. Eventually the accumulators will deplete and starting the JFS will be impossible. But running the JFS alone does not mean the accumulators are constantly dumping pressure to spool the engine. If any SME's want to jump in here to correct me, I'm all for it. But the tracks supplied in this thread show no behavior that is not intended.

@skywalker22, the reason your engine would not start is because there is no fuel in the aircraft. I added fuel, used JFS 1 position to deplete one accumulator, then manually shut off the JFS without moving the throttle to idle. Waited a moment for the engine to spool down, then tried JFS 1 a second time and was able to start successfully.

@Suffer_Player, you did not follow the instructions in my previous post. You set the MIDS LVT knob to ON before the engine was even started and left it ON throughout the entirety of your track. Again, you must wait until the TIME DED page says "GPS SYSTEM" before setting MIDS LVT knob to the ON position.

This was already fixed internally. Expect it in the next update.

Since I don't know what you are doing precisely, it is difficult to troubleshoot reliably to know if you are using the correct procedure. But, if you are intending to use the datalink in the AH-64D, you should not be interacting with the COM>MAN sub-page at all. Using the manual tuning functions on the MAN sub-page will prevent datalink from working; you must use the Preset tuning methods described in the Early Access Guide.

After landing and repairing, you must set the MIDS and GPS back to OFF during the shutdown sequence. When starting up again, set the GPS back to on and wait for at least two minutes. Confirm by going to the DED TIME page and check that GPS SYSTEM is displayed. Once you see "GPS" displayed here, you can switch the MIDS LVT knob to ON.

When you edit a Preset's frequency, you will need to re-tune that preset with the updated frequency into the FM1. Select that preset on the COM page so you get the radios along the top row, select FM1, set TUNE on the bottom to PRI, and then press SC under the TUNE FM1 bracket. (These steps are illustrated in the DCS AH-64D EA guide in the Radio Communications chapter) Going to the MAN page to enter a frequency manually tunes the radio, which cannot work with datalink.

@AndreNL, could you be more specific? Precisely what part of the "preset" are you referring to that must be the same? You may have discovered some erroneous behavior under strange conditions, so I'm curious as to what you mean. The radio frequency and wingman ID numbers must of course be the same for the messages to get through, but if you are referring to how the name of the Preset is displayed on the COM page or EUFD, then that should not matter nor cause a NAK.

First of all, I want to point out that DCS is not modeled after other flight sim games. The ED devs do their own research and have their own SMEs that they may take input from. Just because another game does it a specific way does not mean it is correct or accurate. That is all I will say about that because this is not the place to make comparisons. (and it is a violation of forum Rule 1.15) Having said that, the CZ option should be on the HSD if the criteria has been met for its display (such as if a cursor slew has been incurred). If it is not, then there may be a bug. Regarding the question about TMS Aft, this is a common point of confusion. A double press of TMS Aft is not a universal Cursor Zero option, nor is Cursor Zero a feature of the TGP. Cursor Zero is a function within the F-16 avionics as a means to reset the applicable cursor slews to zero and is primarily available as the "CZ" OSB option on the FCR, HSD, and TGP MFD formats. However, a hands-on CZ "shortcut" using TMS Aft is available under the following conditions: TGP is set as SOI TGP is in SLAVE mode (i.e., not in AREA or POINT track) Since the TGP is typically in AREA or POINT track if TGP was SOI (because the player has likely been using it), the first TMS Aft sets the TGP to SLAVE, and the second performs the Cursor Zero since the 2x conditions have now been met. However, if the TGP is made SOI and the player does not enter AREA or POINT track, then the first TMS Aft will command Cursor Zero since the 2x conditions above are met. But again, these two conditions are only available as a shortcut when using the TGP. Otherwise, the only means to command Cursor Zero without the TGP is via the MFD OSB option on the FCR or HSD MFD formats. I hope this clarifies the logic.