Ghost changes

[freaktechnik]

This is a really weird one that I'm calling "ghost changes".

STR:

• Work on solution for a puzzle
• Suddenly one row will become invalid (but from what is visible to the user is still valid)
• Finish the puzzle with everything looking correct, but one row still red for unknown reasons
• Other rows and columns will become invalid once completed and some cells will toggle their state (so far I've only seen cells marked as empty become filled up)

It seems that something may be accidentally changing the values of cells. I do not see any logging output or similar and I have not used any of the auto-solving abilities with affected games/boards. I usually have used the "fix my mistake" thing (though not on the ghost changes when finishing a game with them), which will revert to an arbitrary state when these "ghost changes" occur, btw.

[jeremypw]

Thanks for the report. I have not noticed this but I mainly play using Juno unstable where I develop. Maybe something different in Loki so I'll try playing more on Loki. If you have 'tap to click' enabled it is quite easy to accidentally change a cell, but in that case the row/column should be visibly invalid. If the clue turns red while the row/col is actually valid there must be a mistake in the code somewhere. I'll try and find it before next release.

[freaktechnik]

I play on a desktop with a wired mouse, so tap to click is not the issue. This is primarily a visual issue IMO, where the internal model state seems to de-sync with the displayed state. The internal state changing unexpectedly is something I'd be much less concerned with if that de-sync wouldn't happen, since the displayed state actually is consistent in itself.

[jeremypw]

The error state of the clue is one thing, the fact that the cells themselves change state is quite another (and harder to understand). The underlying model holds two grids - one for the solution and one for the workings. A work grid cell can only change state individually (theoretically) if the user clicks on it, or if a move is undone (or redone) or if the "hint" button is pressed. Of course "restart" and "autosolve" will change a lot of cells. The displayed cells do not hold any state independent of the model - they are drawn directly from the model.

Does this happen with any particular sizees of grid or difficulty settings?

[jeremypw]

Oh, and certain keys change cells: 'F', 'E' and 'X' keys mark a cell Full, Empty and Unknown respectively. Ctrl-Z undoes Ctrl-Shift-Z redoes, Ctrl-H hints, Ctrl-R restarts, Ctrl-N for new game.

[jeremypw]

When you say "suddenly a row becomes invalid" I assume this happens after making (or undoing) a move rather than at a random moment?

[freaktechnik]

Yes, this seems to be linked to user interaction, which makes sense. I haven't managed to pin it to a certain kind of user interaction.

Do the keyboard shortcuts affect the hovered cell? Is there cell-focusing with the keyboard? If not, then I can safely say that can not be the reason.

I mainly play on 15x20 and moderately difficult with random patterns.

[jeremypw]

The F,E and X keys affect the cell where the cursor is (Arrow keys move the cursor). I mainly play on 15 x 20 as well.

[freaktechnik]

Right, so I can rule out keyboard interaction then.

[jeremypw]

No, the cursor is the circular black frame which moves when you move the mouse, or press the Arrow keys.

[jeremypw]

I have found one flaw in the logic for striking out the completed blocks affecting certain corner cases, but I do not know whether it explains your problem.

[freaktechnik]

I have noticed the striking out to not work properly in corner cases too, yes, which is probably what you found, but those shouldn't be related to marking them as invalid, I assume?

[jeremypw]

It could do since it involved miscounting the number of complete blocks in some circumstances.

[freaktechnik]

I've had the issue 1.5 times in a recent game. Note that the first one had the "Ghost" issue and I only managed to screenshot after it had corrected the appearance.

I guess it's unexpected that the error finder only notices when a block is enclosed that there's not enough space.

The last screenshot is the "purest" bug, I guess.

[jeremypw]

@freaktechnik : Thanks for these examples. In each case shown, the clue is correctly marked "in error". In screenshot 2, you have a block of 4 instead of 5 and in screenshot 3 you are missing a block of 1. Which bug do these illustrate?

You are right that only completed blocks are considered when deciding whether there is an error (at the moment), and the have to be connected to an edge. I don't want to make it too easy for the solver ;-)

[freaktechnik]

In the last screenshit for example the first vertical row (top left) should also be marked as wrong, but is not. Im the first one you can see the horizontal and then later wrong row be marked as correctly done (and I'm quite certain I had correctly marked it earlier until it suddebly jumped to an error state and "toggled" the cell).

[freaktechnik]

In the first screenshot the horizontal row is marked as wrong incorrectly. However the second screenshot reveals what the board state actually was.

Note that these screenshots were taken in reverse order than they were uploaded, so the "wrong" cell got marked as empty on the screen between screenshots, however the internal model was not, thus the row is still marked as wrong.

Toggling its state fixed the issue. The screenshot uploaded here as first Screenshot is after reverting to the last correct state but it did not revert to an actually valid state, since the row is still marked as invalid. And when I go through the changes protocol only me actually toggling the value is in there (with redo/undo).

[jeremypw]

OK,thanks, so the problem is that errors are missed in some cases (which is the effect of the logic flaw I have already found). The grid cells should only show the model state, but the clue labels do have their own state with respect to the strike outs and error colour. The cell toggling by itself is puzzling but I'll try to find out the cause and construct a test case. Thanks for taking an interest in improving gnonograms!

[freaktechnik]

It seems the displayed board state is corrected as soon as the game loses focus (which is why I can only get a screenshot of the invalid state after reverting to the last "correct" board, which is still incorrect (since the first screenshot in my last comment was supposedly the last correct state).

[jeremypw]

That's interesting. It sounds like the window is not always being redrawn when it should be. I think I am calling "queue_draw ()" at all relevant points but I'll check.

[jeremypw]

If you are interested, you can get a pre-release package for gnonograms from here:

https://github.com/jeremypw/gnonograms-testing

You should just be able to download the .deb file and install it using Eddy (from the AppCenter). Please let me know if you need further info.

[jeremypw]

Version 1.2.2 includes some changes that should fix the issues you raised but if you are able to beta test it that would be very helpful.

[jeremypw]

To go back to the released version, just uninstall gnonograms using the AppCenter and then reinstall it.

[freaktechnik]

Thank you for this version, I'll install it asap!

[jeremypw]

@freaktechnik : Did you manage to install the pre-release version?

[freaktechnik]

Yes

[jeremypw]

Did it fix any of the issues you raised? Were there any regressions?

[freaktechnik]

So far most things seem fixed, but I've only played about 4 games so far on it.

[jeremypw]

OK, thanks. I'll leave it a bit longer and if there are no regressions then I'll release it. Please comment against any issues fixed.

[freaktechnik]

Haven't seen the crashes and this in a while now. Will re-open if I encounter them again.