Feature suggestions and discussion [READ THE FIRST POST]

@DanielTepesKraus  
@PartTimePegasus  
I third Numbah 3~

@Zeb  
I fourth #3.

@Zeb  
@Yoshimon1
 
Well, it seems that the third option is the favourite at the moment.

@TheAnonShy  
#3

@TheAnonShy  
TSP has yet to respond as to whether he’s going to require spoiler images always use the same blue.

@cheezedoodle  
=[
 
I’m not really fussed about it; I kept the blue in the past because I figured people would associate it with “spoiler”, but whatever people like works with me.

there’s been no mistake. tsp has no authority here. this is merely a sentencing hearing.

@TheAnonShy  

 
Is the pink fill color behind the characters on #3 solid? If not can you make it solid? Then please upload the SVG for #3 to the site. That one meets the requirement that the outer burst ring and the text underlay be the same color, so we’ll just go with that.
 
I thought about holding a fave-earning contest between that and TSP’s blue and a 3rd option like the contest for worst pony that >>1116770 won but this is just colors, not characters.

@cheezedoodle  
The fill color behind the characters was practically solid, though now I have fixed it and I have uploaded it.
 
I like the idea of a fave-earning contest, it sounds fun, though in that case, I guess all the images should have been uploaded at the same time and of course, this doesn’t seem to be the case.

to apply equestria girls tag to characters from equestria girls drawn as normal humans too.  
yeah, the logic is as good as brazil’s politics

@age3rcm  
The Equestria Girls tag is for images of characters drawn in English EqG style, or stuff directly related to the movie.
 
Applying it to anything tangentally related to EqG (such as characters drawn in pony/standard human form) is a bit too broad and unspecific.
 
Edit: My phone has a dumb sense of humor

I’d love to have either a whitelist section to filters that override the usual spoiler/hide filters, or a setting somewhere that would override filters on my uploads (or images with artist tags associated with my username).
 
The basic reason for this:  
I may want particular content spoilered (or even hidden) in general, because it’s not stuff I want to see without warning. But I give absolutely no hecks if I see the thumbnails of art I drew myself. Someone else might want to hide or spoiler certain content EXCEPT by a couple of artists whom they know draw it in a way that doesn’t bother them. Currently, I’m doing this for e.g. semi-grimdark content with complex filters:  
semi-grimdark, NOT artist:quoting_mungo  
This has the drawback that I can’t tell at a glance WHY the content was spoilered, since it gets the “complex filter” spoiler image rather than the semi-grimdark spoiler image, so I have to look at ALL the tags to figure that out.
 
Another option, if whitelists (wider utility) and/or a checkbox to ignore filters for one’s own uploads/artwork (narrower utility, maybe more convenient to use?) don’t feel like a good idea, would be to add an “as” function to complex spoiler filters. So the complex filter above might look something like  
semi-grimdark, NOT artist:quoting_mungo, AS semi-grimdark  
Which would tell the system to display the spoiler image for semi-grimdark content for content spoilered under that complex filter. This would probably have the widest utility, but I suspect might also be a tiny bit heavier on the server load.

@quoting_mungo  
You can create as many personal filter as complex as you like by using the search syntax to exclude your uploads with -my:uploads, or -artist:XXX
 
Thought, a personal whitelist wouldn’t be too bad, for those who are not as good with computers and complex syntax.

@Mad Black  
I realize that, and it’s definitely a sufficient workaround, if a bit clunky at times. It’s just a shame to lose the at-a-glance information as to why something was spoilered (in the form of the spoiler image) when doing so, which is one reason I think a whitelist or an ability to associate spoiler categories with complex syntax would be an improvement.

I Definitely agree that being able to tell why exactly something is complex filtered would make them significantly more useful. Disapproving Celestia telling me “its complicated” doesn’t help much when you have lots of complex filters.

@Keith Mowz  
This is exactly the reason I don’t use complex spoilers more than I do. Maybe it could at least detect what line of the complex filter it matches and display that?
 
Or, maybe a crazy idea that probably won’t be implemented: a way to set spoiler images and text on a per-line basis.  
As in, something like this on a line:  

would produce this:  

Would it be the smallest logical disjunction of the filter that would hit the image?

@byte[]  
Could you give some examples some inputs/outputs for how that would work?

Even if it was as simple as having the option to show as much as will fit of whatever filter line tripped it instead of complex, maybe still in italics to indicate that is what it is.

@Exedrus  
Well, the first thing that’s important to understand is that in the context of complex filters, information about individual lines in a query string is thrown away whenever the filter is compiled.
 
A complex filter of
 
explicit,oc:milky way anthro
 
is reduced to this
 
\(explicit,oc:milky way\) \|\| \(anthro\)
 
so that it can be compiled into this AST(it’s actually just compiled directly into the output tree for Elasticsearch, but that’s irrelevant)
 
\(or   \(and     \(tag "explicit"\),     \(tag "oc:milky way"\)\),   \(tag "anthro"\)\)
 
For an image tagged anthro, but not explicit or oc:milky way, the smallest piece of this filter that matches is the (tag "anthro") portion of the main logical disjunction (OR statement).
 
For an image tagged with explicit,oc:milky way, but not anthro, the smallest piece of this filter that matches is the (and ...) portion of the main logical disjunction.
 
For an image tagged anthro,explicit,oc:milky way, the smallest piece of this filter that matches is the (tag "anthro") portion of the main logical disjunction.
 
I don’t suppose you can see the problem here?

@byte[]  
Yeah, I kind of figured lines would just be converted to OR statements serverside (due to the statement “Lines are ||’d together.” on the watchlist page), which is why I doubted that it’d be possible. Still, it was worth suggesting.

@byte[]  
Smallest sounds like it would work, I’d say - it’s not like it’ll show multiple spoiler reasons for the “simple” spoiler tag filter setting. (If I search for foalcon, spoiler:s06e13 (two arbitrarily selected tags I have spoiler-tagged), the first match shows up as spoilered for spoiler:s06e14, having foalcon and both episodes tagged, so I’m guessing it might be grabbing the LAST matching spoiler tag?)

@quoting_mungo  
I think if you try to do a search that’s clearly including a particular tag, possibly AND’d with something else, it’ll unspoiler the tag if you have it spoilered normally. (If a tag is part of an OR statement of some sort, though, it seems to be spoilered like normal.)
 
It might actually be nice to be able to have an option to turn that off, so they remain spoilered even if you search for them (for example, I have explicit spoilered, and sometimes I want to do a search involving the tag without having to actually look at a whole bunch of porn; I usually avoid this by writing “expl*cit” or something instead).

@SuperSupermario24  
I don’t like the “ignores spoilers” behavior of simple tag searches and would like to see it removed.

@byte[]  
k
 
We have the spoiler behaviour things from bbq now, so makes sense given you can vanquish the things pretty easily if you want to .