I think it would be good to document the current thing
It's better to release something that has some simple feature than nothing

Before the first release of the plugin, a documentation should be written. This would cover the details of various dependencies and strategies, as well as how to create your own.

The name "dependency" is very misleading, given the context in which they are used. Renaming them to tasks would be much more intuitive.

While state machines are useful for helping the bot determine how to correctly perform a specific task, it may be also useful to create a graph transversal option for solving more complex actions in order to pass a series of options to the state machine to perform. Imagine a set of gameplay mechanics that were represented as nodes within a high dimensional graph. (This graph would be procedurally generated based on known mechanics within the game) Each mechanic would have its own node and all connected nodes where other mechanics that are related. By performing a search algorithm on this graph, the bot could theoretically write down a various set of paths of mechanisms to use in order to achieve a specific result. This path can then be transformed and passed to the state machine for execution.

For example, imagine the bot was given the goal of collecting grass blocks. It would start looking at the grass block node and discover information on what biomes contain it, what blocks drop it when broken, what mobs drop it when broken, etc. The bot could then do a more in-depth search, jumping from node to node, in order to determine that the grass block can be obtained by using silk touch on a grass block. It could also be obtained by killing an Enderman holding it. It would also be obtained by breaking a grass block by holding a silk touch enchantment book. After coming to this conclusion, it would then continue the search for how to obtain silk touch, how to kill an enderman, how to get the enderman to pick up blocks, etc.

Tasks should be able to configure how the solver approaches solving the task as well as children of that task as needed. This could in theory help with solving specific tasks with a more appropriate algorithm. Such as using A* to solve movement related tasks, request greedy reactions where computation time is more sensitive, or think steps out much further ahead where quality is more important than computation time.

This is a collection of common goals that can be provided to the plugin for the bot to achieve. The purpose of this issue is to direct a roadmap to implement the base functionality of the plugin. Feel free to comment on more suggestions below.

Goals

Low Level

• Collect Item Drop
• Collect Block
• Select Correct Tool while Mining
• Craft Item
• Determine Block Drops
• Kill Entity
• Create Tool to Harvest Block
• Use Anvil
• Enchant Item
• Use Grindstone
• Use Furnace

Medium Level

• Build a Mineshaft
• Find Ore
• Collect Food
• Store Items In Chest for Later
• Hunt Mob Type
• Basic PVP (Sword, Shield, Bow, Armor)
• Light Area to Stop Mob Spawns
• Bookshelves around Enchantment Table
• Sleep at Night

High Level

• Travel Between Dimensions
• Locate Stronghold
• Build Simple Structures
• Kill Enderdragon
• Advanced PVP (Crystal Aura, Enderperls, Health Potions, Escape Routes)
• Max Tier Tool Enchanting

Additional Considerations
These are likely to be made into separate add-ons

• Structure Design and Planning
• Large-Scale Structure Building
• Item Farms
• Chat based functions

Since the algorithm had an extremely heavy focus on working with making strategies to do nearly anything, it's essential to make the API for writing custom strategies as smooth as and quick as possible. Ideally, simple strategies should be written in only a handful of lines.

This builds onto #15.

Given the nature of tasks, it might be often useful to pass groups of tasks to the solver rather than one at a time. In the case or orderless dependencies, the order in which these are handled does not matter. Additional arguments could be made for optional dependencies which only should be executed if they are expected to reduce the overall cost of the tree. Another instance of this could be "or-able" tasks, where only one needs to be handled, but the exact one doesn't really matter.

While these situations can be implemented through the use of helper strategies, it would be better to build these directly into the solver in order to achieve better search results during execution and reduce the cost of the tree.

Allow for multiple dependencies to be passed to the solver at once, where the order in which the tasks are executed is not important. This would allow for the solver to optimize the route in which these tasks are handled.