There is english subs for the first Ep now! :D

here or here too
chances are good that there is more to come :3

Awesome! Really hoping the rest of them get translated.

Also, I'd say the second link definitely has the better subs.

My copy finally got in today, and oh lord was it worth the wait. Morinaga is just so, so good at making the romance feel real, I could not imagine a more wonderful end for these two! Literally had to put it down a few times because I couldn't handle cuteness of that magnitude.

Also, the author gushing over yuri in the afterword was hilarious. I wonder the same thing myself sometimes...

Dynasty Tag Hider

This userscript allows you to hide tags that you choose, preventing them from being displayed on all chapter listings. Some tags can be rather spoilery in nature so this helps with avoiding that. Thanks to Bury's post for the idea. Currently only tags that appear on the Tags page can be hidden (i.e. not doujins or pairings). This functionality may be added in the future.

To clarify, this is not a tag blacklister. It only hides tags from being shown in the tag list of a chapter or series.

Installation

1. Install the Tampermonkey browser extension.
2. Install the userscript.

Usage

After the userscript has been installed, tags can be hidden/unhidden from the Tags page, accessible via the site Directory. Hovering over a tag should now display a show/hide toggle.

Changelog

• 1.0: Initial release.

last edited at Dec 1, 2017 7:35AM

Damn it Rightstuf, what gives... I preordered the volume months ago, and it still hasn't shipped? I need this. NEED.

Alice Cheshire posted:
It's Windows. I'll give that a try then. Last I heard there was a GUI but it was a total mess.

I like TortoiseGit for Windows myself, although its context menu based interface is a bit unusual. However none of the GUIs I've tried really help out much if you try to do something Git doesn't want to do. Usually they'll just fail and relay the command line error message back at you, so you'll still have to figure out the underlying issues on your own.

last edited at Nov 23, 2017 10:37PM

gwennie-chan posted:
The old version before partially worked, but displayed the wrong link colors and was incomplete.

I'm not able to reproduce the issue on Firefox 58 beta 4 (Windows/x64). I suspect your installation might have broken localStorage in some way, since the updated script relies on it now.

EDIT: I just came across this post which suggests your profile might be corrupted. You might want to try creating a new profile and seeing if that changes anything.

last edited at Nov 17, 2017 7:26AM

I can tell you it doesn't work at all on Firefox 58.

I haven't tried nightly, but it works for me on FF 56 and 57. Was it working for you before the update to the script?

gwennie-chan, your suggestion has been implemented. That was a fun little project :)

Note that the mechanism for cache reloading has changed. To trigger the initial cache reload, remove or add an item from a list using the list drop down, then navigate to the front page or any chapter list.

Alice Cheshire posted:

You could possibly handle series separately from normal network requests and have a fairly low time-limited throttle on the caching so it doesn't become a severe issue. It would just require more patience from the users for their list to update. Though you could potentially sidestep this issue somewhat for future requests, if you haven't already at least (I still haven't examined the code very closely yet), by adding event handlers to the add-to-list buttons that would immediately add/remove an entry from the corresponding script list.

My current idea is similar; attach event handlers to the list buttons that invalidate or reload the cache. Your suggestion to update the list client-side would definitely have better performance, but I'm hesitant to sidestep the server with direct modifications to client-side state since that could lead to a number of challenging issues, particularly keeping state on multiple machines consistent with each other.

gwennie-chan posted:

cyricc, your Dynasty Markread only works for individual chapters. I can't have a whole grouping selected as Read and that inherit to individual chapters.

Hm, now this is a more challenging (but worthwhile) problem to solve. The script right now only marks entities directly corresponding to an entry in the list(s), or whose status appears as read/to_read/subscribed on the chapter page. Dynasty itself doesn't apply inheritance to groupings, which leads to the issue you mention. I can think of two general approaches at the moment, each with their own tradeoffs:

• Scrape each series/anthology entry in the Read list to get its member chapters, and mark those as well. Problem with this is that it could be expensive in terms of network requests if the list contains a large number of groupings. Caching could hide most resulting performance issues from the user, but the server would still get hammered in the background. Also introduces some possibly confusing inconsistency, i.e. all future chapters added to the series will immediately show as marked.

• Change the behavior of the Read button on series/anthology pages, such that adding/removing the series from Read does the same for every chapter on its page. Given that this has persistent effects beyond how pages are displayed, I would probably create a new userscript for this as I believe it is out of scope of this one. Problem with this method is that it would not apply retroactively; you would have to go through your list and re-add all your series.

I can't really say I have a strong preference toward either approach... possibly the second one by a slight margin. Any thoughts?

EDIT: hm, the performance issue with #1 could be alleviated by making cache reload more intelligently, and would also reduce the server load generated by the script as a whole... might work on that over the next few days, actually.

last edited at Nov 15, 2017 5:39PM

Alice, your suggestions have been implemented. Let me know here or on Github if you find any issues I missed.

Alice Cheshire posted:
Hey cyricc. I have two potential requests for this userscript. I haven't actually looked at the underlying code so I don't know how reasonable either of these are but:

1.) Letting it work on list pages would be pretty helpful. For example some of Nechan's lists have a huge number of entries and for me at least there's a lot of shared entries. With so many entries it's really difficult to remember all of the ones I've read so I frequently come across ones that sound interesting but it turns out I've already read them.

2.) The other suggestion is to let it work on your to-read list as well, although for this one I'd suggest coloring them differently since they're not yet read. This actually comes up frequently with issues like the first one as well where a significant chunk of those that I haven't read are already on my to-read list to begin with.

Sure, these suggestions should not be hard to implement at all. In fact #1 can be done by simply adding the lists url to the includes; I neglected to do so because I hadn't thought of that particular use case. #2 should be pretty easy after some refactoring to allow code reuse.

Just a note, anyone using the Mark Read userscript should update to the latest version. I've (finally) set up autoupdate to make this manual update process unnecessary in the future. More importantly, performance of release 2.0 has been greatly improved by use of caching (I actually got the idea from working on your script Alice, so thanks).

Read chapters should now mark more or less instantly in most cases, regardless of the length of the page or size of your list. The only caveat is that removal of chapters from your Read list may not always be detected immediately (additions always show immediately). The cache will naturally refresh as you browse around the site, so no special action is required if this happens.

last edited at Oct 24, 2017 5:17AM

Alice Cheshire posted:
Well it sounds like it's fixed either way so it doesn't really matter but my personal suggestion would be to use document.onreadystatechange which is an event listener which can do different things depending on what stage of loading the page is at. Something like this:

document.onreadystatechange = function () {    
    if (document.readyState === "loading") { //Runs first    
        //Do something here    
    } else if (document.readyState === "interactive") { //Runs second    
        //Do something else here    
    } else if (document.readyState === "complete") { //Runs last    
        //Do a third thing here    
    }    
};    

This would allow you to make sure that certain code should always run before other code.

With ES6 now being more or less standard if we ignore IE, I find promise chaining the simplest way to order asynchronous Javascript functions; they're worth looking into if you're writing stuff that depends on multiple AJAX requests and such. ES2017 introduces async-await constructs which are even cleaner, though I'd say still a bit too bleeding edge to be using just yet in public releases.

last edited at Oct 23, 2017 2:29AM

KQy posted:

Can this site make exclamation mark, or check mark or something like that, on right after the chapter, for marking progress, i dont know if i am explaining enough, and i dont know if this has been suggested before, but for example is like novelupdate reading list, i tent to forget last chapter i read so i spend so many times to find last ch i am reading

I made a userscript that might do what you're looking for.

Both Chrome and FF for me. Try clearing the local storage if you're testing, I believe having the JSON cached may mask the error (without existing cache data, the error terminates the script before it has a chance to save it).

Here's the debugger right before it crashes:

And here's some console output at that point. As you can see, both GM_getValue and mainJSON are not initialized. The following error occurs when that line gets executed.

Forum tagger functionality for the Tagifier is not working for me. From what I can tell it seems to be an issue with callback chains running out of sequence (sortJSON() can run before mainJSON is loaded).

Sweet, thanks. Unfortunate that there's no API for user defined lists, now that would be quite interesting to have.

By the way Alice, put in another PR that should stop the expanded menu from flashing on screen every time a page is loaded (I found it mildly infuriating :P).

gwennie-chan posted:

Dynasty Tagifier

Current Version: 1.01 || Released: October 14, 2017

---

Dynasty Tagifier is a Tampermonkey userscript that adds functionality regarding site tags.

---

Features

Forum Tagger

Forum Tagger scans forum post Tag objects for valid tags and turns them into clickable links to each tag's page.
(For the nerds, it does this dynamically pulling and parsing Dynasty's JSON and then scanning all <code> elements.)

Tag Suggestions Switcher (TSS)

TSS puts a controller bar on the tag suggestions status page (link requires account) so users can select the type of tag suggestions (Approved, Rejected, or Pending) the page displays, whether a single type, a mixture, or all of them.

---

Installation

Make sure you have Tampermonkey installed. Once that is done, if necessary, click this install link and follow the extension's instruction to install.

Whoa, I didn't realize Dynasty supported a JSON API for tags. Any others you're aware of? Very cool!

Alice Cheshire posted:

Ah, that's a good point. Git commands in Mercurial need to have "git" before the command since a lot of them are the same commands between Git and Mercurial. I completely spaced that.

I still get this though:

Dynasty Thingifier% git reset --hard    
fatal: Not a git repository (or any of the parent directories): .git    

This is with my Thingifier repository selected so I'm not sure what to do. I may need to look into Mercurial's reset command instead. (Didn't do the HEAD~1 part since I need to revert back a fair distance and that only goes back one commit from what I was reading in the help file.)

Well, that's odd. My best guess is that the Mercurial client does not actually clone into a local git repository, but simply interfaces with the remote repository and stores everything in its own format locally. I know nothing about Mercurial so I'm afraid I can't help in this case.

Alice Cheshire posted:
Not entirely certain what this means and Git's help page on the reset command doesn't have any functional examples (a very common issue with documentation for most programming related things in my experience) that might indicate what parameter I'm messing up and how.

I'm not familiar with the Mercurial client, but it looks like reset in the console might not be bound to the actual Git reset command? Try something like git reset --hard HEAD~1

Alice Cheshire posted:

I'm using hggit which is one of the default plugins for Mercurial. And I'm not sure but I think this may be what I needed to do:

The default option was "none" and this sounds more or less correct. I'll have to try it out next chance I get to test it though.

Yeah, you definitely want to be using the second option (first is equivalent to git fetch, which by itself does not actually apply any changes to your local repository).

It's just local commits I'm trying to revert. Basically what happens is that I merge your changes on Github then when I sync through Mercurial it considers those changes to not be the main branch for some reason. So if I don't merge them then any changes I make will refuse to push to Github if I try. So what I need to figure out is how to revert back to the point where I downloaded your changes so I can properly get them merged with the main branch locally so I can subsequently change things and actually push them to Github when I'm done. I'm not entirely certain which of those you described this would fall under. I think it may be the last one though.

You should be able to get it to push by pull + update from Github, then doing the push. Although this does result in a more spaghetti commit history and you get to deal with possible merge conflicts. To do what you're describing, you could reset --hard to the commit before you made your local modifications, then pull + update, then reapply the changes. Hopefully your client has an easy way to do this, perhaps by right-clicking the commit and choosing a "Reset to this" command? Just make sure to save your changes elsewhere before you do this (you can actually rebase to do this without losing changes, but, uh.. let's not go there for now, tis a silly place).

last edited at Oct 13, 2017 3:00AM

Alice Cheshire posted:
Apparently when I merge changes on Github and download those changes through Mercurial I have to explicitly tell it to subsequently merge those changes with my local files for some reason before I can modify them in any way. If I don't happen to do that first then it's a complete and utter mess trying to resolve whatever the issue is.

Ah yeah, learning how Git works is kind of a... hostile experience, to put it mildly. I'm not sure what you mean by Mercurial (a Git plugin for a Mercurial client, I'm guessing?), but sounds like it does not automatically merge into your local workspace after fetching from the remote repository (as git pull does). Maybe there is a differently named command that does this?

However, in the case where you have made modifications locally before merging changes from Github, you should be able to resolve this by committing locally -> fetch + merge from Github -> push, provided you resolve whatever merge conflicts it might throw at you. Alternatively you could push with --force to just overwrite the Github history with your local repo, if you're not concerned about possibly wiping out commits.

This is a total mess due to me trying to figure out how to resolve the issue. I'm having issues figuring out how to rollback a change. I found a prune option which just seems to hide changes and there's "backout" or "revert all files" but neither of those seems to actually do anything when I try them.

How to rollback a change depends on how far it's gotten in the whole Git process (stage -> commit -> push). Each command is, naturally, unintuitively named:

• To revert unstaged changes: git checkout -- <file or folder> (I'm guessing this is what "revert all files" does in your client)
• To revert staged changes: git reset --hard
• To revert to a local commit: git reset --hard <commit> (e.g. git reset --hard HEAD~1 reverts to the commit before the latest one)
• To undo a specific commit in the middle of the history: git revert or rebase (this is more complicated so I depend on a GUI for these)
• To revert a commit that has already been pushed to Github: revert the local commit with git reset as above, then push with the --force option

last edited at Oct 13, 2017 2:49AM

Xan posted:

gonna leave this here https://www.youtube.com/watch?v=kH3xUnDm26s

Omg this is SOOO funny. I'm glad my remnant japanese comprehension was still enough to enjoy this. The cinematography was better than expected too was a nice bonus. Thanks a bunch for sharing it :D

For those who don't understand Japanese, give the auto-translated subtitles a try. Hell, try them even if you do, they're hilarious.

ENFORCEMENT OF THE MINI SKIRT COMPUTER

I sent up another PR. It's just moving the change event.

Edit: I haven't tested it with actual suggested tags, but the debugger does seem to indicate that the correct code path gets executed regardless of whether the option is clicked while on the suggestion page, or if enabled by a saved config. (i.e. it enters the if (DT.pendtags) block every time I visit suggestions as long as the option is enabled)

last edited at Oct 12, 2017 11:47PM