Jump to content

Jak525

Members
  • Posts

    752
  • Joined

  • Last visited

Everything posted by Jak525

  1. Exact issue remains in latest patch. Seems present as soon as you start bugging targets or entering STT. https://forum.dcs.world/topic/309174-hsdfcr-information-out-of-sync/#comment-5069458
  2. Will this be marked as reported? Should be a pretty straightforward bug. Thanks for your time
  3. The symbology on the FCR/HSD for targets is occasionally "out of sync" with respect to the identification and evidently altitude as well. In the track, you can see I track a target which on the FCR page is yellow and on the HSD it's red. Also, the altitudes displayed are 1,000ft off. EDIT: Also sometimes Target A will be drawn over Target B on the FCR, but opposite on the HSD. FCR HSD symbology bug.miz.trk null null
  4. The AzEl is correct as is. This stuff has to do with the FLIR page itself when the FLIR is in A/A TWS mode. The FLIR has a TWS mode, not implemented, separate from autotrack and regular pointed modes; basically a fake IRST. Much more pressing matter would be to integrate autotrack into MSI.
  5. You can cursor over the MAN/AUTO button and TDC depress. If everything was implemented correctly there would be pretty much zero reason to use MAN.
  6. I will semantically add also, the L+S technically slaves the FLIR to the MSI L&S, meaning, you could for example make it follow the LOS of a Link 16 target.
  7. @BIGNEWYThere is probably nothing that explicitly states "FLIR track does not drop when radar drops track". However... this is is the whole point of MSI. While not implemented right now, the FLIR and radar are independent sensors. If the FLIR is in autotrack on a target, the radar losing track would not affect it. The FLIR is its own, independent contributor to the trackfile. Even if you were to deselect FLIR as an MSI contributor, it's still not linked to the radar. That would make no sense. If the Radar dropped the target for whatever reason, the FLIR remains there to contribute. In fact there are specific indications to show whether both the FLIR and radar have lost it or if only the radar has. Both are providing data on the target, if one is lost you still have the other to keep providing data. Now, if the FLIR was in a pointed/slaved mode (L+S, SLAVE) and the radar was the sole contributor to the trackfile, then radar drop would equate to the FLIR losing it. But that's because the FLIR isn't tracking. It's just slaved to the line of sight to that MSI trackfile. But in the case of this report, the FLIR is independently tracking the target. And again outside the idea of MSI, even in softwares prior to MSI, it would still make no sense. The FLIR is in independent track, it's not in any way connected to the radar.
  8. Yes, just hit the FLOOD pushbutton on the STT/Attack format.
  9. Yes, it's a matter of being in AA master mode and also RWS mode specifically - it doesn't work in TWS. When they implement the AMU (mission card) one of these days you should be able to plug in the 3 set of Set parameters preflight.
  10. Yeah the radar trackfiles should continue to extrapolate and go into memory, flash, and eventually disappear. The whole point of memory is to let you know the trackfile has not been observed in a while, and is going to delete soon. Yet it is still being extrapolated - off of the radar's memory.
  11. As per the edit, it's an old function that was removed. It's a relic of the old "pre-MSI" era where they hadn't revamped a lot of things yet like the HSI.
  12. Hey NineLine, don't take this as a "gotcha" or anything but I would like to briefly explain why this harsh assessment is accurate, at least in my opinion. And I understand this is a subjective thing, but I think I can articulate it objectively just so you can understand why people have this opinion about the Hornet A/A stuff. The thing is, it's not about some small areas needing some touch-up to make it as good as possible, it's that there are fundamentals to "daily use" of the A/A systems that are missing or wrong. In other words players regularly use certain functions in a way they would not use them if things were done differently. Just for some examples that come to mind, the way the jet deletes trackfiles is supposed to be based on a radar frame-based logic, whereas it is tied to a plain seconds timer in game right now, making the process of maintaining targets totally different than it would be; being purely time based means the radar easily loses targets before it can even have the chance to re detect them. Also, TWS Auto is just "L&S centering" where it should really be keeping all your targets like the F-14, which nearly removes the advantage of TWS since RWS does its LTWS trackfile processing anyway (in other jets obviously the advantage of TWS is the fact it's TWS, but in the Hornet, you get the same TWS tracks in RWS). Another thing is the inconsistent display of targets across the 3 AA formats, so you may have Target A appear as a different looking HAFU (color/shape or rank for example) on your SA vs ATTK page. I don't want this post to come off as "hah look at all these things I can name off, get owned!!". I really don't think the Hornet has been done poorly in all areas, but I think that with the A/A systems in particular the mark was kind of missed. I just wanted to write this so that you might better understand why people have this critical opinion. People aren't just saying this cause some obscure feature is wrong and therefore the whole thing is totally screwed. Again, I'm just trying to explain, so please don't take this as rude or an attack or a "gotcha!" type thing. Thanks for reading.
  13. It's just the way it's implemented now. Toggling LTWS should merely change the ATTK page cursor-over logic (on=show hidden HAFUs, off=only show the raw brick's altitude). The LTWS option does not actually disable the "LTWS" concept where the radar is building TWS tracks in RWS mode. IFF interrogations, and the interrogations' contribution to MSI, shouldn't be impacted by the state of the LTWS option. Id also note the auto-IFF on TUC was removed, at least I thought it was. Don't believe that's realistic. You only get the AUTO INT/AUTO L&S configurations, plus the ability to manually interrogate.
  14. You can think of this like shooting a gun. If you point the gun at a target and shoot, then point the gun at the ground afterward, it doesn't affect the bullet in-flight. Of course, the next bullet under the trigger would hit the ground given the current parameters, but the bullet that's already in flight is on its way. Maneuvering the barrel "post launch" has no impact on the in-flight bullet. Thus, post launch calculations must account for this.
  15. I don't know what circle you're talking about... the seeker max range cue potentially? That cue indicates (along the launch zone marker) the max. range of the Sparrow seeker. Just for a hypothetical launch.
  16. Go read everything Harker said in that thread
  17. I didn't watch the track but the radar should go back to AUTO after exiting SCAN RAID and do its AUTO thing. Of course AUTO is highly simplified right now, but it should at least be maintaining the L&S/DT2 in the volume. Again I didn't watch the track so not sure if it's going to MAN and going to the center (which'd be wrong) or if it's still indicating AUTO and going to the center (which'd also be wrong). Either way, should just go back to AUTO.
  18. The range to the designation is not supposed to be slant range. Only TACAN is slant range.
  19. This has been reported before. MSI as an all encompassing issue requiring a redo is known. It's just a matter of when. We'll just have to be patient and provide input when they eventually come around to it.
  20. Pretty sure that NWS should exit AACQ in TWS as well. I believe that is a very old thing from a very old software (pre MSI) where the L&S target undesignate stepping was only applicable to TWS. In later loads though it should work to reject AACQ in any mode (since undesignate steps in both RWS and TWS anyway). Paging friendly neighborhood @Mo410 to double check
  21. I thought they fixed this... but that would be a bug. Everything should reference magnetic unless set to true generally.
×
×
  • Create New...