Balance

After releasing the beta 1 of 0.5.0 I've gotten some nice feedback from both Al and Simon, mainly related to gui and user interaction issues. As a developer it's too easy to become accustomed to all the quirks and inconsistencies in the interface, to the point that you don't notice them any more. Therefore it's great to get some fresh outside perspective on the player experience. I've fixed most of the issues in cvs and should publish a beta 2 soon. I still haven't looked at getting it to compile on Windows though. Hopefully roger will be able to provide me with a working compilation solution.

One thing that's still bothers me is that the world doesn't look as good as it should be able to. There's still a lot of rough edges and bad lightning. The main reason for this is that I've focused on providing other functionality, such as editing and underlying frameworks for scripting, model definitions etc.. There's tons of things that could be done to improve the look, chief amongst them is to make better use of shaders. Currently there's pretty much no shaders used at all. In previous versions I've used shaders for the terrain, but since I got some strange artifacts on ATI cards I disabled that. Using shaders I would get a much better looking terrain, as well as a nice speed boost (since I don't have to do the multipass texturing I do now).
Another thing which would improve the look a lot would be some normal maps on the characters. The current vertex lightning makes them look very blocky and jagged. With normal mapping and per pixel lightning it would be possible to give them a much smoother look.
As I've gotten the entity editor in a working state I'm gonna take a closer look at some of these issues. It's a shame not to utilize the many, many nice features of Ogre.

Navigating

I've added two improvements to Ember that I think a lot of people will appreciate. The first is finally putting in checks so that the camera never dips below the terrain. In the end it wasn't that hard to do, I just had to make sure it wouldn't bring everything to a crawl due to massive ray checks. It's still not perfect; when the camera is close to the ground it will still show some of the underworld as it pokes through parts of the terrain. I'll see if I can enhance it to use a more smoother algorithm for positioning the camera a little bit above the terrain.
The other thing I added was terrain decals for showing where the avatar was heading when using the "move to" functionality. It looks really nice and adds some visual hints to the user. Some screenshots of it in action.
Right now it's used for the movement marking only, but it could be used for all kinds of nice in game markings.

Release

I finally got a beta1 of Ember 0.5.0 out. An announcement can be found here. No Windows version this time since I haven't even began looking at the windows build. And also because I got some offers on helping out with the Windows build.
It's always hard to do a release, mainly because I have to halt adding new features for a while and focus on fixing bugs and handle package peculiarities. Basically all development is put on hold until the release is out. Now, this has gotten better as I now have more helper functions in place, but it's still a break from the normal progress.
This last week I've focused on finding and fixing all of the lingering memory corruption issues. I've managed to hunt most of them down I think.
I also reworked how binreloc was integrated. This only applies to Linux builds, and basically means that Ember can either be built as a normal UNIX app with hard coded paths, or as a "relocatable" app where all paths are relative. The main issue is that the "ember" script was meant to be run if you wanted the relative paths functionality, while the "ember.bin" executable was meant to be run if you wanted the standard behavior (for example if you compile from source yourself). This is of course unnecessarily confusing, so it's now changed so that the "ember" command will always work.