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:
<<inline: mapedit_autocomplete_1.png>>
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:
<<inline: mapedit_autocomplete_2.png>>
Now a button (the tab key perhaps?) will pop-up the possible auto-completions:
<<inline: mapedit_autocomplete_3.png>>
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:
<<inline: mapedit_autocomplete_4.png>>
Once you've got the one you want, you hit enter to confirm:
<<inline: mapedit_autocomplete_5.png>>
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 >> 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