Buggers

I've been spending the last couple of days finding and fixing smaller bugs in the Ember codebase. The client itself is pretty solid, I very rarely get crashes, and when I do I can most often fix the underlying problem right away. But then there's the issue of shutdown... It's so much easier to not clean up and instead just exit the application, because it doesn't really matter if there's a segfault when shutting down; the memory is about to be reclaimed anyway, right? Well, there's the problem with sockets and other data structures that aren't that nicely shut down when the app crashes. And there's the issue with shutting down partially and then restarting, like disconnecting from a server and the reconnecting. And so on...
As I wrote in this entry I started Ember as a project to teach me C++, so initially I didn't care much about proper resource handling, because there were so many other things that I had to wrap my head around. But not so any more. Which means that I have to fix all of those lingering problems with resources not being released as they should. The most common culprit is Ogre, CEGUI and Lua. The interdependencies of these libraries forces me to be very careful about how I both acquire resources and release them.

I'm thinking it's about time 0.5.0 was released. The thing is that I always dread doing releases because it means I have to put development on hold for usually more than a week while I try to package Ember for both Linux and Windows. The latter one is always the most time consuming, since I do all development on Linux and then port to Windows at release time. So far I've used gcc and the automake toolchain for Linux and Visual Studio for Windows. This means however that I always have to update the Visual Studio project every time I do a release, and more worrying; that I have to work around all the missing features in msvc (compared to gcc). I'm thinking that it might perhaps be better to set up a mingw system on Windows so I can use gcc for both platforms. If I can get the autotools to work on Windows that would be even more excellent.

Move dammit!

Yesterday I implemented the ability to double click on the terrain and have the avatar go there. It's something that users have been requesting for some time. I've put it on the back burner because I'm myself so used to moving by using mouselook and wasd, and I was hoping that it would be one of those simple things that aspiring developers could tackle to better getting to know the code. All of the functionality already existed in both Eris and Cyphesis, I just hadn't done the connecting. So in the end it took no more then 20 minutes to implement it. Double clicking in the world now makes the avatar move.
The mouse picking system is very flexible and extensible. This flexibility is what allows us to react differently when the user clicks on an entity to when clicking and dragging a world base point in terrain editing mode. It's also what makes an addition such as this so easy. Ember development sometimes feels frustrating because so much work has been put into making base architecture and functionality, without any obvious "external" improvements. But it feels good that at least some of that work pays off. :)

Collisions

Ember uses Opcode (coupled to Ogre through OgreOpcode) for mouse picking. Opcode is a generic collision detection library and could probably be useful for many different things, but currently it's only used for mouse picking. The version used is however many moons too old and also a WIP prerelease. I've been itching for some time to upgrade to a more modern and robust version. One of the things that I've missed is the ability to do raychecks without backface culling. Not being able to do that results in not being able to pick the market stalls from behind, since the fabric is a single face where the material has backface culling turned off.
This weekend I finally took care of this nagging issue by upgrading to the latest version of OgreOpcode. It took 2h to upgrade the code, and then 4h of hunting down why no symbols could be found after the update. It turned out that it's not a good idea to use "," as delimiter in Makefile.am files (instead of the preferred " " version). Ah, the joys of stupidity.
Opcode is however not actively developed, and uses some dodgy "optimization" techniques, resulting in the code being nigh unreadable. It's working for me right now though, but if we in the future get cramped by it it might be wise to pursue other options such as Bullet.

Delisting?

By chance I went over to the wikipedia entry on Worldforge to see what it said. Not so good things it turned out. Apart from devoting a full third of the entry to "Problems", it said nothing of the different clients, the feature set of servers, the media repository and so on. Instead there's outdated and totally incorrect information (branching out into other parts of entertainment?).
What's worse however is that there's a notice now that there's not enough "notability" and that the article will be taken down unless it's filled with more information. Now, I've previously haven't wanted to touch the Worldforge entry on Wikipedia because I understand their position on preventing bias and avoiding original research. As one of the developers of Worldforge I'm quite biased. And therefore I've felt that it would be better if some of the regular Wikipedia editors gathered the information needed and updated the entry.
But it obviously doesn't work that way. And faced with the prospect of disappearing from Wikipedia I had to update the entry with some correct information. I added an software info box and added a screenshot of Ember, but I'm not sure how much more I should add.
I don't want to astroturf, and I fully understand that Wikipedia wants to keep the database clean. If Worldforge isn't notable, well then it shouldn't be there, just as so much other information that's added to Wikipedia every second. But I with my full heart don't believe that, and I think it's more of a case of a neglected entry. There's so much to write about Worldforge, about the clients, the tools, the servers, the AI, the Atlas protocol, the Mercator terrain generation etc.

Adapting

Currently I've been working on the Entity Editor widget. The idea is to allow for world builders to edit every aspect of entities in the world.
The properties of an entity are very loosely defined. Apart from some standard attributes, such as position, id, name, orientation etc. WF puts no specific constraint on the attributes. So, for example, it's possible to create an attribute with the name "age" which is a map of two strings. Such an attribute would of course make no sense. So I'm trying to present some more user friendly representations to the user of the most common attributes.
An example can be see here, editing a settler. With the exception of "bbox" all attributes are shown using the low level representation widgets. So for example, the "guise" attribute is a map, which contains two other maps, named "material" and "mesh". The "material" map in turn contains three string values, identified by the names "dress", "head" and "pants".
The bbox on the other hand is presented with a "Size" widget. In essence, the "bbox" attribute is just a list of six float values, but using the regular List widget to present that would just be cumbersome. In addition, there's no point in removing or adding another value to the list, something that the List widget allows. Therefore, a Size widget is used instead.
So far I've created specific widgets for Size, Orientation, Position and 2DPosition. The latter one is used in areas where the area is defined by a list of 2d points.
By adding more specific widgets I'm hoping to make it much more simpler for world builders to update the world.

Expanding areas

Well, turns out there's still some work to be done in the area department. Mercator has some missing methods in the area handling code. For one thing, there's a Mercator::Area::setLayer method signature, but no implementation. I don't know however if it makes much sense for an area to change it's layer once it's been created; perhaps that's why it's missing?
In addition, when an area is added to the terrain, through Mercator::Terrain::addArea, there's no corresponding removeArea method. Writing such a method is however not completely straight forward since when an area is added to the terrain, it's in turn added to only those Segments that it intersects. One would however think that when removing an Area all one has to do is to iterate over all Segments and remove it when found.
The third problem is that since an area only is added to those segments that it intersects, problems arises when an area is either moved to another segment, or changed so that it now intersects another segment. The effect is that no shading will occur on the new segment. The solution for this would be to add a new method Mercator::Terrain::refreshArea(Mercator::Area* area) which will iterate through all segments, and remove the area if it no longer intersects the segment, and add it where it does.

Also, I had to restart cyphesis since all the NPCs had died. They start out at full health, but since they never eat, they eventually starve to death. When restarting I took the opportunity to update to the latest cvs version. I also added some boulders to the landscape. We have some very nice boulder meshes that Jay did, along with a nice texture, but for some reason it's not used. A normal forest landscape is filled with all kind of boulders. The result can be seen here. Note that the shading of the boulders for some reason is a little bit strange; I'll have to investigate why that is.

The areas of my expertise

I went away over the weekend so I didn't have much time for Ember, but I did manage to fix another one of those things that have been bugging me for a while.
While Ember has supported areas for a while, it hasn't allowed for dynamic updating, either of changes to the area itself, or the position of the parent entity. So yesterday I set out to try to rectify this. Turned out that it was really simple to make that happen. Some new events on the TerrainArea class, some listening glue and some TerrainGenerator logic later it all worked. It's now possible to edit an area on the fly and see the updates directly. The area will also be moved when the entity is moved.

In addition to that, I finally found and fixed a bug in the EntityEditor which made refreshing take ~5 seconds. That's quite the leap from the 0.02 seconds it used to take, so I was a bit perplexed by what might cause it. Turned out that I had accidentally created a int-wrapping loop, which looped from 1 to 2^32. Oh well...

In other news, Ogre 1.4.2 was released today. No major changes as far as I can see, but this version will contain a fixed OGRE.pc file, which will make Ember's configure.ac work as it should.

Back from vacation

I haven't posted to this blog in a long time, mainly because I didn't have anything to say and I didn't think that anyone would be interested in the things I didn't say either.
However, I'll try to rekindle the blogging flame by posting more about my work on the Ember project. I feel that it would be nice to have a record of the development process, mainly for myself. So...

I'm currently preparing an Ember 0.5.0 release. The main reason for the jump from 0.4.3 is that I'm now using Ogre 1.4 and CEGUI 0.5.0. Mainly the latter includes some main improvements.

Apart from those upgrades, I've been focusing heavily on creating intuitive authoring widgets. Ember, and indeed the whole Worldforge project, has been lacking good authoring tools. Currently, if you want to set up your own world, you need to hack the python and xml files of cyphesis by hand. And then there's no easy way to alter existing entities. Sure, there's the cycmd tool which allows for console type editing, but that's not really a smooth experience.
Thus I've now incorporated a new framework for editing entities into Ember. It's using adapter classes to bridge between CEGUI and Eris, with Ember handling the connections. I would really have wanted to go MVC all out, but there are some things in CEGUI that prevent that. Instead I've tried to take it far enough.
One problematic area has been to properly divide the structure into C++ and Lua code. The former is much more powerful, and adds compile time checks, while the latter is more dynamic and allows for run time editing. The overarching idea is that all layout related code should be handled by Lua, while most of the other logic should be handled by C++. I think I've succeeded in part, but there are still some rough edges. And it's never a clear cut case where some part of the functionality should go.

Yesterday I needed to take a break away from the work on the editor (mainly to get my bearings on where the code is heading) and work on some smaller issues. One of the things that have been bugging me for some time is that wielded entities aren't correctly aligned. This is because the hand bone to which wielded entities are attached to isn't really meant to be used for attaching entities, and thus attached entities needs to be adjusted for that. I've planned to add a rotation adjustment setting to the modeldef xml format for some time, but I never had the time. I was also hoping that this would be one of those things that would be excellent as an introductory task for a new developer. But sad to say so far no new developers have contributed anything to the project. It's been a one man show since it's start, with the exception of some greatly appreciated help from Hagen with the console.
So yesterday I finally took care of this issue. It's now possible to specify the rotation needed to get a wielded entity to align properly. The only thing that's missing now is an easy way to edit this in the ModelEditor.