[Adonthell-devel] Re: Revisiting render zones (and much more)

[Kai Sterker]

On Tue, Jan 26, 2010 at 10:00 AM, Kai Sterker <address@hidden> wrote:

> There is a bit more testing needed as well, but that has to wait until
> mapedit actually allows to define zones. So that will be the next item
> on my list (and hopefully the last bit for a useable mapedit v0.1).

Started working on that today, but truth to be told, it's yet another
boring bit of GUI coding. I'll try to get done with it, but may take a
little while.

I also get a feeling that the current zone implementation in the map
view might not be what we want. So far it excludes objects above the
render zone based on their position. But maybe it should rather
exclude them based on whether they would be rendered above the zone or
not.


Also, speaking about zones, I am wondering if we should introduce
another zone type. Kind of a trigger that launches an associated
script when entered/left. See

  http://adonthell.berlios.de/doc/index.php/Tasks:Map_Events

Related to that are interactions with map entities that will trigger a
description/comment of the player character when "examined". There
were quite a few of those in Waste's Edge, so we'd need a means to
recreate those for the v0.4 remake. My initial idea is to make the
description a property of the entity. Then the current action script
would be able to bring up the comment if no other interaction was
possible. However, that would leave text inside data files, with no
easy means for gettext to extract it for i18n purposes. OTOH, I think
this was the case in v0.3 as well, and I worked around this by copying
all those strings into a python script. But now that our data files
can be represented as XML, it should actually be possible for gettext
to extract translateable strings from them. (A little research into
this shows that intltool-extract can process generic XML files and
convert them into C headers readable by xgettext. So what I had to do
manually for v0.3 might be automated for v0.4, by extending our file
format to identify translateable strings. All that is required is an
underscore in the element name, i.e. <_string> instead of <string> for
our data files.

Guess that would be a worthwhile extension to our file format. And it
can be achieved easily by defining a new data type.

Kai