Moved things around and updated xml_extract.h so that everything compiles again.  Other than NIF_Blocks.h/cpp which will be removed in the future, of course.

Implemented some of the object hierarchy the new way in nif_objects.h and started updating niflib.cpp.

Removed interfaces and moved documentation to real classes.  NIF_Blocks.cpp and niflib.cpp no longer compile.

Begun work on the new type of Attributes which store pointers to their data rather than the data itself.  Moved some code to new files to fix problems with cross-includes.
Need to decide what to do about TexSource, a struct in the external interface that should have a link in it.

Key streaming in NIF_IO.
Added xml_extract.cpp to SConstruct.
!! The extracted files are based on a modified XML, with CrossRef and Link implemented as uint, and char implemented as byte.

TODO: implement CrossRef and Link in niflib.h?

Did some research in the C++ FAQ and found out how to have vectors of objects that have no default constructor:  http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.5  Therefore, LinkGroup and CrossRefGroup were removed and the NifStream functions and << operators were shifted from blk_ref and IBlock to Link and CrossRef directly.  The Python will now just have to worry about inserting the owner into the constructor of all links.

Created NifStream and << operators for blk_ref and IBlock *.  Special code will need to be generated by the Python to handle reading of links.

Implemented HeaderString class.
Removed more legacy code from NIF_IO files.

Added several NifStream functions and << operators to the built-in types.
The new xml_extract.cpp file now compiles.
Problem areas that must be fixed in the generation script were marked with !!BUG!!

Moved some temporary defines to NIF_IO.h.

Added optional version parameters to all NifStream functions.  Couldn't figure out why it conflicted with Amorilia's later change so I used my code.
 

* Support for all ten NiStringPalette offsets.
* There's still a problem with NiStringPalette: apparently the C++ string type does not allow null characters? ... Maybe we can try to find a workaround in the string reader function.

Block implementation is current with DocSys again.

Created classes for all new 20.0.0.4 blocks.
Re-implemented NiTexturingProperty as a data-style block.  Still needs an interface so is currently uncontrollable.

Implemented NiControllerSequence block and interface.

Renamed Color structure to Color4.

NiSkinPartition and NiLODNode are now read fully and can be examined by calling the asString function or written back out to a file unchanged.
NiTriStripsData has been given a public interface, ITriStripsData, so that the triangle strips it contains can be extracted.

Finished basic version support � still need to implement new block reading scheme for version 5 and up.
Updated all basic blocks with correctly versioned attributes from DocSys database.
Updated all data blocks except for NiSkinPartition and NiControllerSequence to react correctly to known version differences up to 10.1.0.0.
All blocks but the above now have both a Read and a Write function.