We need to be able to check if things are visible from goal scripts, so
a MemEntity version of the Enitty wrapper is required.
This would mean we could make buy_thing goal expire when seller goes out
of site.

The getTickAddtion calculation is almost certainly redundant. We almost
certainly worked in out in previous call to generateMove().

Butcher should tell you how much money you are getting.

Add face() to buy_livestock and related goals.

Check if disappear/appear with incremented stamp causes BaseMind to want
another look, like it should.

Modify mindMap so that entities are visible if they get updated.

Once Script returns an int which differentiates between an error, and
a missing method, then mind reference in PythonMindScript can got, and
error can be reported in BaseMind or somewhere similar.

Once stored python wrapper is done, the wrapper can be specialised for
Character so that task related code is exposed.

Don't do the same bullshit help every time the user clicks on a helping NPC.
Bugs: Crash when fire burns. (sear)

Look up upgrading the python API usage to 2.2 spec. In particular
look at generic attribute handling, PyType_Ready, inheritance etc.
Method doc strings.

Use getProperty to implement a surface property, and integrate into the
height adjustment code.

Do any Python types with have an _attr member initialise it before
they have to in setattr? Py_Entity/Thing used to.

Character jumps to the bottom when swimming.
Jumping to bottom is because when the character rises above water
the movement code assumes it is walking, and then height is constrained 
accordingly to terrain.
Character/Pedestrian needs to handle surface properties, so it can't walk
up steep slopes. Also need to handle jump, to get down steep slopes the quick
way.

Lobby accounts still indexed on string IDs. Good or bad?

Should ImmutableProperty inherit from Property, or the other way round so
that implementations of get and add can be shared? Yeah.

Write test for SignalProperty.

In cycmd, use flag to indicate when output is written, so it is possible to
identify when at prompt, and move to next, and also possible to more cleanly
redraw prompt, rather than forcing it every time codec->poll() is called.

ForbiddenThingFactory::duplicateFactory could return PersistantThingFactory
so its possible to add more abstract factories.

In order to have attribute defaults inherit from parent classes,
the code must first store the unmodified defaults direct from the rule
in a separate place. Its main attributes should then be the result of merging
those with its parent. This ensures that the result is always right, without
having to walk all the way up to GameEntity. It is also makes propagating
modified attributes down the tree easier, as long as a factory stores
a list of its children. This means we have two compelling reasons why the
parent factory needs to be available when the child is being installed.

Handle SQL escaping of attributes encoded string before persisting.

Implement tracking terrain surface, and preventing climbing of steep terrain.

Implement data driven gui dialogues, in Sear and perhaps equator.

<map>
  <list name="parents><string>dialogue</string></list>
  <string name="label">Dialogue</string>
  <list name="contents">
    <map>
      <list name="parents"><string>vbox</string></list>
      <list name="contents">
        <map>
          <list name="parents"><string>label</string></list>
          <string name="label">This is a dialogue</string>
        </map>
        <map>
          <list name="parents"><string>hbox</string></list>
          <list name="contents">
            <map>
              <list name="parents"><string>button</string></list>
              <string name="label">Okay</string>
            </map>
            <map>
              <list name="parents"><string>button</string></list>
              <string name="label">Cancel</string>
            </map>
          </list>
        </map>
      </list>
    </map>
  </list>
<map>


        ---------------------------------------------------------
        |                                                       |
        |   A dialogue                                          |
        |                                                       |
        |     --------------------     -------------------      |
        |     |      Okay        |     |     Cancel      |      |
        |     --------------------     -------------------      |
        |                                                       |
        ---------------------------------------------------------

BaseEntity::error() should take string.

Are attributes inherited? I think not. Need to be.

Carefully use flags to check for illegal stuff from client/mind ops.

Walking army of the undead, daily.

Spatial iterators, for map have a reference to a const_iterator, and filter
while incrementing. Iterate between space(bot_left, top_right)  and end().

Don't update POS in database if VELOCITY is non-zero.

strlen.com

Predators should now use combat code to defeat prey before eating, and
then Eat op on character should only work on incapacitated characters.

A bunch of stuff in Character::externalOperation can go if we don't care
about ops having serialnos.

Move contents of mindUseOperation to UseOperation, and have mindUseOperation
filter ops like it should.

Combat system needs to depend on character stats, armour, clothing and
weapon at very least. Probably need a class to encapsulate important
processed stat information for a character. This makes it harder to
have a fully configurable combat system.

Define new class Volume which contains the set of points and normals
required by the collision code. Cache the volume, and bounding radius
of entities in Location. bounding radius is very easy. Add a course
collision check based on bounding radius.

Not sure destination based movement is working right if destination pos
changes due to LOC change.

Fix collisions. Leaving needs to be the inverse of entering, and this
implicitly means we need to check collisions with the parents' children.
We could also probably do with a very course check to make the whole thing
cheaper.

Collision code would be more reliable if collisions were check with
current parent's siblings, as well as entities siblings.

Make sure all Property classes have add(Entity)

Task tick ops need to embed the ident of the task, to ensure a replacement
does not cause a problem.

Modify Attack handler so it is the attackee that creates the task object,
so attacking a pointless target has no effect without any smarts required
in mindAttackOperation().

Script code would be simpler if we could call the scripts in Entity::operation
rather than in each method individually.
Need to handle double op methods, and some special cases.
BaseMind blocks sight ops if character is not awake.
We can probably block all ops to mind when its unconcious from
the Character class. BaseMind handles Appearance and Disappearance
even if the script handled them. Character Pre-processes Setup
before passing to ensure a setup op happens. Character tick ops
are checked to see if they are movement related, if not they are passed
to script. Character never sends nourish or wield op to script.
Thing pre-processes Setup. Thing increments m_seq when it gets Set or Move.

Make Connect and Attack standard Atlas op.

Sort out issue where carrying a living tree kills people. Caused by
eat op from tree.

Attribute modifiers should be a new low-level primitive on Entity,
like property. They should be done before attributes are set from data,
but after default attributes are set. Scale control variables should
be assumed to be 1 initially for the purposes of scaling.
A function like merge should be used to apply scalars. It needs to be
able to copy the modded data into Atlas for reporting back to the client.

Fix dodgey collision code which causes structures with complex parts to cause
tight loop conditions.

It should be possible to make trees fall so that they are parallel with
the terrain, if a mechanism is available to determine normal of the
supporting surface.

Does it matter if World gets a delete op when status becomes < 0? It
shouldn't, as the delete op should be ingored, so World does not need
a Set op implementation.

Sort out a way to move world functionality into a script.

On #python talk to deltab TFK or #pyrex.

When reloading a python module, try to load it even if it didn't load before.

Prevent forbidden attribute from leaking through in move ops from client.

Re-code chickens so they flee on contact, rather than on sight.
Fix lych and skellys.

Implement swimming, which requires constraining the updated pos in the movement
code to be sure of getting the right Z. Try and do some direction stuff in
the sear interface.

Clean up old movement code, get rid of Movement::m_velocity, and perhaps
m_orient.

When getMoveUpdate is first called in moveMoveOperation, it doesn't really
want an operation, just an update of the position.

Add swimming to Pedestrian. Try and add floating by default to non aquatic
creatures.

Move Create handler from Entity into Thing, as everything IG inherits from
Thing.

Make an Atlas encoding to describe basic layers.

Implement buying clothes to be worn. Garment base class, use wield operations
to use.

Implement spawnpoints, and separate mason and werewolf locations.

Make sure python object references aren't leaked in script factories.

Implement subsystems on server object. Allow Admin to fetch the subsystems,
like "configuration", "policy" etc.

policy should include things like:
   Account creation on the fly.
   Number of characters per account.
   Number of character played at the same time per account.
   Visibility of player on character and character on player.
   Character removal from world on logout.

Installed types from the client need to be persisted in the database.

Create harness device which is a number of entities connected by ropes.
Consists of hook, and a number of ends to be held by people. Each end is
attached by a rope entity to the thing to be moved. To attach the hook,
it is wielded and used on the target. Each person the wields and uses
their ends. When enough people pull, the target moves. Vector of travel
is the average of the distances to the people pulling.

Add use of pickaxe to split rocks. Initial rock in ground could be huge,
and require splitting, or heavy equipment to move. Rock can be shaped into
stone billet for use in building using a chisel.

Add operation Increment which allows deltas to be made to attributes.
Important for atomicity in delayed events. Propagated as Sight(Set).

Grass should dry out.
Earth and sand should return to the soil.
Sand can be made into a sandy area using a tamper.
Digging earth could create a field area.
Might need to notify entities when their parent changes.

Code up projectile movement as a first test of entity movement.

Sort out so lobby had a real ID.

Code up allowing accounts to create rooms, and guilds.

Optimise down the number of calls to iterator::end in mindUseOperation

Add a reach attribute to tools which tells the client how far the NPC must
be from the target before they can use it on something.

Fix Creator::LookOperation so that it doesn't return anything if no
match can be found. Also it should probably not accept ops with TO already
set.

Add cydumprules to the man pages.

Clean out Python operation API, as its full of unused and useless functions.

Slave or Peer servers need to negotiate types at startup.

Make the butcher more helpful to n00bs.

Implement a Tool base class which eliminates the need for tool scripts - 
handles the necessary op conversions driven by data.

Make sure stamp is updated in MemMap and checked, and implement Unseen.

Implement trivial combat, and code up a bunny bashing quests for the hard
of thinking.

Add ticker callback mechanism to WorldRouter, which calls callback whenever
a tick is required. Will reduce the cost of the op queue by making it smaller,
and should be cheaper than tick ops. Needs to be carefully designed. Can handle
stuff like one-shots, as well as regular ticks.

Spec an op similar to use, but for things which are just used by themselves,
like buttons, valves, levers etc. Target has operations=[...] just the same,
and the arg of the new op specifies what op to do, but the Character just
needs the one gateway.

Implement Task interface, which represent enduring tasks, including combat.
Could also include destination based movement. Task needs a name, and an
accessor for it, so it can be used as a private Property.

When calling NPCMind.face when buying an item, for some reason the velocity
of Pedestrian is valid and set to a weird value. This is because the
target position where the merchant wants to be is at a different z value
from where the character ends up. This is a general problem with moving
to pre-defined positions.

We could move the loop into ServerRouting, rather than CommServer.
Rename CommServer::idle to CommServer::poll or something like that.
Perhaps we don't even need idle any more. Idle objects would then
be owned by ServerRouting rather than CommServer. CommServer would
then be almost fully generalised. In order to lose the reference to
ServerRouting in CommServer, the listeners would have to have this reference
instead - move the specialisation into the listeners.

Does sightFooOperation etc. in BaseMind.h have to be virtual? I think not.
Yes it does, as its overriden in some client code.

CONTAINS could be some kind of spatial set of buckets for efficiency
when doing collision detection, but if this is not to be true for all entities
then the mechanism for modifying CONTAINS needs to be virtualised, and
made a method on the container/LOC. If the spatial stuff is to work then
the entity needs to be removed while it still has its old coords, and added
to its new container with its new coords.

We should be able to look at the attributes of an python instance to
determine what operations it needs to be subbed to. It doesn't have a
dictionary, but it does have the methods as attributes.

Make sure that goals involving movement don't issue a move op unless its
necessary. ie check to see if we are already moving in the right direction.

Fix Movement/Pedestrian to handle destination based movement where LOC
changes. Just use distanceTo as the velocity vector.

The spot_something goal is a hack - need something better. Probably need
some kind of Knowledge about target entity. Give the Knowledge predicate
as an argument to spot_something(), and add Knowledge with that predicate
once something has been spotted. For example
spot_something('lumber', 'spotted_lumber')

mind.things in NPCMind seems to be completely based on the name attribute,
though it seems like it would make more sense for it to use type some of
the time.

Each entity could have a Mode object which controls how its movement/position
is simulated, including the effect of gravity etc. This would be associated
with a mode string.

If the character moves an entity into another similar entity, then
we should create a Pile. This can be detected in mindMoveOp().

Currently no mechanism to inform client/mind that the ID they just
specified is gone. Need to think of something, and make sure mind
deals correctly. Something like Unseen operation.

Can Property mechanism be used to handle raw Python data as properties?

Sort out the issue of un-initialised POS, ORIENTATION and BBOX in the
database.

MemEntity needs some kind of reference flag/count if a python object
is holding a reference. Probably as well to ref-count all IG entities,
then we can hold a reference in the op queue, and avoid lookup up the
FROM at dispatch time. Would also allow entities to hold pointers.

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()?

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

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.

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.

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

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

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

Is listen socket getting opened before it will accept or negotiate because
more work is being done before poll/select occurs.

Fix up cypasswd to allow creation of additional admin accounts.

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

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.

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.

General TODO

  Come up with a way to persist general attributes.

  Persist more complex things like geo stuff.

  Generalise and virtualise the collision code.

  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.

  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.
