[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Adonthell-devel] Mapedit filtering
From: |
James Nash |
Subject: |
Re: [Adonthell-devel] Mapedit filtering |
Date: |
Wed, 1 Jun 2011 23:31:35 +0100 |
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
>