This is mainly the force used to propel characters forward. I.e.
walking, running and so on.
For now it's not activated, since we rely on proper physics to be
implemented first.
This property tells how the entity should behave when put into
different modes. Currently we only allow for specific transformations
to occur.
The mode specifications are registed in properties where "mode-" forms
a prefix, and the mode a suffix. For example, "mode-planted".
This also does away with the "plantable" property.
Instead of directly setting position and orientation we've now
added a "transforms" property. This property contains zero or many
transformations. The result of these is what drives changes to an
entity's position and orientation.
By cleanly separate disrete transformations we can more easily undo
or alter them. This allows us to do things where the position or
orientation of an entity is affected by other properties, or other
entities.
The client protocol is intact. Changes to position and orientation is
still sent the same way, by specifying "pos" and "orientation". However,
these values will now not be written directly to corresponding values on
the entity. Instead they will first be written to the "transforms" property,
with the final values being a result of combining all data in the property.
We want to allow for archetypes with orientations, along with also
sending orientations in Create ops. To do this we need to combine
these two rotations into a final orientaton.
This describes how entities should behave when they are put in the "planted"
specifically how they should be oriented and adjusted in vertical position.
Though we need to alter the way the MindProperty requests possessions,
as we don't want to generate possession requests for anything that's
handled by a client anyway. Problem right now is that we won't know that
at the time of MindProperty being applied.
We now register a an external mind with the ExternalMindsManager and
then let the manager make sure that there's an external mind connected.
When the external client is disconnected the manager will try to find a
new client to handle the mind.
The idea is that the aiclient runs in a separate process and handles all
AI functionality.
This is done by having a "possession" client which recieves possession
requests from the server, and spawns new AI clients for each request.
When a signal is caught we want to exit from the boost::asio loop.
However, we can't do this by pusing another handler onto the io_service,
since this will involve a malloc call, and this can cause a deadlock (if
the signal handler is invoked from within a malloc call).
Therefore we instead need to use the signal_set functionality of
boost::asio, which guarantees that signal handling is done without
issue.
