I would compare them, but there’s an error in the console with your calculations - it fails to fetch a non-existent srs_stages endpoint, so the calculations never appear.
My calculations in 1.1.0 also account for dependencies. Feel free to take a look at what I’m doing!
I have the same problem. I think it’s due to how Tampermonkey handles when a script is loaded, and how navigation on the wkstats site works.
The navigation bar at the top of wkstats doesn’t trigger a full page reload, instead it only seems to fetch the part of the document that needs to be updated with javascript, and updates the page, history and URL from there. This is why you never see a full page reload when you’re navigating wkstats. However, Tampermonkey and similar extensions only check if a script needs to be activated once a page is loaded, and since this script is only enabled on the projection page, it will not activate unless the initial page loaded was this page. Hence why it does work if you use the link in the OP, since that takes you directly to the projections page, and thus the URL matches what Tampermonkey expects, but doesn’t work if you go there using any other page on WKstats as the first page you visit on the site. You can also manually trigger a full reload of the projections page, after which the script activates too.
@UInt2048 I think a solution for this could be to allow the script to run across the entirety of wkstats, and then add a listener to detect if you’re on the projections page, and running the script if so. I think this should work as a workaround for how these extensions manage when to run their scripts, as they don’t seem to activate scripts if someone changes the URL using the history API.
I agree. I had that idea as well. I plan to do this in the future.
Could you add a console.log(stats[45]) on line 188 for me and share the console output?
As I said, I don’t know what I’m doing. I see no line 188 or any other numbered line. Am I even in the right place? Can you explain what I need to do in more detail?
Go to the TamperMonkey (or equivalent) dashboard and edit the script. Then you should see line 188 to insert this code.
Thank you. That’s interesting - it suggests that kanji of level 45 will be ready for you in 2.5 hours and 10.5 hours. Is that true?
It is. The reviews that will guru the radicals that will unlock the final 4 kanji of level 45 are coming up in 2.5 hours. After that, I still need roughly 4 days to guru at least one of them in order to level up.
On wkstats, I added an event each time the user navigates to the Projections page. You can use it like this:
//--------------------
wkof.on('wkstats.projections.loaded', your_startup_function);
function your_startup_function() {
// Your script's startup code here
}
//--------------------
[edit: oh, and I fixed the srs_stages issue, so the projections page’s calculations are now visible in the Javascript console again]
Yes, it is better, but still not quite right. It currently says that the fastest I can level up is NOW. But actually, I have a few kanji that I haven’t even done the lessons for yet, so even if I did them now, the fastest I could level up would be a few days from now.
And the right and left columns are still showing dates from last year.
Silly question, may have messed sth up but I seem to travel back in time with each level? 
Any reason why this may be happening?
Just pushed version 1.1.1 to add a debug current level view. If you would like to report problems with the projection for the fastest possible projection for your level + 1, please include a screenshot of this as well.
@Greti33 I don’t know. I can guess that this value for level 31 is in Central European Time and that this is the value of new Date(0) but I don’t have the slightest idea why that’s happening to you.
I’m a little concerned by your fastest as well: levels 31-39 shouldn’t be fast levels!
@rfindley Thank you for this. Unfortunately, I’ve played around with it, but I’m kind of stumped.
To anyone, this script does have a GitHub. I made this for personal convenience and hoped it might help others. If you know how to fix something wrong, please submit a pull request there! 
so happy this exists and sad at the same time…(realistic vs fastest)… thanks for putting this together…it’s not perfect but with my slowness it’s plenty accurate enough
2024… (maybe sooner with 50-60 but at least I’ve never reset)
Hahaha, that’s fine - I kinda like this power anyways 
I just fear that I may be unable to continue my WK journey once I get yote back into 1970, pre-WK launch.
But srsly now, thanks so much for putting this together (and unleashing my true potential) - it’s nice to be able to look at projections after so long! :333 I’ll try to have a look later myself, perhaps I can help out a lil :3
I updated the script to use @rfindley’s new callback to load the script once the projection page is loaded. I also found a bug where if the script had been active and another page on the site was loaded after it, some tables under Items would fail to load. I found out a modification of the Array prototype was causing it, so I changed the added methods to normal functions for now which seems to solve the issue. I made a merge request on the github for it 
I’m guessing the first of these two is left over from an earlier edit:
@BIsTheAnswer Thank you. 1.1.2 is now live and your PR has been merged.
@rfindley Good catch, this has been fixed in 1.1.3.
The fast level mismatch is not specific to me though. If you look at shuly’s screenshot, fastest start date for 45 is Feb 17, and for 46 it’s Feb 20, only 3 days later.
Mine still claims I should have levelled up hours ago:
Interestingly, the kanji analysis looks okay as far as dates go (the times are a little off):
I also notice that 48 appears to be a fast level, when according to the autoupdated list of fast levels it isn’t. And 49 seems to be a slow level when it’s in fact fast. 52 also appears slow when it isn’t (always according to that list of fast levels).
