Authoring clients can send a Think op, wrapping a Get op with a "path"
attribute to get information about the path. The mind code will then
send back a list of points for the path.
Every 30 seconds the thoughts are persisted to the server, by sending a
Think op which wraps a Set op with the name of "persistthoughts".
An improvement to this would be to only send these ops when the thoughts
actually have changed.
Instead of using separate Commune and Think goals depending on
whether we're querying for or setting thoughts we now instead solely use
the Think op. This op wraps another op, which is then used to determine
what to do. The ops that are supported are: Set, Get, Delete and Look
Think(Set): sets new thoughts and updates existing ones, if an id is
supplied.
Think(Get): get all or specific thoughts (replaces Commune)
Think(Look): inspects a specific goal
Think(Delete): deletes all or a specific thoughts (i.e. both goals and
knowledge)
Entities are references using a format of "'$eid:...'".
For example, an entity with id 2 would be references as "'$eid:2'".
This specific pattern is handled specifically by both the importer, the
exporter and the minds themselves, allowing for entities to be properly
restored with correct minds.
The way goals are authored is refactoed so that each goal gets assigned
an id. The client can then refer to this id when issuing both Think and
Commune commands. This makes it much easier for the client to properly
author the goals, independent of the "subject" they are attached to
(which is an Interlinguish construct which isn't relevant to direct goal
introspection).
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".
