Delta134 Posted November 26, 2024 Posted November 26, 2024 Hello, a while ago I made the following bug report: I am happy to see this was (partly) fixed on the last major update. Thank you. The following part was fixed: Slewing away from Cursor Target does not restore scan limits. (now slewing away from a Cursor Target, thus making it a System Target, correctly restores previously set scan limits). However, the following issue remains: Once a contact has been upgraded to Bugged Target, upon downgrading the contact to a System Target again, the scan limits are not restored. See the attached track for a demonstration. tws_scan_limits_bug_2.trk
ED Team Lord Vader Posted November 27, 2024 ED Team Posted November 27, 2024 Hello @_Delta13_ We have reviewed this quite extensively after we raised this internally. We are confident we have made the logics work closer to reality. The specificity of having the scan limits restored if the bugged target is downgraded, however, is not something we found in our references, hence why it wasn't changed. What you claim makes sense but again we need actual evidence this is the case and not change it based on an opinion. If you have any documented non-classified and publicly available evidence about this, please send it to @BIGNEWY via PM and we will certainly look into it again. Esquadra 701 - DCS Portugal - Discord
Delta134 Posted November 27, 2024 Author Posted November 27, 2024 Hey @Lord Vader The purpose of narrowing the scan limits for a bugged or cursor target is such that the contact is scanned more frequently. In the current implementation these scan limits are kept even if you cancel all targets. Like you said you agree; what is the sense in that? The only compelling argument for the current implementation is documentation explicitly stating it is correct. Even official documentation might not explicitly mention what happens to the scan limits if a target is debugged (it may be regarded as obvious and thus not explicitly mentioned). If you claim you have this explicit documentation, fine. Otherwise, I would request you please refer to common sense. 3
Frederf Posted November 27, 2024 Posted November 27, 2024 An azimuth setting of +-60° is not available under any condition in TWS for the APG-68(V)5, TOI or no. The only azimuth selections are +-25° or +-10°. 1
Delta134 Posted November 27, 2024 Author Posted November 27, 2024 11 minutes ago, Frederf said: An azimuth setting of +-60° is not available under any condition in TWS for the APG-68(V)5, TOI or no. The only azimuth selections are +-25° or +-10°. Do you have a source for this? The documentation I have states TWS uses RWS scan patterns when no targets are designated (1, 2, 3, 4 bar 10°, 30°, 60°) 1
Frederf Posted November 28, 2024 Posted November 28, 2024 I see APG-66v2 documentation that has TWS search volumes are the same as RWS... however volume decreases to A2B3 when TOI. APG-68v5 is explicitly different. APG-68v5: A2/B3 and A1/B4 only options. No azimuth bumping. Spotlight selects manual (cursor) A1/B4 while designate held. APG-66v2: RWS volumes (A6/B4, A6/B2, A6/B1, A3/B4, A3/B2, A1/B2, A1/B4, A1/B2, A1/B1) are available without TWS TOI and revert to the "normal" A2/B3 or A1/B4 options with TWS TOI. APG-66 is doing a pseudo RWS when in TWS no-TOI which APG-68 doesn't do. I believe this is the source of the discrepancy. 1
Delta134 Posted November 28, 2024 Author Posted November 28, 2024 (edited) That’s correct, I was looking at AN/APG-66 documentation. Good to know it is different for the AN/APG-68. @Frederfif you have a publicly available source for this, I suggest you pass it to @BIGNEWY In the end I wouldn't mind it being implemented either way. As long as it is consistent Edited November 28, 2024 by _Delta13_
Recommended Posts