My 2p on the filtering: Perhaps it's better to reflect the directory structure of the models in mapedit for now. Related wall parts and suchlike are already grouped in a single directory, so we can exploit that. Perhaps have one pane/dialog/whatever with collapsible directories (like Windows Explorer) and another which then shows a list of mapobjects within the currently selected directory.
As far as the templates go, there are a few simple options for hiding them: - We just move them out of the gfx48/models48 directory trees and keep them separately somewhere else. - Or: In mapedit we just hide any directory whose name matches *template* (possibly this can be enabled/disabled via a tickbox somewhere). Ultimately though, I think meta-data that describes which mapobjects fit together and user-defined tags are the way to go. Once we have a format for such data and have augmented the mapobjects with it we can do much better filtering. IMHO, finding mapobjects that way will ultimately be the default, so users don't need to know or care about the directory structure. I think the meta-data topic deserves a bit more discussion first though. Off the top of my head, I'd like support for stuff like: - User-defined keywords (aka tags) to help categorise the mapobjects - Descriptions: I'm thinking a free text field where designers can put comments about intended usage, tips, instructions etc. As for describing how objects fit together, I'd propose something like the following: - We have something that describes the surfaces where two related objects touch. E.g. the left & right vertical sides of a facing wall piece. When tiling that piece, the left side of one touches the right of the other. Let's call it a "connecting surface" for now (can't think of a snappier name right now). - This connecting surface would most likely be created in the modeller as a special kind of shape. It is saved as an individual file though. - It gets a unique ID assigned to it (probably automatically) - Possibly it has an optional, user-friendly display name too - Then, when creating actual object in the modeller you can import relevant connecting surfaces and position them on the model. The idea is that you describe where any other object that contains the a connecting surface with the same ID can connect. I think this is preferable to, for example, explicitly linking from one object to another since that can quickly become a maintenance nightmare when you get lots of objects. Later on, the mapeditor can use this meta-data to suggest the next object to place on the map. I imagine this to be a bit like auto-complete in an IDE or browser address bar. E.g. I put an object on the map and as I move the mouse cursor near one of its connecting surfaces I get some kind of indication that there is a connecting surface (maybe it lights up or I get a different cursor). Some key or button press then displays a new object that is connected to the previous one (maybe it's duplicate of the one I just placed initially) and using some other button I can cycle through other available objects until I find the one I want. Hmm... this'll be a lot easier to describe in picture. I'll make a quick UI mock-up. brb! - James On 1 Jun 2011, at 19:49, Kai Sterker wrote: > Seems I've ran into a bit of trouble with my tag based filtering idea > for mapedit. I've attached the filter dialog I've implemented so far, > but I'd like to get some input on the underlying logic. > > Basically, there are two ways to filter the list of map objects: show > only objects that "match" the current object, i.e. all objects that > could possibly be placed seamlessly next to the current object. Since > the meta-data for this feature would have to be supplied by the user, > I did not start on this type of filter yet. I've got some concept in > mind and I don't expect much trouble there. > > I did start with the supposedly easier, tag based filtering, where the > components of the model path make up the tags attached to each model. > (In the future, this might be extended with user-supplied tags, too). > The result of the current model48/ content is shown in the filter > dialog screenshot (The Count column gives the number of models with > the given tag). > > My idea was, to automatically exclude the "template" stuff from the > model list, but in a way that would be obvious to the user. So it's in > the list like a regular tag, but unchecked by default. Going with > that, the filter logic would have to be "hide all objects that contain > 'template/' in their file path". But then I thought, when editing a > map, I might want to see all "inside" "walls". And it would be easier > if I could just check those two tags to narrow down the list. But that > would also include all the inside wall templates. And now I am stuck, > not really able to decide which route to go. > > Maybe just hardcode the template stuff filtering and otherwise go with > the latter filtering logic? > > Or there could be two columns of checkboxes, one for inclusion and the > other for exclusion. Then I could include "inside" "wall"s and exclude > "templates" at the same time (and "stone" and "mine" and "cave" walls > too, if I wanted), OTOH, perhaps I'd be better of to just filter for > "plaster" "walls" then. > > Anyone got a better idea? > > > I've got some stuff to work on besides the filtering, so I'll let that > sit for a little and wait for your suggestions. > > Kai > <filter.png>_______________________________________________ > Adonthell-devel mailing list > Adonthell-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/adonthell-devel _______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/adonthell-devel