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.
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.
To allow for better performance when scaling to larger worlds we can't keep
iterating though all entities when checking visibility.
Instead we now have the PhysicalDomain keep track of all entities that are
either observering something, or being observed.
Since Bullet already contains efficient structures for doing space partioning and
collision detections we'll resuse that for visibility checks.
Each entity now has a sphere of "visibility" with which each perceptive entity does
checks against.
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.
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.
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.
Though this change isn't fully set in stone. We have to revisit if we
add motion between physical domains. This change would at least prevent
segfaults when domains are destroyed.
It would be better to use a Broadcast of the Disappear op though, but
that would require a change so that the location is encoded in the op
which will be broadcasted. Otherwise the WorldRouter will just use the
location of the entity as it is when the op is processed, which will be
wrong for this case.
Collision detection should fully be handled by the domain, as should
sight checking.
The plan is to let the domain keep a separate structure of all collision
geometry, optimized in something like a quad or oct tree. Since the vast
majority of geometry is static, in the sense that it very seldom moves,
the Domain should keep a flat representation of all geometry, with
precomputer meshes for fast lookup.
Similarily it should keep a separate structure, or structures, for sight
checks.
And it should of course also use Bullet for collision detection.
