reported Search Radar AI (1st group) stops reporting hostile aircraft position on F10 map, when SAM group (2nd group) is put into GREEN state.

[Shadow KT]

Place two groups. First group consists of a a single unit of ST68U “Tin Shield”, used as an EWR radar. Second group is made out of any sort of fully operational SAM (SA-10 used in track), meaning launchers, C2 vehicles, search and track radars.

What will happen is, if you have both groups in RED state, tracking the target aircraft and you put the SAM group to GREEN, to stop it from emitting, the target aircraft will drop out for between 30 seconds up to 2 minutes, even tho the first group, which consisted of the Tin Shield radar has not stopped emitting.

If you operate each group separately, this behavior is not observed and both groups work as intended.

What you will see in the track is:
1) On mission start I place both groups to Green.
2) I put Tin Shield Radar group to Red. Check that contact appears. 
3)Change Tin Shield state from Red to Green. Contact disappears. (Basically checking that the group works as intended by its self).
4)Repeat same actions for SA-10 group. While the Tin Shield is off, turn the SA-10 to Red. Check that contact appears.
5)Return SA-10 to Green state. Contact disappears, as there is no radar on, to provide picture.
6)Turn on both groups' states to Red, first on the Tin Shield and then on the SA-10. Both radar groups are now emitting. Check that contact appears.
7)Have positive contact with target. Now switch off SA-10 group to GREEN, while Tin Shield group is still on Red and emitting.
8)What is observed is that the contact is lost for about 1 minute and 50 seconds, although the Tin Shield radar has not been interrupted and has been working all this time.


This basically makes it useless, when trying to human control an IADS network. You cannot use your EWR/SR to spot targets, without exposing your SAM.

I have not tested this with the 1L13 and 55G6, but I have observed the same behavior when using the Sborka "Dog Ear" radar combined with SAMs such as SA-3 and SA-6.

It would be nice if the developers could check all these interactions between the different radars.

Search Radar NO SPOT2.trk

I've placed this in the AI section, as I believe it has more to do with the AI and you can change group states using triggers, instead of CA.

Edited August 7, 2021 by Shadow KT

[Flappie]

Hi @Shadow KT. It seems I can't reproduce this issue in DCS 2.9. Can you please confirm this was fixed at some point?

[Shadow KT]

Some sort of a variation is still going on.

Seems like ROE is playing an effect on what is happening when changing states. In Spot ROE.trk you can observe how if ROE is set to HOLD, and as an example you go from RED to GREEN, dishes will stop spinning, but the target will remain visible on the map and vice versa. 

I have not tested what is seen from a pilot's perspective (RWR). @Flappie

 

Spot No Radar 2.trk Spot No Radar.trk No Spot Rada On.trk

Edited December 9, 2023 by Shadow KT

[NineLine]

Yeah something weird is going on.

It seems to be impacted by Hold. If I set Group 1 to Fire, then Green and Red work as expected. But if I set that unit to Hold then Green and Red do not work as expected.

I will do some more experimenting and see what else is going on and report as needed. Thanks. 

[NineLine]

I have reported this issue with ROE: HOLD. I will leave this open incase I am missing something else here or there is possibly another issue with this. Thanks!

[Whiskey11]

3 hours ago, NineLine said:

Yeah something weird is going on.

It seems to be impacted by Hold. If I set Group 1 to Fire, then Green and Red work as expected. But if I set that unit to Hold then Green and Red do not work as expected.

I will do some more experimenting and see what else is going on and report as needed. Thanks. 

I believe there is a problem with state changes to begin with.  A few months ago, a bunch of us in the Skynet IADS Discord ran into a problem with the Set Emissions state not updating correctly when it changes and an aircraft is within the detection range of a SAM site.  In those particular examples, we were using the destruction of a building (a "power node") to turn off a SAM site.  It'd work perfectly if you destroyed it from outside the SAM range, but it would not update correctly when you were in the zone and it was actively locking you.  The SAM site would never update correctly.

There was some extensive work around stuff being done to revert Skynet behavior to an older version where it just turned off the AI, but many people are trying to get it work with the default Skynet implementation and having issues.  It might be related to this same bug.  I thought it was a problem with something in Skynet.