Split taskqueuebehaviour in subfiles

[pandaro]

the idea is split taskqueuebehaviour in 2 files one new behavior for choice the factory. Here we insert all the builders that can build a factory, so we can have a indipendent bestfactory function and other related things.

[pandaro]

i start to work on this, but have some problem. the problem is that: i have write a first attempt: pastebin here i will build the factory, and the commander effectively build the factory, but the factory don't work. the the factory behavior tasks is yet inside taskqueuebehaviour, rising the function called inside taskqueuebehaviour i found that: self.progressqueue is ever nil because seems that unit.ID is nil inside function TaskQueueBehaviour:UnitIdle(unit) and some other incongruence. From this problem i deduced that i make somethings of wrong. Can you explain me what am I doing wrong?

Sorry but if i don't understand a bit better how some foundations work, i can help not much. thank you and sorry for this...

[eronoobos]

I don't understand the purpose of splitting building factories from taskqueuebehaviour. Just for code readability?

I'm not sure why the factory that the commander builds doesn't work. /give armvp in the console creates a working factory just fine, so I don't see how your behaviour would block that.

[pandaro]

I don't understand the purpose of splitting building factories from taskqueuebehaviour. Just for code readability?

not just for code readability: 1 performance improvements by use this only when the condition is coming and not every taskqueuebehaviour:update() calls. And for the same reason we can have a better and complex factory choice. 2 skip inconsistent and reverse filter: at the actual state we make all the process to chose a factory, after we have get a result, the result can be stopped by economic situation, duplicated orders, location problem or absence of helpers. Reversing, we will check eco, location, helpers and don't have duplications, starting a cleaning process of choice based on every necessary data and build a factory in a major clean way. 3 better readability but if you dont agree, no problem, this is only a issues and can be ignored. as an aside: as @tarendai suggested here

A separate behaviour that takes over from the task behaviour when it's deemed that a factory should be built, using whatever logic or system is desired

I'm just inspired by this conversation.

about this:

I'm not sure why the factory that the commander builds doesn't work. /give armvp in the console creates a working factory just fine, so I don't see how your behaviour would block that.

well this point is very strange to me, I keep getting inconsistent answers from my tests, ultimately the answer is that you pass the wrong argument to the TaskQueue of the factory: the builder have the "core" side and 'cannot build armcv' wtf i have break i don't know!

[tomjn]

There doesn't have to be one single way to decide to build a factory, or which one to build. So long as the resulting behaviour is effective. The original NTai had 3 scouting algorithms, each optimised for different things, and that worked well, 1 was great for scouting aircraft, another doubled up as an accidental raiding system ( if the scouter has a weapon, send it from mex spot to mex spot )

[eronoobos]

from https://springrts.com/phpbb/viewtopic.php?f=15&t=22582&start=760#p576049

It doesn't appear that the code that figures that out tracks where these areas are, it simply counts them. You'd need to modify maphandler to store the location/shape of these areas.

Untrue. maphandler stores the location/shape of mobility areas. That's how it has any idea what units can go where. The mobility areas that a potential factory location is within is a major deciding factor.

the builder have the "core" side and 'cannot build armcv'

It sounds like the problem is that the commander is arm, and the factory is core. Unfortunately, the side is decided for the entire AI, and not for each unit. (I should really change that.)

My main worry about another behaviour for building things is that taskqueuebehaviour has pause/resume functionality, which is helpful for building factories. This is to handle wardbehaviour taking over when construction units are in danger. If they were in the middle of construction, when the danger has passed they will return to that construction if it's still alive. Certainly this code could be duplicated in factoriesbuildersbehaviour, with some research (I've completely forgotten how it works).

regarding benefits 1 & 2: I think the filters in taskqueuebehaviour need to be refactored. Truly it makes no sense to perform all the taskqueue logic and afterwards throw out build orders based on economics. That's why you made taskEco.lua

[pandaro]

Untrue. maphandler stores the location/shape of mobility areas. That's how it has any idea what units can go where. The mobility areas that a potential factory location is within is a major deciding factor.

i have understand this in the past and now there is not problem about this.

It sounds like the problem is that the commander is arm, and the factory is core. Unfortunately, the side is decided for the entire AI, and not for each unit. (I should really change that.)

no no, the factory and the comm are core, the problem maybe was the point inside behaviours.lua where i insert the factories inside my new behaviour, is possible?

anyway for doing this new behavior is necessary a communication between taskqueuebehaviour and my new behaviour. So for now i will push my last innovation in taskqueuebehaviour

There doesn't have to be one single way to decide to build a factory, or which one to build. So long as the resulting behaviour is effective. The original NTai had 3 scouting algorithms, each optimised for different things, and that worked well, 1 was great for scouting aircraft, another doubled up as an accidental raiding system ( if the scouter has a weapon, send it from mex spot to mex spot )

I understand that you are in principle in favor of this splitting

[tomjn]

I've forgotten what the original thing was that I was commenting on when I said that, but I'm not keen on the idea of behaviour to behaviour communication. That's why I created the attackhandler module rather than having attackbehaviours communicate with each other. If a behaviour can't decide on its own what to do, it should refer to a higher power or yield control of the unit.

Perhaps if we state the problem and proposed solution again clearly, in my mind this would do the job:

• A module that helps pick a factory, and figures out if factories are needed
• A behaviour that communicates with the module and builds factories when they are needed
• A modification to the taskqueue behaviour to ask this module which factory it should build

The last one suggests that functions in task queues will need access to various AI objects. If so, they should be passed a copy of the ai object, which would allow them to talk to the module and ask if which factory to build.

Anyway apologies if I'm stating the obvious, but I think at some point my wires got crossed and a brain dump may reveal where that happened

[eronoobos]

I agree.

[eronoobos]

@pandaro after your modifications to taskqueuebehaviour, i think it would be sensible to move the functions having to do with factories to a module. i might combine that with what's currently in CheckForMapControl into a module called something like plans or brain. or maybe the factory functions should have their own module, factorybuildhandler, or something.

[pandaro]

I agree and will delegate the job I still have not fully understood all the steps for creating a new module

[tomjn]

@pandaro I've updated the docs at https://shard.tomjn.com/lua-documentation/modules/ and https://shard.tomjn.com/lua-documentation/modules/modules-lua/ that should clear up how you'd do that, I'll see if I can update one or two more pages while I'm there

[pandaro]

so, seeing that I was able to divide TaskQueue behavior once, well then I will do it again. my plain is this: 1 have a buildersBehaviour for mobile builders 2 have a factoryBehaviour for immobile builders 3 maybe in the middle have a handler what do you think it about?

[eronoobos]

What benefits do you have in mind?

Having two different behaviours is bit different from what you did before (outsourcing some of taskqueuebehaviour's algorithms to a module). I think a lot of code would be duplicated between the factory and builder behaviours

[tomjn]

It seems that the behaviours are doing the same thing, just with different decision making.

Instead, how about making it more generic:

• BuildRequestBehaviour that communicates with a module
• BuildRequestHandler that lists things that need building with an attached priority, a shared task queue of sorts, a construction job system
• BuildRequestGenerator a module that watches and generates requests based on the current economic status of the AI and its needs, e.g. factories, energy, etc

Thus we have a generic system for building needed things, a generic system for requesting something be built, and a module that makes decisions.

I envisage as the number of builders that are around increases, so does the priority of the BuildRequestBehaviour, such that we end up with a ratio of builders using task queues and builders doing odd jobs.

There will need to be these particular features:

• The both the task queue behaviour and the buildrequest behaviour will need to notify the BuildRequestHandler that they're about to build something, at which point the handler can ticket that job off the list else every builder will build the same thing even if only 1 is required
• BuildRequestBehaviour will need a function that looks in the queue of things to build and figures out if there's anything in there it can actually build. If there's nothing then it should set the behaviours priority super low and let other behaviours take control

It might be an interesting idea to let the priority of the first item that behaviour can build influence its own priority, so that taskqueuebehaviour units can take a short break to build a critical item. It's also tempting to have assist and repair tasks but that's feature creep