Harker

That behavior was wrong and was fixed in the meantime. There might still be a bug here, according to OP's video, however. The Azimuth selection option should not affect the DBS scans.

It never had it, in DCS. The ability to use the Hand-off to step though and monitor threats is not removed, just the ability to route the PRF audio for the Hand-off threat to the pilot's headset.

Why not both? A chart from the devs would be very welcome, to at least get us started. And people like you will surely fill the community part of the equation. I know I'd be grateful for both, since I don't have the time (and to be honest, the inclination as well) to test often.

Above sea level.

Your cockpit seems set up correctly, but you're outside of the detection range of these air defense units. The ZSU-23-4, for example, will only show up on the RWR when it's tracking you, which it'll only do if you're close enough. I start from cold and dark all the time and I don't have your issue. If you determine that the above is not the solution, post a track of a small mission, so we can see what exactly is happening.

Flex your hands and your toes regularly and remember to take slow breaths. Focus on keeping in formation with the tanker, nothing more.

That sounds reasonable. You need to actively select a weapon for it to be available for firing. So if the HARM isn't boxed, the only mode that should work is SP in Pullback mode, which activates when you're being locked by a surface threat.

I don't have links readily available, but there have been both reports and discussions about it in the Hornet (and I assume the Viper) forum(s). They should be easy enough to find with the help of the Search function. The short explanation is that the HARM should detonate with a proxy fuse, so that shrapnel shreds the radar aperture, which is very sensitive. In DCS, it does use a proxy fuse, but the problem is that radar apertures are not separately coded from the rest of the vehicle, so if the unit is armored, the radar is armored. Coupled with the lack of shrapnel modeling in DCS, this means that the "armored radar" takes no damage at all. As for my first comment, I was just referring to OP's suggestion that Hornet pilots are lazy for not extensively testing against every single unit in DCS, as it if was their actual job. Every good bug report is a kindness to both the developers and the community and should be appreciated, not expected.

I really hope you're being sarcastic here... In any event, this has been brought up, reported and acknowledged multiple times, perhaps not specifically to the Roland, but certainly in general. If the Roland has armor, it'll likely not receive proper damage from the HARM and that's a problem with the damage modeling.

The Viper has more than enough liveries now. If people fly with the default Gamblers livery, it's because they choose to. Anyway, it's more realistic to have multiple jets of a single squadron flying in the same AO, than single jets of every squadron out there.

The POWER button on the THREAT WARNING AUX panel. Left of the CMDS panel, left side.

It absolutely should, all aircraft detected are shared. That's the entire F/F part of the DL. I think you're talking about the TXDSG function, which will show designations and dashed lines to L&S targets.

By what logic is the pod drifting with the motion of the aircraft, with a designation present? If the current behavior was desired, the pilot can simply undesignate. Designations slave sensors to them. Furthermore, the pod cannot be commanded to stop drifting by TDC Depress. If the current behavior was correct, then a TDC Depress would stop the pod and maintain a new designation at its current position.

That's not what the problem is though. The issue is that the trackfile is deleted, which should be the end of it. But if you create a completely new trackfile, on the same target, the system somehow knows that it's the same aircraft. This shouldn't be possible.

Sadly, it doesn't seem to be a bug (as in unintended). It seems like it's like that by design. It seems that there is no separation between trackfiles and units, as far as the engine and the missiles are concerned. There is no real "detection" or "ambiguity", these are merely visual effects presented to the player, but not taken into account for under-the-hood calculations. As an example, take the fact that, while the FCR cannot range jamming targets past a certain distance, the HSD shows their range just fine and very accurately. How can the HSD display info that the radar seemingly cannot provide? It's because the "aircraft" knows the range just fine, but merely hides it from the player. It's the same with the missiles. They should guide towards "a trackfile", not only a trackfile that corresponds to the same unit. Neither the radar or the missile should know any better, but they do.

That's... very unfortunate. That's completely game-y...

The AZ/EL does not show datalink contacts of Link16 contributors. This is a bug, as all 3 MSI displays (RDR ATTK, AZ/EL, SA) should show the same info and trackfiles, on different formats. Track and screenshot attached. FA-18C_AZEL does not show Link16 aircraft.trk

@marzzzI observe the same thing. The IZLAR cue on the HSI does not account for terminal parameters right now. It should change, to show the correct zone to drop the bomb, so that it can achieve its set terminal parameters. If you have multiple bombs selected, with different targets and/or terminal parameters, it should also show a combined zone for all of them, if possible. The IZLAR should take into account the term parameters, alongside the jet's altitude and kinematics. Now, it only takes the jet into account, so it does not change to reflect the terminal parameters. Meaning that if you actually input any, you don't know where you need to drop from. The JF-17 already does this already and it works more or less well, if you're not dropping while heading towards the opposite direction.

Hi, sorry for taking so long to reply. Yes, you normally won't see those HAFUs, at least in DCS. If your mission computer classifies the track as friendly, then the top will be a semi circle, the bottom can be whatever and the entire HAFU will be all green (example, you IFF interrogate an unknown aircraft, your wingman does not - top is semi circle, bottom is square, green HAFU). If the MC classifies it as hostile, the top will be diamond, the bottom whatever, the HAFU will be all red (example, you IFF+NCTR a hostile aircraft, your wingman PLIDs it as friendly on their SA - top is diamond, bottom is semi circle, red HAFU).

What makes sense is for the missile to not guide towards a new trackfile. This is how it works IRL, based on available info. Since that's not how it works in DCS, logic goes out the window. Based on DCS's approach, if the missile is happy going towards a new trackfile, it should be happy to go towards *any* new trackfile, because the radar has no way of telling to which aircraft a trackfile belongs to. If the above occurs, then at least it's a fault with the missile logic, which can be changed. If it only resumes guidance towards the initial target, then it means that the radar and/or missile "know" which particular aircraft corresponds to which trackfile, which would indicate a huge problem with how the radar creates trackfiles. The logic behind the IRL behavior is that neither the pilot or the radar can tell if that new trackfile corresponds to the initially engaged aircraft. That's the reason why track memory is a thing, so that the radar has a chance to re-acquire the target, if it momentarily loses its return signal or can't find it in the noise. If the target cannot be re-acquired quickly enough, then the memory timer runs out and the track is dropped. If you detect the target again, after that window, then it'll be classified as a new trackfile, not associated with the previous one. It can also happen that the radar detects the initial target while in memory, but fails to correlate it to the trackfile. In that case, the initial track proceeds to time out, but until that happens, there will be two tracks displayed to the pilot. Obviously the criteria for correlation etc are tuned to avoid that, but I'm guessing it's not impossible to happen. Then it's up to the pilot to use their judgement. But as far as the missile is concerned, its target is still lost, so it'll continue to the last calculated intercept point and not guide towards the new track.

Oof... This really shouldn't be a thing. Does it happen only if you create a track on the same target? What if you create a track and designate another aircraft close-by?

Indeed a bug. I've never read about CCIP used in conjuction with a designation. While a designation is present, CCIP should always revert to AUTO. Also, if you have a designation and then switch to a weapon that had CCIP selected, that weapon should also automatically enter AUTO upon selection.

True, if the RWR filters are not implemented to at least filter out signals associated with friendly emitters, then this is going to keep happening. Depending on whether the unit is present in the friendly coalition only or not, the RWR should have built-in logic to treat it as friendly and display its only if the filter knob is in F. Example: the SPS-48 (SS or 48 on the RWR) of a CVN should be filtered as friendly, as long as all units carrying it are on the friendly coalition. If there is a CVN on the other coalition, then both emitters should be displayed in Normal mode.

You can attempt STT on a trackfile right now, either with the SCS or by depressing the TDC, that's not a problem. STT can fail, for various reasons, even IRL. The problem (that you also discuss) is that: 1. Tracking range is always below the range where the radar can gather enough info to generate a brick/trackfile. Given that bricks (and even more, trackfiles) represent processed data already, STT should not be a problem on a target with resolved range, altitude and velocity (that a brick represents). STT should fail if the target does not match the parameters of the track (eg. is no longer there) or if the radar cannot generate accurate enough info to transition to STT. (2. Not necessarily related to this thread, but related to your comment. We cannot attempt an STT on non-radar trackfiles with the SCS, because we don't have MSI. At best, we can try and match the DL track info manually and depress the TDC while in RWS. We should instead be able to designate and command STT on any MSI trackfile, with the MC taking care of pointing the radar to it.)

No conflict, they're separate systems and ideally should both be used, for redundancy. ACLS cues take priority, but in case something goes wrong with that, you can always use the ICLS cues to land.