No search feature? Everything but the kitchen sink!

[AngelWolf]

So I finally began work on my first FM. I drew up a map on some graph paper, re-created it in DR, played around with warp glass a bit, and then put on my interior designer hat and started to place objects. That's when I began to get frustrated. I want to place a sink in a kitchen area. I try models first....hmmm...what category might it be under? Ahah! Kitchen! Food, utinsels, plates, bowls, cups....a stove....hmmm....no sink. Waterworks maybe? Faucets, tubs, wash basins, wells....no sink. I start picking random directories looking for a sink...no luck. So, ok, maybe it's a prefab...hmm....Household? No. Furniture? Nope. Mechanical? Nada. So many catagories.....so many misc folders. I know I've seen sinks in the levels I've played so far...were all of them made by hand?

 

So that went on for about a half hour and I still haven't found a kitchen sink. I think the sheer number of prefabs, models, and entities is becoming unmanagable and could sorely use a search feature. A designer shouldn't have to jump through so many hoops to find what they are looking for. If I want to look at the tables availiable, I really don't care if they are a model or a prefab, or what directory/sub-directory someone decided to put it in. I just want to type "table" and see a list of all the tables, preferably presented as thumbnails so I can visually browse them. Going from directory to directory, clicking on each one to see what it looks like in the model viewer is tedious and gives me no way to compare similar objects. I could be looking through models, not realizing that what I'm really looking for is a prefab and vice versa. So I guess this is basically a feature request combined with my intention to make such a feature if someone else doesn't speak up.

[STiFU]

That is in fact something nice to have and usefull. I'll add it as a featurerequest to the bugtracker later. It should basically be added to every browser: sounds, models, entities, textures.

[Melan]

Yeah, it is a good idea for a feature. Searching for entities by name, too.

[SeriousToni]

Hey, try:

 

Insert Model -> Click on "darkmod" folder -> Press Shift+Right Arrow Button -> type the words

 

scan by pressing arrow button down / up

[Bikerdude]

So I guess this is basically a feature request combined with my intention to make such a feature if someone else doesn't speak up.

I already have several kitchen sink prefabs, I really nned to get around to uploading them somewhere.

[SeriousToni]

I already have several kitchen sink prefabs, I really nned to get around to uploading them somewhere.

 

1.08 !!

[STiFU]

Bugtracker'd!

 

Might actually be a good task for me in the next holidays...

[Bikerdude]

1.08 !!

Oh yes I forgot I added them to 1.08, sweet!

[Xarg]

This happens to me all the time... you'll often find what you're looking for in the weirdest place, or never even find it at all until much later when looking for something else. The amount of frustration it's caused...

[demagogue]

Looking at the options, I could go with tagging, as long as I knew what tags were available so maybe there should be an alphabetical list of tags somewhere. But then you could search for "windows" when you want windows, "church" when you want things for a church, and maybe things like "city" vs "crypt" vs "village" families... The whole catch is your search-criteria varies by the task at hand, and tagging skirts around the hierarchy issue altogether.

[STiFU]

We've had a few posts on the bugtracker entry about that. You should check that out. The theme definition approach seems to be a lot better. By the way, the tagging discussion was in another thread... ;D

[Springheel]

Looking at the options, I could go with tagging,

 

How would tagging work with models?

[AngelWolf]

Just wanted to add a few details to the feature request in the bugtracker. I would change the right click menu to say insert asset rather than create model, create entity, etc. Let the browser itself tell the designer what's what so it can list models alongside entities and prefabs. Keeping the assets in separate categories each with its own browser is part of the problem. The other point I want to emphasize is visual browsing. Every asset should have a thumbnail picture to make it easier to choose. It slows down my workflow when I have to click on each item to see what it looks like. I usually already have a general idea of what I'm looking for so my eye is just looking for a match. Looking through a row of thumbnails is far more efficient.

 

Proposed Workflow:

Right-click 'insert asset'

Browser opens in search mode. Search for 'table'

Browser shows thumbnails of all the table assets in the game with names and data types shown below the thumbnails.

Designer picks out the table that has the look/style they were imagining and places it in the game.

 

I could pick out the table I was looking for in a few seconds, rather than the minutes it takes to look at each asset in three separate browsers.

 

Taurus philosophy:

Give me a hammer and tell me I have 6 hours to break up a 2 inch thick layer of ice. As soon as you walk away I'm going to use some hot water and salt so I can take a nap for the remaining 5 and a half hours. Taureans hate wasting energy and if there's a more efficient way to do something they will find it.

[Obsttorte]

but where to get the hot water?

Edited October 11, 2012 by Obsttorte

[Tels]

+1 to the "tagging model". Searching for things by tags/keywords works much better than a hirarchy because we don't have a good hirarchy and never will get one (is a brick+metal texture under stone or under metal? etc)

 

+1 to the "search feature described in post 13", selecting assets is a royal pain unless you memorized all assets already and know where they approximately are (is the weapon I am searching under "kitchen knife", "dungeon torture knife" or under "pagan ritual weapon knife"? etc) Selecting sounds is the most painful of all of them, because they are completely unsorted (sorting them alphabetically is the worst order because the d3 sounds are starting with the level where they are used and all TDM sounds start with "tdm_".)

 

The only addition to #13 search is that there need to be filters (show only models, show only entities, or sounds etc) because sometimes you know you look for an entity and don't want the models. (This distinction is nec. due to how the engine works and mappers need to choose what they want. Substituting a model for an entity and vice versa is not really possible in a lot of cases).

[STiFU]

At this point, I would just like to point out once again, that the tagging-proposal was related to a whole different issue and has been discussion in a whole different thread for that matter. Here we are just talking about adding a searchbar to the different browsers! But aside from that, on the bugtracker we have more or less decided against tags in favor of theme definitions, for various reasons pointed out in the issue discussion on the tracker. This model could very well be extended to all sorts of content, instead of just textures, and also allow searching for themes.

 

And one other thing, while Angelwolf's suggestion does sound good, it also makes the little sideproject of implementing searchbars a pretty big one.

[Tels]

Ah well, discussions on the bugtracker are invisible unless you follow the tracker (which I only do if I'm involved in a bug).

 

Buw anyway, how does a "theme" differ from a "collection of things tagged with 'nameofthetheme'"?

[STiFU]

The difference is the direction of association. Tagging is a bottom-up association, where you assign a tag to each element and multiple elements form a taggroup, whereas the proposed theme definition approach is a top-down association, where you define a group (themename) and add elements to it. If you want to alter a group of textures, you can just edit the theme definition whereas in the case of tagging, you'd have to visit each contained material. Other than that, you can also use themenames that create a virtual folder structure, just like the material definitions, which wouldn't make a lot of sense in the case of tags and it's bound to get messy on the long run. Theme definitions furthermore allow for easy sharing of themes without altering any existing files. Tags on the contrary are generally added in the meta-info of elements, hence material definitions would have to be altered, which is a no-go. Everytime you want to alter your tabgroups, you'd have to redistribute the material definitions... Sure, you could add some sort of meta files storing the tags, but that's not true to the tagging concept and if you store them in external files anyway, you can just as well go the clean top-down way. Also, a simple typo would add a material to a different tag-group. This can't happen with theme definitions. The worst thing that could happen is, that an element is missing, which you can easily correct by looking in one single place.

 

As you can see, I am quite fond of the theme definition approach, although I initially suggested myself. But Bikerdude had the idea of material-playlists, which led to the concept of theme definitions.

[demagogue]

How would tagging work with models?

 

... furniture, weapon, kitchen, bedroom, utensil, loot, wearable, architecture, plant, door, readable, wood, metal, glass... All the major features of a model, I suppose. It would be even less categorical than textures I imagine; just feature tags. The idea is you're searching by tags, and narrowing the field with tag combinations (furniture kitchen, utensil kitchen, furniture bedroom, utensil bedroom, etc.)

 

But I didn't imagine it as a *replacement* for a tree, just going on in parallel to it.

[Tels]

The difference is the direction of association. Tagging is a bottom-up association, where you assign a tag to each element and multiple elements form a taggroup, whereas the proposed theme definition approach is a top-down association, where you define a group (themename) and add elements to it. If you want to alter a group of textures, you can just edit the theme definition whereas in the case of tagging, you'd have to visit each contained material. Other than that, you can also use themenames that create a virtual folder structure, just like the material definitions, which wouldn't make a lot of sense in the case of tags and it's bound to get messy on the long run. Theme definitions furthermore allow for easy sharing of themes without altering any existing files. Tags on the contrary are generally added in the meta-info of elements, hence material definitions would have to be altered, which is a no-go. Everytime you want to alter your tabgroups, you'd have to redistribute the material definitions... Sure, you could add some sort of meta files storing the tags, but that's not true to the tagging concept and if you store them in external files anyway, you can just as well go the clean top-down way. Also, a simple typo would add a material to a different tag-group. This can't happen with theme definitions. The worst thing that could happen is, that an element is missing, which you can easily correct by looking in one single place.

 

As you can see, I am quite fond of the theme definition approach, although I initially suggested myself. But Bikerdude had the idea of material-playlists, which led to the concept of theme definitions.

 

What I was trying to get at that there is no real difference. The end result is the same.

 

The biggest drawback to the "theme" thing is that to create multiple themes, you have to visit almost everything mutliple times - or make one grand swep through things and assign the into multiple themes - at which point you might just as well "tag" them.

 

For me this is semantic hair splitting, regardless on wether you use:

 

* theme A: contains element a, b,c, d

* theme B: contains element a, b,x, y

 

or:

 

* element a: tags A, B

* element b: tags A, B

* element c: tags A

* element d: tags A

* element x: tags B

* element y: tags B

 

The result from a point of getting the search result is the same, search for A and you get the same "set" in both cases. Just the storage is a bit different laid out.

 

You are storing the same information in both cases, and with the over 10000 "things" we have in TDM (possible 15..20000), you need some sort of central storage and editing, anyway, because there is NO WAY you are gonna sort 2000 material shaders into themes, or tag them manually, and then repeat the same for sounds, particles, skins etc.

 

Edit: Searching for "A" is a bit easier with the themes, because you can just "take" everything in the theme. But thats a storage algorithgm difference, and needs not to be visible to the user. The idea here is that a theme works good if the users wants anything in the theme, but breaks down if you add search modifiers. Like "give me everything from theme A but no sounds, and then add every entity from theme B". At this point the user might as well say "give me everything tagged with A except sounds, and every entity tagged with B" and there is no difference in output. Just that parts and mixing themes makes no so much sense as just saying "give me a list of things that match these tags", which essentialy is.

 

The "theming" thus leads the user to believe they get something different, which they don't.

[STiFU]

Yeah, what the user sees in the end is nearly the same, aside from the virtual folder structure (VFS). I was mostly talking implementation, cleanness, error proneness and data management.

 

The VFS can be used to sort groups into categories, e.g.

 

rooms/bathroom/luxurious/bright

{

Element A, Element B, ...

}

This will be usefull, as you can create a theme browser (in which you can also just search of course).

 

Also, I had suggested a very comfortable theme editor. In any browser you can just click "edit ..." or "create theme" and add elements to the theme by simple checkmarking them. But we wouldn't even need an editor for themes, as the information would be stored all in one place, so that one could edit it without any problems in a texteditor.

[demagogue]

The problem with a "theme" system (I think) is that it's forcing the assets into categories they may not fit well into or that don't make sense; or I mean it's forcing the mapper to think in terms of discrete "categories" at all, when that may not be most effective. Whereas a tagging system doesn't impose any "system"... Tags are completely open-ended, and could be at any level of scale or heirarchy -- you could have: bathroom-furniture, made-of-wood, Victorian, X-author's set, good for triggers, items for a bookshelf, architectural, magic, etc, etc... as tags, but not all of those categories make sense as discrete themes with other co-themes at the same level. I guess this is a longwinded say tagging more intuitively lets you target what you want without imposing a structure you have to wedge it into ... just a totally open field of tags from any walk of life.

 

Edit: This is not to say tags should be arbitrarily specific. There should be tags of general categories too of course; even these will be the backbone of the system. But the whole point is tagging allows multiple layers, so you can use the general category tags to start your search, then ween it down with increasingly specific tag sets, whatever is best for the asset set. Some asset sets, or especially combinations, will categorize differently than others, and tagging is ok with that.

 

Edit2: The image I have in my mind anyway is like a photo-collection tagged collection. There's an opening page with a tag cloud with the most common basic tags (general category) the largest in size and minor ones smaller, which you click on and then you get a browser with that set of textures. Then on the left hand bar will be all the tag-combinations within that set (other tags textures in the set are carrying; then in parentheses maybe the number of AND-textures it'd filter down to / OR-new textures they'd bring in), the major tags again larger or highlighted somehow, which if you click one of those new tags, it'd filter the browser to show the AND set. And maybe there's also an option so you could have an OR set and get both (or even select a new OR set from the full tag cloud), which adds new textures into the browser window, and also new sets of tags in the left-bar (the new tags carried by one or more textures in the new set). Also there's a place you could back out of a tag to cut that subset out. So you could open up & winnow down the set as you desire. It ends up a kind of way to browse through the whole collection by navigating through tag AND/OR combinations. Also there's a search bar where you could type in a tag at any time also.

[Xarg]

If nothing else, I'd sure appreciate breaking the sounds folder in DR into "music/ambient" and "AI" and maybe, with the 200 new impact sounds added, something like "weapon" or "impact", so if I'm looking for the sound of a club hitting a metal door, I look in the weapon/impact folder, a quick guard saying would be under "AI" and one of the ambients for streets would be under "music/ambient". Unless this has already happened in the latest DR build, as I'm still using 1.70, in which case disregard

[STiFU]

Edit2: The image I have in my mind anyway is like a photo-collection tagged collection. There's an opening page with a tag cloud with the most common basic tags (general category) the largest in size and minor ones smaller, which you click on and then you get a browser with that set of textures. Then on the left hand bar will be all the tag-combinations within that set

That does indeed sound very good. But this approach is not limited to tags. You can very well do it with themenames as well. I mean, it's not like you can't have one texture in multiple themes. You could have Theme-VFS-based browsing, where the themenames are interpreted as a virtual folder structure, just like the material definition names, or you could toggle the browsing style to tag-like, where each single virtual folder of the vfs-path of the themes a texture is contained in is interpreted as a pseudo-tag. For example, our material is in the themes "architecture/doors/bright" and "wood/doors" or something like that. Said material would then have the pseudo-tags architecture, doors, bright and wood.

 

This way, we would combine the advantages of both approaches and not limit our selves to category-thinking.

[demagogue]

I admit they work similarly and I might be making more difference than I should, and if you could toggle back and forth maybe all the better.

 

I'm just thinking of examples like, e.g., a collection of textures that have little to nothing in common with each other but there still might be a reason to collect them together... You wouldn't really call it a theme or work with it like that I think. Like items with detail work on them, or orange colored, or have a flower pattern, or spooky... And it's collecting dishes & chairs & wallpaper all under the same heading. You wouldn't really say they're thematically linked since they're very different objects, and I don't think you want to hierarchically nest them... Just it's useful to have them together under this one heading for this one shared feature... Like you've got all your doors and want to winnow it down to a specific feature (scratched up, a color, a design)... Or for that matter even non-visible shared features like author, or "Used for X's FM", or from X CG-website, or my favorites, or for FM1, for FM2, etc ... if mappers can set up their own categories.