Two big overall designs:

Two independent programs, one that handles the common sense and the other that handles the
actual placement of objects.  The "message" between the two is a file: essentially you can
pipe the output of the common sense program into the editor program.

The other option is to have one single program that does the common sense operations and
then directly uses the editor API to place objects, cutting out the intermediate process
of the "message" file.

I think the first approach makes more sense.  It's easier to separate the tasks, and it's
also more flexible/open to later expansion.  This approach also pushes the frontend onto
the Common Sense program.  Or rather, a front end can basically wrap the two programs.
Runs an instance of the CS program and pipes its output to the Editor program, all the
while showing pretty things to the user.

We're going to need a database of the available objects: for our purposes a subset of
the objects should be more than enough.  This could be the same or separate from the
Common Sense database of objects.  But this database needs to provide Morrowind specific
object properties like id, size, and texture model.

So program flow:

Common Sense Program -> common sense file -> editor program -> morrowind plugin file



TODO:
  
  * finish data extractor
  * UI considerations
  * comments
  * find out where to get size information
  * need to load the database of game objects