Monday, March 15, 2010

1.8.2 Might be coming soon

Items are being marked off the to-do list pretty well now, so it's getting to the stage where I start speculating about possible release dates.

Of course I'm still going a little slower than normal with my work, but starting to build up some momentum now. However there are a few items on the list - like debugging fog - that I can't really guess how much time they'll require. Having said that it's looking quite likely that sometime towards the end of March (if not sooner) is one possible release date.

The latest work done was a little more on the sound system. We now have the old "Sound Options" menu back, and unfortunately even the so-called "Simple Menus" are now becoming a little full. What it does give you hovever is the ability to set sound parameters in-game without needing to go near the console or command-line, which I'd argue is a usability improvement that justifies it. (You can still use cvars or the command-line if you want of course, and sometime soon I'm going to add the cvar list to the CodePlex site).



The other big thing to be marked off the list is scoreboard ping in Multiplayer games. As I mentioned before I've put a few walls around this feature, so that it only gets parsed if you're playing with a valid gametype and connected to a Protocol 15 server. An extended protocol should just send pings to the client without needing any nasty hacks.

One final change for today was that I've restored the use of "config.cfg" and the Necropolis demo. I might yet make them optional, but for now they're back, as firstly I think that loading Quake and seeing e1m3 play is part of the charm and atmosphere, and secondly I think that using a different cfg file - while it may provide for better engine cohabitation - actually is a usability fault as it's doing something that the player doesn't expect.

Any comments on that from anyone?

3 comments:

xaGe said...

..Sounds good, no pun intended. I agree with your decisions here.

kempie said...

I really can't think of a situation where reading and writing a DQ cfg would be a bad thing. Skipping the console spam with unsupported parameters is a plus. Even if you load the default cfg you are still going to have to tweak things to get DQ running as you like it. Why write those settings to a default that will spam another engine's console.

Cheers, kempie

mhquake said...

Good point kempie. Like I said I'm still personally unsure about the whole thing; my real reason for reverting back to config.cfg was because it's familiar territory and expected by players, but otherwise there are advantages to a directq.cfg instead.