-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Task queues per Group #1
Comments
Then we can make amazing things with ease like upgrading MExes, building defences around new resources, reclaiming enemy MEx before building our own. |
Agreed, this would simplify things. Also we would need to restructure tasks themselves into more primitive ones. For instant a mex upgrade should be composed of MoveTask, ReclaimTask, BuildTask in the priority queue. |
One problem is inherited from this one. Should this queue be like a transaction? I mean if one task fails the hole queue is failed? Or better mark them they belong to one transaction group so we can pus different group of tasks? Or better not to complicate things and make it as transaction? |
I wish not to separate ordinary move command into MoveTask until it will be TransportTask actually. |
Here is my implementation of queue. I do not like 'future_group' approach, but do not know how to do better. |
This is not true task queues. It is another hack. Error already made many hacks for faster AI release (he was working alone, also, imho, it was just proof of concept goal from his point of view), and now we faced with refactoring needs which everybody hates and which is very hard to implement because you have to rethink AI architecture in a way of less changes (thus less bugs) while reaching the goal. Task queues should come on ATask or/and CTaskHandler layer. Also note, that resouceScan(), enemyScan(), repairScan() are also hack procedures (repairScan() is my procedure, i was just following original design) because they are really parts of different tasks. |
The *Scan() are independent from taskqueues I think. Unless you want taskqueues to be able to run partially in parallel like some kind of behavior tree? There is no task queue that can satisfy both a resourceScan while planning a build (unless some tasks can run in parallel). |
Actually they are composed of behaviour and sets of target prototypes (preset instance of target filter class). Of course the latter can be used in other places. But we thought another way when there were no task queues. In target selection (CMilitary) there is too much similar to enemyScan(). ;) |
We need task queues per Group. May be in stack form. Only top of the stack can be executed currently.
The text was updated successfully, but these errors were encountered: