Harker

Hi, this is related to another bug (reported just below this one). The issue here is that you *can* designate the trackfiles, but they don't show up on TWS as soon as they're ready, but with a delay.

2.7.16.27869 Open Beta Currently, trackfiles are not available to be designated as soon as they are ready. This is wrong based on available documentation. I'm going to repeat myself from another thread: A trackfile is something the Mission Computer (MC) of the Hornet generates. It may or may not correspond to a real aircraft out there, it only exists in the software. Note that I'm talking about radar hits (bricks), that correspond to raw returns. Trackfiles are created, from 2 or more raw hits, only when there is enough info to create them. For all intents and purposes, a trackfile should always be able to be designated, as soon as it is created, or have an STT lock attempted on it (which may fail), because it is a digital object that the aircraft itself created. It is made with the express purpose of being interacted with. The mere fact that a trackfile was created in the first place, means that the MC has enough info to build it and allow the pilot to interact with it. A trackfile might have trouble being created, due to various reasons, but if it is created, then it should immediately be able to be designated and have STT attempted on it. If confirmation is needed, the 742-100 manual describes the process of trackfile creation and their display via the MC. This is in continuation of another similar thread that spoke about MSi trackfiles in general and was moved to the Wishlist: /topic/305237-designating-based-on-datalink/#comment-5012313. However, I am only talking about trackfiles, as they exist in DCS right now (radar trackfiles only). I am not talking about trackfiles from other MSI sources. FA-18C_cannot designate valid trackfile until shorter range.trk

2.7.16.27869 Open Beta TWS should display HAFUs (for the highest 8 ranked trackfiles) as soon as they're ready. Currently, the trackfile is ready (you can hover with the TDC and see valid Mach and Altitude values and you can designate it), but is not displayed in TWS as soon as it's ready. Instead more hits / time is required until it is displayed. The current behavior is not described anywhere in available documentation (mainly the 742-100). Thus, TWS should display trackfiles for valid targets, as soon as they are available. Note that the current implementation of 2+ bricks required to create a trackfile is not wrong (good addition!), but once the trackfile is created, it should be immediately displayed in TWS. Edit: you can also observe the trackfiles show up on the AZ/EL and SA as soon as they're created, but not on the RDR ATTK page with TWS. FA-18C_TWS does not display HAFU as soon as trackfile is ready.trk

2.7.16.27869 Open Beta When in NAV master mode, if A/A mode has not been yet entered, designating (not STT) a trakcfile as L&S will show the GO STT message. GO STT should appear only when in A/A with the AIM-7 selected, and when the L&S is not tracked in STT. If you enter A/A and select AIM-120 or AIM-9, which do not feature the GO STT message, then NAV will work correctly. (should also be GO STT and not GOSTT, that's a quick fix). FA-18C_GO STT appears in NAV master mode.trk

Good write-up. For the current DCS implementation, which only allows for the designation of radar-generated trackfiles, this stands out: A trackfile is something the Mission Computer of the Hornet generates. It may or may not correspond to a real aircraft out there, it only exists in the software. For all intents and purposes, a trackfile should always be able to be designated, as soon as it is created, or have an STT lock attempted on it (which may fail), because it is a digital object that the aircraft itself created. It is made with the express purpose of being interacted with. Also, as the OP said, it takes 2 correlated radar hits to generate a trackfile, since they obtain enough information on the range, altitude and velocity of the target.

You don't have to toggle WPs back and forth. When you press WPDSG, the WYPT label (right top on the HSI) changes to a boxed TGT label. You can clear the existing designation and get WPDSG back by pressing the button next to TGT. The designation will be cleared and you'll get WYPT and WPDSG back. Or you can use the NWS/Undesignate button on the stick to clear any existing A/G designation, instead of doing it via the HSI.

These rings are just there to indicate the estimated range of the SAM. They're just static "drawings" nothing more. They turn red to notify you that you're flying inside a SAM's WEZ, but that's it.

In the IRL Link 16 stuff I mentioned? I have no docs I can share, this is me merely passing on info I've read or heard (from people working IRL in the field), so take it with a grain of salt. The same topic has been brought up and discussed in the Hornet forums, where the same issue is encountered with the HMD MIDS symbols.

Hi, sorry for the late reply. We don't have any custom scripts running on the server, the only script is the Tacview export. Also, the server is fine, it doesn't crash. Only specific clients do (not always the same people and not all clients in the session), but the odd thing is that they crash simultaneously (e.g. the flight lead and all wingmen crash within a few seconds of each other) and it usually happens when they're returning to the carrier. I'll still show your comment to the guy running our server though, thanks for the reply.

The issue is that, in DCS, the update rate of all Link 16 functions is fixed at 1 update per 12 seconds. IRL, different elements update at different frequencies, with PPLI updating very frequently for example (~1-3 seconds IIRC, perhaps faster) and other things, such as AWACS contribution to non-PPLI aircraft, updating at a slower rate. So, if you had the PDLT set on your wingman, it should update constantly and thus stay on top of the aircraft. If you have it on a bogey, it will likely update more slowly, like in DCS. So the problem is not with PDLT, but with the L16 update rate in DCS. The vertical thing is something else, because it seems like extrapolation is implemented in XY, but not in Z. No idea how the real thing works there.

+1. We can't use ACLS at all in MP with my squadron, because the SC ATC just can't handle multiple aircraft at the same time correctly and we also prefer not using it anyway. An automated switch based on distance or initiating with a single F menu interaction would go a long way.

Everything that's not in vanilla. Remove all unofficial mods from both the install directory and Saved Games, do a slow repair and try again. If it's fixed, you can try adding your mods back one by one (install, test, install, test etc). As for your RAM usage maxing at 27 GB, Windows will always try to leave a little bit of RAM unused.

For about a month now, maybe a little more, myself and others have been experiencing very frequent freezes in MP. Specifically, DCS will freeze for all clients in a flight, most often when we're returning to the carrier. Because DCS freezes, no useful logs or crash reports are generated and the game needs to be terminated via the Task Manager. This post is meant to draw attention to the fact that the freezes occur simultaneously for all clients in a flight. As of now, I'm unsure if it's related to the fact that we're in a flight or to the fact that we're at the same location or same distance from something, when the freeze occurs. Sometimes it'll occur when we're in the stack, just orbiting, but most often it'll occur when we're still a little further out and approaching. I'm aware of the crash related to the Tomcat, but in my case, and the cases of the rest of my flight, we're flying the Hornet. It could be that the crash occurs when we're approaching Tomcats though, as our group flies both. For what it's worth, our Tomcat players also experienced freezes like that (all clients in the flight), but I can only speak for the Hornet, as that's what I fly.

You can place down an A/G designation with selected JDAMs just fine. What's the issue? If you want to do it via the HMD/HUD, you need to be in A/G mode. The current JDAM target will still be displayed separately as a diamond, if it's different than your current A/G designation. You can also select other A/G weapons, while leaving the JDAMs boxed. They only lose power if you explicitly de-select them, but you can select another weapon and de-select it to return to the JDAMs.

Used it. For our Hornet, it should do what it does in DCS. Blank the HMD when the TDC is not on the SA page and command EXP when it is.

Yes, the radar presents a range-azimuth scope, while the elevation is determined via AG ranging. Thus, upon TDC Depress, designation will be created on top of the desired point, with correct elevation. All other sensors, including the TPOD, will be slaved to that point now and the TPOD will be looking at the correct elevation. Although the ground radar is not particularly useful for precision targeting, it can come useful if you're looking for large structures, large aircraft, ships or even stuff out in the open (after a lot of gain and contrast adjustment, you might spot small blips), if you cannot use the TPOD and your eyes to spot the target. It's not easy to use, but it does comes useful in certain scenarios, I've found.

If you can't find the target with the TPOD so you can get elevation, you can always create a designation via the A/G radar, which will be at ground elevation. Then, the TPOD will be automatically slaved there and display the correct elevation.

It's not related to the pods, any ground designation, done in any way, will move the currently selected WP. It's a reported bug in the Hornet section.

With so many operators, do you realize how many liveries we'd need for 3-4 per country? As BN says, it's very easy to get bloated installs and some other modules are guilty of doing that. People can install whatever livery they want, very easily, there's no need to bloat the vanilla install more. I f someone cares about using or seeing a particular livery, they can install it.

Thank you for running by the team. I don't have any documentation specifically stating that "the designation continues to be updated by the designating sensor, even after the TDC is taken away from the page". Manuals logically imply that the designation is driven by whatever created it, regardless of TDC priority. The TDC comes into play if you depress it, while on another sensor page, in which case, that sensor becomes the designating one. The current logic in DCS is also not described or implied anywhere and furthermore makes no sense, at least based on anything I've read. Anyway, I'll see if I can find a document that clearly describes the process, however I don't think that TDC priority will be covered in it, because it's never stated that it affects anything in the first place, at least according to what I've been able to find.

That's not the issue, the real issue is that the designation diamond stops being updated as soon as TDC priority is moved away from the FLIR page. That's wrong, since the FLIR is still the designating sensor, as indicated on the HUD (it says FLIR) and thus it should continue updating the designation no matter where TDC priority is. As for the Maverick, it should slave to the designation, that part is not wrong. The problem arises from the fact that people move TDC priority to the IMAV page, in order to uncage it and then the designation stops being updated from the FLIR.

not related to pods only, every way of designating will cause the bug

Observed the same, but with any sort of designation. OP, maybe you can change the title to reflect this. What happens is that merely depressing the TDC to create a designation, will permanently move the current waypoint to that location. Selecting WPDSG or having a WP boxed before or not makes no difference, it always happens. It occurs with the ATFLIR, but also with other modes of creating a ground designation, such as via the HUD while in A/G mode. EDIT: added track I really hope we see a hotfix ASAP for this, this makes navigation and A/G impossible. FA-18C_AG designation moves waypoint.trk

The actual issue is that the ATFLIR, while in AUTO track, will not continue updating the designation if the TDC priority is moved to another display. Normally, it should continue to do so, until another sensor is commanded to designate, regardless of where TDC priority is.

The CIT should receive replies (and even create CIT-only teackfiles, but let's not get into that) even without a radar contact. IF a radar trackfile exists, CIT data can be combined with it, via the MSI system and the ROE matrix, for HAFU classification. But a radar trackfile is not a prerequisite. Look at how the F-16 and JF-17 do it in DCS, it's modeled there. They can interrogate the airspace in front of them and receive replies, even if they don't have a radar contact (the F-16 lacks the ability to combine a reply with a radar trackfile, but it can still receive it). So, in the Hornet, if you run an interrogation and there is a friendly aircraft inside that space (with an enabled and correctly set up transponder), then you should receive a reply from it, even if you don't see it on radar or datalink.