It looks like wkEnableAudio is checking the answer somehow without calling answerChecker.evaluate or enhanceAnswerChecker. Is there some other answer checking function that wk uses that it might be a good idea to also patch?
For the multiple audio playback issue, did the issue only start after this most recent set of changes? If you’re still looking for the issue and post code, I can take a look at it.
Not that I’m aware of… but a lot of the new UI code is difficult to read without a React dev plugin.
I assume it only started after removing everything except enableButtons()… but until now, I haven’t really done much testing on Lightning any time recently.
If it looks like I need some help, I’ll go ahead and post the current code, but I’ll spend a few minutes narrowing it down first. (I had taken a break for the evening to eat dinner and spend time with my wife, but now I’m back on it).
Not sure if you are still doing this, but I do think it is still necessary to temporarily disable wkEnableAudio when you go to call old_submit_handler.
It seems to be working fine without disabling wkEnableAudio.
I’ve just discovered that the multiple-audio seems to be linked to clicking the ‘play’ button (for the audio) after answering wrong and then retyping a correct answer, with lightning enabled.
Actually, it seems it’s simpler than that. Just typing a wrong answer, then hitting backspace and retyping the correct answer, it plays double audio. But only in lightning mode.
I did some checking and have verified that in the latest published version of the script, failing to disable wkEnableAudio when doing the real submit causes the audio to play twice. However, this is often very difficult to notice because if your computer is somewhat fast, the double audio will often start at the exact same time. So instead of sounding like the audio playing twice, it merely sounds like the audio is playing back slightly louder, which is easy to miss. You can verify this by logging the number of calls to wkEnableAudio and verifying in the console that wkEnableAudio(); wkEnableAudio(); sounds slightly louder than wkEnableAudio();
Edit: Also, if you have lightning mode disabled and submit the answer, wait for the audio to finish, and then continue to the next question, you hear the audio playback two distinct times total. This issue only happens for me if wkEnableAudio isn’t disabled during the real submit.
Rather than disabling wkEnableAudio(), I’m temporarily setting window.audioAutoplay = false. That allows all side-effects inside enableButtons(). Seems to work well.
edit: When lightning mode is ON, I don’t set audioAutoplay to false. I leave it at it’s current value.
I’m currently adding the setting for hitting ‘+’ to cycle through correct answers. After that, I will post an update. Shouldn’t be long…
Things are already being looked at it seems, so please accept my thanks for the update, rfindley. And thanks to the community for being so quick to jump in and help. Much appreciated. <3
And much thanks to @est_fills_cando and @Sinyaven for helping troubleshoot and contribute fixes.
Sorry I misunderstood. That sounds reasonable.
With the latest update I have no sound at all, and no way to turn it back on. The echo was preferable…
I don’t think there’s been any update in the last several hours. What version of doublecheck are you using and have you tried disabling all other scripts except wanikani open framework?
Confirming that audio is working again on my end. Much love.
Still broken for me, but possibly because the above link installs 2.2.23 (despite saying 2.2.24). Presumably it’s a caching issue; I’ll try again later.
I’m in Chrome, I simply went to the Utilities > Check for userscript updates and pulled the update in that way. Feel free to ignore if this deviates from your set-up.
Just verifying that, after updating to 2.2.24 (which just required time) the audio is working again
I found a bug where settings.lightning_enabled can get desynced from whether the lightning button has the active class. For example, this happens when lightning mode is enabled and you open the kana chart dropdown. I think the issue is that WaniKani’s own code looks for tags that have the active class and removes it in certain cases:
[ // WaniKani's additional-content.js
function toggleContainer(contentId, elem) {
elem.toggleClass("active");
$(".active")
.not(elem)
.removeClass("active");
So the fix would be to rename your class to doublecheck-active or something.
Edit: You may also want to fix this in the standalone lightning mode script you maintain.
I had a hard time troubleshooting this issue. I have so many userscripts for wanikani installed that I had to deactivate every single script to find the troublemaker. But finally after the update it works again!
Noticed a new autoplay audio bug that appears to be coming from this script. Audio is not autoplaying after answering reviews correctly. And when I disable this script, the audio works again.