The overwatch checks are called every time for every task in the stack. They are for emergency game state changes that are unanticipated. An example would be if your current task was a movetopos task, and you encountered an enemy on the way. Since a movetopos task should only be concerned with how to get from point a to point b, it should not be checking for aggro. Therefore the parent task has a check_for_aggro cne in its overwatch that adds a killtarget task if it detects aggro while the bot is moving somewhere. The name itself, 'overwatch', is a good indication of what its used for. Another example is for fleeing. Anytime we're in grind mode, we want to flee no matter what if we get below a certain hp threshold. So rather than add the flee cne to the process_elements for every task, we just add it once to the overwatch_elements of the grind task. Since it is the lowest level task it will 'overwatch' all of the subtasks above it on the stack.
Your understanding in the list seems to be sound. 2) is a bit complicated for reasons I mentioned above...attaching your cne to a task can be tricky since the static table for the task (ffxiv_task_grind, for instance) isn't really the task thats being executed when the bot runs...it's important to understand the distinction. An instance of that task is created. The reason we do it this way is that we may want to have two instances of the same task in the hub at the same time, which is a likely possibility if we were using multiple task queues. In that scenario, the task in one queue "sleeps" while the higher priority task is executed. So it's a likely possibility that both of those tasks might have a movetopos task, for instance. If we use the static task table, the data members will be overwritten by the second movetopos task. So that's why we create instances of the tasks rather than using the base task itself.
Your understanding in the list seems to be sound. 2) is a bit complicated for reasons I mentioned above...attaching your cne to a task can be tricky since the static table for the task (ffxiv_task_grind, for instance) isn't really the task thats being executed when the bot runs...it's important to understand the distinction. An instance of that task is created. The reason we do it this way is that we may want to have two instances of the same task in the hub at the same time, which is a likely possibility if we were using multiple task queues. In that scenario, the task in one queue "sleeps" while the higher priority task is executed. So it's a likely possibility that both of those tasks might have a movetopos task, for instance. If we use the static task table, the data members will be overwritten by the second movetopos task. So that's why we create instances of the tasks rather than using the base task itself.