TASKING: Update assigned tasks to players

[FlightControl-User]

This is a requirement that has been raised by @mechanist to update tasks when they are assigned to players, depending on the emerging battle scene.

• [x] Add additional targets that have been detected as part of the detection to the assigned task.

• [x] Cancel the task if a change in task is required

• [x] Notify the players who are executing the task upon the task changes. For this a very welcome functionality to be used is the DETECTION "changed" texts that are automatically generated, informing in textual format the changes after each detection... X units added/removed of type Y ...

• [x] The menu consistency needs to be checked also as the task is evolving. It seemed that double menus were generated for the same task for the same group. This is wrong.

This will be the last addition from a functional perspective to release 2.2 before releasing.

[FlightControl-User]

Additional information from slack, copy/paste:

flightcontrol @mechanist: Ok. There is some more debugging work. This is the first real multiplayer test that I see after @dooom and @whiplash did their initial tests on A2G. Let us walk the pictures.... Pic 1: Ok Pic 2: How was deducted that the FAC detected other targets? Pic 3: Ok. Thinking... So you are assigned to the task... The dispatcher will only replace tasks after a change when they are in state planned. In this case, the task is assigned (to you), and there is one task process running for your client slot. Then your friend joins same task... I think I understand. So the task was not changed, your assignment to the task, that means. But the detection was. The 002 corresponds with detection zone 2. But it is decoupled. That means, at the moment the task is defined, it takes what it knows from the detection and creates a set of targets as the task goal. Your friend got a different set than you. So here we see a conceptual issue.. When a task is assigned, and the detection changes....

flightcontrol Option 1: The assigned players get new instructions. Each player gets their scope updated as more targets are detected. Option 2: The assigned players remain at their assigned "scope" of the task.... No new detected units get added.

mechanist
Option 1 sound good, also if the task type changes between BAI SEAD or CAS the players whom selected that task shall be informed about it.

flightcontrol True I did option 2... Wrong choice :) There was however a reason why I did 2... But can't remember anymore...

[FlightControl-User]

Now i remember why I did go for option 2.... Task classes are discrete processes, that means, they are defining the process, but not executing the process. Each task process needs to be executed for each client (player slot) that is alive. The reason is that routing and task updating (score, goals etc) are for the specific unit executing the task. Messages are sent to each specific group, location and status is for each unit different!

So, the current logic works as follows. When a player accepts a task, the task "template" is copied and becomes a task instance or a concrete process for the assigned player unit (client). As part of the task concrete process, the task targets are also defined, as well as the task type... In other words, when the dispatcher creates a task, it will create a BAI type of task when it wants to do that, and will define which targets are relevant for BAI. Same for SEAD, same for CAS. So, when a BAI task becomes a SEAD task, it may be that the task targets change completely (that is, the non-radar targets are removed)...

So my question is: a player that engaged for a BAI or CAS task, does he want to suddenly get a SEAD task assignment??? I guess not! He will abort the task and will be frustrated because he needs to jump into another unit. Correct?

[FlightControl-User]

@mechanist I have a suggestion:

• [x] 1. When new targets are detected but the task class does not change, the targets are added to the task. All the pilots get a confirmation of the changes. (edited)

• [x] 2. When new targets are detected and the task class changes (BAI->SEAD for example), I will send a cancel of the task, but with the message that the task has become obsolete and will be replaced with a new assignment task ... So the pilots executing the task will get a cancel... (edited) And this is logical, as first the area needs to be SEADED .... The pilots in the attack group may not have the payload airborne that is required. (edited)

If the pilot(s) want, they can always re-engage on the task using the menus. (edited) Also, this minimizes code rework for me!