Skip to content
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

Open
slogic opened this issue Feb 6, 2010 · 8 comments
Open

Task queues per Group #1

slogic opened this issue Feb 6, 2010 · 8 comments

Comments

@slogic
Copy link
Collaborator

slogic commented Feb 6, 2010

We need task queues per Group. May be in stack form. Only top of the stack can be executed currently.

@slogic
Copy link
Collaborator Author

slogic commented Feb 6, 2010

Then we can make amazing things with ease like upgrading MExes, building defences around new resources, reclaiming enemy MEx before building our own.

@Error323
Copy link
Owner

Error323 commented Feb 6, 2010

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.

@slogic
Copy link
Collaborator Author

slogic commented Feb 6, 2010

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?

@slogic
Copy link
Collaborator Author

slogic commented Feb 18, 2010

I wish not to separate ordinary move command into MoveTask until it will be TransportTask actually.

@snakeru
Copy link

snakeru commented Jul 15, 2010

Here is my implementation of queue. I do not like 'future_group' approach, but do not know how to do better.
http://github.com/snakeru/E323AI/commit/3a9549dccf1baeec9d4cba15d83ceb015684de41

@slogic
Copy link
Collaborator Author

slogic commented Jul 15, 2010

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.

@Error323
Copy link
Owner

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).

@slogic
Copy link
Collaborator Author

slogic commented Jul 15, 2010

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(). ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants