search

FlightControl-Master / MOOSE

Mission Object Oriented Scripting Environment (MOOSE) for lua mission scripting design in DCS World
http://flightcontrol-master.github.io/MOOSE/
GNU General Public License v3.0
291 stars 95 forks source link

TSK-A2G DISPATCH FAC detection accumulates tasks #480

Closed d0o0m closed 7 years ago

d0o0m commented 7 years ago

Example: 5 enemy groups therefore 5 BAI tasks identified. MP clients move in on TASK BAI001. Clients engage BAI001 while FAC overflies. HQ reports a new task identified and reports new task (same target group as BAI001 as CAS001. Now reporting 6 tasks (when there is only 5). Destroyed TASKs not removed from F10 menu.

FlightControl-User commented 7 years ago

OK! I understand and thanks for describing the scenario. Will try this at home ...

FlightControl-User commented 7 years ago

Heum.... Thinking about it. This is a consequence of the logic and it is not easy to solve.

What the logic does is the following. It detects at regular intervals for targets. Once the targets have been detected and grouped, they will be provided to the A2G dispatcher. The dispatcher will analyze the grouped items and will create a SEAD, CAS or BAI. It will remove any obscolete tasks.

Typically, a CAS task is generated where there are friendlies (your coalition) within 6km from the detected targets. If there aren't any friendlies within 6 km, then a BAI task is generated.

Now, the problem as you describe is well documented. Initially a BAI task was generated and is currently assigned to a group. So, when the FAC is overflying (which is a friendly), it is detecting now a CAS task instead of a BAI task, because a friendly is nearby within 6km. It cannot find the CAS task, and thus creates one.

The BAI task will remain and won't be deleted, because that task is assigned.

What i need to do, is, i need to check the ID of the DetectionItem. If the ID of the DetectionItem is already associated with a task, then i should not create a new one, regardless of the kind of task it is engaged with.

Now I am going to have a careful look at the logic to see what I can do here...

OK... The problem is because i am searching for the Task by name, while I should be searching them by ID. I need to set the Task equal to the ID of the DetectionItem. Then it can clearly compare apples and apples, because now i am comparing apples and pears.

Think I can fix this one.

Whiplash822 commented 7 years ago

Just my two cents. If the FAC is detecting friendlies within the 6km range where it once detected no friendlies and thus assigned a BAI task, would it not be better to upgrade the BAI task to a CAS task? The advantage I see in this logic is it could help when a client wants to prioritize their task. Visualize an advancing enemy front scenario where a CAS task would be considered a higher priority than a BAI task. As the mission plays on and a enemy group previously assigned BAI task has advanced and is now within 6 km of friendly forces I think it is reasonably valuable to upgrade that enemy group task to CAS status. After all what is the value of categorizing task task groups if not to establish some priority level.

However, if proven too difficult to code this logic I would prefer that task not be broken up into any category verses a single task being designated as both CAS and BAI status.

Again just my thoughts.

FlightControl-User commented 7 years ago

I have currently resolved this issue. Reworked the logic and it is much better now too. Will publish soon and let you all know.

FlightControl-User commented 7 years ago

Fixed issue with pull request #483

-- The A2G dispatching logic has been reviewed. -- There is now a direct link between the Detection ID and the Task in the A2G_TASK_DISPATCHER.