Jump to content

Harker

Members
  • Posts

    3674
  • Joined

  • Last visited

7 Followers

About Harker

  • Birthday April 25

Personal Information

  • Flight Simulators
    DCS World, Falcon BMS
  • Location
    Europe
  • Interests
    Science, Tech, Aviation
  • Occupation
    Nuclear reactor physicist

Recent Profile Visitors

3460 profile views
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. That's... very unfortunate. That's completely game-y...
  6. It's showing correct and stable (not jumping) range, even when the FCR itself cannot resolve it at all, and HUD says F099.9. I want to add that this also occurs with promoted TWS tracks, they all show at their correct ranges and much further out than the radar could ever detect them normally.
  7. 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
  8. While the FCR cannot resolve range for jamming targets (correct), the HSD shows their actual ranges (bug). It should either not display them, or display them at max distance. Additionally, this also occurs with promoted TWS tracks, they all show at their correct ranges and much further out than the radar could ever detect them normally. Screenshot attached, all displayed targets were jamming Su-27s. One non-jamming Su-27 at ~50 NM is not detected and displayed yet. Track attached. F-16C_HSD shows range to jamming targets.trk
  9. @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.
  10. 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).
  11. 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.
  12. 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?
  13. 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.
  14. 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.
  15. 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.)
×
×
  • Create New...