robx / pzprjs Goto Github PK

As per the title. Draw auxiliary direction marks on the grid, then switch to "Cross marks" mode (not auto), and you'll find that clicking on an auxiliary direction mark does nothing whereas it should replace the direction mark with a cross.

Specifically, clues that are pointed at by incorrect clues.

double choco error message doesn't highlight source http://puu.sh/DrXZ3/44ebc3221c.png

See image below. The checker seems to think that any areas that aren't exactly three squares large are congruent. I think better behaviour would be that only areas exactly three squares large can be congruent, if you don't want to run congruency checking on large regions.

This is to collect issues with the English translation.

As per the title. When not in object moving mode, dragging an arrow across a circle or across other arrows can result in this sort of weird behaviour:

Switching back to object moving mode causes all sorts of weird stuff to happen:

draw a closed region
click a square inside it
press 1 to place a circle in the square
press "ctrl" which makes the square blank
then switch to answer mode
you can't shade the region
also if you do this, you can't place any symbols with the mouse
attempting to place a symbol with the mouse doesn't do anything
uh, in the cell with the "erased" symbol specifically, not in general

this is probably related to removing cells after drawing some walls

(related issue, you can draw lines then place blocks over them)

puzsq generates some links of the form

https://puzz.link/p?http://pzv.jp/p.html?yajilin/10/10/0.0.0.420.e0.0.410.f0.420.g420.h0.r33h120.g330.0.f130.0.0.e310.0.0.0./ 

These are broken, but they do work. I'm redirecting to the correct link via nginx now, but it would still be good to handle these more cleanly. E.g., via pzprnode, I'm getting some solves reported with pzv = http://pzv.jp/p.html?yajilin/10/10/0.0.0.420.e0.0.410.f0.420.g420.h0.r33h120.g330.0.f130.0.0.e310.0.0.0./ .

One option (heyawake style)

Probably better to highlight one of the components, as is usually the case for "shaded cells are divided"

https://twitter.com/pzosdc/status/1118855768877359104

it seems to not count the outside border

@x-sheep could you look into this?

Someone posted the following puzzle on twitter: https://puzz.link/p?curvedata/20/20/0zzzzzzzzzzzzzzzzzzzy/20/20/fffffffffbfffffffffbfffffffffbfffffffffbfffffffffbfffffffffbfffffffffbfffffffffbfffffffffbfffffffffbfffffffffbfffffffffbfffffffffbfffffffffbfffffffffbff7ffffffbfffffffffbfffffffffbfffffffffb5555555551

I've made a change to the linewidth so that the clue is somewhat visible now. But when trying to solve it, the checker seems to break down towards the end, with my browser asking me if I want to stop the script.

In the situation below, it's impossible to finish drawing the diagonal rectangle, because apparently the marked empty cell is considered part of a grid-aligned rectangle.

Assuming that part is desirable, it should not be possible to mark empty cells within large diagonal rectangles empty. Or something else should change.

A cell in a neighboring row/column can cause autocompletion, but this doesn't currently trigger a redraw.

Several twitter users report that https://puzz.link/list.html doesn't work. It displays a list of bullet points without any labels. Clicking a button results in the following script error:

ReferenceError: v3index is not defined

This happens on my local checkout as well.

there are some gray borders displayed in edit mode that shouldn't be:

There should be a test per fail code per type, but there are some missing currently.

It's possible to place notes in the corners in meandering loop. These should disappear when placing numbers by dragging.

This issue is to collect missing Japanese translations.

currently you can draw a loop over the shaded cells, which seems to not be very useful

suggestion: drawing a loop onto a shaded cell unshades the cell; shading a loop cell removes the loop segments that use that cell

interesting bug with circle movement during editing: if you delete a partially moved circle bad things happen http://puu.sh/Dv5AD/9499cb3fe7.png
to reproduce: pick a genre that involves moving circles, place a circle and move it around in answer mode
then switch to edit mode, select the square the circle is currently on, press delete, then select the square the circle originated from
the head and tail of the path should be deleted, but the path is still on the board (and prevents other circles from moving through it)

i use one button auto input. create a region in edit mode, and in one cell click three times in auto (this goes through circle and triangle then back to blank). go to answer mode, and the region it's in shouldn't be able to turn black (it alternates between white and green)

Compare #7. A possible explanation is a middle mouse button event.

e.g. this works: https://puzz.link/p?amibo/20/1/9s
but after changing the clue to 10, the url becoms https://puzz.link/p?amibo/20/1/t

there appear to be none

with grey clue cells, question marks shouldn't be shown

This is off twitter, due to @pzosdc.

The "check" button in Spiral-Galaxies works correct when you partition blocks after placing stars, but it works in-correct in some cases such that you place stars after partitioning blocks.

To reproduce this, place the left star in edit mode, switch to answer mode and draw the border, then switch back to edit mode and place the right star, then hit the check button.

The border lines should go under the dots, they don't always.

I haven't been able to reproduce this.

via an answer code check (like heyawake's "there is a room which is not a rectangle")

Apparently hitting the volume mute button on a laptop keyboard clears a cell. It shouldn't.

White cells are usually the main thing you enter in nurimisaki, hence that should be definitive for answer checking purposes.

I think the new unshading mode which doesn't erase shaded cells is very nice on the right mouse button, but not on single/left-button input. Should fix that.

This rule is currently validated after rules such as checkViewOfNumber and check2x2UnshadeCell.

I'd argue that this rule belongs at the top of the priority list, since the only way to violate it is by making a mistake (as opposed to just having an incomplete answer).

We use the error code test cases to generate rules pages, e.g. https://puzz.link/rules.html?cbblock.

For some puzzle types, these are incomplete, ordered awkwardly, or otherwise not very helpful.

The hard work here is coming up with better test cases, and it's easy to help here without touching the code: Create an example puzzle, and "solve" it to exhibit each error scenario, and save via "File -> Save file as..." and send them to me.

I tried this with a yajilin:

• start solving
• enter trial mode
• draw a few more lines
• erase the answer
• some lines will be drawn in trial mode again

This is to collect some obvious improvements to existing puzzle types.

• It would be great to be able to easily "shade" the wall in Nanro. Perhaps by shading numbered cells and placing the numbers automatically, or by providing a fully shaded variant puzzle. ✅ (partially done)
• Similarly, bag/corral/cave would benefit from a shading input. ✅
• Fillomino number entry is also awkward, maybe something like what croco-puzzle does?
• Auto-shading of completed clues for Yajilin. ✅

As reported on Twitter. Presumably some nonzero qnum.

this may affect similar puzzle types

I've seen this quite frequently with ringring, but elsewhere.

@edderiofer found this:

It would be nice to automatic borders around e.g. single 1s. This isn't purely visual though, since such walls would change the completion check. E.g.:

http://pzv.jp/p.html?fillomino/2/2/1i

Currently the puzzle is not complete after adding a single 3. It is complete after additionally drawing walls around the 1.

Sometimes, when drawing a bed with left-drag, it stays shaded red after lifting the mouse button, and weird things happen.

This may be related to the heyawake input change.

It should be "check connection of white cells" probably, and it should do something.

When you change the "invalid cells" around in an 8x8 fivecells grid (default is that the corners are missing), then export the puzzle url, and load the generated url, you typically end up with extra invalid cells. E.g.:

exports to http://pzv.jp/p.html?fivecells/8/8/7777zzh, which loads to

I just added heteromino, where I phrased the same shape rule using the word "touch". It was pointed out to me that "adjacent" might be more correct when talking about "touching by an edge". On the other hand, star battle currently uses "adjacent" so it seems the change doesn't help a lot without going over all the instructions and phrasing things consistently.

On puzzles with a dashed grid, redraws sometimes move the dashing of grid lines around. They shouldn't.

(It's a theory that this is due to selective redrawing.)