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.
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.
This is a mind which only registers the world, and then is responsible
to send what it knows about the world to any external mind that's
connected to the character.
Currently it only sends the thoughts that's been sent to the character.
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.
It's currently a copy of the Mason ruleset.
Where Mason focuses on letting the users create the world themselves,
Deeds instead focuses on allowing world authors to set up enticing
worlds with gameplay and stories. In contrast to Mason there are more
features available to the world authors which allow for automatic
creation of entities and so on.
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.
Minimal will not be changed, it will serve as a barren and
minimalistic ruleset that allows someone to start. Mars will be
the result of all tutorials applied to minimal.
Also reverted minimal ruleset to use moraf, to avoid additional
requirements.
