GCRev

Yo I also noticed this! Thanks for calling it out. To clarify, the binding updates the visual state of the switch, but it doesn't change the logical state. This is pretty confusing if you see the LMC switch in the "On" position but it's not actually on.

I can confirm this is still an issue on the latest patch. It's easy enough to work-around if you know that it's inverted, but hopefully this gets resolved soon. Seems like it's a just flipped sign in the display logic.

As an additional note, I've noticed that C-SCP on the TADS display is also not appearing when I take the gunner position as a single player (not multicrew). SHOT cues are missing as well. I've seen some of this symbology appear on the IHADDS though. Update: the symbology renders, but it looks like it's centered around an alternative set of coordinates. From any other position this appears to render all cues onto the same point in space very far away.

It's also worth mentioning that you must be stationary on the ground in order to change the APKWS laser code.

Seeing similar in MP. Sometimes it seems to work, sometimes it only works in one direction, sometimes not at all. Hopefully this track file provides ED with some more info!

Boost pump switch toggle also seems to be incorrectly implemented. It's like a press and hold for me, instead of a toggle between two states.

Sorry to be posting about our favorite topic again I've been having some issues with the Datalink recently. I think there could be some display or data logic bugs here. On the Caucasus cold-start mission, VHF PRE1 has an invalid VHF SC frequency of 263.000, which you are allowed to tune to. Tuning PRI seems to tune both PRI and STBY at the same time. Swapping PRI and STBY also has some strange behavior if one of the frequencies is associated with a link. I'm not sure whether this is intended behavior or I need to re-read the manual or re-watch the videos. I also remember a while back there was a WIP item for EUFD updates, so I don't know if this is known already. In this track file I perform the following actions: Select Preset 1 and tune PRI to VHF SC Attempt to change Preset 1 VHF SC frequency to an invalid value (200.000) Successfully change Preset 1 VHF SC frequency to a valid value (145.000) Select Preset 1 with new frequency and tune PRI VHF to the VHF SC preset Use the swap PRI/STBY button on the EUFD to change between values Specify a MAN frequency of 127.500 for VHF Swap PRI/STBY on the EUFD Tune VHF PRI to the VHF SC preset on Preset 1 again ah64_datalink_eufd.trk

I was testing out the new C-SCOPE feature and I may have encountered a bug with the positioning of laser-designated TADS SHOT marks. In a cold-start scenario and after a full four minute ground EGI alignment, there still seems to be an offset. I also tried resetting the INUs in flight, but I didn't see a change in behavior. This behavior occurs regardless of missile type, so I think that it's related to the TADS logic and not the 114Ks or 114Ls. I can't remember whether this is a known issue (a general offsetting problem with the TADS) that is under active investigation, or it's a new issue that popped up with the recent release. Hopefully the attached track + miz files provide a repro. I was able to play back the track file and observed the same outcome. Hot starting doesn't seem to have the same issue - I tested on the "Live Fire" instant action mission on Caucasus and didn't see the same offset. Fortunately, FCR targets and SHOT marks don't have this issue and are spot-on. The following post could be related to this, since it also has to do with a TADS-derived global coordinate. I didn't see a solution yet in the linked post. I think this issue also manifests in this "INU tracking" problem that was identified earlier in the sense that the position fed to the Lima from the designator can be so far from the intended target that the Lima effectively "misses" it. Having the ability to see the shot marker makes it simpler to visualize. I'm optimistic that resolving this will also fix some of the tangential issues. ah64_tads_offset.trk ah64test.miz

Confirmed by ED to still be a WIP here:

server-20240228-214026.trk I think there may be something here. In this test we set up a datalink from scratch again, but on my aircraft I already had a different preset with another helo that was not spawned in. This time the datalink we configured was for FM2, since my other preset was already set up on FM1. We walked through the setup carefully and made sure that we had all the correct information between our aircraft. I am hoping that means we can rule out a datalink set up issue in this case, unless there really was a setup issue. Although, based on the behavior we observed, I still don't quite think that's the case. My friend's aircraft did not have any other datalink presets configured, and they did not see XMIT NAK at any point (according to them). I did not see XMIT NAKs for PP, but I did see XMIT NAK FM2 for FARM and TGT reports. However, when I went in to the first preset (on FM1) and removed the other inactive (not-spawned in) flight member manually, I did not see XMIT NAK FM2 again. It seems like the aircraft is trying to check for ACKs for any aircraft added to any preset. I'm under the assumption that this is not intended behavior since I didn't set my active datalink to transmit on FM1.

I've attached two track files. server-20240226-210417.trk is an ideal control run on a totally fresh Caucasus mission without any triggers or scripting of any kind, with only two helos (hot start) and two players. We mainly did this to practice the procedure of configuring a datalink from scratch. We did not observe any NAK issues here . We tested PP, FARM, and TGT after an FCR scan, all of which worked fine. SYRIA_TPE_v1_RUN1-20240227-211110.trkis from the Rotorheads Syria PvE server (cold start), following an identical datalink setup procedure, only we used a different datalink name (we confirmed that we both had the same Unit ID and call signs for our datalinks). Since our datalink was configured from scratch, we are certain that there were no other helos that it should expect ACKs from. PP did not return an XMIT NAK -- I haven't seen issues with it before -- but FARM gave us both XMIT NAK when sending. We still were both able to receive the FARM reports, though. This track file is large (I'm sorry), but I hope it's still within reasonable (time) length to analyze. Fast forwarding should hopefully get up to the configuration steps. I checked the replay to make sure I observed it there as well. These are from total extremes of mission files in terms of complexity, so I'm going to try to see if I can build up to something that causes this. I suspect it is something in the way the aircraft are configured in the mission itself, or something else present in the mission's environment. In both scenarios my friend's aircraft was stationed close to mine, so I would hope that would rule out LOS issues. I think that, based on the fact that we set up the datalinks in both runs using the same steps, that we should not expect to see transmission issues between aircraft in the latter case. I hope this begins to help. Hopefully more testing to come shortly.

@Raptor9 Thank you for being responsive on this thread. As a software dev I have a lot of empathy for support since I frequently see issues that don't reproduce internally. I'm hoping to get a track file soon to feed through. Hopefully we can figure something out -- whether we discover an edge case or we identify a gap in the available documentation or setup instructions. This may be too much to ask, since you may have policies against distributing certain information or resources, but if you happen to have a track file from one of those in-house tests between employees, I'd be interested to try to replay it on my machine to see if I observe the same results.

I've also observed this. A friend and I set up a totally unique datalink from scratch (new frequency, manually configuring the datalink to share the same information, and verifying that we had unique originator IDs), specifically to avoid the possibility that there could be any other helos with us that might somehow cause an XMIT NAK to occur. The only transmissions that did not produce an XMIT NAK were requests for PP updates. All other exchanges worked but were accompanied by an XMIT NAK, and the helo appeared to be attempting to re-send the same request multiple times as a result. I agree that there's something fishy is going on here. @AndreNL if you have time to test again with your friend then you could attempt to verify that a PP does not cause an XMIT NAK to occur. Getting track files for this is exceptionally difficult since it has to be done on a multiplayer server. I'll try to harass my friend to see if they can put up with a short testing session.

This could be empty advice depending on what kind of gear you fly with, but I used to have a HOTAS setup (Logitech X56) that had a rotary axis dial on the throttle under the thumb (a potentiometer, not an encoder). This was before I had even gotten pedals, and before I did the DCS thing and dropped a pretty penny on VPC gear. I got really used to flying the Apache with no pedals, using the thumb dial to control anti-torque. In a way, it was kinda nice because it didn't auto-center, so I never needed to "trim" it. These days I only fly solo from the gunner seat of the Apache anyway since relying on George for flying and fumbling with the interface is cumbersome IMO, plus it usually eats up a hat switch that I'd rather have bound. I also find the gunner seat more engaging because you can do anything the pilot can do* plus everything the gunner can do.

s_hsd_cursor_jumping.mp4 Here's a video demonstration of it as well. Virpil got back to me and cannot offer support for specific games.