Must fix for Mason 0.0.2

  Stop broadcasting passwords around the place. Probably best done by sorting
  out the account table properlly.

  Lets get rid of this nonsense about ids having too much meaning.

  Fix movement BUGS, and other BUGS

  Test well the mind2body op filter, now that the copy has been eliminated.

  Perhaps look at the way idle handles internal and network traffic. It
  is possible that network traffic should be given a higher priority.

  Generalise the way CommClinet objects work so there is a generic
  interface, and object of different types can work, including
  different listeners.

General TODO

  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 base class for CommClient and other connections which listen/talk
  on a socket, such as the database connection, so we can have non blocking
  db access.

  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.

  Omnipresence currently has no effect. If its really needed, do something
  with it, otherwise remove it from the code. Talk to aloril about getting
  rid of it.

  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.

  Add custom ops into the global opEnumerator as OP_OTHER or something.

  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.

  Its probably a good idea to make sure Location has an operator== and
  operator!= to make sure operator bool is not stuffing it up.

  fire is being installed as a type of operation, and as an entity class.

  Lookup whether c_str() returns a pointer which must be deleted.

  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.
