Raptor9

I hear you. Unfortunately if I give any date, even a rough estimate and state that it is only "planned", I will then be chained to it. When dates are mentioned as "planned", these are often interpreted as promises or guarantees. I completely understand your position, and I want the first round of updates pushed out as soon as possible. However, as much as it pains me to say it, I can't give any ETA or estimates at this time. This is the best way.

That's simply from the recording. It's never visible in the video source in the aircraft.

I just spoke to the dev team about this, and they confirmed that no flight model changes have occurred since the tail rotor VRS behavior was modified in the Open Beta patch on September 30th. As for these items... The below screenshots are from the current OpenBeta, and rockets are clearly reaching beyond 2.2 km, even at a lower altitude and a hover; and the gun is also clearly landing rounds beyond 1.5 km. And the new George setting was also clearly identified in the changelog:

This has not occurred. From my understanding, the last 2.7 patch in September was the only instance when the flight model was updated and not in the changelog. I do remember making a comment in a separate thread in Bugs & Problems that sometimes things are missed in the changelog, but that it isn't intentional; not a deliberate effort to conceal changes. Further, no flight model changes were made in last week's patch to 2.8, so I think there may be some placibo effect going on. Or maybe you all are just that good.

I just watched your track (multiple times due to the rapid fire data entry), and the numbers were accepted just fine. I'm not seeing the issue you are describing, nor did I have any issue modifying any programs when I tried it myself. 1's and 0's went in without any issue.

It wasn't, which is why I asked for the clarification as I did. Thank you. As stated, these items are not implemented yet, but will be tested at the appropriate time of implementation.

@Nereid, are you: 1) Saying that the functions associated with the switch are not working? or 2) Saying that the switches themselves are not animated back and forth? If you are saying 1), the Laser Spot Tracker (LST) and Image Auto Track (IAT) functions are not implemented yet in the DCS: AH-64D. This is why nothing happens when you try to use these functions. And just to ensure their is no confusion, the LST is for detecting other laser designations with the TADS, it doesn't actually fire a laser from your own TADS. If you wish to use the laser trigger to designate targets, you will need to select TADS as your Sight. The laser will not fire if this is not the case, regardless of whether you pull the trigger or not. If you are saying 2), the module is WIP and some cockpit animations may not be added yet. EDIT: sniped by Floyd1212

The same reasons apply, in that the airspeed over the wings is what's important when you are rolling down the runway on the wheels

Thanks. I've watched the track and I'm attempting to replicate to determine a cause. I'll get back to you.

Ah, then I'm probably mistaken.

I believe the generic comms menu should only work on the ground, like if you were talking to ground crews. Otherwise the comms menu needs to be opened using the Push-To-Talk (PTT) commands to "use the radio". Some key bindings that were present across all modules have been re-located to a single unitary control group called "UI Layer". This can be found in the drop-down list in the top left corner of the control options where it lists all the different modules. Should be at the top of the list. As for custom scripts, those will be up to the authors of the scripts themselves to ensure they function properly. And as a friendly reminder, in the future when creating bug reports, please start a thread for each individual report, and attach a short track file demonstrating the bug behavior (on the Caucasus map if able, it allows more of the dev members to access it since not all have each map installed). If you are simply inquiring about aircraft functions or behavior that you aren't sure is user error or if others can help you, a track file may also allow others to see exactly what you may be doing wrong and may speed the process. Thanks.

A short track replay to demonstrate the specific conditions of what you are describing is normally required to correctly diagnose behavior.

I'm away from my DCS computer and couldn't watch the track, but I was trying to help by outlining the likely causes. So this is a "correct-as-is" situation.

Did you have the gear down or were you in DGFT mode when you checked it? When either of these conditions are true, the speed switch on the HUD control panel is overridden and defaults to CAS.

Admittedly, I'm not exactly a wizard of words, so that doesn't help.

Not usually. It is pretty typical to only get the Square identifier "CX" followed by the Easting/Northing "12341234". The Grid zone designator is extremely large, and especially with helicopters, you are almost always occupying the same Grid zone as everyone else sending/receiving the coordinates, so it helps with brevity.

I imagine there were quite a lot of updates, improvements, and new features to the core DCS World that were not included in the changelog.

@Soundman766, I can't speak for the dev team; I'm a manual writer. But in my personal opinion as a user of it, I think it makes sense and is more efficient to place the same commands all under one list instead of replicating it throughout all modules. It cleans things up a little bit. For example, I re-map my Active Pause command to RShift+Pause. So now if I need to re-install DCS, I only have to re-map the command once in the UI Layer, instead of re-mapping the same command in the control settings for every individual aircraft module I own.

Nope, still "Active Pause"; but you need to go to the top left corner where it says "F-16C Sim", click on that drop-down menu, scroll through all the aircraft modules to the top of the list and select "UI Layer".

@Soundman766, the Active Pause has been moved to a single location in the UI Layer controls category, along with some other associated UI commands like time acceleration, instead of each individual module. Hope this helps.

Hi @drsoran, I hope I can be of help. When a markpoint is generated, it can only be generated by designating a location using the HUD in VIS mode, the TGP in Point track mode, the FCR in FTT mode, or designating the aircraft's current position (as in the case of the OFLY option). If you are in CCRP or DTOS air-to-ground sub-modes or NAV master mode, the TGP can designate a location in Point track mode without issue. This is why it is necessary to press TMS Forward twice to generate a markpoint when using the HUD, TGP or FCR sensor MARK options. The first TMS Forward command enters TGP Point track, FCR FTT, or ground stabilizes the HUD VIS pipper, the second TMS Forward designates the location for the markpoint. When in CCIP air-to-ground sub-mode, the TGP is normally slaved to the CCIP pipper, which allows TGP-laser ranging to be performed in conjunction with CCIP weapons employment. As a result, the TGP cannot enter Point track mode, which means the TGP cannot designate a location to generate a markpoint. In the case of having no air-to-ground weapons loaded (and as a result no corresponding air-to-ground SMS weapon profile to generate the CCIP computations), the TGP doesn't have any CCIP pipper to slave to, and the TGP can be slewed about if necessary for ground reconnaissance and such, even without air-to-ground weapons loaded. However, I suspect that this very specific circumstance (CCIP mode without an air-to-ground SMS profile) is why it is not possible to generate a markpoint with the TGP, even though the TGP can be commanded to enter Point track mode under these conditions. As to whether this reflects the actual USAF F-16C Block 50 avionics logic, I do not know (I'm neither an F-16 pilot, nor a member of the F-16 dev team). I've determined this is how the logic currently exists within DCS: F-16C, based on my research and testing as part of the process of updating the DCS F-16C manual . For now, you can still accomplish what you desire (using the HTS to cue the TGP to a location and then designating a markpoint from the TGP, with just air-to-air weapons loaded), but you will need to be in NAV mode. Regarding this question, any time the CCIP or STRF air-to-ground sub-modes are entered, the FCR is switched to AGR mode for accurate ranging and the HUD is automatically selected as the SOI. If HUD is toggled as the sensor option on the MARK DED page, a similar process occurs: HUD VIS sub-mode is entered, the FCR is switched to AGR mode and the HUD is automatically selected as the SOI. After this occurs, the first DMS Aft press exits VIS mode and returns to the previous master mode/sub-mode (so that having MARK on the DED with HUD as the sensor option doesn't inadvertently lock-out other master modes, it allows the pilot to abort the markpoint process without needing to take his hands off the HOTAS to press the ICP DCS to SEQ or RTN). In the same specific circumstance that you've described above of having no air-to-ground weapons loaded but in A-G master mode, the only two air-to-ground sub-modes that could be entered are CCIP and STRF. So what you are seeing is the VIS mode switching back to CCIP mode when DMS Aft is pressed, which is why the SOI instantly switches back to the HUD. To re-enter HUD VIS mode, you will need to use the DCS SEQ position to cycle back to MARK *HUD* sensor option to re-enable HUD VIS mode. This doesn't occur with the other sensor options since 1) there is no mode switching required when these MARK sensor options are selected and 2) the SOI must be switched to TGP or FCR to command them enter Point track or FTT in order to designate the location for a markpoint. I hope this helps, along with the future update to the F-16 manual (still WIP) that will include in-depth explanations into MARK logic/functionality.

George arms the aircraft when you direct him to target an enemy vehicle in preparation for an engagement. The implied task is that the aircraft needs to be armed for him to do so, because he cannot fire the laser if the aircraft is SAFE. If you want him to allow you to SAFE the aircraft, you need to use the Down Short command in the AI menu, which will cause him to stop targeting and slave the TADS to FXD forward, and you can SAFE the aircraft. But if you direct him to target something, he will once again ARM the aircraft so he can use the laser if necessary, or employ a weapon. Aircrews would never fly around with the aircraft set to SAFE if enemy contact was likely, the aircraft is always Armed when performing pre-combat checks. Further, if you are directing George from the backseat, the idea is that you are flying the aircraft, and it is standard procedure for AH-64D aircrews (at least in the US Army) that the person not flying is the person responsible for setting the master ARM/SAFE button state. The pilot-in-command does have the final say of when munitions will leave the aircraft, but the master ARM/SAFE button is not directly indicative of that consent.

The T700-series engines have an integrated air particle separator (APS) system. Airflow is directed through a series of vanes in the inlet and into a "swirl frame" which uses centrifugal force to separate dust and particles into the APS. Dust and FOD would have to make it past a "dogleg" of sorts to get to the compressor itself. The entire system is integrated into the function of the engine. However, this isn't a 100% solution to prevent FOD or sand degradation of the engine. The only way any engine can achieve that is to physically block such particles from even entering the inlet, which can be done to a good extent using inlet filters or air particle separators over the inlet, but these will also restrict air flow and will typically create negative impacts to the engines overall performance. Some examples: filters on a Blackhawk and IPS on a Chinook:

Correct, no proximity fuzes. The M423 is indeed point-detonating which is normally what would be used for the M151 and M229 HE warheads, or the M156 WP target marking warhead. The M433 is an impact-triggered delay fuze that can be programmed from the cockpit with different delays, and can be equipped on the M151 rockets in DCS: AH-64D. Technically they could also be equipped to M229 rockets in real-life, but I don't know if that configuration was ever actually used. The M439 on the M261, M264 and M255A1 rockets isn't directly configurable by the crew, it's automatically sent to the rocket based on the range that exists at the moment of launch, so that the rocket deploys at the optimum moment. The crew just aims and fires, the aircraft does all the math. The M442 fuze is a fixed time delay for the illumination rockets just like how they work on the other DCS modules like the A-10C.

I think I need to explain my original point a different way. When flight model changes were pushed to Open Beta last month, it included changes of how the main and tail rotors were calculated. This affected the behavior of the aircraft such that pedal positions within the yaw axis resulted in different behavior than what was previously experienced, causing the slight right roll on the ground when the rudder pedal input axis was centered. It was stated by several players that the pedals were adjusted so that the input was offset to the left, with the "zero tail rotor thrust" point now being right of center. While the apparent behavior did indeed seem to indicate that the control input positions were adjusted, this was not the case. The tail rotor bias to the left was always there, but as the flight model was adjusted, the behavior of the rotor systems changed. The tail rotor's anti-torque effect at a given pedal position observed in the Controls Indicator was different, which resulted in some players (through no fault of their own) mistakenly thinking that the pedals themselves had changed or that the rudder input axis was bugged. Whereas the flight model "under the hood" is what changed, not the controls themselves, nor the Controls Indicator axis positions. So what I'm saying is that if someone is basing their assessment of how the FMC is functioning on what they observe within the Controls Indicator, their impression of what is happening may not fully account for what happens within the flight model of the helicopter as refinements are made during Early Access. Changes may be made that result in different observations of the Controls Indicator compared to what occurs currently, which is why I said not to take what is happening in that window as fact for how the aircraft performs or behaves. If the DCS AH-64D were to gain/lose stability or maneuverability, it may not come from changes in the FMC inputs (as indicated by the green SAS indicators), it may be from changes to the flight model itself. My intent wasn't to imply that anyone should just "get good", but rather to temper expectations of what to use as a tool for learning how to fly the aircraft. In the real AH-64D, there is no indicator that shows in real-time what the FMC is doing. Through training, academics, and practical experience, the logic within the box can be learned and correlated to what is happening in the cockpit, provided there are good mentors around that know what is actually happening (senior pilots, especially maintenance test pilots).