In the meantime, I also achieved some nice integration between Lua and my engine. The cool thing about Lua is you can exclude and override the standard library to make an extended subset of the language, customized specifically for your purposes. So I've written a new version of print which outputs to my log sinks along with any script errors that occur. I've selected a few useful functions from the standard library and included them, such as assert, error, dofile, tonumber, and a few more. My dofile implementation doesn't work yet, but the intention is that it will access the requested script from the resource manager, rather than from a file, and execute in parallel (possibly blocking the original script until completion, but that depends).
Scripts run until they meet an operation that they cannot fulfill immediately; in essence, all script operations are blocking from the POV of the script. So I've written a wait system which can yield the script and only resume execution when the conditions are met. Currently, I only have a single-frame yield with no conditions, as well as a timed wait. More important uses would be to stop the script until an entity reaches its destination. Note that this wait system is transparent to the script writer; its implemented behind-the-scenes as the blocking mechanism for various functions that can't be fulfilled immediately.
I wrote the basics of the server-side auto-update feature. I'm planning to use pure HTTP because I've heard that it will prevent network monitors from popping up a box asking if the user wants to continue with the connection. To determine the current version, you just send a GET request to http://rosin.habitualhiatus.com/version/. To download a cumulative patch, you just send a GET request to http://rosin.habitualhiatus.com/patch/ with the base parameter set to your current version and the target parameter set to the target version. For example, http://rosin.habitualhiatus.com/patch/?base=0.9&target=1.3. The server side script (written in Python; how I miss that language) determines the most efficient route to get from your version to the target using incremental patches, and sends the concatenated patches as an application/octet-stream. Next up on the list is a patch file format (I'll use a standard one if the format is reasonable) and the client-side implementation.
I'm writing a linked-list utility object which will hopefully make it easier to deal with a certain data storage pattern I've been seeing in parts of my code (particularly in the script manager and some physics modules). I need the list to not modify pointers when an element is deleted, and it must handle arbitary insertion, deletion, and iteration efficiently. I don't need indexing support at all, so it would seem that the perfect scheme is the linked list. Its going to be a C implementation, so it should be an interesting experience. :)
On the art side, I've been learning Blender finally! Its actually not as easy as I was hoping. The workflow is probably smoother than a lot of other programs, but the key combinations are going to take a while to remember, especially considering I have to remember hotkeys from 3DS Max (for school) and Wings 3D. I already have enough trouble getting camera controls mixed up between them. The poly-modelling workflow in Blender is different from Wings to say the least and, as far as I can tell, not as efficient. So I'll be sticking with Wings for basic poly-modelling and UV mapping, and using blender for non-volumetric poly-modelling hair and clothing as well as animation. I'm avoiding 3DS Max because the school has the educational version which I don't want to taint my game content with, and the real version costs way too much. So I'll be trying to migrate all my Max skills to Blender for future posterity. Plus Blender uses Python for scripting which I'd much rather use than MaxScript, which seemed a bit convoluded last time I tried to mess with it.
Hm longer post than I expected... thanks for reading.