Re: [Adonthell-devel] Mapedit filtering

[James Nash]

Ok, I've done a quick'n'dirty UI mockup of the mapedit auto-complete I was 
trying to describe:

So, let's say you've just put a wall piece on the map:

Assuming the wall piece has a connecting surface defined in its meta-data, then 
moving the cursor over it will give some kind of visual indication. For example:

Now a button (the tab key perhaps?) will pop-up the possible auto-completions:

In this case it's suggesting the same facing wall piece initially. Pressing up 
/ down (or scrolling with the mouse-wheel) selects one of the other completions:

Once you've got the one you want, you hit enter to confirm:

Done! ^_^


Using something like this building a wall could be done really quickly with 
relatively few clicks / button presses.

What do you think?

Regards,
                        - James



On 1 Jun 2011, at 22:44, James Nash wrote:

> 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
>