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.
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.
The object was to make it easier to follow, and to also remove fruit
spamming.
The attribute "fruitsMax" now denotes the maximum number of fruits in
the plant at any given time.
"fruitsChance" now denotes a percentage, i.e. [0, 100]. The closer to
100 the greater the chance of a fruit being created or dropped each
tick.
The existing fruiting entities were also altered to make them produce
less fruits, to prevent spamming.
Instead of hard coding the shaders we now allow the terrain property to
supplied data about the shaders. This is not optional currently, since
we expect the clients to understand the different layers (like "sand",
"grass" etc.), but we'll leave it at that for now.
When the server is run it checks if it's empty. If that's true, and the
cyphesis:autoimport variable is set (which it is by default), and the
file it points to exists, the server will spawn a new process which will
call on the "cyimport" tool to import the world specified.
The effect of this is that when cyphesis is run for the first time, it
will automatically populate the world into a playable state. This should
allow for a much better user experience, since many users never manage
to properly populate the world.
Note that we're spawning a separate process to run the cyimport command.
We could as well just do the importing in-process, but that would
require some more coding. Using a separate process if good enough, so
that will do for now.
This required the EntityKit to be refactored, so that most fields are
pushed into EntityFactory. Due to the nature of how the rule handlers
and the factories interact the code is pretty messy. It works, but it's
tangled and not really clean.
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.
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.
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.
