Re: [Adonthell-devel] Mapedit filtering

[James Nash]

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
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/adonthell-devel