123easy said:
we already effectively get this with the avoidposting tag;

When artist tag has 0 instances (happens rather often with DNP artists) you don't get avoid_posting tag, especially since trending tags were disabled. With that feature you will know instantly whether artist is on DNP, or there are no artwork of this artist yet/you mistyped tag.

Gilda_The_Gryphon said:
When artist tag has 0 instances (happens rather often with DNP artists) you don't get avoid_posting tag, especially since trending tags were disabled. With that feature you will know instantly whether artist is on DNP, or there are no artwork of this artist yet/you mistyped tag.

why not make one actual image that says this artist is DNP and tag it with every artist that is dnp, so when you search them you get that one image. No coding required.

Sollux said:
why not make one actual image that says this artist is DNP and tag it with every artist that is dnp, so when you search them you get that one image. No coding required.

Good idea.

Additionally, whenever the next build comes out the lack of tags in the sidebar will be fixed, according to Tony. They just won't be trending (which is fine).

123easy said:
Good idea.

Yeah, it sounds good to me.

Additionally, whenever the next build comes out the lack of tags in the sidebar will be fixed, according to Tony. They just won't be trending (which is fine).

The point is that, if I remember correctly, there was avoid_posting when searching for tags that had no instances because tags were trending for searched tag. And if I remember correctly new trending tags are independent from search.

Nevertheless I miss them also because I can't quickly go to searched tag wiki just by clicking on question mark.

Gilda_The_Gryphon said:
Yeah, it sounds good to me.

The point is that, if I remember correctly, there was avoid_posting when searching for tags that had no instances because tags were trending for searched tag. And if I remember correctly new trending tags are independent from search.

Nevertheless I miss them also because I can't quickly go to searched tag wiki just by clicking on question mark.

The AvoidPosting tag I remember from before the trending tags change went in (like, back before Varka took over as owner, even). They were just a sidebar of tags that have nothing to do with tags being searched and just the tags on the images as before, from my understanding?

123easy said:
The AvoidPosting tag I remember from before the trending tags change went in (like, back before Varka took over as owner, even). They were just a sidebar of tags that have nothing to do with tags being searched and just the tags on the images as before, from my understanding?

Yes, but when you searched for dnp artist and there was none results there still, at least sometimes, was avoid_posting tag on sidebar. This is what I'm talking about.

Suggested Feature:
Remove empty changes from tag history.
Reason:
Sometimes there is just to much of them. In this post I can't check what changes were made because I can't get to 2 page because it was disabled.

Gilda_The_Gryphon said:
Yes, but when you searched for dnp artist and there was none results there still, at least sometimes, was avoid_posting tag on sidebar. This is what I'm talking about.

Suggested Feature:
Remove empty changes from tag history.
Reason:
Sometimes there is just to much of them. In this post I can't check what changes were made because I can't get to 2 page because it was disabled.

some 'empty changes' are generated when someone adds a tag that is aliased to a tag already on the list, or when an invalid tag is added that then gets cleaned.

And yes, that's the AP tag I was referring to; it was there even when no posts were displayed.

123easy said:
some 'empty changes' are generated when someone adds a tag that is aliased to a tag already on the list, or when an invalid tag is added that then gets cleaned.

And yes, that's the AP tag I was referring to; it was there even when no posts were displayed.

maybe they need to change the coding so that when an alias is changed, it doesn't get set in the record, or just allow all pages to be viewed again (why can we only see page one now anyways?)

Sollux said:
maybe they need to change the coding so that when an alias is changed, it doesn't get set in the record, or just allow all pages to be viewed again (why can we only see page one now anyways?)

Hmm? No, I mean if say booty_call is aliased to sex, for example- if you try to add the tag booty_call to an image already tagged sex, you'll get a blank record because the alias flipped it to sex, which was already tagged, so no tag changes actually occured. It'd add another layer of complexxity to the code to make it actually check for things like that, I'd think, since right now it's just a "press button = get record" function, very simple by comparison.

As for the second point, whenever the new build comes out I think we're getting that resolved; I know Varka turned them off for some reason, it's listed in one of the sticky threads in a post he made a while ago.

123easy said:
Hmm? No, I mean if say booty_call is aliased to sex, for example- if you try to add the tag booty_call to an image already tagged sex, you'll get a blank record because the alias flipped it to sex, which was already tagged, so no tag changes actually occured. It'd add another layer of complexxity to the code to make it actually check for things like that, I'd think, since right now it's just a "press button = get record" function, very simple by comparison.

As for the second point, whenever the new build comes out I think we're getting that resolved; I know Varka turned them off for some reason, it's listed in one of the sticky threads in a post he made a while ago.

oh, that's fine then, if its getting fixed in the next build its no problem anyways. And I understand why tag aliases appear in the records, but I feel like a line of code saying if the tags are the same before the edit and afterwards, to not post it in the record wouldn't be deathly hard to make, but I'm not a pro coder so I can't say for sure.

Sollux said:
oh, that's fine then, if its getting fixed in the next build its no problem anyways. And I understand why tag aliases appear in the records, but I feel like a line of code saying if the tags are the same before the edit and afterwards, to not post it in the record wouldn't be deathly hard to make, but I'm not a pro coder so I can't say for sure.

basically a "after aliases, nothing changes, are you sure you want to submit?" check? I get what you're saying, and not saying it's a bad idea. Just it might be too much work for a simple thing like this.

123easy said:
some 'empty changes' are generated when someone adds a tag that is aliased to a tag already on the list, or when an invalid tag is added that then gets cleaned.

And some are generated when someone is trying to remove a tag, but it's automatically re-added by some implication.

...happens to me all the time. There's so many implications that it's hard to remember what is implicated to what.

I'd find that check quite useful.

123easy said:
As for the second point, whenever the new build comes out I think we're getting that resolved; I know Varka turned them off for some reason, it's listed in one of the sticky threads in a post he made a while ago.

Not in the next update, no. There's some performance problems with the page we still need to work out. But I'm hoping we can at least view more than just the first page.

tony311 said:
Not in the next update, no. There's some performance problems with the page we still need to work out. But I'm hoping we can at least view more than just the first page.

Aw, darn. Best of luck with that!

Requested feature: Ability to tag both character and artist of the same name, without one being removed.

Why it would be useful: This would allow us to search specifically for "character:<insertcharacter>", which would display any post that has this tag. Under the current system, if a post is tagged as "artist:<insertcharacter>", but also has the character of the same name, it does not show up under searches for "character:<insertcharacter>".

Supermeh said:
Requested feature: Ability to tag both character and artist of the same name, without one being removed.

Why it would be useful: This would allow us to search specifically for "character:<insertcharacter>", which would display any post that has this tag. Under the current system, if a post is tagged as "artist:<insertcharacter>", but also has the character of the same name, it does not show up under searches for "character:<insertcharacter>".

Why not just do this. Artist:Bob_(artist) and character:Bob that would work as we have been doing it for awhile now.

Conker said:
Why not just do this. Artist:Bob_(artist) and character:Bob that would work as we have been doing it for awhile now.

Though having tags check against catagories for duplicates would be nice, agreed. Though, in this particular example, we'd probably have it be both Artist:Bob_(artist) and Character:Bob_(<character owner's name>) given that it's a fairly common name.

Conker said:
Why not just do this. Artist:Bob_(artist) and character:Bob that would work as we have been doing it for awhile now.

Well, didn't even realize this was a thing. I've been lurking on this site for years, but just recently started posting, so this is new info to me.

Requested Feature:
On an image's tag list, hide implied tags in a default-closed collapsible dropdown under the tags which imply them.

Why it would be useful:
Implied tags don't usually need to be shown on the tag list. By definition they're implied by the other stuff. You could click to expand the dropdowns if you really want to see every tag, but usually showing sex_toy when you already show dildo is a waste of space.

I explain this proposed feature in a little more detail over on this thread.

Wyvrn said:
Requested Feature:
On an image's tag list, hide implied tags in a default-closed collapsible dropdown under the tags which imply them.

Why it would be useful:
Implied tags don't usually need to be shown on the tag list. By definition they're implied by the other stuff. You could click to expand the dropdowns if you really want to see every tag, but usually showing sex_toy when you already show dildo is a waste of space.

I explain this proposed feature in a little more detail over on this thread.

And I explained why it was a terrible idea there as well, least of all being tag list bloat and searchability ("how many times is sex_toy going to be implied here?!")

123easy said:
And I explained why it was a terrible idea there as well, least of all being tag list bloat and searchability ("how many times is sex_toy going to be implied here?!")

And I addressed all the points you raised in my longer explanation. Please be more specific in your criticism. This would have no impact on searching. It's a cosmetic change to how the tag lists appear beside images, and its purpose is to reduce tag list bloat.

Feature Request: Have the site load in Hexagon Clean (or at least Hexagon no secondary theme) by default/Have the theme setting be what is loaded initially instead of Hexagon with Winter theme.

Reason: Reduce site twitching during loading sequence/consistancy in visual cues as to theme.

123easy said:
Feature Request: Have the site load in Hexagon Clean (or at least Hexagon no secondary theme) by default/Have the theme setting be what is loaded initially instead of Hexagon with Winter theme.

Reason: Reduce site twitching during loading sequence/consistancy in visual cues as to theme.

Change it yourself. That way makes it stay.

Xch3l said:
Change it yourself. That way makes it stay.

Excuse? I HAVE my theme set. It loads up the Hexagon + Winter theme *every time* I open a page, THEN swaps over to my set theme (regardless of what theme I have set). It looks REALLY bad, and I doubt that loading up one theme then loading up another for everyone who changes their theme is helping the server. :x

123easy said:
Excuse? I HAVE my theme set. It loads up the Hexagon + Winter theme *every time* I open a page, THEN swaps over to my set theme (regardless of what theme I have set). It looks REALLY bad, and I doubt that loading up one theme then loading up another for everyone who changes their theme is helping the server. :x

I set it to Hexagon clean without any extra and it survived a few refreshes. Or you mean on different devices.

Edit: Oh, I see what you mean! The default theme is "Hexagon+Winter", then a script loads the theme you've set after the page finishes loading based on a cookie

Xch3l said:Edit: Oh, I see what you mean! The default theme is "Hexagon+Winter", then a script loads the theme you've set after the page finishes loading based on a cookie

Yes, that is exactly what I put the request in to change.

It is a bit annoying having the page twitch around on every load as the theme switches from the default. Pages should be served with a user's selected theme already set. Or if that's not possible, maybe theme transitions could be faded with CSS animation to make them less jarring.

It's a known bug but since CSS selections are stored in cookies I don't have a solution for it yet other than moving it serverside, but that would mean it doesn't work for anonymous users. Maybe I'll keep it stored in cookies for everyone but if you're logged in it'll save it to your account too...

tony311 said:
It's a known bug but since CSS selections are stored in cookies I don't have a solution for it yet other than moving it serverside, but that would mean it doesn't work for anonymous users. Maybe I'll keep it stored in cookies for everyone but if you're logged in it'll save it to your account too...

Cookie for anons, account saved for regulars? That sounds good to me. \o/

That sounds good to me too! But why is continuing to store theme settings only in cookies incompatible with doing the formatting serverside? The CSS cookie is sent in every page request, right?

Feature request
No tag limit for anyone.

No, it's not a dream. Just when there is member and he is searching for a b c d e f g h then interpret this search like this.

1. Search for first 6 tags a b c d e f on server side.

2. Temporarily, for this one search, add to user's blacklist:
-g
-h
Reason:
If user already filtered first 6 tags he/she will most likely not be bothered whether rest of them are filtered like search or like blacklist. And for sure it's more preferable than getting too much tags error.

This way of searching still gives correct result, still only 6 tags are filtered on server side,and this is more convenient than changing blacklist manually each time (You have to click My Account -> Settings -> Enter new words for blacklist. It takes some time.)

Gilda_The_Gryphon said:
Feature request
No tag limit for anyone.

No, it's not a dream. Just when there is member and he is searching for a b c d e f g h then interpret this search like this.

1. Search for first 6 tags a b c d e f on server side.

2. Temporarily, for this one search, add to user's blacklist:
-g
-h
Reason:
If user already filtered first 6 tags he/she will most likely not be bothered whether rest of them are filtered like search or like blacklist. And for sure it's more preferable than getting too much tags error.

This way of searching still gives correct result, still only 6 tags are filtered on server side,and this is more convenient than changing blacklist manually each time (You have to click My Account -> Settings -> Enter new words for blacklist. It takes some time.)

you mean if he searches a b c d e f -g -h right?

Sollux said:
you mean if he searches a b c d e f -g -h right?

Blacklisting -g allows you to see only pictures when g is present. Blacklisting -g is equivalent of searching for g.
Blacklisting
-g
-h
is equivalent of searching for g h
Blacklisting -g -h (notice no newline)
is equivalent of searching for ~g ~h

I hope I didn't fuck up logic here.

Gilda_The_Gryphon said:
Blacklisting -g allows you to see only pictures when g is present. Blacklisting -g is equivalent of searching for g.
Blacklisting
-g
-h
is equivalent of searching for g h
Blacklisting -g -h (notice no newline)
is equivalent of searching for ~g ~h

I hope I didn't fuck up logic here.

I don't know if you said that right or not but I get what you mean now, that is kinda roundabout.

But isn't unlimited tags supposed to be the benefit of being privledged?

123easy said:
But isn't unlimited tags supposed to be the benefit of being privledged?

More (but also not unlimited) tags for server side filtering is one of benefits of being priv+. However, you can have your blacklist (filtering on client side) almost unlimited. This suggestion is really only about improving ways how you can change your blacklist. Allowing you to easily make change in it just for one search.

Gilda_The_Gryphon said:
More (but also not unlimited) tags for server side filtering is one of benefits of being priv+. However, you can have your blacklist (filtering on client side) almost unlimited. This suggestion is really only about improving ways how you can change your blacklist. Allowing you to easily make change in it just for one search.

maybe there could be a check box on your user page to allow your blacklist to actually appear on the post searching page, so you can edit it on the fly during regular searches without having to go to your account page.
Edit: after thinking about it I'm fairly certain the coding would be so ridiculously easy to do.

Gilda_The_Gryphon said:
More (but also not unlimited) tags for server side filtering is one of benefits of being priv+. However, you can have your blacklist (filtering on client side) almost unlimited. This suggestion is really only about improving ways how you can change your blacklist. Allowing you to easily make change in it just for one search.

Isn't it limited to something like 250 or 500 characters?

123easy said:
Isn't it limited to something like 250 or 500 characters?

3900 characters. This is my current blacklist. It uses only 427 characters.

Requested feature: denied aliases and implications be listed under searches, highlighted in a specific color for denied ones, and have a link to the thread that had the suggestion.

why it would be useful: when someone has an idea for an implication or alias if they search it they would be able to see that it was previously denied and know not to post it, and see why it was denied.

Not sure if this has been mentioned, but what about an image threshold?

You can hide comments that have, say, a -20 score, so why not have a feature that automatically blacklists every post below or above a certain threshold? It would give more meaning to upvoting/downvoting images, and it would eliminate a bunch of drama in regards to gore, scat, bad art, etc.

SirAntagonist said:
Not sure if this has been mentioned, but what about an image threshold?

You can hide comments that have, say, a -20 score, so why not have a feature that automatically blacklists every post below or above a certain threshold? It would give more meaning to upvoting/downvoting images, and it would eliminate a bunch of drama in regards to gore, scat, bad art, etc.

We're not going to hide any posts by default but it's easy enough to blacklist score:<-20

tony311 said:
We're not going to hide any posts by default but it's easy enough to blacklist score:<-20

Due to the fact comments that are -3 still show when you have it to hide them at -3 I doubt this will work unless you blacklist -20 and the image has -21 to hide it. For comments at least, the number you put isnt the number it hides....though it seems to be a bug. Just thought I mention it though.

Conker said:
Due to the fact comments that are -3 still show when you have it to hide them at -3 I doubt this will work unless you blacklist -20 and the image has -21 to hide it. For comments at least, the number you put isnt the number it hides....though it seems to be a bug. Just thought I mention it though.

Nope, it isnt:
"Comments with a score below this threshold will be hidden by default." c:

And for the score blacklist, just make it score:<=-20 so it hides posts with a score less than or equal to -20
s'on the help!]

tony311 said:
We're not going to hide any posts by default but it's easy enough to blacklist score:<-20

Oh, I didn't mean hide by default. I essentially meant have a function to blacklist posts below or above a certain threshold. But I had no idea you could already do it.

I don't know if this has been already proposed or not, so if it has been already, please forgive me and ignore this post.

I think it will be a good idea to have a per-character tagging. I mean, on a picture with, two characters for example, if I search for "male canine female feline", there is no way to specify currently who's the male and who's the female.

My idea was adding a per-character tagging system. One could search for "c1:male c1:canine c2:female c2:feline" and easily remove those pictures where the male is a feline. Searching for "cC:male cC:canine cF:female cF:feline" should yield the same results, ignoring whether the character "ID" (the "key" after the "c" and before the ":" is a letter, a character, or anything else.

People could also search for "charcount:2", to find a picture with two characters, "charcount:>4" for pictures with more than 4 characters, or "charcount:0" for wallpapers and the like.

If one does not specify the "c1:" and use just "male", the search engine will look for pictures where at least one character, doesn't matter which, is a male, as it does now.

This could be easily implemented adding an additional column to the SQL database containing the character ID (a simple unsigned byte should do the job), or 0 if the tag is for the picture rather than for an specific character, being thus backwards-compatible.

There's definitely a lot of room for improvement when it comes to tagging systems. A way of specifying what characters are in the image, and which tags apply to which characters, and which characters are involved in certain acts would be awesome.

It would be a major overhaul though, considering all the interface changes that would be needed to make adding and editing that sort of information easy and intuitive. Probably not practical to implement in the foreseeable future.

It's not really that hard. In the tag editor screen, it's a matter of adding a button to add another character, with its own tag box, and a button in each box to remove the character, in case the user adds a character by accident.

Requested feature: To be able to use range search syntax with favcount.

Why it would be useful: Most people on this site seem to only fave images that they like, and don't upvote them. To see evidence of this, search "score:0 order:favcount" and you can see that there are quite a few images with over 50 favourites but no upvotes. Because of this I feel like favcount is the more accurate measure of an images quality and being able to use searches such as "favcount:>100" would be very useful.

Thanks.

Request: Separate the source field on the upload page from the 'download the image from here' functionality. These should be separate boxes.

I really like being able to specify the URL the image is located at, so I can make posts without having to download and upload each image. But I never want the source link to be directly to the image, I want it to be to the blog post, image page, user page, or whatever.

Wyvrn said:
Request: Separate the source field on the upload page from the 'download the image from here' functionality. These should be separate boxes.

I really like being able to specify the URL the image is located at, so I can make posts without having to download and upload each image. But I never want the source link to be directly to the image, I want it to be to the blog post, image page, user page, or whatever.

We're getting multiple source link sections soon enough, so this isn't necessary.

Requested feature: To see the exact date and time of all messages in the inbox

Why it would be useful:
It would be useful to have a better overview of all messages.
It's hard for someone like me to find the right message because i have over 1000 messages, and i don't think i'm the only one who write many
messages :)

PS: Sorry if this request is already posted ^^

@Akay127:
Actually it's not that hard, just hover your mouse on the date ant the exact date will appear (unless you're on a tablet/smartphone). It would be better if you could search by date, imo.

Akay127 said:
Requested feature: To see the exact date and time of all messages in the inbox

Why it would be useful:
It would be useful to have a better overview of all messages.
It's hard for someone like me to find the right message because i have over 1000 messages, and i don't think i'm the only one who write many
messages :)

PS: Sorry if this request is already posted ^^

...Dude. Clean your inbox. ._.

Xch3l said:
@Akay127:
Actually it's not that hard, just hover your mouse on the date ant the exact date will appear (unless you're on a tablet/smartphone). It would be better if you could search by date, imo.

That didn't work, but i can see the date when i open the page-source code :D
Thanks for the hint^^
But it would be still a help to see the date direct :)

Requested features:

• Add not-deleted pages number to page for browsing pools.
• Possibility to hide pools that have 0 (or maybe any number specified by user) not-deleted pages.
• Possibility to sort pools by number of pages.

Why it would be useful
When I'm browsing pools I'm rather fed up when I open 5 consecutive pools only to find that all of them have their all posts deleted. I know that posts taken down should stay in their pools, but wouldn't it make sense to make a feature to help to avoid such pools?

Request:
The ability to edit/cancel tickets.

Why is it useful?
Let's face it, we've all accidentally clicked the "Report" button instead of the "Reply" button when we're trying to communicate with other users. If we add this feature, people who accidentally clicked the "Report" button can cancel that complaint and thus avoiding embarrassment from the admins that handle the tickets. Also, some users change their minds and want to remove the ticket due to a misunderstanding.

TheHuskyK9 said:
Request:
The ability to edit/cancel tickets.

Why is it useful?
Let's face it, we've all accidentally clicked the "Report" button instead of the "Reply" button when we're trying to communicate with other users. If we add this feature, people who accidentally clicked the "Report" button can cancel that complaint and thus avoiding embarrassment from the admins that handle the tickets. Also, some users change their minds and want to remove the ticket due to a misunderstanding.

There appears a dialog when you click "Report". But I have to agree on the cancel/edit part

Requested feature: Folders in favorites

Why it would be useful: Well.. Quite obvious. Ones like DA has. Or more simple ones. Has this been thought about yet? I can't be the first one.

Siera122 said:
Requested feature: Folders in favorites

Why it would be useful: Well.. Quite obvious. Ones like DA has. Or more simple ones. Has this been thought about yet? I can't be the first one.

That is one of the uses for Sets More info here: https://e621.net/help/sets

Honestly I think uploaded should be able to lock the voting system so it displays 0 when done so and cant be used. Priv+ users too. It would stop the whiners who cant handle -votes. Hell even I am disappointed when I post something good, and get negs because either people Hate /me/ or dislike the subject matter... or I post a painting and because its not lobster (pron) its downvoted. Its...disappointing, depressing, aggravating....

From a previous thread. It is true... down votes can discourage new artists from posting, decent or not. Hell it can discourage pro artists too...

You shouldn't -vote just cuz you don't like the person or content... if you like it fav it, if its good art +vote... if you dislike, blacklist.
Otherwise this addition would do wonders for... a lot of people.

Esme_Belles said:
Honestly I think uploaded should be able to lock the voting system so it displays 0 when done so and cant be used. Priv+ users too. It would stop the whiners who cant handle -votes. Hell even I am disappointed when I post something good, and get negs because either people Hate /me/ or dislike the subject matter... or I post a painting and because its not lobster (pron) its downvoted. Its...disappointing, depressing, aggravating....

From a previous thread. It is true... down votes can discourage new artists from posting, decent or not. Hell it can discourage pro artists too...

You shouldn't -vote just cuz you don't like the person or content... if you like it fav it, if its good art +vote... if you dislike, blacklist.
Otherwise this addition would do wonders for... a lot of people.

I really think we should leave the voting alone as it's really just an add-on for the site and not really a huge feature, and if an artist wants to be great, they have to learn to take criticism and negativity and not let it take them down

The tag history should have an option allowing to show tag edits made only by a certain usergroup. I've tried using it to find tag vandalism, but it's a struggle to find anything between the mass edits done by priv+ members.

Small nitpick about the new Source list:
That edit box is now so large that it's harder to see both the tag edit box and the image (especially the taller images) at the same time. Which makes tagging a bit harder.

Could that order be switched?

Genjar said:
Small nitpick about the new Source list:
That edit box is now so large that it's harder to see both the tag edit box and the image (especially the taller images) at the same time. Which makes tagging a bit harder.

Could that order be switched?

....scroll? I always resize images if I'm going to tag them, if they're too large. it takes but a moment to scroll up and grab a few more tags.

Feature request: Apply avatar blacklist function via a separate box/have a method of excluding a specific subject from blacklist for purpose of avatars.

Reason: I don't mind people's MLP avatars, but I don't want to see the scads of the stuff that's everywhere. On the other hand, I definitely don't want to see people's gory avatars. Under current format, What do?

123easy said:
....scroll? I always resize images if I'm going to tag them, if they're too large. it takes but a moment to scroll up and grab a few more tags.

I use both of my hands to type, and mouse wheel to scroll. Having to constantly switch between the two is inconvenient, and I'd get more work done if I didn't need to do that.

v Thank you.

Switched tags/sources around in post edit form. Should be live later tonight.

As an artist, when I upload a pic, I'd like to be able to delete it, instead of just flagging it for deletion, mostly because sometimes I'll keep working on a pic after I'm done with it, and I'd like to make sure the best version of the pic is up for display

Syynx said:
As an artist, when I upload a pic, I'd like to be able to delete it, instead of just flagging it for deletion, mostly because sometimes I'll keep working on a pic after I'm done with it, and I'd like to make sure the best version of the pic is up for display

The usual COA (Course of Action) lol MGS ref is post the new image, parent it to the old post and then flag it. A good feature idea would be a delete button on your own posts for Contrib+ user level, to avoid the hassle of flagging the old post and waiting for a mod/janitor to delete it

Xch3l said:
A good feature idea would be a delete button on your own posts for Contrib+ user level, to avoid the hassle of flagging the old post and waiting for a mod/janitor to delete it

That just makes sense.

Requested feature: Would it be possible to automatically add the the image resolution tags such as hi_res and absurd_res? I've seen that feature on other imageboards, and it's pretty handy.

Why it would be useful: ...we wouldn't need to tag those manually.

Genjar said:
Requested feature: Would it be possible to automatically add the the image resolution tags such as hi_res and absurd_res? I've seen that feature on other imageboards, and it's pretty handy.

Why it would be useful: ...we wouldn't need to tag those manually.

Base it off a strict width x height factor? Makes sense.

Do implications based on metatags work? If so it might be as simple as creating the implications mpixels:>2 → hi_res and mpixels:>4 → absurd_res. Obviously the exact values would be up for debate.

Wyvrn said:
Do implications based on metatags work? If so it might be as simple as creating the implications mpixels:>2 → hi_res and mpixels:>4 → absurd_res. Obviously the exact values would be up for debate.

Unfortunately they do not