Cleaning up the engine wiki. It had a page on behavior trees, which are somewhat in flux - unsure if doc should go in Pathfinding or Behaviors, so making issues for both and linking them. Duped by: Terasology/Behaviors#2 - pinging @synopia :-)

Original doc (make into Javadoc, readme file, or wiki elsewhere?):

TODO, copied from pathfinding module.

Nodes

Nodes are the core elements of a behavior tree. A node is a piece of code, that is run while an Actor is interpreting the behavior tree.

When run, every node must return one of this states: SUCCESS, FAILURE, RUNNING.

SUCCESS and FAILURE are returned, depending on the behavior node's task. If the task takes some time, a node may return RUNNING.

Decorators & Composites

Nodes may have child nodes assigned.
If a node accepts exactly one child, this node is called a Decorator. Such nodes add some functionality to another node, or subtree.
If a node accepts many children, this node is called a Composite. The order of the children is important, since a composite delegates execution to one of its children.
The three basic composite nodes are:

• Sequence - All children run after each other. Failing child will fail the sequence.
• Selector - All children run after each other. Succeeding child will succeed the selector.
• Parallel - All children run in parallel. When the parallel finishes, depends on its policies.
• Monitor - All children are executed in parallel. As soon as any child succeeds or fails, the monitor succeed or fail.

Some basic decorators are:

• Invert - Inverts the child's state.
• Timer - Stops time and finishes with given state after defined duration.
• Repeat - Repeats its decorated behavior forever.
• Delay - Delays the execution of its decorated node some time.

Actor and interpreter

A behavior tree can be assigned to be interpreted by several different minions. So, for each actor the tree has a unique state (state of timers, sequences, etc). This state is realized using a Task class. Instead of handling the actual work itself, a Node delegates its work to a Task class. So a node just create a Task for every actor, where the custom state data can be stored safely.

The tests that use HeadlessEnvironment are failing. (due to some changes made during the migration to gestalt-module v7)

Rather than fix HeadlessEnvironment, I recommend basing these tests on ModuleTestingEnvironment instead, so we don't have to maintain multiple testing-environment implementations.

Currently, 38 out of 40 tests fail with

java.lang.RuntimeException: Failed to find natives from .jar launch
at org.terasology.engine.paths.PathManager.<init>(PathManager.java:70)
at org.terasology.engine.paths.PathManager.getInstance(PathManager.java:121)
at org.terasology.HeadlessEnvironment.setupPathManager(HeadlessEnvironment.java:218)
at org.terasology.Environment.reset(Environment.java:53)

I suspect that this is related to the config change in build 105.

Woo first ever module repo bug report! :D

While fixing the Jenkins build for Pathfinding (wrong source job to grab artifacts from + older Java 7u21 didn't support static imports right in one case) I ran into the use of com.sun.xml.internal.ws.util.ByteArrayBuffer in FactoryTest.java which actually causes a failure to run tests locally for me and in Jenkins

Looks to be a good practice to avoid the com.sun packages. There's probably a simple replacement?

http://www.oracle.com/technetwork/java/faq-sun-packages-142232.html

Hoping the build will work after that.

I deleted the unique build.gradle here in favor of updating the template as Jenkins overwrites that version at compile-time anyway. Rather than introduce a unique one just update the template under modules/Core and do a "gradlew refresh"

Note that pulling the latest from Pathfinding with the existing unique build.gradle locally may cause the module to be ignored by Gradle (because it looks for a build.gradle to declare the module valid - but right after the deletion there would be none, so an updated copy isn't copied in!).

Just manually copy build.gradle from modules/Core this one time and it should work. Can even run "gradlew refresh" immediately after to see that work if you like :-)

Buggy Character Movement

Even though pathfinding has had improvements, and seems fairly stable at the point, the main issue with in game pathfinding, is actually moving along the path. Even fundamental nodes such as the MoveToAction node that pretty much all pathfinding behaviors use/depend on seem buggy. These lead to a plethora of quirks in game well described by Terasology/Behaviors#20

Vaguely remember kaen and I discussing how the prediction systems and delta values might having something to do with the glitch, so the Character Prediction System should be a good starting point. Could also have something to do with CPU usage.
There could also be a bug in kinematic character, specifically with the code dealing with extrapolation leading to all kinds of funny behavior.