Instead of handling broadcasts when the op is dispatched, handle them
when the op is first added to the world router.
This way we can better handle the case where an entity is deleted, as well
as make away with storage of perceptibles entities in the world router.
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.
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.
Instead of the root entity always being the default one (for new
entities being created etc.) we now can specify another entity which is
the default one.
Don't keep the time in field, updated only at poll requests. Instead
calculate it when it's needed.
This fixes an old bug where all client movements were slightly
incorrect. The time was only recalculated at WorldRouter::poll calls. However,
when polling for IO the process waited up to 100 milliseconds. That
meant that any client received operation would get an on average 50
milliseconds offset in it's registered time. The result of this was that
most Move operations would be slightly incorrect, resulting in jerky
movement.
Since the queues weren't queues until after the destructor had run,
there was a risk of a spawn entity being deleted later on, leading to it
referencing invalid spawns since m_spawns weren't cleared.
There's no reason to use the hacked in "contains" feature for creating
inventory. Instead we can rely on the Archtype features. Any entity
declaration for which we also want inventory created should use an
archetype.
The change is that the "contains" and "character_types" attributes are
removed. Instead there's a "entities" attribute, which is a map. The
keys are the names of the entities as seen to the client, and the values
are the entity specifications.
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.
An archetype is used for creating new entities. It contains one or many
definitions for entities, along with relationship between them. It also
contains any extra data needed for a world simultion, such as thoughts
and knowledge.
Archetypes should be seen as blueprints for entity types, as they
describe how new one should be composed. They are created just as
regular entities, using the existing Create op functionality.
As an example, there should be one "human" entity type, with archetypes
such as "settler", "merchant", "soldier" etc. This differs from the
current setup where each of these are separate entity types.
