MemEntity needs some kind of reference flag/count if a python object
is holding a reference.

Fix unit_vector_to in python interface to make sure it doesn't cause
a normalise() abort(). Probably re-write to use relativePosition() which
may need to be fixed to give the right direction. The correct direction
should be the coordinate space that the observer's position is in. It
is probably currently returning it in the entities local coords.

Stop creator characters for getting filed into the accounts_entity_ent
table.

Transforming with an invalid quaternion creates an invalid vector or point.
We must not do it. See FIXME in WorldRouter.cpp.

Is it necessary to copy new_coords in Pedestrain::genMoveOperation()?

Debug broadcasting of perception ops, as a Character seems only to be able
to see itself near the origin. Orientation is making a huge difference
to whether the character can see itself. That is wrong. The wrong
orientating is getting used in relativePosition() somewhere.

Sort out trees thrashing database. Postpone until we have done something
about database transactions.

Make sure that terrain modified points does not contain any points still
listed as created points.

Consider moving destroy() functionality of Connection into the destructor,
thus allowing Connection to be accessed via its BaseEntity interface
in CommClient. Potentially allows more flexibility in use of
various server classes.

Make Connection::verifyCredentials() protected.

Track down anywhere where a normal mind is setting TO on IG operations sent
to body.

Centralise serialno assigment on IG ops, checking for 0 to see if we should?

Sort out FIXME in Creator::operation().

Character creation should not fail if creating its bootstrap inventory fails.
Errors from coin creation are confusing clients.

Take note of the places where behavoir is not the standard.
BaseMind::AppearanceOperation() uses both results from script and from
from the C++ methods. As does BaseMind::DisappearanceOperation().
Character::ImaginaryOperation() does not call a script at all.
Character::TalkOperation() does not call a script at all.
Character::TickOperation() does not initially call a script, and when it
does, it continues and merges the result.
Character::NourishOperation() does not call a script at all.
Thing::SetupOperation() _ALWAYS_ emits an Appearance op, but then processes
op as normal.
World provides no script overloading for any of its methods.

Convert FormatedXMLWriter into a templat that can drive any Atlas codec.
Thus we can have any Atlas Codec output in formatted human readable form.
Formatter can be a generic non-template Brige that sits between Encoder
and Codec.

It might make sense to keep a pointer to the entity an operation is from
in the queue, if its available at the point when we store it. How do we
then make sure we don't hold bad references?

Report error properlly in MemEntity when clock skew is detected.

Try and avoid removing stuff from the mind as soon as its been added. Perhaps
by checking the iterator ID on insert?

Try out dynamic cast rather than string test to identify ops in WorldRouter.

It would probably be easier to move extraction of parents from a new entity
to world.addNewObject() to avoid duplication.

Use "REFERENCES foo ON DELETE CASCADE" SQL to make sure character table
relations are removed when a character is deleted, or an account is deleted.

So, we have skill, which is a way of mapping tool use into actions.
How about tasks, which are a way of giving persistence and state to actions?

Sort out deer animations.

Add grasing.

By adding a skill class to be referenced by character, and defining Teach 
(transfer skill) Sling (stop wielding tool, and place somewhere convenient)
we can have almost a complete system. Implicitly, the click action when a tool
is wielded is to use that tool.

Re-work the way PyEntity and PyMind are defined so the inheritence is
available, and open up the scope for exposing more directly the functionality
of other entity classes.

Stop creating new objects from causing so much activity. Perception of the
new object must be based on its visibility. Perception of its deletion
should also be limited. Implement LRU in mind.

Upsidedown chickens suck!

Use tool, Wield op and Use op.

Add beet.

Look at me Swimming!

Debug skellys.

Make lych move. Construct skeleton nearby.

Handle modifying bbox proportionally to parameters.

Linears and stuff.

Path finder based roads and stuff.

Create pig pen.

Generalise money_transfers in mind to store general information about
all transfers of ownership. Preferably in knowledge.

Make chickens afraid of wolf.

Make vis re-calculated on bbox change.

Make walking speed depend on height.

Make cyclient more robust about receiving random ops.

Implement spawn points in the EntityFactory.

Verify that the persistant code does not insert entities into the world with
invalid location data. It shouldn't.

Fix movement bug with destination based movement after collision. Ammend
find target to be derived from velocity.

Fix or get rid of cyphesis-setup

Fix usage of map.get in BaseMind and NPCMind

Make ExternalMind inherit from something higher that BaseMind. It has so
few features.

It may be possible to get rid of getXyz() (crappy absolute position)

Its really not necessary for WorldRouter and its base to be so virtual, or
inherit from BaseEntity. Get rid of that, shift all the serialno stuff into
base.

Add time to location, so we can stamp update time, and always calculate pos.

We can neglect to send appearance if we are about to send Sight Move.

distanceTo does not take into account orientation.

Sort out putting everything at terrain height. This may require some strange
stuff.

Invesitage interaction between mind/body WRT type. We shouldn't ever use
the type string in Atlas.

Get rif of Entity::m_name, and other related pointless static attrs.

Fix Entity::addToObject to be more efficient with contlist

Make the server easier to kill.

Replace Sight(Create) broadcast from Thing::SetupOperation with an appearance
broadcast.

Enforce well-formed args and parents on IG ops centrally.

MemMap::add and MemMap::update are the same, identical. Eliminate this
sameness

Broadcast appearance on entity creation. Not that other Sight(Create())
bullshit.

Real sight ranges

Do minds delete stuff from memory? Replace Entity with a special class
for memory entities, includin some kind of LRU thingy.
Implement LRU culling to minds, only for things with empty contains.
MemMap::lookId should probably not be exposed to the python API

Add Restore op if required which does the same as Setup, but for restore.

Make sure we don't schedule database maintenence if its already doing it.

Add a search function to cycmd to search for entities by type or name.

There is probably a problem with getLocation bailing if LOC is not of the
data from the mind code's point of view.

Why the hell is there so much mind activity on database restore.

Take precautions to ensure multiple looks don't get stacked up in the MindMap.
Probably best done by making additionsById a map.

Add some simple sound op examples

Make Forest a non-solid bbox

Fix problem with vertical movement. (See BUGS)

Debug collision with sty.

Make cyphesis less reluctant to shutdown. Check for exit_flag in more
places.

Can we get a code size or performance improvement by passing in the result
list as part of the operation method call. The answer is yes, but the
further question is whether this will break anything. We can also stop
calling the script post dispatch, and call it before op dispatch instead,
giving a single call point, instead of loads of call points all the way
through the code. Problems:
  BaseMind: Blocks perception when it is asleep - this would be bipassed.
            Process Appearance in the C++ code, even if script takes it.
  Main script subscription process is bipassed, but this may well be ok
  and mean that we can remove scripts from the subscription mechanism
  completely.
  Character: Tick - some types of tick need to be processed in the core,
             even if others go to the script. Complicated processing.
             Why no script in nourish?
  Thing: Broadcasts a sight(create()) op in Setup, before calling script.

Think about how to deal with things that probably don't need persistance.
Seeds in particular. Flag in the rules?

Need to profile why startup takes so long - we are chewing a lot of ops.

Can we run our own RDBMS in the event that root access is not available.

Modify var dir for socket so it is actually the right place.

Run "SET autocommit TO 'off';" on connection to database, and run "COMMIT;"
every 30 seconds (or so).

Make database maintainance intervals configurable.

Sort out character relation so it has the right foreign key stuff.

Looks like zero collision time results in move then stop being sent
almost immediatly. Check for it, and send nothing. This may mean
re-ordering the movement code. Possibly checkCollisions needs
to be earlier.

Modify Movement and Pedestrian classes so they handle restricting an
entity to their parents constraints. In the case of Pedestrian, this
means walking on the ground.

Re-write appear/disappear code so we use real square distance instead
of boxes, and use some kind of function involving objects size 
to judge how visible it is. ie. get rid of fixed sight range.

Re-work distance measuring functions to ensure orientation is taken
into account.

Clean the database. Use VACUUM once an hour, and probably VACUUM ANALYSE
and VACUUM FULL each once per day. REINDEX may also be required.

Sort out socket address re-use, and lingering.

Move big functions out of physics headers into .cpp files

Long term, try and sort out the way object factories, scripts, and atlas
inheritance are handled, so they are a bit more coherant.

Re-work Decoder on client connections so operation dispatch is not done from
with the poll() call. Instead, the decoder should just que ops, and they
should be read off and dispatched from elsewhere.

Make sure plant base class is working.

Think about how to install classes over the wire. Perhaps adding
a bind() operation, which binds a specific script or C++ class to
an entity class? This means that the entity class definition itself
is clean of server internals, so can be done in a non server specific way.

Modify the logging code so that it mangles script output a bit less.

Fix up the pedantic checks in the python code to return AssertionError,
and only be compiled in when DEBUG is enabled, like those in
Py_CreatorClient.cpp. Clean up the Python type names as has been done
in the process python API. Fix up the other error types used, including
fixing the error messages.

Fix up python checks so they work with a prefix other than /usr

Is socket getting opened before it will accept or negotiate?

Fix up cypasswd to allow creation of additional admin accounts.

Think about adding UPnP here or to skstream (or both)

Replace PyExc_TypeError with the correct exception in most cases.

Use PyInstance_New to create an instance given a class.

Use PyModule_AddObject(), PyModule_AddIntConstant(), and
PyModule_AddStringConstant() when setting up the python consts module.
(new in version 2).

Look at re-writing python API code to work with python GC

Look at using zipfiles to store entrie trees of python files for a ruleset.
Look at making sure .pyc and .pyo files are included in the distribution.

Check if "common" module reference in init_python_api() should be decrefed,
and also any others.

Still plenty of python object leaks. Need to carefully see if references are
being handled right in the mind code.

Sort persisting world so things like its orientation are initialised correctly.
Either valid or invalid.

CreateOperation and DeleteOperation behavoir probably should be moved from
Thing to
entity as they should work on entities.

Add attribute handler objects, which hold a reference to the attribute value, so
that the looking up of these attribute can be accelerated by a map.

Test what happens if we use shutdown instead of close on a socket.

Implement constraints on entities, which have to be checked before movement
is allowed.

Add propper type engine.

Benchmark various setting arguments ways. RESULT: When using Message::Object
args, it is much much more efficient. When using op.AsObject(); for args, it is
quite a bit more efficient.

Put in different high level exception catchers, to differentiate between
exceptions caused by a client, which should result in a kick, and bugs in game
which need to be logged.

Mind state is still utterly unpersisted, so creatures are waking up brain dead
- mind does not even get kick started with a setup op.

Putting an index on entity_ent.loc massively improves database loading
performance. Need to assess impact on runtime performance. Should definitly
consider putting this index in place permanently. Why is it that on some cases
this does not help? Indexes are not good for lots of instances of a small set
of values.

When deleting an entity, need to deal with reparenting its children in the
database.

Experiment with BEGIN / COMMIT blocks to reduce load on database. A
possibility is starting a transaction, and then commiting, delaying if their
are requests which have not yet been sent. This of course pre-supposes that
the mechanism for sending queries to the database asynchronously has
been done. It is probably acceptible to only accept queries that do not
return any tuples, and then the asyncronous recieve mechanism doesn't need
to worry about who wants the tuples.

Write a base class for plant which has a standard forumala for managing the
growth of plants - the fundamental measure of which is mass, then another
formula for calculating the size (height, width) etc from the mass, so the
shape of the plant as it grows can be customised. This could largely eliminate
the need to scripts to define plants.

General TODO

  Come up with a way to persist general attributes.

  Persist more complex things like geo stuff.

  Allow types to be installed from the client.

  Calculating absolute entity position has now ignored orientation for
  too long. This needs to be fixed after this next release of mason,
  or we are screwed. This would probably be best achieved simultaneously
  with the generalisation and virtualisation of the collision code,
  and a switch to using wfmath.

  Generalise and virtualise the collision code. Handle at very least obboxes

  Implement jump operation, which specifies target, and comes back with,
  a sight of a jump which has the starting velocity, and finish position.
  If the client sends only velocity, then something else happens. Add
  a method to Pedestrian to handle it.

  Implement ontology querying for AI code.

  Add Feel as the counterpoint to Touch, as Sight is to Look.

  Implement piles.

  For entities which have a bbox, which other entities do not collide
  with, such as geo entities, provide a virtual methods which allows the
  collission code to check whether entities within this bbox should
  be moved into the bbox entity. Should work fine for irreguler shaped
  things, as long as bbox is kept up to date.

  Investigate why attempt to make admin entities move around doesn't work
  right now. Fixed I think.

  Ensure that maxmass set in python has some effect in C++, and investigate
  other related attributes.

  Connecting to other server: Make class peer of CommClient called
  CommConnection or something which is basically the same, but implements
  connecting instead of accepting. Might even be able to merge the code
  in, or make it a template. Make object which inherits from Connection
  called ServerConnection which is created and linked to CommConnection
  which handles pushing operations from the other server into the
  WorldRouter. The question now is, how this is managed at the other end,
  and what is done with operaions generated by this server due to
  operations from the other one.

  Add suspend functionality, which stops the advance of time, and
  thus suspends all mind activity. Could also inhibit broadcasts. Effectively
  puts the server in bulk maintenance mode, from which NPCs should be
  removed. Should consider the effect this will have on NPC memory,
  and whether or not it can be rebootstrapped.

  Clean up the removal of idDict. Need to fix deletion of idDict contents,
  and arbitrary object requesting by admin.

  Why don't the pigs eat?

  Looking at contains attribute currently only applies sight ranges in
  world entity. Need to apply sight ranges in all entities.

  Find out why pure orientation changes don't get echoed by the server.

  Once the subscription mechanism works, transfer its setup into the factories,
  and use it to inform the clients what op types are meaningful for object
  types.

  Fix the database so it handles updating entities. Need to actually lookup
  how this is done. Need to lock row if its being updated.

  Implement installation of a new type by admin account.

  Entity classes need to be added by world builders. They also need to be
  persisted, so it seems as though they need to installed in a database,
  and for this database to be loaded just before the world state. This implies
  that majority of config on startup needs to be loaded from some kind of
  writable config store, rather than read only system files. Does this mean
  that predefined rulesets should only be loaded when explicitly commanded,
  or perhaps even externally to the core server?
  This also asks the question whether the current db code is up to scratch.
  Need to look into SQL for the database now. It is going to be a relation
  object database hybrid, using current tech to serialise objects, despite
  Funcoms warning. One question is obviously whether to use a database
  server, or in process database access.

  Add services features, and test them in equator.

  Current watchdog keeps server running. Should a future version ensure
  that the server is working?

  Add support for maps list attribute on world_0. Good idea?

  Implement accelerated Atlas Objects API. MAYBE:
    POSTPONED FROM 0.3
    POSTPONED FROM 0.4

  Fully implement stackable objects.
  Use combine operation to deal with making more than one object into one.

  Add sending of touch op on collision.

  Implement omnipresent

  Establish a way to handle the location of db3 headers on debian without
  library header file requiring config.h

  Clean out C isms in watchdog and control tool

  Clean up Python_API.h, and add init/shutdown functions.

Required for werewolf:

  Implement calendric time using WorldTime and DateTime classes, so nighttime
  and moons are properlly handled.

  Implement sleeping.

  Sort out a reasonable way of representing day and night to client. Look
  up info on Durals astronomy. Weather (clouds, snow, rain, thunder and
  lightening).

Required for mason:

  Create a skills system which the action is passed to, and the skill
  returns the resulting operation to the world. This skills system
  would be handling by the character class, in the mindXxxxOperation()
  methods. The skill would be an object with a reference back to the
  character it belongs to, and a method that is passed the action taking
  place. It would return operations to be passed to the world which carry
  out that action to the extent of the ability of the character. Some
  skills will just do nothing, like the ability to wave, or shout. or
  maybe the shout action could decide using a skill how loud the shout is.

  Implement the Mason raw materials.
  
Possible ideas:

  Add fully featured database persistance.

  Persistance system is naive right now. It does not take account of that
  fact that characters need minds, and it stores the world object.
  Persitance is now sorted so it loads the world hierarchicly, but
  it still does not handle minds and things. Problems with current
  code include velocity being stored, and bounding boxes not being
  recovered.
  Basic C++ code for supporting saving and loading of mind state is now
  in place, but support needs to be added into the Python NPCMind
  class to store the data it requires.
  Code is still required to store the state of the operation queue.
  Restoring of accounts from database requires re-connecting characters
  too.

  Get system working as an AI client to another server. This would also
  be a good time to get cyphesis working as a mindless server, without
  any AI code.

  Route finding for the AI. NPCs already have symbolic knowledge of places.
  All we need is a mechanism for describing that two places (or nodes) have
  a direct route between them, and then the mind can build a graph which
  allows them to find a route. We also need to provide a mechanism so that
  NPCs know about a particular entity. This can be done by sending a generated
  sight operation.

  Sort out collision detection wrt moving alongside an object in close
  proximity, and add CD for two moving objects. Basically we need sliding.
  along an object. This can be done by zeroing the velocity along
  the axis perpendicular to the collision. Obviously we need to add
  a mechanism for establishing which axis is perpendicular to the collision.
  This now works, but the direction the moving entity is facing is sometimes not
  modified.

  Modify map to make more use of stamp.
