A few more updates were just done, including fixing one extremely rare crash bug. This one only occurred when surface extents were greater than 1008; DirectQ allows for extents up to 2032 (i.e. LIGHTMAP_SIZE * 16 - 16) but when I reduced LIGHTMAP_SIZE to 64 I didn't also reduce the max surface extents. This could have caused a buffer overflow, and consequent crash, in maps that had really really large surfaces. I don't consider it serious enough to warrant a more immediate release, as the bug only occurred in maps that has surface extents well in excess of what ID Quake allowed.
The fix was to increase LIGHTMAP_SIZE back to the standard of 128. Tests indicate that use of 64 is slightly faster, but the increase is somewhat marginal and being able to support larger extents seems preferable to me right now.
I'm probably going to go back to the lightmap code at some point in time and allow variable sized lightmaps, as a more general solution is preferable to my way of thinking. The default will be 64, but a lightmap will be able to be generated at 128, 256, 512 or even higher if required.
Another change came from an Inside 3D discussion here. This is quite a nifty solution to the problem of exponentially slow anti-wallhack, which is also applicable and useful in single-player games. As a result of having done this I've been able to switch the default value of sv_cullentities back to 1. It was originally defaulted to 0 as I had felt that it was just too slow to justify being on by default.
Credit needs to go to LordHavoc for the suggestions and discussion leading to this.
As well as behind-the-scenes changes I like to have something more immediately visible in each release. I've been thinking a little about what this could be for 1.7.2, and right now I'm leaning in the direction of PK3 support. The plan is to port the Q3A code so that there won't be any dependency on external DLLs (something I hate). It's not final yet, but right now it seems to be something useful that could be easily enough done.
Of course, there are other consequences. PAKs are easy to work with as I can just create a FILE * pointer (or a HANDLE in this version of the code) in the main COM_FOpenFile routine and then read normally elsewhere if that's the way I want to load the file. I'll probably end up extracting to your temp directory and creating a HANDLE on that instead, but it's still early days and all liable to change as soon as I start writing code.
As for a release date, I'm happy to say that I finished on my legacy codebase stuff in work on Friday just gone. I am off on holidays/vacation/archaeology-trip-stuff for a while shortly though, so roundabout mid-October I'm planning on being sufficiently unwound and relaxed to launch into this again, with an objective of a late October release. This is a month later than I had originally planned for, but things don't always work out.