Sleazy Fork

Feature request Mk. II

Well, well hai thar Pseudonymous and Moebius, it's your (almost) favourite user, me!

Anyway, since Userscripts is pining for the fjords, we might as well re-open this lil' thread. Also I wanted to thank Moebius for fixing that Ugoria bs (I was just about to ask if something can be done with it). It would be nice if we could save it as .apng or .gif, but I guess there's no need for that (at least now).

I'll be here to ask for more impossible-to-do features, so staye tuned!

Incoming favorites listing support. Seems they added an API at some point. <_<

Wow, great, thanks for the fix. Haven't even noticed that they did this.
By the way, is this one possible:
- now that your favs are listed chronologically (that is, when you fav'd them), can you add the number of the page you're on? It's quite problematic when you want to see your old favs and the only thing you have is next and previous buttons.
And yeah, I know that you can go back if you type in

page=a[number]&user_id=[user] or
page=b[number]&user_id=[user]

but that's kinda annoying. So can that be added?
Oh, and thanks for everything else, Ugoira is really pissing me off.

Oh, and Alternate Image Swap seems to be broken (again). Fix pl0x?

The swap option should be fixed now. As for the pages on the favorites listing, the numbers after the "a" and "b" for the pages don't correspond to any number value known to me. They're related to some index value that appears to be available to the server only. Changing it to an actual page number only ends up breaking the paginator for pages greater than 1. The simplest workaround for it is just using the search "ordfav:username", but I am considering some other options.

Value "a" goes backwards (that is, if you type in, say, "a=1", you'll get to the last page of your favs). Value "b" goes forwards, but I have no idea how to use it.
"ordfav:username" is the same as "fav:username" now, except it is easier to handle since it has "page=number" in it. However, script doesn't work on it for some reason (you can't get to the last page, max is 1000), thumbnail count is broken as well and I'm sure that there are some other issues as well.

Value "a" goes backwards (that is, if you type in, say, "a=1", you'll get to the last page of your favs). Value "b" goes forwards, but I have no idea how to use it.

I'm at the exact same point as you. The "a" stands for "after" and tells Danbooru to return the posts after the provided numerical index value. Similarly, the "b" stands for "before" and tells Danbooru to return the posts before the provided numerical index value. In the regular search listing, the index values are the post ID numbers. On the favorites listing, the index values are some other values related to the order of the posts that I apparently don't have.

Something to be aware of with these page values is that they will break any search that changes the default order of the thumbnails. For example, any search that uses order:score will stop being sorted by score after page 1000 due to the use of the "a#" and "b#" values. This also applies to ordfav: since it changes the order of the posts just like order: does.

"ordfav:username" is the same as "fav:username" now, except it is easier to handle since it has "page=number" in it.

The fav: and ordfav: metatags definitely aren't the same. The order in which the posts were favorited is preserved with ordfav: just like it is in the favorites listing. With fav:, the order of the posts is based on post ID number.

However, script doesn't work on it for some reason (you can't get to the last page, max is 1000)

The 1000 page limit is a hard limit based on your account type and there's nothing that can be done besides working around it. If you change the number of thumbnails per page, you can browse up to 200000 (200 * 1000) thumbnails using actual pages. Depending on your tag search, other options are possible as well.

thumbnail count is broken as well and I'm sure that there are some other issues as well.

I'm not seeing any problems with thumbnail count. Do note that if you're using a search or URL where "limit" is already defined, that will always override the script's current thumbnail count limit. If you try to manually create a URL or use a search URL linked from somewhere with a predefined page number, you will have to manually define the limit.

'kay thanks for answers (and update).
Well, if you think of something, do add, I'm out of ideas at the moment.

Well, I'm back! I bet you missed me!
Anyway, here's another one.
A few days ago, they anounced this. Naturally, I'm kind of interested. So I had to ask my favourite coder. Can this be done somehow? Probably not, but I still have to ask.

That's pretty much a server side only option that would take far too long to work in a client side script.

Eh, thought so. Well, you can still find similar users even without that so it doesn't matter really.
Oh, and many many thanks for still updating this script.

Oyyyy Moebius, haven't annoyed you for quite a while so I might as well ask for something annoying.
Anyway, this might be a big request so I'm not gonna ask directly (well not yet, only if you're interested). It's about tag subscriptions.
Premium users have that privilage, we mortals do not. That problem can be (partly) fixed via RSS readers, but even they have their limits.
So that's it then, if you're interested, leave a comment.

I wonder...

Can you detail the limits you're running into?

Ahem, well, can you implement some sort of simple RSS reader that works only for Danbooru via JS?
RSS readers work fine, but you can't use some features that this script offers (loli, shota etc.).
Just wanted to ask, if it's too much work (can it be done even?) you can ignore this.

I've never really had much interest in feeds or Danbooru's subscriptions, so I'm not really sure where I'll end up going with this. My first thought is to modify the saved searches section of Danbooru so that it can manually and/or automatically check each saved search for new posts within the first 20 or so posts.

Damn, haven't thought of that one (I never use save search so...).
And, like I said, if it's too much work or if you're not interested it's OK.
I know that couple of artists that I like draw some stuff that can't be seen via RSS reader, so I check on them from time to time.
Well, that's all from me then, if you build that in it would be awesome of course.

Popping back in to say I'm still considering it, but I'm fixing another issue that's been bothering me for a year or two now. Hopefully it'll be a good working solution that will allow user settings and cache info to be stored with the userscript manager's built in methods while still allowing the main script to execute in the same scope as Danbooru's scripts.

That will mean:
* Much more storage space.
* Settings that will persist during private browsing.
* Only having one set of settings for all Danbooru (donmai.us) domains, subdomains, and secure connections (https). Settings currently have to exist individually for each domain, subdomain, and secure connection. They aren't shared across them, so a change in one case does not affect the other locations.