[aidden]

I think the TaskScript framework should only execute a single task each loop. Once it finds a valid task it should perform execute and then return the loop. What does everyone else think? An example being, right now my monk killer tries to loot, fails the interaction and then moves on to attacking the next monk and this happens quite often which is clearly not very human like.

 

[eagles13]

Support. I've had issues with this too. However I'll probably be demolished by someone more experienced.

 

[infinite inferno]

I think the TaskScript framework should only execute a single task each loop. Once it finds a valid task it should perform execute and then return the loop. What does everyone else think? An example being, right now my monk killer tries to loot, fails the interaction and then moves on to attacking the next monk and this happens quite often which is clearly not very human like.

You can add a condition within your Task so that it only proceeds to attack another monk if the loot item on the ground is not valid or the length == 0.

 

[aidden]

You can add a condition within your Task so that it only proceeds to attack another monk if the loot item on the ground is not valid or the length == 0.

While this is true, its not a good thing in my opinion. The whole point of dividing things up into tasks is to make each task focus on one thing. We shouldn't have to check that other tasks shouldn't be executing.

 

[infinite inferno]

While this is true, its not a good thing in my opinion. The whole point of dividing things up into tasks is to make each task focus on one thing. We shouldn't have to check that other tasks shouldn't be executing.

Technically you are not checking whether another task is executing, you are writing a condition for a particular task that will only execute when those particular conditions are true. The way i see the Task Framework is basically a series of executions where you (the scripter) create a set of rules for each particular task which do not correlate or clash with other tasks.

 

[arbiter]

I agree with OP. I can see multiple use cases in which the sequential order (or priority) of tasks is pivotal to its function and not returning to the top after an execution completely breaks it. @Cloud thoughts?

 

[aidden]

I agree with OP. I can see multiple use cases in which the sequential order (or priority) of tasks is pivotal to its function and not returning to the top after an execution completely breaks it. @Cloud thoughts?

It also currently goes against what you guys always say about each loop should only perform one action.

 

[arbiter]

It also currently goes against what you guys always say about each loop should only perform one action.

Very true. Sounds like an oversight in the framework to me.

 

[cloud]

Okay so here's how the framework will work in the next build. As most of you already know (or at least should), the task framework is built on a tree of tasks. This means that tasks can have children that are dependent on the parent tasks being validated.

Initially only the top level tasks will be checked for validation. As soon as one is found to be valid, it will be executed. All other tasks that could be evaluated will then be ignored (one task per execution). After this the child tasks of the validated task will be evaluated. This cycle will continue recursively until there are no tasks remaining to be validated or none of the tasks are considered valid.

In other words, TaskScript will attempt to follow a single branch of nodes out as far as possible, and as soon as it can't reach any further it will end the loop.

 

[qosmiof2]

I use this

for(Node node : nodeList) {
    if(node.activate()){
             node.execute();
  }


}

activate is a boolean.
execute is a void.

 

[cloud]

I use this

for(Node node : nodeList) {
    if(node.activate()){
             node.execute();
  }
}

activate is a boolean.
execute is a void.

Although a simple implementation like that would work for some people, the current TaskScript is a more powerful framework. It's a flexible tree, not just a list of tasks.

 

[aidden]

Okay so here's how the framework will work in the next build. As most of you already know (or at least should), the task framework is built on a tree of tasks. This means that tasks can have children that are dependent on the parent tasks being validated.

Initially only the top level tasks will be checked for validation. As soon as one is found to be valid, it will be executed. All other tasks that could be evaluated will then be ignored (one task per execution). After this the child tasks of the validated task will be evaluated. This cycle will continue recursively until there are no tasks remaining to be validated or none of the tasks are considered valid.

In other words, TaskScript will attempt to follow a single branch of nodes out as far as possible, and as soon as it can't reach any further it will end the loop.

Sounds good