Scorbie wrote:@Sphenocorona Great job. I guess you would be sleeping by now, but it works real nice on 32bit linux. (Or, a 32bit ubuntu derivative at least.)

Works fine on a 64-bit Windows laptop as well, as I implied on the Demonoid thread where this all came up. Thanks again!

Sometimes when I paste a new puzzle in and add still lifes, then exit the program, the changes to the search tree apparently aren't saved to the .sod file. Other times it works fine. I haven't figured out if this is due to some kind of corruption in the backup file format. Maybe a further small adjustment is needed to complete the fix.

I vaguely remember running into this problem in SODGame 0.3, so it's nothing new. I think, but I'm not sure, that newly added keywords are sometimes actually visible in the save file, but the data is not in a form that can be read back out again. Further bulletins as events warrant.

In another thread, Sphenocorona wrote:I'd like some input on this thought I had regarding SoD: should I add the honeyfarm constellation as a bait object? It's completely impractical in the current version, and yet they're one of the cheapest stable patterns to produce. Naturally, fixing the save game issues is important, but I had just been thinking that we could miss a cheaper method involving an HF.

It probably wouldn't hurt to have a honeyfarm as a bait object. On the other hand, they're fairly big and there won't always be room for them.

It might be worth writing an objects.txt file when the application closes, and reading from it at startup, similar to the savegame file. Then people could edit the file to add whatever objects they might want -- useful splitter/edge-shooter constellations or whatever.

It may not be obvious from the current GUI, but honeyfarms can be added quite easily already. Create a honeyfarm in Golly, with regular state-1 cells. Copy it to the clipboard, and in the SoDGame, roll the mouse on "Puzzle" to turn it to "Seed". Click on the "Seed" button and you can paste in any object you want to use as a bait.

This was a last-minute addition to the alpha before Paul stopped working on it, so it's not well advertised, and it doesn't work quite like other seeds -- there's no option to rotate or reorient or rephase an asymmetric bait, so you have to paste it in in the right orientation.

Other possible improvements include access to all four phases of gliders, or multiple phases of a pasted-in blinker or other oscillator seed. I'd rather the Demonoid cleanup circuits had only stable patterns in it, but it certainly seems to be true that blinkers are very cheap and efficient when you need to extend a reaction -- blocks are more implosive than explosive.

------------------------------------------

While I'm wishing, it would be really nice to have keyboard shortcuts to cycle through the baits, and to cycle through the different orientations/phases of a bait. That would make the SoDGame usable on a laptop, and would also make it much more efficient to test different baits while keeping the mouse centered in a key area.

The only thing better than that would be an option to try all possible baits automatically inside a small selected area, showing results in order of smallest final population... but that's a much bigger feature request!

Version 0.5 will have honeyfarms as a built-in seed, so that they won't clog up the paste seed feature (I actually had seen that feature previously and then forgot about that when stating my wish to add HF as a seed). I've also reordered a couple seeds because the previous order put gliders in the middle of the list (I think putting them at the beginning is more logical) and hives were buried in the middle of the list which seemed pretty silly.

I also figured out the shorthand convention for the stills, and noticed that tubs are named incorrectly according to it; the format is [number of still lives][first letter of still life name][still life pop]; but the tub is called T3 by the program. I'm going to be changing that to T4.

These are still minor things; I do plan to fix the save game stuff before actually releasing 0.5.

There's another change I might make, that will actually change the game itself - two leveled quarantining. Some trivially legitimate solutions that can be constructed (placing two hives point-to-point for example) are prohibited by SoD's current quarantining method, but allowing for some regions to be partially quarantined (where stuff can be placed there, but only under certain conditions) would make these all possible.

Obviously, situations where a block that interacts with a conduit without having an effect won't be helped by this, but supporting that sounds like more of a nightmare than anything else currently suggested.

Okay, this is really confusing. Nodes that disappear are saved, and the program seems to be able to read them despite not showing them. But upon closing, during the save routine, they aren't written to the savegame, and they are deleted forever.

But it's also possible for puzzles to only disappear the second or third time around, instead of the first. In these cases some other puzzle has already disappeared, and then those end up next on the list. Multiple puzzles can disappear at the same time, too, but if no puzzles disappear after a session then those ones will never disappear unless the save gets corrupted...

... I'm not sure I want to try and figure that out. Expect that whenever 0.5 comes out, it will not be compatible with your current savegames I'll only be releasing that once I'm sure that things save properly with whatever new savegame system I end up creating.

Sphenocorona wrote:Okay, this is really confusing. Nodes that disappear are saved, and the program seems to be able to read them despite not showing them. But upon closing, during the save routine, they aren't written to the savegame, and they are deleted forever.

That matches the strange behavior I've seen. The problem is subtle enough that I haven't been able to come up with steps to reproduce the problem.

I don't think anyone will have a problem with an incompatible update -- can always keep an old version of the SoDGame around to open old savegame files. I hope you'll consider having the next savegame format be some editable format or other... Andrew Wade used YAML in his Gemini-building code, not that that's particularly relevant. The details don't matter much as long as it's possible to make careful adjustments with a text editor.

The bug fix is fairly stupid and doesn't solve the actual root problem, but instead simply makes sure that the bug never kills any important save data. Unfortunately, this means that opening a 0.4 savefile will still result in data loss. After the first session everything will save and load safely. In order to avoid re-incurring data loss, do not open 0.5 saves with older versions of the software unless you want to lose 0.5 of your data.