unable to reproduce Datalink error after update 19-12-2023

[GCRev]

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.

[AndreNL]

@ GCRev,

 We have discovered for ourselves that the NAK problem is not consistent. We start on the server by setting up our helicopters. With of course the NAK message. But, if we choose 2 other ah64 to fly with on the same server because they are stationed closer to the AO, then we have no NAK messages......

So our first flight / mission there we have the NAK message, Our 2nd flight / mission from another airport but on the same server we have no NAK messages at all anymore... That's something we don't understand. What I find annoying is that we made a side-by-side video for the dev team and that we received no comments on it. 

So my buddy and I just assume that we're not doing anything wrong, but if there's something I can't stand, it's assumptions. I would like to see confirmation.

[UncleStains]

I have found all kinds of DL weirdness except when using the VHF radio for DL.

[BIGNEWY]

if you are seeing issues please attach a track replay example

thanks

[Floyd1212]

It would be nice if ED would get 4 employees in 2 helos on the same server at the same time to test this.

I can understand needing a track from a player for capturing some obscure bug that is difficult to reproduce, but how are you going to replay 4 track files from 4 players at the same time to see how they all interact with each other?

[Raptor9]

55 minutes ago, Floyd1212 said:

I can understand needing a track from a player for capturing some obscure bug that is difficult to reproduce, but how are you going to replay 4 track files from 4 players at the same time to see how they all interact with each other?

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.

55 minutes ago, Floyd1212 said:

It would be nice if ED would get 4 employees in 2 helos on the same server at the same time to test this.

@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.

[Floyd1212]

13 minutes ago, Raptor9 said:

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.

Fair enough.  I will admit my comments were made out of my own frustrations.  I'm sure there are many hard-working people behind the scenes trying to squash these bugs, as well as bring us new features.  For that, we are grateful, even if we occasionally have some sharp criticism to go with our gratitude.

But...

If you look at it from our perspective, we have a group of 8-10 guys that fly the Apache multi-crew, on both public and private servers, for many hours per week, and we constantly run into the same bugs.  Not just one of us, but all of us.  And not just on specific servers, but on many different servers.  From our perspective, it is hard to believe that if ED employees were to do the same -- that is, fly the same servers the same way we do -- that they wouldn't experience these issues for themselves.

I will gather some of my guys and record some tracks on a short mission to try and capture these issues early in the flight, and hopefully provide something useful for debugging.  I will also extend an invitation to you, or any ED tester, that would like to fly with us one night, and see if you can experience any of these issues first-hand, out "in the wild", as we do.

[Raptor9]

1 hour ago, Floyd1212 said:

If you look at it from our perspective,

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.

Edited February 26 by Raptor9

[GCRev]

@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.

[GCRev]

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.

[krazyj]

@AndreNL Just saw your msg on my post on the error in the manual. it seems you already got a reply. But its quite normal to get the NAK message and I get it too with other users but they do receive the message I send. 

I can only assume its an intermittent bug

[GCRev]

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.

[AndreNL]

On 2/28/2024 at 2:26 PM, krazyj said:

@AndreNL Just saw your msg on my post on the error in the manual. it seems you already got a reply. But its quite normal to get the NAK message and I get it too with other users but they do receive the message I send. 

I can only assume its an intermittent bug

@krazyj

Thanks for take a look. Me and my buddy just ignore the whole NAK stuff. Datalink works fine, with or whitout that message.

[krazyj]

28 minutes ago, AndreNL said:

@krazyj

Thanks for take a look. Me and my buddy just ignore the whole NAK stuff. Datalink works fine, with or whitout that message.

no wackers mate, yeah its still a WIP but its very cool flying with guys that know how and will use it.

[Floyd1212]

Here are two tracks recorded specifically for this bug report, so they are very short and to the point.  The XMIT NAK bug is reproduced here, in addition to a couple more bugs that are likely related to multi-crew.

In the tracks, you can observe:

• #1 loads into first air-frame alone
  • Orig ID is predefined in the ME as "11"
  • Callsign is predefined in the ME as "1-1"
• #2 loads into second air-frame, and a human CPG joins him
  • Orig ID is predefined in the ME as "12"
  • Callsign is predefined in the ME as "1-2"
• #1 and #2 both switch Battery On and APU On
• #1 adds #2 to DL on Preset 3 FM1 by typing in C/S and ID, and sets TEAM and PRI for 1-2
• #2 adds #1 to DL on Preset 3 FM1 by browsing the MBR DIR and finding 1-1 and adding
  • Notice member 1-1 is added twice to the DL group.  This happens when there is a human CPG in the aircraft.
  • The second instance is deleted from the group, and TEAM and PRI are set for 1-1

At this point, DL is setup correctly for each aircraft.

 

• #1 sends #2 a text message
  • The message is received twice by #2
  • #1 gets a XMIT NAK FM1 message, even though the message is received
• #2 sends #1 a text message
  • The message is received twice by #1
  • #2 gets a XMIT NAK FM1 message, even though the message is received

Hope this helps reproducing some of these issues.

DL Bugs - 1-1 Solo.trk

DL Bugs - 1-2 Multi-Crew.trk

        

[Floyd1212]

@Raptor9 Can you ask the team to take a look again with the new info and tracks above?  Thanks!

[Floyd1212]

@BIGNEWY Can you confirm that someone is looking into this?

[AndreNL]

@Floyd1212

 

I saw your post yesterday, good work!!

The dev team still marked the topic as "probably dl setup error". Well, that's not the question anymore. There is a bug in the system.

I advise you like I and my buddy do, just ignore the whole NAK stuff. The datalink works fine, I does everything that it should be doing. With or whitout the NAK-message.

You and your buddy are already badass  that you use the datalink in the first place. On the servers we fly there are none members that use it.

[Floyd1212]

We definitely ignore the NAK messages, but we still consistently see plenty of other issues.

• Double messages received
• RQST for PP not always working
• some team members receiving data while others do not (and we are all still sitting on the tarmac together)
• data not being sent from the CPG, but the same data works when sent from the PLT

[UncleStains]

Which radio are you using for the DL preset? My squad has had a lot less issues since we switched to only using the VHF radio. 

[Floyd1212]

We typically use FM1.  We will try VHF and see how that goes.

Of course, they should all work the same, right?  With range/reception being the differentiating factor between them?

[UncleStains]

Our experience is random bugs (exactly the ones Floyd1212 describes a few posts up this thread) using FM and HF. Since we switched to VHF, we have had very good results with PP, FARM, BDA, PFZ/NFZ, target points, and mission data. This works well for our group since we rarely use VHF for anything else and can set it and forget it.

Not sure about range as we're generally pretty close, but perfect line of sight appears to be necessary. You can be within a few KM but just behind the crest of a hill and DL won't go through.

I have no idea how realistic any of this is, but now that we know the limitations we can work around them.

 

[NeedzWD40]

4 hours ago, Floyd1212 said:

Of course, they should all work the same, right?  With range/reception being the differentiating factor between them?

HF > VHF > UHF > FM1 > FM2 is generally the order of performance between the radios. The FMs should have virtually no NLOS capability, much shorter range compared to the others. I haven't done any detailed testing in DCS (lack of players in my group with thorough AH-64 experience makes this difficult), but generally I find the VHF performance to be ideal. The HF should give the most range and have an NLOS capability, but I want to say the HF is only good for specific, narrow data types. The FMs on the other hand should have the most data type compatibility. As we're really only concerned with sending data between AH-64s, VHF and UHF should be the go-to, followed by FM if range and LOS requirements are met.

Generally speaking, the FMs should be adequate for most tactical situations involving target data, etc. but I've no idea what usage conditions or expectations are for the datalink.

[Floyd1212]

Still getting double entries in the DL group when adding members from the MBR DIR.

Still receiving double messages when they were only sent once.

Still getting NAK messages despite the messages being received.