On Tue, Jan 26, 2010 at 10:00 AM, Kai Sterker <kai.ster...@gmail.com> 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 _______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/adonthell-devel