Bunny Clark

You're probably seeing the CPG screens. If both the Pilot and CPG screens are exported to the same view port, the CPG screens will draw on top. If you're using the LEFT_MFCD and RIGHT_MFCD at all, in any modules, and have them defined in your monitor config you need to remove them. Unfortunately right now the Apache exports its screens to the two default viewports whether you want it to or not. Have you edited both the init.lua and LCD.lua files to redirect them to your view ports?

Apache display exports are temperamental right now. You can find some info on it looking back over this thread, otherwise a good summary of where we are can be found here:

Most of them need to be .PSBs because they're over 2GB. A few of them could be converted to .PSD though, I'm not sure what the policy would be on me uploading those in PSD to User Files.

You actually can in this specific case, as the George AI commands are under a separate control section.

I meant clicking on them to move them. All the modules have keybinds for it.

I don't think ED does this for any of their modules, do they? It's a fairly common feature of 3rd party modules, but ED seems to be against the idea.

Hey, since you're not the first to ask this type of question, I'll walk you through it here. Most of the files we'll be looking at are found in Mods\aircraft\AH-64D\Cockpit\Scripts. You've already mostly figured this part out, but start with the clickabledata.lua file. This will give you the "id" value, but it will also give you the device name, which we won't type into the JSON file, but we'll need next. Here we can see the id is 308 and the device is HYDRO_INTERFACE. Type 308 into the "id" field and remember the device. Next we'll find deviceId. For that open the devices.lua file and search for the device name you found in the previous step. The Find function in your editor is a big help in every step of this process. Here's where it is in the devices file: Now we need to do something slightly annoying, and this will be a theme later on too. The deviceId is enumerated from the start of this file and incremented all the way down. So you need to count, starting from the top. Only count devices though, not every line. Only lines with devices count. Every time I find a deviceId I add it to this file as a comment (you can see I've found the lighting system id in the past), making this process a bit easier as you work. Thankfully the HYDRO_INTERFACE is near the top of the file, counting down we find it is device 5. Type this into "deviceId". Next we need to find the action id number. This is in the command_defs.lua file. We'll do counting similar to the previous step, but thankfully not through the entire file. Every time there is a reset_counter() header, we start counting over. This makes things rather a bit simpler. These counts almost always start at 3001 - you can check this in the file header if you want, but I've always found them to be 3000. The command we're looking for is the third on the list, so our action id is 3003. For a button, this becomes the pushId and releaseId. The final step isn't strictly necessary, but I'll walk through it as an example. We'll navigate to a new path, this time Mods\aircraft\AH-64D\Input\AH-64D_PLT\joystick\ and open the default.lua file. Again, look for the command we're mapping. Since this is the file that creates all the available control bindings not everything will be in here, but it's often helpful. Here we find: This shows us the value for each position of the button. In this case down = 1.0 and up = 0.0. These become the pushValue and releaseValue. This isn't surprising, as these are the normal values for a button, and I normally wouldn't even bother looking them up for a button object. When mapping switches though, it's often helpful to see which switch position is which value. Put it all together, and you get this: { "heliosType": "DCS.Common.PushButton", "device": "NVS Mode Panel", "name": "TAIL WHEEL Pushbutton", "description": "Current state of this button.", "exports": [ { "format": "%1d", "isExportedEveryFrame": false, "id": "308" } ], "buttons": [ { "deviceId": "5", "pushId": "3003", "pushValue": "1", "releaseId": "3003", "releaseValue": "0" } ] }, I generally use the name from the clickabledata file, which is what I've used here. Hope that helps!

Hey BN, is this officially recognized as a bug and being investigated? I haven't seen any movement on my bug report and want to make sure it's on people's radar. I totally understand that there were other higher priorities for the first patch, but a progress update on this would be nice.

Radar Hellfires are great against big metal vehicles. If you're shooting a bunch of tanks, then radar guided is likely the way. But, the radar Hellfires can only guide on things that can be picked out as objects by the radar. Laser Hellfires, by comparison, can be guided to anything the CPG can point the TADS at. This allows pinpoint precision in crowed urban environments, hitting specific sections of buildings, hitting very specific visually identified vehicles, and hitting objects which don't have a great radar return like fortified infantry positions, MG emplacements, mortar teams, and supply depots.

I think a lot of the confusion here is that there are three things going on at once right now: 1) The DCS Apache has bugged monitor exports. I've gotten around the problem for now by disabling the CPG screen exports in favor of correctly showing the Pilot screens, but this method potentially breaks other modules. Without putzing with the display init.lua files and your monitor config, you will only ever see the CPG screens, as they are drawn on top of the Pilot screens. For this to really start working well will require a fix from ED. 2) The current build of Helios does not support the Apache. I have created a new Interface file for the Apache which serves as a translation system between Helios and DCS for things like button presses, axis positions, and indicator lights. These files are normally installed with Helios and available right away, but because this is all new, you need to download my Interface file and copy it into your Helios install directory. I have submitted my work upstream to Helios, so it should hopefully be included with the next update and save people from having to do this step. 3) I shared my profile for people to use and modify how they like. This should be installable like any other Helios profile, but it does require the Interface from Point 2 to function properly. If you want display exports from DCS to work with it, you'll also have to solve Point 1. This adds a few additional steps beyond what normally is required to get a profile installed and working. Cptn Zeen has some great tutorials for Helios on his YouTube channel here: https://www.youtube.com/channel/UCH3vOMBzNRnTliVQmhhrjng/videos The Helios User Guide also has some great info for creating and modifying profiles: https://github.com/HeliosVirtualCockpit/Helios/blob/master/Helios/Docs/Helios Release 1.4 Users Guide.pdf

I spent some time working on this myself this evening. Eventually I was able to destroy 9x T-80Us solo. I found two techniques that worked: Low hover from behind cover. Pop-up, engage, and as soon as your missile hits dive back down and shift to a new location. Do not stay unmasked and engage another target, no matter how juicy it looks. Do not pop right back up in the same location. Move around down low, make them loose track of you, then pop back up from a different spot and hit another one. Stay low and fast, moving perpendicular to them or circling them. Pop up to a few hundred feet, turn into them, lase and engage while flying right at them, staying fairly fast. Once your missile hits, break hard left or right and dive back into cover. Get into position to make another attack, and repeat. This tends to be better at shorter ranges, you don't want to get into MG range, but the shorter your missile time of flight the less time you need to be up and lasing before breaking back for the deck.

It's probably not a gun round, the T-90 (and most other modern Russian tanks) can fire ATGMs from its main cannon. Hovering, especially high, is a bad idea in combat. If you're going to fight from a hover, stay low, mask behind cover, and don't be exposed for any longer than absolutely necessary. LOAL can be useful here, lob a missile up from behind cover, then pop-up to lase for the last few seconds of flight. You can also fight more like a fighter jet, make a run-in at your target, fire and lase to hit, then break off, circle around, and come back for another run. A moving target is much more difficult to hit with an ATGM or guns, and gives you a bit more defense against MANPADS too.

Update to my profile: Added Armament Panel for the Pilot and Master Caution and Warning panel for the CPG, added new illuminated buttons for the Armament and Caution and Warning panels, made the page select buttons on the MFDs bigger, added screws to the various panels I grabbed from DCS textures and were missing them, and I fixed a issue with the CPG EUFD rockers. Bunnys AH-64 Profile.zip

This is the monitor config I am using right now - it's a temporary one which breaks a bunch of other things to get the currently malfunctioning Apache monitors to work. I set it all up manually rather than using Helios to manage the monitors, again because this is temporary and I'm hoping I can build something that is more functional and doesn't break other modules after ED releases a fix. My setup is a 1440x2560 main game monitor with a 1080x1920 touchscreen below. If yours is different you'll need to adjust viewport placement. Something in your Profile is looking for a "DCS NAH-64D" Interface. I don't know what that is, but it's not mine. Helios Touch.lua

Double assigning buttons is pretty simple. If you start from my profile, open up an MFD and just add the button commands for both seats. Each button should look like this when you're done: Each button has the press and release command for both the Pilot and CPG button. I've chosen not to do it this way because I knew I wanted a separate layout for the front and back seat, hiding the TEDAC when in the pilot seat in favor of a larger EUFD. Since I was already hiding and swapping panels, adding separate MFDs for the pilot and gunner was simple. I also have some concerns about what sending button presses to both seats at the same time may do, especially in multiplayer.

Capt Zeen has great tutorials for Helios. There's some stuff in this video that's not applicable to my simpler profile, but the basics are all the same: This thread is all about Helios, which is Windows software primarily designed for integrating PC touchscreen monitors. It has other uses, but none of them cross outside the Windows ecosystem as far as I'm aware. For phone and tablet devices there are some very good options, I've used DCS UFC for Android and found it to be very good. For iOS, I have heard great things about iUFC Export but have no personal experience with it as I do not own any iOS devices. Neither of these options are user configurable though, so you'll need to wait until the developers add support for the Apache. Weird. That uses all stock Helios functions, so I'm not sure what may be going wrong.

Just about anything can do weird things, it's a matter of how likely a specific weapon is to do something dangerous when dropped from a specific location on the aircraft within certain parameters. The video I posted has several examples of CBU mishaps. Maybe, maybe not. Bombs don't release from the exact same point relative to the aircraft when mounted directly to the pylon rather than mounted to a rack. The rack itself causes aerodynamic perturbations of the airflow and may have something to do with it. Or, again, it may be totally fine and the USAF just never bothered testing it because they didn't think it was worth the expense. We don't know. These things aren't generally classified, exactly, but frequently are restricted for public distribution or restricted from overseas distribution - and in the modern day of the internet any document that is shared on-line is essentially shared overseas and immediately becomes a violation of international arms treaties. That's why the forums rules here are so strict about posting documents - there are unclassified publicly available PDFs of the F-16C tactical operation manual available on the internet, for example, but these manuals are still subject to the International Traffic in Arms Regulations (ITAR) which makes "exporting" them illegal. Yup. Just realize that it is a "DCSism" - an artificial perception created by the way computer gamers play the sim that doesn't reflect operational considerations in the real world. In real life no single aircraft would be expected to hit more than 4 targets with LGBs in a single flight. If there were more targets that needed hitting, the USAF would just add more aircraft. It is always safer to have 4 aircraft make 1 pass at a target area than have 1 aircraft make 4 passes over a target area. What you need is a wingman, not more bombs.

That should be a fairly easy change to my profile. I built everything in panels, so you can grab entire MFDs, the KU, EUFD, and so forth and drag them around and resize them however you like. You'll just need to tweak display exports to match.

Paveway II is a pretty dumb system, as far as I know it does not actively steer itself away from the aircraft or participate at all in safe clearance. The bomb will fall ballistically until it picks up a laser spot to track. Fins help with stability in smooth airflow, but in disturbed flows they can do weird things. If a GBU-12 gets caught in a slipstream along the edge of the fuselage / engine nacelle I can easily imagine it yawing severely or being pulled into the side of the aircraft. But ultimately my point is we can't just look at the geometry of these things and say that because it looks like it should work it probably will work. If that were the case there would be no intensive weapons separation testing program. If that were the case the incidents in the video I linked to would not have happened - I'm sure no engineer looked at the stores on those aircraft and thought they were probably going to impact the aircraft but decided to fly them anyway. Even with advanced computer 3D modeling and CFD, the F-35 is still going through hundreds of flying hours of weapons separation testing for every desired configuration. Unless someone knows if the USAF did any TER separation tests with GBU-12 on 4 & 6 and is willing to share, we'll only ever be able to speculate.

Because the GBU-12 has much larger aerodynamic surfaces than a CBU or slick bomb. With the nose mounted steering fins and pop-out rear stabilizer fins, I can easily imagine a GBU-12 getting thrown around a lot more by aerodynamic forces when released. The large CBUs also weigh twice as much, which would help stabilize them. It's entirely possible that testing was carried out, a problem was identified, and it was determined that modifications to the bomb, racks, or aircraft were not worth the cost. Or maybe it was determined that testing such configurations wasn't even worth doing. Think a bit about how tactical jets and weapons are used in the real world. CBUs and slick bombs tend to be released in large numbers all at once. Make a single pass, drop 12x Mk.82s or a bunch of CBUs, then get out. For those weapons carrying large numbers of bombs is useful. But GBUs aren't used that way. They are dropped individually and guided all the way down. In a high-threat environment the aircraft is vulnerable for the entire bomb time of flight, they're not going to make 8 or 10 passes at the target area to drop that many bombs, that'd be ridiculous. In the low-threat environments of Iraq and Afghanistan in the last 20 years that number of weapons was simply not needed, and the inner pylons were always needed for gas to loiter on station. Many XCAS aircraft went on missions with only 2 bombs, clearly that was enough, why would they bother trying to carry 8?. It's entirely possible, likely even, that the USAF considered carrying more than 4x GBU-12s unnecessary for any conceivable mission and not worth the cost of even testing.

That's a cool way to get around the problem. Right now I'm just breaking the CPG screens in the hopes that ED fixes display exports soon and I can build my monitor config the way I would like to.

Sure, it's kinda a mess right now to get the Apache working. It'll make the Pilot screens work, disable the CPG screens, and break any other modules using the LEFT and RIGHT MFCD viewports. Helios Touch.lua

I honestly don't know. I can't claim to have any expert knowledge on weapons separation, nor hard data on USAF certified loadouts circa the mid-2000s. I assume ED has better information than I. I disagree, and that was the point of the video I posted. Aerodynamic effects on weapons separation can be difficult to predict and behave in unexpected ways. I'm fairly confident that the reason we can't load GBU-12s on the inner station of a TER on 3 & 7 is aerodynamic effects from inboard stores, especially drop tanks. The inboard stations are closer to the fuselage and forward of the horizontal stabs, it wouldn't surprise me at all if there were aerodynamic concerns caused by a slipstream, or issues with weapon impact on the stabs. The other side of the issue is that the extensive testing required to certify weapon carriage on a station means that's it's a fairly expensive process. It wouldn't surprise me if 3x GBU-12 could be carried and released safely from 4 & 6 and it was just never certified by the USAF because the low probability of its use didn't justify the cost. Unfortunately, without specific knowledge about why the USAF does not use such loads, we can only speculate. Maybe it's safe, maybe it's not, unless someone has more knowledge all we can say is that the USAF does not fly with those loadouts. That may be doctrinal, it may be safety, we don't know. But pure speculation that it may be safe and practical isn't sufficient cause to add it to DCS in my opinion.

Another update to the Interface, and I'm happy enough with my Profile now to share it as well. Added to the Interface: Pilot and CPG Master Warning/Caution panel, Pilot and CPG Arm/Safe panel, IHADSS Video panel. I also solved the issue with DCS communicating with Helios, so it'll sync switch and axis positions now. My Profile files, extract to Documents\Helios\ DCS.AH-64D.hif.json Bunnys AH-64 Helios Profile.zip

I started a while ago with fixing up some problems I've been having with the Hornet and Viper Interface, during which I learned the format of the file and where to find the needed data in the DCS files. I mostly relied on Zeen's tutorials and just trial and error. Using that experience, I just started writing a new file from scratch for the Apache. I'm not a programmer, I'm just good and poking things and figuring out how they work.