LetMePickThat

That's not how you're supposed to use it. This revetment is for a single TEL, with an access/exit lane for a missile carrier/loader. Furthermore, you don't want to stack your launchers like that as this would make them very easy to take out with a single strike, and very likely to recieve damage in case of a missile launch failure.

I think I posted some examples above. I'll make some new ones if you can't find them. The VM and PMU are definitely doable, but you need people to fly with you and a ton of weaponry. Those systems might give you a lock warning (not a given), but they won't give a launch warning. Assume the worse when you're crossing the SAM ring. I'm not familiar with that jammer script, maybe it needs specific inputs to work with custom SAM systems like Skynet does, I'll take a look when I have the time.

If your MWS system doesn't rely on radar pattern analysis, then yes. The DDM on the 2000 might be able to pick them, if fired from close enough, but that's about it. Anything RWR-based in a coin toss at best.

Modern electronic scan radars would likely not give a launch warning. Whereas a mechanically steered radar will indeed trigger a lock warning when switching from general scan or TWS to STT, and a launch warning when fired upon, there are no changes in the emission pattern of an electronically scanned antenna when an engagement is initiated that could be used by an RWR to trigger an alert. An electronically scanned array relies on multiple, agile beams that can all track targets with a precision akin to that of STT modes on older radars. With a PESA/AESA design, right after primary detection, the system will work in "pseudo STT" mode for all targets, regardless of whether they are to be engaged, engageable or even hostile. Every internal track will be de facto "locked", with a very high refresh rate and high radar dwell time. This is why the refresh rate on modern AESA designs is very low regardless of the operating mode. On top of that, inherent AESA/PESA characteristics like high frequency agility, advanced scan patterns, a bunch of other LPI techniques and high duty cycle make it very hard for RWRs to understand whether they're just illuminated as part of a regular scan process or if a missile is actually in flight. Modern RWRs try to work around that problem by intercepting other signals like weapons uplinks, but this isn't guaranteed to work since those signals are designed to use very narrow beams. I would suggest taking a look at Air and Missile Defense Systems Engineering by Bord and Hoffman if you're interested in that subject. There is no J-serie message for such thing as a SAM launch warning. Missile warnings can be transmitted using dedicated messages, but this is more relevant for the defense (SAMs, mainly, being informed of an impeeding attack) than it is for aircrafts being actively shot at.

That's the issue, ED's HARM code doens't tie with our own. The way we do it is by specifying an existing radar type in our own files to piggy back an existing HARM code. The SA-12 has its own RWR and HARM code because there used to be a SA-12 in Flanker/LOMAC, and the associated codes were never deleted. For newer systems, it's a hassle and we usually use the closest equivalent ingame.

ED's SAM update broke stuff, I'll take a look but not ETA since I'm really busy IRL at the moment.

Hey, thanks for the pointer ! As I'm not flying the Apache, I never cared that much about how the barriers were declared. Also, since we released them before the Apache was out, no one pointed it out before you. I guess I'll change that so that this doesn't occurs anymore.

Hello guys, here is a quick fix for some of the small issues with the S-300 pack. I'll be working on the various conflicts with the HDSM in the upcoming days as well. Changelog: Corrected typo in 5P85SU display name Corrected type in 5P85DE display name Corrected the 3D model of the Grave Stone Truck Corrected the issue preventing the 5V55RUD from displaying a 3D model Corrected the issue preventing the Mast-mounted Grave Stone (30N6) used on the SA-10B/S-300PS from working Download: https://drive.google.com/file/d/1qcpVERQhsK4xHNrFHQsr5SpG6H7n1Bwf/view?usp=sharing

They should dissapear when destroyed. I'm logging that for futher investigations. This is a question for @Strigoi_dk.

No. I'm real busy IRL right now. I'm logging the issues and requests but I'll need to find some free time to actually work on them and publish an update.

I have a fix for that, I'll push it when I have the time to work a bit on the mod. How so?

I'm not conflating detection and identification. Even when knowing that a plane is here, NTCR would need to have a return from the blades to perform the blade count and subsequent identification. Assuming that the blades produced no return (or too small of a return), NTCR wouldn't be a thing. Sure, you'd be focusing more energy on the threat and thus have increased resolution and range, but the main rotor of your average helo has more surface and is more exposed than a compressor first stage, and should produce more returns for a given power output. Also, NCTR doesn't always require STT, TWS and equivalent also work on modern AESA radars because of the ability to use multiples beams. Thales for instance publicly stated at Le Bourget that the RBE2 could perform multiple identifications at the same time. There are also various NCTR techniques that do not require the target to show compressor blades (i.e have an hot aspect), like narrow-beam interleaved search and track or other pseudo-imaging approaches.

Most NCTR systems use blade count to classify targets, when there's a signature ambiguity. It's doubtful that the main rotor on an helo wouldn't reflect enough energy to be detected when modern radar sets can distinguish a MiG-35 from a MiG-29 using the difference in blade signature between the RD-33 and the RD-33MK...

This is what most module makers do, I assume, regardless of whether the missile is a Fox 1, 2 or 3. Guidance algorithms aren't discussed in detail in open source litterature when dealing with specific missiles, even if the theory is well known.

It's already on GH, albeit on a private repo. I'll see with @Strigoi_dkwhat's his take on switching our repository to public.

Thanks. Probably a sensor issue. I'll check.

They work fine here. Can you send me your log file so that I can take a look ?

The Panstir is not CA-ready yet. CA doesn't handle multi-targets radars, hence the problems you have with it when controlling it directly. At the moment, I would suggest leaving the missiles to the AI and only use CA when/if you want to use the guns. Keep in mind that this is an early relase, and as such is filled with various bugs and limitations we are yet to solve. I'll take a look, thanks.

No, not at the moment.

It should work, I'll take a look. It's up to you, both are very similar but the S-300 pack does not features the older units (e.g SA-2/3). The S-300 pack focuses more on modern(ish) systems. These lines aren't related to the problem at hand. Try using only the HDSM and you'll have the same errors. The systems in common are the following: S-300PS S-300PMU2 S-400 S-300V S-300VM I'll take a look and update the S-300 pack to ensure compatibility.

Just to complete what @Strigoi_dksaid, I'm currently quite busy IRL so progress on the mod has slowed down in the last two months or so. I'll get back to full speed once I have more time on my hands.

Yes.

GR is using systems we have not released yet. Stay tuned for more.

We use AAP quite a lot. From the page you quoted: The V-759 is the 5Ya23. Note that values might not match exactly since DCS requires some tweaking here and there for gameplay purposes.

Yep. Unfortunately, I haven't found a way to add custom SAM systems to the HAD...