Instead of having different properties for max size and max mass we now
only use a "max scale" property, and we only change the size of the
plant by altering the scale.
This is now the preferred way to change the size of any entity, instead
of editing the bounding box. The "scale" property is either uniform if
only one value is present, or in all dimensions if all three values are
present.
The property "planted_on_desired" can be used to tell an entity that it
should try to plant itself on a specific entity before it performs the
general planting tests.
This can be used to for example force planted entities to share a space
(such as multiple rocks being clustered when planted on the ground).
Instead of having it determined by sending looks ops.
It's a float value since there's a possibility to apply is as a factor
of the default view distance.
Entities that are "planted" on bodies of water are floating.
This does away with the "floating" mode.
To mark that entities should by default be floating when placed in
water the boolean property "floats" has been added.
Through the "water_body" property. An entity which has this is a water
body. If there's a bbox the entity is a lake (bounded), otherwise it's
an ocean (infinite bounds).
We've introduced the properties "speed-ground", "speed-water" and
"speed-flight" which specifies the top speed in m/s for each medium.
The "propel" attribute is now normalized, since it's multiplied with the
applicable top speed (depending on the medium, although currently we
only use the ground speed, TODO).
These properties didn't work out when we moved to a physics based world.
Instead we've introduced the properties "planted-offset" and "planted-scaled-offset".
These properties takes a float and specified vertical offset for planted entities.
Likewise with "planted-rotation" which specifies a rotation applied for planted entities.
"active-rotation" keeps track of any applied rotation.
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.
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 a player controlled entity is deleted, and the player currently
isn't controlling it, it's placed in limbo. When the player once more
connects and start controlling it, the entity is respawned.
This prevents the world from being littered by inactive player
characters.
The "respawning" property makes an entity respawn instead of being
deleted. It intercepts the Delete op and instead of deleting the entity
it moves it to the specified spawn point.
A typical use case of this is to place the property on any user
controlled entity, thus making sure that it's never deleted and istead
respawned when killed or defeated.
When an entity has this property it acts a an spawner entity. At an
interval it checks if there are enough of the specified entities
available, and if not it spawn new ones. This allows for some better
gameplay mechanics.
It's imperative that all properties are installed here; else the system
will end up in an invalid state whenever data is restored as a result of
a restart (since any missing property then will default to a core
property class.
