Jump to content

Ahmed

Members
  • Posts

    367
  • Joined

  • Last visited

Everything posted by Ahmed

  1. HUD: CAS External view: EAS (not TAS... TAS would be higher than CAS) F10: GS off the top of my head.
  2. MANPADS*, no MANPAD
  3. The LAR calculations for the AIM-120 seem to grossly mismatch and underestimate actual missile performance. In the two tracks attached you can see that the missile end-games with the same speed in both the in-lar and the out-of-lar tracks, and in both it is flying faster than its launcher. However, in the out-of-lar track, the Raero/Rmax indications show it well out of LAR, at 140% of the displayed Raero/Rmax value. in_lar.trk out_of_lar.trk
  4. Just a quick quote from CNATRA on the matter (P-881, cleared for public release):
  5. Already reported, and it is not just ATFLIR but any kind of designation. It really needs a fix...
  6. Hi, In the past a design decision was taken by the team to interpret that an IFF Interrogation by two different aircraft without a positive friendly response means hostile. This is fully inconsistent with how real IFF works, where this would just mean a LoF (lack of friendly) indication, and it could very well be a friendly aircraft with the wrong codes/crypto loaded or the IFF bent. This is now exacerbated by the fact that, since the introduction of TALD, TALD will correctly show as unknown while the hostile launching aircraft will show as hostile due to lack of friendly IFF response, as shown in the attached track. IFF should only be able to positively identify friendly aircraft. A hostile declaration should require more criteria than just a lack of IFF response. In the attached track note that the launching aircraft is tagged hostile out of "NCTR range" and without any surveillance tracks. In an ideal world there would be a mission scripting API and/or ME IFF profile option to specify the hostile declaration criteria and to interact with the system. This is just one of the many incongruences that the current IFF implementation has in the F/A-18/F-16 (such as aircraft without any kind of M1/2/3/4 transponder being able to respond to interrogations, or neutral aircraft showing as hostile, among others). tald_iff.trk
  7. Hi, Probably applies to the viper too as it is probably a core design issue. As many other HARM/RWR related thing, the ALIC codes are tied to the unit type, and apparently the same number can't be used by two units at the same time (using the string identifiers). This leads to odd situations where, for example, the SC Nimitz carriers all have different ALIC codes assigned, despite having the same emitters and showing with the same threat identifier in the RWR and HARM displays. If they have the same emitters, and show the same, they should all use the same ALIC too, and HARM should be able to flex between emitters with the same code (currently it only flexes per unit type). This also affects 3rd party mods that can't re-use an existing ALIC code. No track attached as this is more of a wrong design issue than a bug as such.
  8. Thanks, I'm familiar with how it works in the luas if you need any help with that (not that it is rocket science), but have no clue about how it works on the 3d modeling side. If it serves you of help, I know that the FRENCHPACK guys have figured it out.
  9. Thank you guys. This is amazing! The only thing... any chance that you could make the new 3D models compatible with the new FLIR tech?
  10. Yes, it's totally messed up after the last update and a hotfix can't come quick enough.
  11. T/R has nothing to do with bearing but with DME. A/A is implicitly a T/R method as it gives DME and for DME you need to transmit a pulse so that a response can be sent back. For the rest, all of it is very well known information: KC-135 only gives DME and works in A/A mode, confirmed by both documentation and SMEs. No idea why this got changed and has gone unacknowledged for son long. For now better to forget about TACAN and just used other means to locate the tanker until this gets acknowledged and fixed...
  12. You can probably trace back specific equipment to specific squadron at the specific date of those videos. It is very easy though to distinguish ALR-69 from ALR-56M tones as they are completely different. The SME issue is a recurring one in flight simulators, that I've seen first hand. Usually for a SME not familiar with the degree of accuracy of modern PC simulator, everything is surprisingly accurate. It is only when you are aware of the current state-of-the-art of PC flight sims that you start to be nitpicky. I've seen this phenomena personally in specific stuff (non-DCS) in which I'm a SME and where the producers kept stating that their product was "SME approved" while they were full of inaccuracies. Thus my post, where I recommend ED to run those very specific points by their SME, before confidently announcing that their implementation is correct when it is not, as you yourself know too. I'm sure that if they ask those very specific points to their SME they will get feedback on how their ALR-56M is currently wrong.
  13. You either have an internal miscommunication or need your SME to take another look at these particular issues: - Missile launch recycle tone: the missile launch recycle tone is 515hz instead of the 1000hz of the "initial" missile launch tone. This sounds every 15 seconds after the initial missile launch tone. You can hear this on the Serbia shootdown video... - New threat audio: whenever a new threat is detected, there is a chirped tone of either 3000hz (air or unknown threat) or 500hz (surface threat). Again you can hear them in both the Serbia and Alaska videos. - Hand-off mode audio: indeed not the same as in the ALR-69, but there is still PRF audio/chirped tones for the "diamond" emitter. Yet again, you can hear the tones in both videos. I have no idea of how you can assert that your ALR-56M implementation is fully correct when it is literally missing all tone features from the real one, and when even your missile launch tone is repeated continuously instead of being "recycled" every 15 seconds. Maybe the DCS viper is headed for a similar future than the DCS hornet.
  14. Hi, Noticed that NCTR will identify a neutral aircraft, even if it is a friendly type such as the F/A-18C in the attached track, as hostile. There are other issues with the way the whole IFF matrix seems to work in DCS, where IFF seems to be able to provide a positive enemy identification rather than only being able to provide a positive friendly identification or lack thereof as a realistic implementation should, but I'll post those in other reports. Regards, nctr_neutral.trk
  15. That's ALR-69 though. For 56M check: and:
  16. It really depends on what suite you are talking about. CONFIG/IDENT 92A and up should display critical, lethal and non-lethal threats in the HUD EW. Currently in DCS we have an incomplete and inaccurate mix of things from different suites (missing flashing long stem, "stt symbol" from older suite, different length stems from 92A, wrong interpretation of what lethal/non-lethal and critical mean, missing status change tone when moving from non-lethal to lethal due to the previous misinterpretation, etc...).
  17. If it is always .01 mmHG lower it is not sense of realism but a bug. While real life METAR or ATIS may give you an outdated altimeter setting, ATC do give you a current reading. It would be a different thing if your altimeter is slightly miscalibrated internally (tolerances irl for this are surprisingly high).
  18. There is a concept called TUC (Time of Useful Consciousness) that addresses this through tables, for example found here: Time of Useful Consciousness | SKYbrary Aviation Safety I quoted 30 minutes from these tables on my post above. However, as people above are commenting, a healthy individual won't suddenly pass out at these numbers.
  19. Good point, I submitted that clip among others several times that got added to an "open" bug report about the RWR having mixed features from before and after CONFIG/IDENT 92A and thus being wrong both ways, but didn't think about mentioning stabilization.
  20. Wasn't this reported recently?? We are getting a lot of mixed information lately.
  21. I recently had TOT indications being wrong and disagreeing with the WPT ETE in the HSI top-right, that was correct. So, it is not working correctly in all situations at least. Still have to reproduce and record a track to report that one.
  22. It's not exactly the same issue, as he reported AWACS BRAA being true (a core game issue) and I reported that several hornet displays report true bearings instead of magnetic for various indications that should be magnetic (Hornet ATTK/SA systems issue), but I'll assume that the team took note despite this ending up merged.
  23. An E/F module would offer the best to DCS. I'd particularly love to see it developed by HB or RB, but both have their hands full right now. Also there may be obstacles to get a contract to develop that particular airframe.
  24. Hi, The A/A WPT bearing and range indications (both ownship and cursor), and the BRA indications in the ATTK format are showing in TRUE instead of MAG. The A/A WPT bearing and range and the cursor bearing and range in the SA page are also showing TRUE bearing instead of MAG (BRA curiously is correctly showing MAG here) Regards, true_aawpt.trk
×
×
  • Create New...