Seems the package handling is more complicated than I supposed to, but,
I've got a working version. It's gotta be reviewed first before I'll
post more details, anyway, this is a major step forward (I've
implemented ten different
Package systems previously until I got it hopefully right). Stay tuned
;)

I've been working lately on two main projects: The new package managment
for niven and a LaTeX package.

LaTeX

Writing a package for LaTeX isn't that complicated, the problem is the
lack of good documentation - most books I found describe how to use
LaTeX and don't mention even commands like \ifx. I used the following
two books:

LaTeX2e for class and package writers

TEX BY TOPIC, A TEXNICIAN'S REFERENCE

These two cover most of the subjects that are needed to write a simple
package. The second one really just a reference, while the first book
gives you examples how to add for example options to your package. Both
are really worth reading - my LaTeX package offers now both support for
technical books and "normal" books which are meant for print (for a pet
project - from time to time, I'm writing on a book).

Packages

niven's package system is currently in its 8th revision, this one is a
fairly good looking one though :). When finished, it will be able to
load and store any kind of object that the user defines into packages.
Packages are the only way to serialize data in niven, and they provide a
container for objects. They also provide means to distribute the content
easily. The current system is different from the other ones as it stores
object instance information in a wrapper object and not in the object
itself - i.e. you access objects via ObjectHandle<Type> and not via
Type*. This sounds complicated first, but it turns out to be rather
easy when you use it. Packages have an advantage over storing the
content in plain files (let's say, .jpg) as they store type
information and dependencies, meaning it's possible that one package is
linked to another package. A good example is a map where several objects
use the same texture, no need to store it several times. So much for
now, as soon as I get the 8th revision ramped up and working I'll get
back to you.

Recently, I tried
AnkhSVN again - and
it worked. For some time, the builds had problems, but the latest build
works fine again. Read on to see what AnkhSVN is. Another thing that is
working again: Niven's MSI based installer - again, read on for more
details.

AnkhSVN

AnkhSVN is a Visual Studio add-in that allows you to use SVN directly
from within the Visual Studio. Click on the screenshot below to see how
it integrates into the IDE.
AnkhSVN in action

With AnkhSVN, you don't have to switch back and forth to the explorer
when working on a SVN repository except for larger tasks like branching.
But for everyday work, it safes you a lot of time and really works out
of the box. Go and get it ;) !

WiX

WiX is
Microsoft's OpenSource toolkit for creating Microsoft Installer
installations. Basically, you have a bunch of XML files which contain
the UI, your product information and the source files, compile it and
finally link it into a distributable MSI file. WiX works great, Niven's
original installer was based on it but not updated for some time. Today,
I took a look at the new features and fixed the installer so it's
working again:

Niven's MSI based installer

When I get a bit deeper into customizing the UI (at the moment, I can't
figure out the right resolutions for the various pictures which leads to
ugly artifacts) I'll post about it.

Completely forgot to mention it, the Collada 1.4.0 DOM is released and
available from
SourceForge.net. It
contains a Visual Studio 2003 project file and several examples, but I
did not try compiling it yet.

I mentioned script-driven classes, without going into detail what I mean
with this. Read on for some thoughts on scripting. Note that nothing of
this has been implemented, and it is mostly just ideas that I carry
around without having time to implement them properly.

The script side

The scripts would run in some kind of ScriptVM, probably a stack-based
machine. Calling script code from C++ would invoke populating the stack
with the appropriate parameters, and invoking a script method. The
script method names and their parameters would be stored in some global
array inside the ScriptVM. When a script is called, the ScriptVM
processes each of the compiled opcodes and operates on the script stack
only. If another scipt function is invoked from a script, the operation
would be the same as if it was called from C++.

Host->Script

The simpler side. Calling scripts would mean: The user knows what
variables the script expects and what function. With a script function
void func (int, int):

Script->Host

This way is more difficult. A possible solution is that when a C++ class
is made scriptable, a new wrapper class is generated. For example,
assume we have a C++ call void func(int,int);. The wrapper would look
like this this: