Classes under "rulesets" have been moved to "rules", and split up into
futher subdirectories matching their library. As a result we can now
better separate the python bindings, so that things that belongs to the
simulation are separeted from things that belongs to the ai.
Though we strive towards moving all of the specific functionality
into attributes and removing the native subtypes altogether.
Note that we default to all plants being planted by default.
When we're restoring from storage we don't want to apply any properties
at all when the entity is created, since we'll do that ourselves in a
later pass. This is done by submitting an invalid RootOperation pointer.
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.
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.
The code would segfault if installing a new entity class failed at the last
stage in Inheritance. Inheritance would return null, which would be assigned
to the factory's m_type. addProperties() assumes the pointer is not null.
This fix adds a check, and reports a failure undoing the whole process.
All IG code should use the interface of LocatedEntity when dealing
with any entity, rather than sometimes requiring Entity. Add virtual
functions to the interface where required, and modify all other interfaces
to stop them using Entity. This makes the code way cleaner, and much better
de-coupled.
This is the second step in cleaning up a rather messy call path
which was different when installing the classes a game actually uses
from the data files from the base rules that are common to all.
