Ahmed

Deleted: misread units

Currently, while some units such as ships seem to have multiple radar sensors modeled in the database, this seems to be ignored by the RWR and HARM that seem to reference the emitter unit rather than its sensors. This affect specially naval warfare. This would be an area where DCS has some room for improvement in the future, and maybe something that can be worked on now that IADS and some EW/ESM seem to be on the roadmap. Additionally, many newer systems (such as the SA-12/S-300V 9A82/9A83 TELARs, or many naval units such as Aegis cruisers) use an illuminator for terminal guidance that is different than the radar used for mid-course tracking, that should be modelled too as it has a big impact in various aspect of the EW arena, ranging from system survaivability and multiple-target engage ability, to late RWR launch detection.

Apologies I didn't realize I recorded that track with a naval unit that is not in the threat library, and that this fact could lead to confusion. I have re-recorded the same using Pyotr Velikiy to show that it happens with all naval SAMs. naval_piotr.trk

Oh no. This again. I just wonder how many of those defending the "airplanes can land anywhere" principle have actually landed any real plane (bonus points if bigger than a 172) in an unprepared strip.

Grimes has already replied, but, as for this, all the changes and new functions I've seen in 2.7 were already documented in their wiki when I checked, so most likely yes.

Currently in-game, the SAM light only illuminates when a SAM radar is locking prior to missile launch. At missile launch the SAM light extinguishes and is replaced by the CW light, regardless of the guidance type (command/SARH/TVM/SAGG/mid-course-GAI). The CW light should only come on for guidance types that rely on a CW emission for missile guidance. The SAM light, according to the very own DCS F-18C manual, should behave as follows. Track attached with SA-2 (command guidance) example. cw.trk

Hi, Currently in-game, when engaged by (at least some) naval units, the symbology in the EW page and RWR don't flash (and they should also flash in the HUD as reported here), unlike when engaged by ground/air threats. Additionally, and as part of the same issue, the "SAM" light in the right advisory/threat warning indicator panel does not illuminate when locked by a naval threat. Track attached. naval.trk

I hope

This is an old bug that happens the first time you slave the pod. Undesignating and designating again (after cycling waypoints too??) usually fixes it. I don't know exactly how to reproduce it but it has been there for a few months.

3.0 is the effective glideslope, due to the relative movement as you say. However, the LOS from the carrier to the plane should always be 3.5 regardless at all points, for a 3.5 B/E that is. In any case, as Swift said, the PLAT crosshair could be misscalibrated for a lot of reasons as it is not a primary reference. Also, it shouldn't pitch up/down with the deck as it currently does in DCS (as you can see in all the YT pitching deck footage available)

This probably belongs to the SC bug report section, but you are right, the crosshair seems to be set to 3.0º instead of 3.5º

Indeed, drop size and composition play a big role in its reflectivity (water being 5x more reflective than ice, for example). Airborne weather radar is tuned to detect precipitation and often misses big buildups still developing, or dispersing thunderstorms. The fact that fighters use ground mapping modes to avoid weather suggests that it must detect returns from water drops in a relatively similar way.

Hi, AUTO mode is tracking moving targets while masked. In the attached track the vehicle is even maneuvering while masked. IIRC this is also happening with the Litening. mask.trk

Indeed we are missing the "NO RDR" cue, the radar contribution circle, some MSI trackfile HAFUs (IIRC), and designating MSI L&S without radar contribution. There is plenty of OS evidence and documentation available for all of those, a some have already pointed out.

Hi, Currently it is not possible for one player to be the shooter and another one the controller for SLAM or Walleye attacks. This should be possible and is described in the TAC-300.

Bumping this to see if it can be added. Would be really handy for SRS and a very tiny fix for ED.

I saw this that apparently reflects what is going on normally at public servers. I reckon it fits as an example of what is currently possible in the sim and how it gets exploited.

Hi, this will probably get a WIP tag really fast, but just in case: the PLAT cam is not indicating the activation of the waveoff lights (flashing W). wo.trk

Same, I hope that this can be addressed in the future then, as all radars, RWRs, etc in PC sims are always quite OP in comparison with their real counterparts (no false returns/tracks, no mippling, no ambiguities...) to even make them more, but yeah that will require the devs figuring out how to overcome some technical limitations I guess.

Hi, I know that this was mentioned in some thread, but I coudln't find a dedicated bug thread or official response to it. GMT can detect and track through dense forests. In probably close relation to it, the land.isVisible() scripting function also seems to ignore trees when raycasting for LOS, as you can see in the attached track. gmt.trk

Hi, With 2.7 we got the working buttons in the LSO console, but it seems no key bindings. Can we get key bindings for them, as this is normally triggered from the pickle?

Hi, As in the title. Track attached. sub.trk

You can click the button on the LSO console. But I haven't found any key preset for it.

Deleted. No point.

Hello, Are there any news about this? As the BARO warning is, among other things, used to alert of the floor, the current implementatio where it goes off at the true ("F2") altitude rather than the indicated altitude, looks very wrong. It is described in NATOPS as "Barometric Low Altitude Warning" so it only makes sense for it to be barometric. EDIT: quick&dirty laptop+keyboard track attached showing it baro.trk