All tree code is now handle by Plant.cpp. However, this file is kept as
reference (it's of course still in Git, but people tend to never look
for it there if it's removed).
This goal will move a character close to something, and then keep the
character within a certain distance of this thing.
This is useful when you want the character to get close to something,
but then search for something else within the vicinity.
Also forget these after a while.
This makes sure that this goal doesn't result in the character getting
stuck on one thing. If used with the clear_focus goal the character can
instead move on to other things, and then return to the same thing after
a while after it's "forgotten".
This makes the NPC wander aimlessly within a specified series of
location. This is often more suitable than "wander", as that goal will
make the NPC wander over the whole map, which often isn't what you want.
The NPC will now wander randomly. However, this isn't completely
natural. The change in direction is too erratic. And the goal should be
expanded to stay within a certain area.
This can happen if the entity is in such a state that the location isn't
valid. We should handle it by consider the memory recall operation as
failed, but not as an exception.
Instead of treating a goal error as something which will make the entity
inactive, we instead allow for some errors (namely three currently) to
occur before the goal is deactivated. Any other goals are however
allowed to carry on even though one goal is faulty.
We also expose this through the goal_info query functionality, allowing
for world authors to better debug faulty goals.
One can specify both the "subject" and the "goal". If no "goal" is
specified, all goals for the "subject" will be queried. If no "subject"
is specified, all goals will be queried.
This is done in a way similar to how thoughts are queries. A Get op is
sent, containing a Goal_info op. The mind code is then responsible for
composing data about the goals, which is sent back to the client.
When a goal is set, the supplied 'object' can also be a list of strings
(i.e. a list of goals). All existing goals for the supplied subject will
be deleted. This allows for much better editing capabilities.
The goal code is a little messy, because we can't rely on looking into
the knowledge map for them, as the knowledge will only keep one goal per
subject.
In order to fix this we instead look for the goals in either "goals" or
"trigger_goals".
