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.
The pos and orientation sent is after transformations have
been apply, so in order to set the correct entity transformation
we need to remove any external transformations from these values
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.
In order for this to work, we must always issue an Update
op after a Set op, so that we can handle any updated properties too.
We also have to add a new Entity flag to handle when the location
has been dirtied, since this isn't handled by normal properties.
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.
In almost all instances most properties will only be used
for a specific key. To make things easier and less error prone
we've introduced the trait "property_name", which when available
allows us to refer to a property only by class, and not having
to specify the key it's bound to.
This describes how entities should behave when they are put in the "planted"
specifically how they should be oriented and adjusted in vertical position.
When checking visibility, we now use the Domains more extensively.
The base rules are:
* If an entity is a child of a domain-less entity, visiblity for the
child is the same as for the parent.
* If an entity is a child of a domain-holding entity, visibility is
determined by the Domain.
* Entities cannot observe things above a Domain.
* Entities can observe things below a Domain, if the Domain allows it.
These rules are not yet set in stone. We need some more time figuring out
exactly how we want visibility implemented. We're striving for a balance
between a powerful but not too complex system, with good performance.
The Inventory domain is meant for all characters, i.e. those than can have
an "inventory".
It's a non physical domain, which means that entities contained in it won't
be affected by any physical constraints, or have physics applied to them.
Visibility for outside entities are by default forbidden unless an entity is
outfitted or wielded.
The idea is that other playes shouldn't see what's in the inventory of another
player, unless things are outfitted or wielded.
Calling "is_valid" checks whether the goal actually can be fulfilled.
If it can't be, False is returned.
By default all Goals return True unless a "validity" function is supplied
in the constructor.
For now we only use it for checking whether movement goals can be reached.
If the character wants to travel too far, we shouldn't try to map the whole
path straight away. Instead we'll cut down on the lenght, and increase the
acceptable radius.
This works since the AI will issue a new destination on its next Tick.
