Jump to content

Ahmed

Members
  • Posts

    406
  • Joined

  • Last visited

Everything posted by Ahmed

  1. @BIGNEWY, we are not talking of adding errors or drift here. We are talking that the aircraft thinks it is at N 00 E 00, while the TPOD shows the real coordinates of the point being aimed. It is not generating the coordinates relative to the aircraft's INS, based on Azimuth and Elevation, but it is just cheating and showing the absolute world coordinates instead. That's a bug and a development shortcut, not a new feature to add.
  2. Hi, When feeding wrong coordinates into the INS, the TPOD still displays the correct world coordinates of the point being looked at. In the attached track, the INS position is updated to induce the error (a separate bug in that process can be noted too), but the TPOD coordinates still show the correct world coordinates. coords.trk
  3. Hoping that this is pushed to a to-do list, rather than being left as a wishlist item, as this is part of the AACQ feature that was announced in the 2019 mini-updates, and that is incomplete without bump acquisition logic.
  4. Hi, Bump Acquisition has been mentioned several times in the forums, but I can't find any report about this missing logic. Currently, selecting AACQ from STT via castle right does nothing. It should command bump acquisition which should try to acquire a different target (out of a exclusion zone around the current one) within one antenna frame, or lock again the current STT target if nothing else is found (Ref to description of Long Range Automatic Acquisition (AACQ) - WITH DIGITAL DATA COMPUTER CONFIG/IDENT 92A AND UP) Track attached. bumpacq.trk
  5. Hi, The SLAM-ER video link works even with no LOS, when the SLAM ER is on the other side of mountain ranges. It probably applies too to the radar/radio horizon. slamer_los.trk
  6. Hi, According to the attached charts (declassified 1.16-compliant source https://www.alternatewars.com/SAC/AGM-84A_Harpoon_SAC_-_August_1974.pdf) , it should be possible to release the AGM-84 at altitudes as low as 200 feet at speeds as low as M 0.43. While the source doc is for the earlier AGM-84A, and not the D, any attempt to replicate anything close to this results in the missile hitting the water after release. The ALT cue also seems to show at an arbitrarily set (by ED) minimum altitude of 2500 feet, that is well above the minimum altitude in the charts. Regards, null harpoon_200ft.trk
  7. this seems to have been mistakenly moved to the F16 bugs subforum, instead of the F/A-18 bugs subforum
  8. Hi, In close relation to this other bug report : The Harpoon seems to fall short of the calculated LAR and doesn't reach the target despite receiving an IN RNG cue. Regards, harpoon_fail.trk
  9. Hi, I think this was reported long time ago, but wind information on the HSI DATA > A/C format is still missing. Regards, EDIT: Intended to post in Bugs subforum, please move wind.trk
  10. Hi, The AGM-84D LAR calculation seems to be hardcoded to ~97.2NM (180KM). FLT profile selection seems not to make any difference. Regards, EDIT: Intended to post in Bugs subforum, please move harpoon_hi.trk harpoon_lo.trk
  11. ^^^^ this. Hoping that one day it gets fixed. The current logic is not accurate for the aircraft operator and year stated.
  12. Gunfighter Mk.III ‘Modern Combat Edition’ Ultimate Base + MCG Ultimate grip + 200mm extension + small base plate, bought on 29th April and unused. 475€ including shipping within the EU. EDIT: sold
  13. HUD: CAS External view: EAS (not TAS... TAS would be higher than CAS) F10: GS off the top of my head.
  14. 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
  15. Just a quick quote from CNATRA on the matter (P-881, cleared for public release):
  16. Already reported, and it is not just ATFLIR but any kind of designation. It really needs a fix...
  17. 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
  18. 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.
  19. 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.
  20. 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?
  21. Yes, it's totally messed up after the last update and a hotfix can't come quick enough.
  22. 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...
  23. 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.
  24. 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.
  25. 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
×
×
  • Create New...