DETECTION: Detection object does not remove units that goes out of scope from the "detected table"

[chrisofsweden]

So, a question regarding the Detection class. As per my testing, it seems like the detected status of an aircraft "sticks" even though it goes out of an EWR's scope of detection.

In my test I set up a RED EWR network, and AI A2A Dispatcher GCI response range at ~60nm. I set up a Blue AI Hornet at 20 000ft start alt at ~80nm from target base, and succeeding waypoints from 75nm out, at 100ft AGL towards the target base. I carefully checked that it is terrain masked all the way up to the target.

So the EWR detects the Hornet on its way down from 20 000 ft, prior to reaching it's first 100ft AGL waypoint No GCI response yet, as it's still out of the GCI range. The Hornet is terrain masked from ~75nm and all the way to the target. However, when passing the GCI range at 60nm, the AI A2A Dispatcher still spawns a GCI fighter when the hornet passes the GCI range at 60nm.

IMHO, shouldn't the detection object purge aircraft that disappears from the EWR network scope from the "detected units list"?

To verify that this is in fact the issue, I set the Hornet up at 100ft AGL starting alt and let it fly all the way to target base and it works. No GCI is scrambled since it's never detected by EWR.

This was with MOOSE Master branch downloaded on the 19th of Sept. MOOSE GITHUB Commit Hash ID: 2018-04-07T21:39:48.0000000Z-d78945fc6780044d2d974b9cb9ba6a8762e46c46

EDIT: Also tested with current dev branch with the same results. MOOSE GITHUB Commit Hash ID: 2018-09-20T20:03:42.0000000Z-1f86ceb6c496bc8e22e0a19209919a80ac6e600c

[Delta-99]

Strange. I thought @FlightControl-User fixed this. Let me see if I can find the commit on it.

[Delta-99]

@FlightControl-User isn't this the commit for this fix? Or is this another issue with it: https://github.com/FlightControl-Master/MOOSE/commit/337b7a69b2ffb22d45b4dc8637d883fb51272f2c

[chrisofsweden]

Thanks Delta. Yeah I had a look in that code and pretty immediately there's a for loop that seemingly clears detected objects. Hm. Since I guess at every detection loop it should check parameters on each detected object against e.g. AI_A2A_DISPATCHER:SetGciRadius() parameter, right?

EDIT: Well not clear detected targets, but reset their known data...anywhoo, I'll leave this up to you experts to figure out. Thanks. Let me know here if I can assist further.

[Delta-99]

I didn't look at the specifics but perhaps the GciRadius was not taken into consideration in removing the "undetected" objects. So perhaps this is a minor bug and case that was not handled. I'm sure FC will look at it and determine in 2 seconds whether it is or not.

[chrisofsweden]

Yeah we'll see I guess. Yeah I'm sure FC will sort it.

[FlightControl-User]

Thanks Chris, i'll have a look at this.

[FlightControl-User]

@chrisofsweden

Ok, i am looking now to this question. As you know, detection works in terms of "detected items", which is a subgrouping. We have detected items based on UNITS, TYPES and AREAS. UNITS is one unit, TYPES can have multiple units, and AREAS can have multiple units in an area. therefore, lets discuss on the level of detected items.

So detection has the purpose to:

• keep detected items from the list that are still alive.,
• remove detected items from the list that were previously detected and that were destroyed. Later, I want to look into removing detected items after x time, that were detected, out of sight, but not destroyed.

I need to keep this detection cache to have the tasking working correctly. Detection is a module that groups detected items, and also keeps stability to the consumers on the detection item set. That is, each detection item gets an id, and that id is kept stable, so that tasking and other consumers can keep that id as a reference.

it is the purpose to indicate within the list whether the detecteditem has a valid detection or not. I've been testing this stuff for a while, and found a bug for DETECTION_UNITS. It seems that the detection was incorrectly registering detected items that went out of sight, thus the detected item still in the list, but with an indication that the item was still detected, which wasn't! That is now fixed for DETECTION_UNITS. I had to redo the code a bit. That bug was in the system for a long time, it was a structural issue (my mistake). I haven't tested DETECTION_AREAS yet.

I had made this test mission to demonstrate the correct functioning of the DETECTION_UNITS module. Suggest you try out this mission and see if this fits the purpose of your question. This is now in the code base.

https://github.com/FlightControl-Master/MOOSE_MISSIONS/tree/develop/DET%20-%20Detection/DET-310%20-%20EWR%20-%20Line%20Of%20Sight

Now, investigating, fixing this to the bones will require a lot of time, and the risk of a lot of changes in the code, because I may discover other (structural) mistakes. Is this an urgent issue, or can we live with this for a while, and I'll move this issue to release 2.5 or to a patch fix? I will need to modify code, which will impact the workings of TASK_A2A_DISPATCHER, AI_A2A_DISPATCHER and TASK_A2G_DISPATCHER, and DETECTION_AREAS, DETECTION_UNITS and DETECTION_TYPES. So I wanna keep a stable environment now and not start messing around with the core code now. What is your advice?

[chrisofsweden]

Hey @FlightControl-User thanks for looking into this. This is not a showstopper issue so I'm fine with if you want to push this forward.

So I tested your DEMO mission and I'm sorry to say I don't see the difference, OR I'm not understanding fully. As I see it, once both of the red aircraft has been detected, even though they continue north over the mountains and definitely is behind mountains, the infobox still states that both aircraft is detected and within line of sight?

Anyway, I understand what you're saying why detection holds detected units in memory for reference for tasking etc. Perhaps this is not so much a bug with how detection works, but rather something that can be changed in how gci is triggered? The problem is that AI_A2A_DISPATCHER dispatches GCI on targets that isn't currently seen by EWR, but was detected earlier.

One suggestion would be to add an additional check when a target is closer than the SetGCIRadius / crossed the border, if it is CURRENTLY detected by EWR.

Like in a cold war scenario a blue fighter is detected by red EWR close to the border. Blue flighter drops down and terrain masks and crosses then the border. This should imho not trigger a GCI dispatch, but it does today.

[FlightControl-User]

Ok. But I need to check out that demo mission again... keep you posted.

[Delta-99]

I think maybe this is a slightly different issue than the one that was fixed. Don't focus on units still being in the detection list (unless @chrisofsweden can fully confirm they are in there and are STILL DETECTED). The list might still be there but NOT detected. I think this has more to do with border than the detection GCI dispatch.

[chrisofsweden]

@Delta-99 Yes exactly. The units that get detected once, stay on the detected "list" forever it seems, until they die or despawn. Thats fine. But AI_A2A_DISPATCHER should not dispatch GCI flights if the incoming threats are not CURRENTLY seen by radar. That they have been detected once BEFORE entering the GCIRadius or crossing a border should not matter. Once a unit crosses a border or GCIRadius there must be a check that it is CURRENTLY detected and then dispatch GCI, if it's not then do nothing.

Like, isnt there a native DCS function like "Unit.IsDetected"? That could perhaps be called when a unit crosses border or goes past the GCIRadius.

[Delta-99]

Don’t forget though I think FC implemented that the flight will investigate the last known location of a detection. Make sure that is not what you are seeing. Probably difficult to test. I thought your issue had more to do with the unit crossing back outside the border. In which case I would assume the behavior would be for the detecting flight to stand down sort of speak. That is, they shouldn’t go chasing over the border.

[FlightControl-User]

@Delta-99 @chrisofsweden Indeed... there is something to be investigated further. I will. It just will take a bit of time to do all this in a good stable manner. I think I need to improve a bit the way for AREAS the "IsDetected" algorithm is working. So an area would get flagged as "not detected", if the EWR network is not detecting anymore any of the targets that were the last grouped within the area. If at least one is still detected, then the area should be flagged as detected. There is indeed a notion of "the last known position", which is one of the main reasons why I built the detection algorithm. So, I've moved this to release 2.5, but what that really means concretely is that I will look already into this stuff, and see what needs to be done to rework a bit further the detection algorithm, so that methods can be constructed that can further enquire the state of the detection item. I've moved this into a bug state from now on. Within a couple of days you should see an update coming on this, or at least some further explanation. The first thing that I need to do, is to make some further test missions on DET (Detection) to simulate the lost of LOS on a group of targets in an AREA. And implement an "IsDetected" method.

[Delta-99]

No worries. These type of things take a lot of time to look into properly. And also can use a couple of pairs of eyes. So maybe a joint debugging session would help in the future.

[chrisofsweden]

@Delta-99 No it is not the "last known position" thing I'm seeing. An example: A blue aircraft is flying course 360 just within an EWR's detection range, and gets detected. If the blue aircraft continues on course 360 it will never be within GCIRadius range of a red airbase.

The blue aircraft descends into a valley where the EWR can't see him. The blue aircraft follows the valley, which turns left 090 to a red airbase where a GCI squadron is placed. When the blue aircraft is within the GCIRadius, the red airbase scrambles a GCI interceptor which indeed intercepts the blue aircraft.

Now, where the red EWR last saw the blue aircraft, it was going 360 and would not end up within GCIRadius of any red airbase. But the EWR lost contact on the aircraft before it turned and thus should by all means "think" that the aircraft is down low still heading 360. You follow me?

@FlightControl-User @Delta-99 Thanks both of you. I'm sure you guys will sort this out eventually. I'll be happy to supply you with my demo mission if it would help you in your testing / fixing.

[Delta-99]

Ok I understand fully. If you have a decent mission that shows this definitely send it along.

[chrisofsweden]

@FlightControl-User @Delta-99 Ok so pause for a bit don't put more time on this just yet.

I tried setting up a new mission, with the same detection code and dispatcher parameters as my "actual play mission" to test this and I did not get this issue. An aircraft detected outside the GCIRadius that went below radar, terrain masked, could in fact pass the GCIRadius without GCI being triggered. I'm baffled. I'll do some more extensive testing this afternoon, trying to see whats different from the test mission compared to my play mission.

As @FlightControl-User mentioned I am indeed using DETECTION_AREAS as the detection object for the AI_A2A_DISPATCHER.

I'll keep you posted.

EDIT: AI_A2A_DISPATCHER does not work with anything other than DETECTION_AREAS right? I've tried this, it detects aircraft but won't trigger GCI:

DetectionSetGroup = SET_GROUP:New():FilterPrefixes( { "REDEWR" } ):FilterStart()
Detection = DETECTION_UNITS:New( DetectionSetGroup )

A2ADispatcher = AI_A2A_DISPATCHER:New( Detection )
A2ADispatcher:SetTacticalDisplay( true )

A2ADispatcher:SetGciRadius( 74080 ) --40nm
A2ADispatcher:SetEngageRadius( 60000 )
A2ADispatcher:SetDisengageRadius(110000)
A2ADispatcher:SetIntercept( 120 )

A2ADispatcher:SetDefaultTakeoffFromRunway()
A2ADispatcher:SetDefaultLandingAtRunway()

A2ADispatcher:SetSquadron( "NCK", 'Nalchik', { "RED_GCI_MIG23" } )
A2ADispatcher:SetSquadronGci( "NCK", 900, 1200 )

[chrisofsweden]

@Delta-99 @FlightControl-User

Ok fellas. I found the bug (maybe not a bug?). So, in my mission where units were detected even behind terrain masking, the EWR groups consisted of 3 units. 1x EWR 55G6, 1x SA-3 Launcher, 1x SA-3 Tracking Radar.

It seems the SA-3 Tracking Radar never "undetects" a spotted target. Removing the SA-3 Tracking Radar from the EWR Group, makes terrain masking functional again.

So, a tip for documentation perhaps, for now, only use a single EWR Unit per EWR Group in the EWR network connected to the Detection object. Have separate groups if you want defensive units around the EWR.

I'll leave it up to you if you want to investigate further if this is a DCS detection bug with the SA-3 TR or a bug with how the detection object works with SET_GROUPS with multiple units in them.

[Delta-99]

Really good debugging work and report. This is the kind of thing thing that makes it much easier for the devs to analyze. I’m going to guess this is a DCS bug but will leave it the FC to see what he can determine.

[FlightControl-User]

Hi guys, Chris, thanks for this. I am now preparing the release which is a lot of work. Next week I'll be in touch on this.

[chrisofsweden]

Thanks, np! Yeah, I have less hair now as I tore most of it out during testing lol, but at least I can terrain mask now :)

[baluballa]

Seems like a happy ending, closing.