Ahmed

Hi, The SA-2 kill radius ('KillDistance' paramter) in the data files is defined as 20 meters, that is less than 1/3rd of the commonly found value if one investigates. If I'm not mistaken, this parameter controls the proximity fusing of the missile in DCS (that is already flawed as it doesn't seem to consider the dimensions of the target aircraft either and just its origin). The values commonly found if one investigates are 65-70m for kill radius and 100-120m for severe damage blast and consistent across sources. The fuse in the V-750 missile series has various settings depending on target height and closure and will be armed at between 100-300 meters from target to actually fuse just past the closest point of approach. For comparison purposes, the DCS AIM-120 is defined with 15 meter kill radius!! The AIM-120's warhead weighs basically 10 times less than the ~200kg SA-2 missile warhead. The SA-5 that has a similar weight warhead than the SA-2, is defined with 45 meters. This results in near misses in DCS not detonating, when they should, and in DCS not correctly depicting the real power of the SA-2 system to take out several aircraft of a formation in a single detonation, or the large warhead compensating for the missile's low maneuverability. No track attached due to the numbers in the data files speaking by themselves.

In this last update, the radar track files seem completely broken. After some testing, it looks like the track files are being dropped within 6 seconds, ignoring age setting. (EDIT: age setting is unrelated to this. However, the "new" 6 seconds are still wrong and result in anything with a frame time greater than 6 seconds being unable to generate/keep a track file. This processing is at the very least performed after one full frame). This means that only very small search volumes (az/bar/prf setting) will result in a track file being generated and maintained in this DCS update... and severely affect Hornet air-to-air performance in SP and MP. Track attached. rdr.trk

The LAR indications for the GBU-38 at altitudes <= 10000 are wrong. At all tested airspeeds, the bomb falls short. gbu38lar.trk

@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.

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

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.

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

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

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

this seems to have been mistakenly moved to the F16 bugs subforum, instead of the F/A-18 bugs subforum

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

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

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

^^^^ this. Hoping that one day it gets fixed. The current logic is not accurate for the aircraft operator and year stated.

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

HUD: CAS External view: EAS (not TAS... TAS would be higher than CAS) F10: GS off the top of my head.

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

Just a quick quote from CNATRA on the matter (P-881, cleared for public release):

Already reported, and it is not just ATFLIR but any kind of designation. It really needs a fix...

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

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.

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.

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?

Yes, it's totally messed up after the last update and a hotfix can't come quick enough.

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...