Feedback and Questions

Interesting puzzle!
Not sure how you get the 3s removed from G7/H7. I'm sure you're right though.
The solver really struggles with such large cages as the number of dog-legs gets beyond what I programmed so it might be giving up on this cage at certain points.

I might have fixed it
Refresh now [CRTL]+[F5], will say v 2.12
Many thanks for the reports, and I hope it works now
All the best
Andrew

Possibly when I was updating the page. How is it now?

I wouldn’t try and compare two close scores as anything very meaningful. They work best in aggregate and statistically but there is too much arbitrariness at that grade. So with the puzzle with the extra clue a naked single is found. This takes priority over everything else so everything takes one step more than the other puzzle (14 steps not 13). There is weighting for how long a puzzle takes to solve/collapse which modifies the scores each round. That will bias the 14 step solution and give a slightly higher score.

Yes that’s one way to think about it. Been a long while but I’ve always approached the strategies from the pov of chipping away at candidates and hoping that will reveal a solution – and mostly that’s the way they work. This rule does go direct to solutions. The mechanism for return data back to the solver is subtractive – a list of candidates to remove. So it’s a little more mechanistic than a human. Might figure out a tweak when I go back into simple colouring gain.

Definitely the browser cache. Both request the same script file and I've set the version to be the same.

In the solver editing a single note immediately changes to a solved cell. However in between two take-steps on a fresh board it is possible to get a single note.

It is true the old print would carry this over as a candidate. But the old way confused some people since, in certain circumstances, it would refuse to draw the board at all. This is because the print page read the opener page directly but if the opener page disappeared, or multiple tabs, or refreshed, the print page would lose its data. Took a very long time to figure out this was happening. And this method was in response to a previous method which passed all the data on the url parameter but this broke in some situations because a) great length and b) the numbers were delimited by commas and in many email programs successive commas broke automatic hyperlinks. So this inspired the ‘packed string’.

The new method passing the packed string is problematic as well since it is designed for the solver and one number in a cell signifies a solved cell. I am loath to change the format of this string since it would invalidate all the packed strings in existence. One needs a solution that is backwards compatible. So my solution is to rely on context. Since I control the function to pack the string at that point and draw the print page I’m reusing the clue flag, which is irrelevant to the print page, to flag that a single number is a note and not a solution. Voila:


link

Okay I just spotted that. Bug is 10 minutes old. :)
Please also [CTRL]+[F5]. I will update the version number to bump this.

Fantastic, kind words, thank-you

Cheers! And glad you like the UI updates, always dicey changing something that been up for ages