Labelling

Yesterday I spent some time revamping the way labels are shown on entities. Currently they aren't shown at all, unless the entity speaks. Then a little "talk bubble" widget is shown. If the entity has some suggested responses, they will appear as clickable buttons. But after a while the widget will fade and disappear. This makes for very bad usability, since it's not possible to easily see the names of any near npc or other players without clicking on them. And it's of course not the way that all other virtual worlds does it.
The plans is therefore to provide a better mechanism for displaying labels on certain entities. I've added a blueprint for this to the Launchpad. The first step is to refactor the quite inefficient way of showing the labels that are currently in use. Instead of creating new CEGUI widgets every time a new label should be shown, and then deleting them afterwards we'll keep a pool of reusable widgets. And instead of doing a lookup of the active widgets every frame we'll use listeners that we attach to the entities and the models to actively listen for events that tell us directly whether to show or hide the labels. Currently it's all still in C++, but the plan is to somehow separate the actual widget creation and rendering into Lua scripts, while keeping the heavy book keeping code to C++. This should also let us mark those avatars that are currently possessed by a human players. There's already an attribute ("external") which marks these, though it's not used. By providing a marking it should be much easier to interact in the world. Currently you often start out in a world with 20+ inactive avatars, with no way to discern which ones are actual human beings (granted, one of the design goals of the AI is that the npc's should behave like humans, but we're not there yet).
So far I've gotten to the stage were a new labelling backend system is fully functional and in use. The next step would be to extend the Model format with information on what entity types to show labels for. Or perhaps it would be better to put that information in the ModelMapping format as an Action? Hmm...