As I understand, it is possible to add ~ in front of a tag in searches to indicate you want result from any of these tags, for instance ~A ~B ~C ~D would yield AorBorCorD as result. However, is there any method to search for (AorB)and(CorD)? Other than separately run C + AorB and D + AorB
AFAIK, the only operators used in search are OR (~), NOT, (-), and the wildcard (*). Parentheses do nothing, and we wouldn't be able to use them in tags if they did. The allowed combinations are documented in help:cheatsheet.
The top 6 results for *_girl are the following: (magical_girl, monster_girl, demon_girl, bunny_girl, dragon_girl, flower_knight_girl)
Therefore, the above search query works out to be:
(girls_und_panzer AND kantai_collection) AND
(dog_ears OR cat_ears OR magical_girl OR monster_girl OR demon_girl OR bunny_girl OR dragon_girl OR flower_knight_girl) AND NOT
(comic OR everyone)
Wildcard search
Note that the wildcard thing can trip people up, as it doesn't do necessarily what you think it's doing.
Example (tag limit 12):
Search query: *_(cosplay)
The top 12 results for *_(cosplay) are the following:
hakurei_reimu_(cosplay)
shimakaze_(kantai_collection)_(cosplay)
hatsune_miku_(cosplay)
alice_(wonderland)_(cosplay)
kaname_madoka_(cosplay)
kirisame_marisa_(cosplay)
hestia_(danmachi)_(cosplay)
akemi_homura_(cosplay)
little_red_riding_hood_(grimm)_(cosplay)
tomoe_mami_(cosplay)
mash_kyrielight_(cosplay)
izayoi_sakuya_(cosplay)
Therefore, only the above will appear in the search results.
Wildcard searches aren't implemented here in the way you're thinking. As explained above, a wildcard search is functionally equivalent to a bunch of OR searches chained together; a *_difference search yields the same results as a ~height_difference ~age_difference ~size_difference search. The use of multiple wildcards in the same search (e.g. open_*e* partially_un*ed) is not supported (see topic #10395) and likely won't produce the results you're expecting. For the same reasons, you can't negate wildcards from searches, so adding -no_pan* to your search doesn't do anything.
Wildcard searches aren't implemented here in the way you're thinking. As explained above, a wildcard search is functionally equivalent to a bunch of OR searches chained together; a *_difference search yields the same results as a ~height_difference ~age_difference ~size_difference search. The use of multiple wildcards in the same search (e.g. open_*e* partially_un*ed) is not supported (see topic #10395) and likely won't produce the results you're expecting. For the same reasons, you can't negate wildcards from searches, so adding -no_pan* to your search doesn't do anything.
(no_shirt AND no_bra)
AND (open_clothes OR open_jacket OR open_hoodie OR open_vest OR open_dress OR open_blazer)
AND (partially_undressed OR partially_unbuttoned OR partially_unzipped OR partially_unbottoned)
NOT (partially_undressed OR (no_panties OR no_pants OR no_pantsu!! OR no_pangs OR no_panies OR no_pangties))
Would it be fit to request such a feature in danbooru?
As I explained in my post, all wildcards get treated as part of the Related (OR) group, which means ONLY ONE of the tags needs to show up for there to be a match. For the post #2939984, the post you indicated, it had partially unzipped, which matched partially_un*ed. That is literally it. None of the other wildcards matter since it found its match and therefore satisfied the search requirements.
Not true. It is supported, however they all only add to one giant OR group. ANY hit from ANY of the wildcards will produce a match.
For the same reasons, you can't negate wildcards from searches, so adding -no_pan* to your search doesn't do anything.
Mostly correct. What it currently does is subtract the literal tag no_pan* from the results. The same for the OR (~) operator. It adds the literal tag no_pan* to the Related (OR) group. Basically it does nothing though, as currently there are no tags with * in the name.
Not true. It is supported, however they all only add to one giant OR group. ANY hit from ANY of the wildcards will produce a match.
Ah, got it. Strange that this isn't mentioned in the wiki, yet there's a bit about not being able to combine wildcards with OR searches when in reality they seem to work just fine.
Ah, got it. Strange that this isn't mentioned in the wiki, yet there's a bit about not being able to combine wildcards with OR searches when in reality they seem to work just fine.
No the limit applies individually to each wildcard.
Given a Gold user with a limit of 6 tags:
brick_*
brick_wall
brick_floor
brick_oven
brick_(ppg)
brick_(borderlands)
brick_road
tile_*
tile_floor
tile_wall
tile_roof
tile_ceiling
tile_background
tile_mosaic
So the only one's dropped that I could see are brick_jock and brick_arch.
Gold users could theoretically have 6 wildcard tags in the search for a maximum of 36 OR'ed tags together. Platinum + could have 12 wildcard tags for a maximum of 144 OR'ed tags.
However, the one downside to wildcards is that you have less control over which tags get chosen. Additionally, they are not like inclusive terms. So with the above example, if any one of those 12 tags appear on a post, then that post counts as a match. To reiterate, it does not need to have a match from each wildcard, i.e. one from the brick_* group and one from the tile_* group.
I just wanted to add an addendum for what I posted in forum #142087 to cover how metatags are handled. Basically each metatag, both plain and negative, are treated as their own AND group equal in weight to the Inclusive, Exclusive and Related groups.
However, there is a difference in how certain metatags are handled in comparison to others. Some can have multiple instances, and some can only have one. In the latter case, it uses the right-most instance of that metatag in the search query string. There are some that are a hybrid of both, depending on what is used for the metatag.
Single instance
user:
approver:
ordpool:
ordfav:
md5:
rating:
-rating:
locked:
-locked:
-id:
source:
-source:
parent:
child:
order:
status:
-status:
filetype:
-filetype:
pixiv_id:
upvote:
downvote:
Single instance with ranges
These can only be used once in a tag string, but they can handle multiple instances by using comma-delineation, ranges (..), or comparisons (>,=,<)
id:
date:
age:
width:
height:
mpixels:
ratio:
score:
favcount:
filesize:
tagcount:
charcount:
copycount:
gencount:
artcount:
metacount:
Multiple instances
-user:
noteupdater:
artcomm:
favgroup:
-favgroup:
search:
Multiple instances with None/Any
None or any count towards their own instance, however any gets overwhelmed by any other instance, and none mostly overwhelms everything else.
flagger:
-flagger:
appealer:
-appealer:
commenter:
-commenter:
noter:
-noter:
Hybrid
-approver:
-approver:none/any is treated as approver:any/none
Other uses treated as multiple
pool:
none/any treated as singular (can't have both)
series/collection get added to the tag Inclusive group
Wildcards in pool name follow the same rules as tags
Any other pool name/id gets added to the tag Inclusive group
-pool:
-pool:none/any is treated as pool:any/none
Every other pool name/id/series/collection get added to the tag Exclusive group
Wildcards (*) are treated literally and also added to the tag Exclusive group
The ability to do arbitrary boolean searches is a longstanding feature request. Adding it would require rewriting most of the query engine, which would be a nontrivial job, for not much benefit given that searches this complex are rarely needed. Don't hold your breath.