On Sun, Nov 6, 2011 at 12:35 PM, Kai Sterker <kai.ster...@gmail.com> wrote:
> But now I'll really be focusing on mapedit :-). Filtering by matching entities is in, as well as filtering by tag. Remains updating the grid based on connectors, if present. There is one minor issue with that, however. For the connector based filtering, the object currently used for drawing is used to filter the entity list. For grid adjustment, by default I will use the last object placed on the map, to adjust the grid to. That will work fine when working on some structure, where you place some objects, tab to the next entity you want to use, place that, tab to the next, and so on. But eventually comes the where you want to extend some other part of the map, and in that case you might want to have the grid aligned to an object already present on the map. Maybe, by picking an object from the map, this would make the grid adjust to this object next. In that case, you'd pick the object where you want to continue building, tab to the desired matching entity and it will adjust to the previously picked object. Sounds like this could work out well enough, after all. I also remembered that there is the whole topic of grouping objects in mapedit. Might look into that too, although it will take some time to prepare. But perhaps more important is making the map file format better suited for version control and distributed editing. That means no longer randomly numbering entities each time the map is saved, but giving them fixed, unique ids. These should be the same if two developers add the same entity independently from each other onto the map, but different for different entities. Maybe a hash of the relative path and file name of the entity. That would have to be implemented on engine side, when saving the map. As an alternative, each entity could get a fixed, unique id at creation time. That would work more like the connector template ids. And the case of collision could be resolved easier by manually editing one of the model files. So that's probably the better approach. Quite some stuff left to do, but looks like we're getting the editing tools into a pretty usable state soon. Now we only need users for them. And good documentation. Cheers, Kai _______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/adonthell-devel