idea for taskqueues

[eronoobos]

Rather than enumerating every unit and everything that it builds, and passing the taskqueue behaviour into the functions within the queue when we need to know things about the builder, what about this:

Generate a queue from a given unittype by iterating through every unittype it can build. This only needs to be done once. When generating the queue, for each unittype it can build, pass that unittype through a universal list of condition generator functions. These functions take a unittype and output a function that evaluates whether that unittype should be built. Rather than maintaining taskqueues, maintain these metaconditionals. The resulting queue of condtional functions acts just like a taskqueue.

It would be a lot of work of course.

[eronoobos]

made the system and three example metaconditions https://dl.dropboxusercontent.com/u/27597873/spring/taskqueuecreator.lua

CreateTaskQueue(unittype, metaconds) would be called whenever an unknown unittype tries to GetQueue. then it's stored in a table of known unittype taskqueues for future use.

it works, but not sure if it's worth converting everything. for one thing, the way metaconditions are written seems difficult to read

one advantage: it would replace categoryeconfilter completely. things would be filtered beforehand, and therefore reduce computational overhead. but that's already done with taskEco to a large extent

second advantage: more concise, generalized definitions. all of taskqueues could be replaced by maybe a couple dozen metaconditions?

third advantage: the side of the unit is already known. there is no if logic that needs to be done to create the right unit. it won't fail if the ai is given a unit of a different side

[pandaro]

i think is not a bad idea, but before spending time on it i will ask you some question: more concise generalized def: if you see at my taskEco and in things like ground metal converters for exampe, you can notice that parameters are different if builder are a commander if builder are lv1, if builder are engineer this is not casual: this prevent from have 10 units that build the same things at same time, the system is not perfect but reduce this problem. what i will say is: for automated i totally agree, cause autmatic setup raise us to rewrite something that change. But the system will not check only the unittype of the things to build but crossing with unittype of builder and other unittype available from the builder.

as an aside: for understand really good what you want do i need a concrete example maybe a pseudocode... if i don't ask to much .

[eronoobos]

decided not to use this. perhaps would be a good idea for a game-agnostic ai