Matrix Games Forums

Forums  Register  Login  Photo Gallery  Member List  Search  Calendars  FAQ 

My Profile  Inbox  Address Book  My Subscription  My Forums  Log Out

[Logged] Ship-Subs detection trigger gen inconsistencies

 
View related threads: (in this forum | in all forums)

Logged in as: Guest
Users viewing this topic: none
  Printable Version
All Forums >> [New Releases from Matrix Games] >> Command: Modern Operations series >> Tech Support >> [Logged] Ship-Subs detection trigger gen inconsistencies Page: [1]
Login
Message << Older Topic   Newer Topic >>
[Logged] Ship-Subs detection trigger gen inconsistencies - 1/16/2021 6:54:23 AM   
KnightHawk75

 

Posts: 1244
Joined: 11/15/2018
Status: offline
So I think I've found some issues with detection triggers that I've been seeing crop up every so often since launch day but couldn't always reproduce in a given complex scene. Below is a sample from efforts to show where problems\inconsistencies exist in a way that at least on my system are mostly reproducible.

There may or may not be issues with fixed,aircraft and fixed-mobile to some extent as well, but they are not the focus of this post, just ships and subs.

Testing Setup: (focus on the Gulf of Mexico, ignore the rest.)
Sides are Red (computer side we are detecting) and Blue (detector)
Red: 9 units - 1 each of a CVN, DDG, SSN, oil platform, surveillance platform, wreckage, life raft,USV,UUV)
Blue: 1-2 units doing the detecting (1 f-35,kitted with multiple radars. only those indicated on a run are enabled. 1 b-1b ibs for the 2 unit test)
Events setup:
 Event -> Trigger -> Action (lua script)
 Dump_All_Red_Detections_Level0 -> DetectAnyRedUnitAnyLevel0 -> DetectionAnyRed0
 Dump_All_Red_Detections_Level1 -> DetectAnyRedUnitAnyLevel1 -> DetectionAnyRed1
 Dump_All_Red_Detections_Level2 -> DetectAnyRedUnitAnyLevel2 -> DetectionAnyRed2
 Dump_All_Red_Detections_Level3 -> DetectAnyRedUnitAnyLevel3 -> DetectionAnyRed3
 Dump_All_Red_Detections_Level4 -> DetectAnyRedUnitAnyLevel4 -> DetectionAnyRed4
Basically each event says if you detect anything Red, at level X, invoke snippet X
The action scripts are very simple and just call a central function noting who is calling, and the trigger level involved, and does it's own contact state management for help in comparisons. The point of the messages are to pause and help compare at any given point in time what transpired recent with what generated events, and the 'state' so to speak of the actual contact record. All you really need to know for this test setup is _Any_ detection\level changes that generate a trigger should\will generate a message.

Attached is a zip with 4 sub folders associated with 4 replays of basically the same thing with slight variations of the same setup, netting someone different results among them. Also fwiw included are sample game logs from the play-through and associated lua log.

What follows is a basic play-by-play of my playing through each scene for the 5-7min mainly at 1x or 2x speed, as detection proceeds to conclusion on all units. If you want to use 5x speed at times it should make no difference, and each scene has been played at least 5 times without any change in results with the exception of scene #4 where the exact outcome is variable but basically goes one of two\three ways regardless of slight timing variations.

I'd like to see if anyone replaying these, especially the first 3 can repo the same results I keep getting.
Most of what follows is overly verbose and repetitive, but I felt more detail was important including the boring parts where things "work as expected" because in some cases it highlights where they do in one scene but may not in another. Anyone wanting the TLDR can skip to the end, brevity is not my strong suit.

W A E is used as short hand for Works As Expected in case it's not obvious to anyone, the longer I was doing this the shorter my short-hand was getting. :)

-----------
1 AGP-81 run TestRig_DetectTriggersMissLevels_1147-16_db487_ShipSub_APG81_StdRun.scen
-----------
4:00:01 - 18 triggers fire
  . 9 as designed for detection unknown [works as expected]
  . 9 for classification level 1 on those 9 contacts. [works as expected]
  . 9 entries are present in the message log noting the new contacts and level 1 status. [works as expected]

4:00:04 - 2 triggers fire
  . 2 contacts (DDG and CVN) are classified level 2, the 2 triggers are properly invoked for this. [works as expected]

4:00:07 - 7 triggers fire;
  . 4 for the CVN and DDG (1 each for the level3, 1each for level 4) [trigger works as expected even with the classification 'jump']
  . 3 for the skunk #124\#125 contact going from level1 to level2 (platforms) and the skunk#126 going from level 1 to level 2 civilian [works as expected]
  . * However only 5 entries are in the message log; 2 for the DDG and CVN level4 positive id, and 3 for the level2 detections.
  . * Note the message log is missing the 2 "identified" messages for the level 3 DDG\CVN detections.
  . I don't know if that's considered a 'feature' to only note the final status during that second\pulse or not.
  . my initial opinion was they should generate entries though, if for no other reason than to match the detection trigger and for debugging purposes. That said I recognize it does reduce log 'spam' and perhaps is intended.
  . ** Also even though the triggers run for level 3 and 4 when jumping from 2. Detection level 4 triggers are running before level 3 at least on my system. This can be seen in the messages by taking note of the "caller:" and the "lastTriggeredState:", and "detectionlevel" fields. My evidence for that is DetectionAnyRed3 if called first should read 2, and DetectionAnyRed4 should read 4 (having been updated by DetectionAnyRed3 to 4 already if it had
actually run first). Instead DetectionAnyRed4 reads 2, and DetectionAnyRed3 reads 4. ?? Is it possible in the code for that case things are fed in reverse order by mistake?

4:00:08 - 5 triggers happen.
  . 1 for a skunk#127 going from level1 to level2 (Civilian #127) [works as expected] recorded in the log. [works as expected].
  . 1 for civilian #126 going from level2 to level3 (life raft) and recorded in the log. [works as expected]
  . 1 for skunk#125 going from level1 to level2 (civilian), and recorded in the log. [works as expected]
  . 2 for each each of platforms #123\#124 both going from level 2 to level 3 classifications and recorded in the long. [works as expected]

4:00:10 - 1 trigger happens, * 1 trigger is not generated.
  . 1 for the Civilian#127 going from level2 to level3 - ProtectorUSV [works as expected]
  . * 1 If you check the message log and the gui you will see that goblin#120 goes from level1 to level2 (SSN). This did not generate a trigger. [does not work as expected]

4:01:20 - 1 trigger happens.
  . 1 for Civilian#125 going from level2 to level3 Floating Wreckage.[works as expected]

4:02:10 - No trigger happened when one should.
  . * Goblin #128 goes from level 1 to level 2 UUV, it does not generate a trigger, it is however recorded in the log. [does not work as expected]

4:02:41 - 2 triggers happen, at least 1 trigger if not 3 are not generated.
  . 2 for the Fixed#129 being detected at all, and then being detected at level 1. [this part works as expected]
  . * However note that while you are still on the special message screen, mouse over it in the gui,
the new ground contact is already positively identified at level 4, positive id Red_VL_Hanger. Not only did it not generate a level 4 trigger, it didn't generate the intermediate level1->2 or 2->3 triggers. Expected is all 3 events (2,3,4).
  . * Additionally there is no log entry in the contact change log for a level2,level3, or even the final level4 positive id on this contact.

-- everything from this point forward works as expected in this run.--
4:02:47 - 1 trigger happens.
  . 1 Platform#124 goes from level3 to level4 Red_SPlatform_B. this is noted in the msg log [works as expected]

4:03:07 - 2 triggers happen.
  . 2 one each for Platform#123 and LifeRaft#126 respective go from level3 to level4 and are recorded in the msg log. [works as expected]

4:03:37 - 1 trigger happens.
  . 1 for floating wreckage#125 going from level 3 to level 4 and is recorded in the msg log. [works as expected]

4:04:37 - 1 trigger happens.
  . 1 for USV Typhoon#127 going from level 3 to level 4 and is recorded in the msg log [works as expected]

4:07:27 - 1 trigger happens
  . 1 for UUV#120 going from level 2 to level 3 OrcaXLUUV, and is recorded in the msg log. [works as expected]
4:07:37 - 1 trigger happens
  . 1 for SSN#120 going from level 2 to level 3,SSN 802 Oklahoma and is recorded in the msg log. [works as expected]
---

--
-- instances #1-5 ran the same.
--

Run observations:
Classification change for units of type Ship, which involved "Jumps", trigger events properly, but do not trigger associated intermediate log messages. Classification changes for units of type Submarine from lvl-1 to lvl-2 while noted in the log did not properly generate trigger events. The Fixed-Facility contact while unlike the submarines could be detected at level 4, never generate a level 4 trigger, and do not generate intermediate triggers or log messages, particularly when "jumping" detection state (can kind of put this aside for now, will report separately). Detection jumping from 2 to 4 are cause the level 3 and 4 triggered to be processed out of logical order. Other than that things work as expected with ship and subs in this run anyway, even when things "jumped" state they generated the proper triggers.


--------------
2 AGP-83 run TestRig_DetectTriggersMissLevels_1147-16_db487_ShipSub_APG83_StdRun.scen

(used to simulate faster and more simultaneous generation of events.. you could do that may ways, I chose the single aircraft + \different\multiple radars for simplicity\consistency in demonstration)
--------------

4:00:01 - 18 triggers fire
  . 9 as designed for detection previously unknown [works as expected]
  . 9 for classification level 1 on those 9 contacts. [works as expected]
  . 9 entries are present in the message log noting the new contacts and level 1 status. [works as expected]

4:00:03 - 18 triggers fire
  . 9 triggers fire for the level 2 detections. INCLUDING the OrcaUUV and SSN which in the first run did not generate a level2 triggers. [W A E]
  . 9 triggers fire for the level 3 detections. [W A E]
  . * of note the jumps from 1 to 3 here fired in order (ie level2 ran before level3 correctly).
  . 9 messages in the log indicate the classification change to level 3. [W A E? *]
  . * Again I don't know if it's by design\intention or not to suppress the level 2 log messages here?

4:00:07 - 2 triggers fire
  . 2 for the CVN and the DDG going from level3 to level4. [ W A E ]

4:02:41 - 2 triggers fire
  . 2 for the Fixed#129 contact for unknown and then level 1. [W A E]
  . * However note while paused in the gui the contact has been positively identified.
  . * No events are generated for the level2,level3, or level 4 upgraded classification. [Does not work as expected]
  . * No messages are logged of the upgraded classification (either level4 or the intermediate levels in the jump). [does not work as expected]

-- rest all works as expected
4:02:47 - 1 trigger fires
  . 1 for the platform#124 going from level3 to level4 Red_SPlatform_B. [W A E]

4:03:07 - 2 triggers fire
  . 2 for the liferaft and the oil platform going from level3 to level4. [W A E]

4:03:37 - 1 trigger fires
  . 1 for the floating wreckage going from level3 to level4. [W A E]

4:04:37 - 1 trigger fires
  . 1 for the USV going from level 3 to level 4. [W A E]
---

--
-- instances #1-5 ran the same.
--
* You can re-run the above with agp-83 sabr-gs disabled and apg-83 sabr enable and get the extact same results.

Run observations:
Ignoring the fixed facility issue everything else worked as expected. Unlike the first run the sub detection level 2 events were generated when they jumped detection state going from level 1 to level 3. Unlike "jumps" from 2->4 jumps from 1->3 do seem to fire in logical order as expected.


---------------
3 APG_Multi run TestRig_DetectTriggersMissLevels_1147-16_db487_ShipSub_APGMulti_StdRun.scen
(AGP-81,82,83,83gs as stand in for multiple aircraft)
---------------
4:00:01 - 18 triggers fire
  . 9 as designed for detection previously unknown [works as expected]
  . 9 for classification level 1 on those 9 contacts. [works as expected]
  . 9 entries are present in the message log noting the new contacts and level 1 status. [works as expected]

4:00:03 - 18 triggers did not fire
  . 9 entries in the msg log indicate that all 9 contacts have gone from level1 to level3 classification. [W A E ?*]
  . * 9 entries in the msg log are potentially missing for the level 2 state...unless again it's by design they are being skipped.
  . * 9 triggers DID NOT fire for the level 2 detections [does not work as expected or previously seen, even when 'jumping']
  . * 9 triggers DID NOT fire for the level 3 detections. [does not work as expected]

4:00:07 - 2 triggers fire.
  . 1 for the CVN going from level3 to level4. [W A E]
  . 1 for the DDG going from level3 to level4. [W A E]
You can see in the messages the last trigger recorded prior to this one for both contacts was level1, confirming level2 and level3 never got generated.

4:02:41 - 2 triggers fire
  . 2 for the fixed facility #129 being detected and also for going to level 1. [Does not work as expected.]
  . * same note as other runs about facility jumps missing detection events and logging.

---rest all work as expected
4:02:47 - 1 trigger fires
  . 1 Platform goes from level3 to level 4. [W A E]
You can see in the message the last trigger state record prior to this one was level1, indicating 2 and 3 were not generated.

4:03:07 - 2 triggers fire
  . 1 both for the oil platform, and the life raft going from level3 to level 4. [ W A E]
You can see in the messages the last trigger state record prior to this one was level1, indicating 2 and 3 were not generated.

4:03:37 - 1 trigger fires.
  . 1 for the floating wreckage going from level3 to level4. [W A E]
You can see in the messages the last trigger state record prior to this one was level1, indicating 2 and 3 were not generated.

4:04:37 - 1 trigger fires
  . 1 for the USV going from level 3 to level 4. [W A E]
You can see in the messages the last trigger state record prior to this one was level1, indicating 2 and 3 were not generated.
---

--
-- instances #1-5 ran the same.
--
* Fun fact, if you rerun that test with the agp-83 sabr disabled but the apg-83 sabr-gs still active you will get 18 triggers as expected at 00:03. That makes no sense as short of range and a little power they are basically the same db cat\role\capability\code wise. But I digress.

Run observations:
In this run with multiple sensors operating, all level2 and level3 triggers failed to be generated on all ships and subs, however the level3 detections were noted in the message log. Also the fixed facility issue but again that's a constant.



------------------
4 APG_2Unit run TestRig_DetectTriggersMissLevels_1147-16_db487_ShipSub_APGMulti_2UnitRun.scen
(2 units std f-35 1 AGP-81,std b-1bibs 1 83gs)
------------------

--
-- instances #1,#3
--
4:00:01 - Same as always
4:00:04 - 2 triggers fire
  . 2 contacts (DDG and CVN) are classified level 2, the 2 triggers are properly envoked for this. [works as expected]

4:00:07 - 7 triggers fire
  . 4 for the CVN and DDG (1 each for the level3, 1 each for level 4) [trigger works as expected even with the classification 'jump']
  . 3 for the skunk #124\#123 contact going from level1 to level2 (platforms) and the skunk#126 going from level 1 to level 2 civilian [works as expected]
  . * However only 5 entries are in the message log; 2 for the DDG and CVN level4 positive id, and 3 for the level2 detections. see run 1.
  . ** However even though the triggers run for level 3 and 4. Detection level 4 triggers are running before level 3 at least on my system. as already mentioned in similar remarks for run 1, so I will not repeat full detail.

4:00:08 - 5 triggers happen
  . 1 for a skunk#127 going from level1 to level2 (Civilian #127) [works as expected] recorded in the log. [works as expected].
  . 1 for civilian #126 going from level2 to level3 (life raft) and recorded in the log. [works as expected]
  . 1 for skunk#125 going from level1 to level2 (civilian), and recorded in the log. [works as expected]
  . 2 for each each of platforms #123\#124 both going from level 2 to level 3 classifications and recorded in the long. [works as expected]

4:00:10 - 1 trigger happens, * 1 trigger is not generated.
  . 1 for the Civilian#127 going from level2 to level3 - ProtectorUSV [works as expected]
  . * 1 If you check the message log and the gui you will see that goblin#120 goes from level1 to level2 (SSN).
This did not generate a trigger. [does not work as expected]

4:00:13 - 4 triggers happen
  . 1 for Civilian#125 going from level2 to level3 Floating Wreckage.[works as expected]
  . 2 for Goblin#128 going from level 1 to 2, then from 2, to 3 Orca UUV. [W A E - minus the aformentioned jump no-log-intermediate issue]
  . 1 for the SSN going from level 2 to level 3 Oklahoma. [works as expected]

4:02:41 - 2 triggers fire
  . 2 for the Fixed#129 contact for unknown and then level 1. [W A E]
  . * However note while paused in the gui the contact has been positively identified.
  . * No events are generated for the level2,level3, or level 4 upgraded classification. [Does not work as expected]
  . * No messages are logged of the upgraded classification (either level4 or the intermediate levels in the jump). [does not work as expected]

-- everything else works as expected
(bunch of things go from level 3 to level 4 on the same schedule as APG_83 runs)

--
-- Instance #2 of the above ran different
--
4:00:01 - same as always
4:00:02 - 2 triggers.
  . CVN + DDG 1->2 (1 event generated for each).
4:00:07 - 14 triggers
  . CVN + DDG 2->4 (4 events generated; for lvl3 and lvl4 out of order)
  . Platform|SPlatform|Raft|USV 1->3 (8 events generated as expected)
  . * UNLIKE ever other time even though there is a jump lvl2 detections ARE detailed in msg log. (this happen because different sensor doing each? would make sense)
  . Wreckage and SSN 1->2 (events generated as expected)
4:00:09 - 4 triggers
  . Wreckage 2->3 (1 event generated)
  . ORCA from 1->3 (2 events generated, only 1 in the msg log)
  . SSN from 2->3 (1 event generated)

.. rest happens on timeline of AGP_83 runs with same results.

--
-- Instance #4 of the above ran different:
--
4:00:01 - same as always
4:00:02 - 2 triggers.
  . CVN + DDG 1->2 (1 event generated for each).
4:00:06 - 12 triggers.
  . SSN + Wreckage 1->2 (2 events generated)
  . CVN|DDG 2->3 (2 events generated)
  . Platform|S-Platform|Raft|USV 1->3 (8 events generated in order, no logging on lvl2 all same sensor)
4:00:07 - 2 triggers
  . CVN|DDG 2->3 (2 events generated)
4:00:08 - 4 triggers
  . Wreckage 2->3 (1 event generated)
  . ORCA from 1->3 (2 events generated, only 1 in the msg log)
  . SSN from 2->3 (1 event generated)

..rest happen on timeline of AGP_83 runs with same results.


--
-- instance #5 of the above ran different:
--
4:00:01 - same as always
4:00:02 - 12 triggers. SSN + Wreckage 1->2 (2 events generated), DDG|Platform|S-Platform|Raft|USV 1->3 (10 events generated in order)
4:00:04 - 1 triggers CVN from 1->2 (event generated).
4:00:05 - 2 triggers SSN+Wreckage 2->3 (events generated)
4:00:07 - 3 triggers DDG from 3->4 (event generated) CVN from 2->4 (2 events generated - out of logical order)
4:00:15 - 2 triggers orca from 1-3 (2 events generated and in order)
4:02:41 - 2 triggers for the hanger,etc,ect.
4:02:47 - 1 trigger s-platform 3->4
..rest happens on timeline of AGP_83 runs with same results.

[Note] APG_Multi_2Unit ran different during different executions mostly 4 outlined. What causes that idk, I guess some level of randomness related to who's sensors get processed first or maybe some thread scheduling difference causing the change. What this means is you may have to run it a couple times to get any one of at least the 4 variants noticed (though #4 and #5 are not really much different), I didn't see any other variants but that doesn't necessarily mean they do not exist.
-------------------------------------------------------------------------


My preliminary conclusions:
1. When the same sensor in the same pulse\second causes a 'jump' in detection level (1-3,2-4,1-4) in observed cases there is a log entry for the highest classification only. In some cases (for non-facilities) the log entry will generate if separate units\sensors make different level detection in the same pulse\second (ie sensor one classifies at level 22 sensor two then reclassifies at as 3).
2. Detection triggers at level unknown (we'll call it 0) and level 1 work consistently in these and other tests.
3. Detection triggers at level 2 involving at least units of type sub or ship depending on the circumstances can fail to generate events. It's not immediately clear what those circumstances are or can be.
4. Detection triggers at level 3 involving as least units of type sub (or ship while more rare) depending on the circumstances can fail to generate events. It's not immediately clear what those circumstances are or can be.
5. Detection triggers at level 4 for ships appear to always work and from best I can tell always generate a log entry, lower levels may not generate entries depending on circumstances, those range from separate sensors doing different classification in a cycle, and when only a singular detection step occurs in the cycle.
6. Detection triggers for ships that jump from level 2->4 do no generate events in order. Generates the level 4 event then the level 3 event.
7. Detection triggers at level 2 or above never generate for a fixed-facility unit, at least not when jumping 1->4. Nor do they get logged even though they clearly occur. They also appear at least in these and some other tests to always jump from level 1 to level 4. (separate tech support post about this )
8. Subs are not detectable at level 4. Mobile-Facilities are not detectable at level 4. (separate topic\issue)

Other thoughts.
When #2 or #3 happen at first I was thinking sensor specific perhaps, but there are cases where one sensor will generate a trigger, and cases where the same may not under different situation (APG-83 non-gs replay APG-83 run with sabr-gs disabled and regular enabled it doesn't miss the 00:03 9 triggers but playing on APG_Multi it makes the same detections but does not generate the triggers. On the flip side the EOTS for example if disabled(marked destroyed) in the first test (APG-81) while it changes when things are detected by the unit (using the gorgon stare instead) it does remove the 2 instances of failed to generate triggers. So I'm a little stumped about that as in both cases detections are are made and logged just triggers aren't generated.


Attachment (1)

< Message edited by Rory Noonan -- 1/18/2021 12:00:51 AM >
Post #: 1
RE: Ship-Subs detection trigger gen inconsistencies - 1/18/2021 12:00:34 AM   
Rory Noonan

 

Posts: 2816
Joined: 12/18/2014
From: Brooklyn, NY
Status: offline
0014351

_____________________________


(in reply to KnightHawk75)
Post #: 2
Page:   [1]
All Forums >> [New Releases from Matrix Games] >> Command: Modern Operations series >> Tech Support >> [Logged] Ship-Subs detection trigger gen inconsistencies Page: [1]
Jump to:





New Messages No New Messages
Hot Topic w/ New Messages Hot Topic w/o New Messages
Locked w/ New Messages Locked w/o New Messages
 Post New Thread
 Reply to Message
 Post New Poll
 Submit Vote
 Delete My Own Post
 Delete My Own Thread
 Rate Posts


Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI

1.906