FalcoGer

Had it happen again. This time I was in the front seat and got engine autopage because "rotor rpm low". back seat did not get rotor rpm warning. Then I got FMC Disengaged in the front, presumably because the CPG client thought the back seat was on the engine page while the back seat was not and their client just send button presses instead of aircraft states.

When pressing CAQ the TSD freeze option is automatically selected. This is normal. When CAQ is done, the TSD unfreezes. However before the last few updates, when using PAN, which also freezes the TSD and then using CAQ, the display would stay at the panned to position. Now the display FRZ is disabled when CAQ is done. To reproduce On TSD press PAN PAN TSD to a cursor selectable item (for example a TG point) Press CAQ Use the cursor to select a point Expected result: When FRZ is active before CAQ is selected (for example by using PAN or FRZ), then finishing CAQ will not reset the FRZ option. Actual result: FRZ is always reset when finishing CAQ. I'm not sure of that is correct, but I find it annoying and it was different before, so maybe it got broken? When I use this feature, I typically zoom in on the TSD on a cluster of units and then use CAQ to engage each one in turn. Having to PAN over to that area again and again makes this process much more time consuming, even when using the LAST PAN option. Of note: When using "Point" or "Route/DIR" to select a point on the TSD with the cursor, the display does not get unfrozen. CAQ_unfreezes.trk

Made a thing to help putting stuff that is ordinarily in the DTC into the aircraft automatically. You can save and load JSON files, too. It did do points before, but now it also does some AH64 specific things. The stuff it does includes: XPNDR settings Comm preset data (C/S, Unit Name, Primary Selection, Frequencies for all radios) Preset Net members Modem settings (Protocol, retries count, can't do auto reply because it's a toggle in cockpit) Tuned presets ASE Chaff program & Autopage setting Weapon settings (MSL Channels, gun burst count, rocket quantity) Laser codes

I use the warthog hotas, too. I don't need a modifier at all. I have a modifier on EAC, but that's to switch to pilot controls. Everything you need when not flying can be done without a modifier. On the stick: FCR mode: Trim Hat FCR zoom: DMS WAS/Target store: TMS (store is down) Slave: Masermode swich Laser 2nd detent: paddle LMC: CMS depress TADS FOV: CMS Cued search: Pickle Trigger: Trigger zoom: pinkie On the throttle: Sight select: coolie hat FCR Single/continuous: air brake aft/fwd Sight TV/FLIR: boat switch fwd/aft IAT: China hat fwd/aft LST: A/P mode select (using _OFF bindings for LST off) TDC slew: microstick Cursor enter: microstick depress NVS select: pinkie switch polarity switch: pinkie button

I see. Yes, it seems the MGRS coordinates are off by around 220m. It seems there is a bug with converting coordinates from L/L to MGRS in the AH64. The correct coordinates for N 42° 10.7600' E 042° 29.7200' are 38T KM 9315 7272 (38T KM 93146 72725) With L/L decimal minutes and 2 digit precision there should be a maximum of ~16m difference, and MGRS with 4 digits groups is 10m accurate. There shouldn't be a discrepancy of ~200m. And if it were INU drift, both numbers should be off, not just MGRS. And again 200m is way too much for a modern laser ring gyro system and military 1m accurate GPS updates.

@NeedzWD40 Just checked. 38 T KM 93141 72729 = N 42° 10.7623' E 042° 29.7161', using a non DCS system. The coordinates are correct and not "off". Powered by the coordinatesharp library, using the ellipsoid earth model for added precision.

the top left corner of the map displays your mouse coordinates. the coordinates of the selected element pop up in the bottom left corner. If you're talking about the MGRS being only groups of 4 digits, that is normal. The AH64 uses 10m accurate grid coordinates, not 1m accurate coordinates like displayed on the map. you can just truncate the last digit off each of the group of 5 to get the 4 digit number used in the AH64. There could also be some drift in the INU. But the easting is perfectly correct, the northing 49336 on the map is off by 200m from what the aircraft displays (4913[0]). My bet is that the mouse position is not exact. Use the window in the bottom left of the map screen to get accurate coordinates for selected objects on the F10 map.

When in a multiplayer scenario, and you request control as CPG, and you find yourself in a situation where the pilot can't accept or deny, the blue box with the text that you have requested controls does not go away. For example the aircraft gets destroyed. To make it go away, you have to request controls in the new aircraft and then the pilot has to accept or deny it. To reproduce PLT and CP/G join aircraft (set to Pilot responsible or Always ask) CP/G requests controls PLT does not accept or deny Die (Apply mountain or ocean to face at high speeds for example) PLT uses Briefing screen (LAlt + B), and select Fly to get a new aircraft CP/G will still have the "Requesting controls" message forever until he requests controls again and is denied or permitted by the pilot.

In the mission editor there is an option to determine who can take control of the aircraft at which time. The options are: Pilot responsible, which is the default, where the pilot can take control without asking, but the CPG needs to ask and the pilot has to click the accept button CPG responsible, which is the reverse Equally responsible, where neither can just take control without the pop up box Always ask, where the pop up box always appears for both This option is a user preference and has nothing to do with the mission or the aircraft itself, and thus should not be in the mission editor. I find it frustrating that whenever the CPG needs to take controls (for example in a training scenario, or when the pilot is not good enough to salvage a situation like a missing tail boom or broken tail rotor), the pilot, currently using his hands in a difficult situation has to grab his mouse and click the accept button. Mission makers have enough to do already, and I have not yet seen a mission where they have set anything but the (IMO poor) default. This pop up box is especially annoying in VR, because it might not even be on screen. Because this is a user preference, and not an aircraft specific thing, I wish for it to be moved to the special options, and removed from the ME. In a multicrew scenario, whoever has the pilot slot, that person's option then should apply. For example the pilot has selected Pilot responsibility, and CPG has selected Always Ask. Then the Pilot responsibility option would be used. Alternatively each crewmember can have their own option that apply only to them, while the other crewmember has their own option as well, or two options: Require confirmation before other crewmember takes controls? No (default), Yes Or As PLT, require confirmation before CPG takes controls? No (default), Yes As CP/G, require confirmation before PLT takes controls? No (default), Yes For example the pilot has set it to ask, and CPG has set it to don't ask. Then when the CPG wants to take control from the pilot, the pop up pops up. When the pilot takes controls back, the pop up does not show up. You should have verbal communication anyhow, through DCS's new VoiP system, through SRS, or through any other voice communication software, or even just shouting across the room. Because of the fact that you are most likely communicating anyway, the default should be set to "equally responsible". Whatever options you want to put, just make it a per user setting, not a mission editor thing.

As for WP saving/loading, you might be interested in the tool I have made until ED creates their DTC implementation.

Missile types are restricted by your selected sight. TADS: Both are allowed HMD: Only SAL FCR: Only RF

@NightstalkerNOR I created a tool to help with configuring stuff like that.

The tree survived.

It might get truncated to 3 characters, which may or may not be correct. I got one though. When sending a FARM with 8 SAL + 38 rockets (2 pods) on, the receiving aircraft gets 16 SAL + 38 RKT displayed in their FARM page.

When creating your own target points, since the latest update (or maybe the one before it), they don't have threat rings anymore. The target points generating when spawning the aircraft are not affected, only those that are placed down after the fact, including those transmitted over datalink. To reproduce Create mission with hot start apache (for convenience) Place down SAM that will generate a threat/target, such as an SA-15 Start the mission in that helicopter Switch to ATK phase on TSD Goto TSD -> SHOW -> Enable Threat See the threat rings for the existing SA-15 Go to TSD -> Point -> Add Add a new TG with IDENT 15 No rings noThreatRings.trk

The roll limit and rate limit restrictions for the hellfire launch only works for a roll to the right. for a left roll, no inhibit is displayed or enforced. To reproduce: Load laser hellfires (more convenient to launch, since you can LOAL) Take off Select missiles and master arm on Roll right slowly Get ROLL LIMIT at around 10° Pull trigger (1st detent), no missile is fired Roll right fast Get RATE LIMIT Roll left slowly by up to 90° Get no safety inhibit until you get ACCEL LIMIT due to being in negative G land Pull trigger, missile will fire Roll left fast Get no safety inhibit safetyInhibitOnlyForRightRoll.trk

The "Get new plane - respawn" doesn't work. Whether the aircraft is fine, damaged or whether the CPG or PLT ejected. Selecting the same slot from "select role" also does not work to respawn. Get new plane should get a new plane, even if the current one is just fine. no_respawn.trk

Didn't do much testing, but when I ejected as CPG, I was able to use the "Get new airplane" keybind (default is RShift + RCtrl + Tab) and it respawned me in a singleplayer mission. Didn't test without ejecting or with PLT ejecting instead. Edit: Tried again. No respawn in any case. I think it might have been due to the helicopter actually being destroyed by landing in the trees that the keybind works.

What I find most frustrating is that When there is a column or group of vehicles, it is impossible to distinguish anything. it's just a yellow blob. When there is a yellow blob, I can't tell what NTS and ANTS is. When there is a yellob blow, I can't tell which unit I have already shot at. when re-scanning effective engagement is impossible because I can't distinguish which of the shot-at markers correspond to which radar return, and even if I could, the NTS button or manual selection of targets doesn't work in continuous mode. It's impossible to know which units have been hit or not. Really what needs to happen is, in order of priority Multicrew FCR sync LINK TADS to FCR NTS ZOOM RMAP might help a tiny bit, especially for closer targets and should be relatively straight forward to implement. it's literally the same as GTM, just the radar returns need to be drawn in different spots. A workaround is to use the TSD in PAN mode and zoom way in. But that's tedious and reduces SA by a great deal, especially with threat rings already marked out or when using the digital map for terrain avoidance. C-Scope would be neat, but not crucial.

I called him and told him to "Engage ground targets" and he said "Unable". I called him and told him to RTB, he said "Copy", and proceeded to continue to follow me. I said nothing and he flew straight into a tree and said "I'm hit". AI wingman are useless.

New update: AH64 DTC Feature

On the COM/Preset/Modem page the Protocol currently called "Datalink" should display "LONGBOW" instead. The "AUTO ACK" button, "RETRIES" button and "BAUD RATE" button should only be visible when PROTOCOL has "LONGBOW" selected. In particular, when None is selected, they should not be displayed. When the other protocols are selected, other options should be displayed. Since those will never be implemented anyway, the easiest option is probably just to bar them out.

I checked again. The documentation provided by ED is wrong. The VHF radio can be tuned 108.000 through 155.995, the VHF radio accepts the correct frequencies. The documentation about the step size is wrong. The UHF radio can be tuned 225.000 through 399.985 MHz in increments of 5 KHz. The DCS apache can only go up to 399.980. Again, documentation about step size is wrong. FM1/2 range is 30.000 through 87.995, in increments of 5 KHz. The DCS apache can only go up to 87.990. Documentation wrong about step size.

According to the DCS Documentation: Max freq for UHF radio in preset is 399.975 MHz, but AH64 allows entry up to 399.980 MHz Min step size for UHF radio preset is 0.025 MHz, but AH64 allows entries to a resolution of 0.005 MHz (for example 380.995, whereas it should be 381.0 or 380.975) FM radio max frequency is 87.975, but AH64 allows entries up to 87.990 FM radio frequency step size is 0.025, but it is actually 0.005, allowing entries like 77.995. Also the default preset that is tuned from mission start for an AH64 for FM1 is 30.015 (Preset 3) and for FM2 it is 30.020 (Preset 4), both of which are invalid, or the documentation is wrong. VHF min frequency is 116, but AH64 allows entries down to 108 VHF max frequency is 151.975, but AH64 allows entries up to 155.995 VHF frequency step size is 0.025, but AH64 allows resolution of 0.005, allows invalid values such as 116.995 Other things that are wrong but not in the DCS documentation: CNV for HF radio starts at 0, but valid options are only 1 through 6, when tuning an HF radio with crypto enabled and C0, this is not displayed. Only C1-C6 are displayed when a valid value is entered for CNV. Preset channel for HF starts at 0, but AH64 rejects anything that isn't 1 through 20. 0 can not be set once it has been set to something that is not 0. ALE Net starts at 0, but 0 can not be re-entered once it has been set to something other than 0. ECCM net starts at 0, but 0 can not be re-entered once it has been set to something other than 0 Tuning an HF preset any frequency results in a wrong frequency being tuned on the EUFD (5.0500A) Tuning that same preset again will push the correct frequency into the standby frequency, but SWAP doesn't do anything. It might just be a display error Some Presets start with HF being 0.0000 for XMIT and RECV. Tuning them results in 15.0000A being displayed in the EUFD.

Mode 1 is 5 bit, it should be 0 to 31, or 0 to 37 in octal, but accepts values up to 99 Mode 2 is 4 digit octal, so it should be 0000 to 7777 in octal, but actually accepts all decimal digits Mode 3A is also 4 digit octal, also 0000 to 7777, but accepts all decimal digits Mode S Address is 24 bit octal, curiously this one works correctly (0000 0000 to 7777 7777). Mode S Flight ID seems to accept any alphanumerical string, but it must be 8 digits long. no idea if that is correct. Mode 4 accepts A and B, which is correct. REPLY is mislabeled REPLAY (But correctly labeled in the submenu when clicking the OSB) Reply options should be "UFD" (Up Front Display), not UDP. While at it, pressing the ident hard switch on the radio panel doesn't invert the ident option on the comm->xpndr page. not sure if that is correct.