Life tag testing

[dvgrn]

The triangular neighbourhood has twelve neighbours. I need a single character way of representing the neighbour counts without using "B" since it will confuse the parser: so 0123456789ABC won't do. Any bright ideas?

The most traditional option for zero through eleven would be 0123456789XE, but unfortunately that doesn't help with the neighbor count of twelve.

It would be great to find some notation related to Conway's base-13 function -- mentioned here -- but I haven't found anything yet. By analogy to "E" being an upside-down "3" -- LaTeX \textturnthree -- we could pretend there was a \textturnfour and use 0123456789XEh, or 0123456789XEH I suppose.

Or if you prefer the analogy of E standing for Eleven, it could be 0123456789XET. But that seems confusing, since T could equally well stand for Ten, Twelve, or Thirteen. So how about 0123456789XED ("D" for "dozen")?

[rowett]

Nice ideas!

I like the roman numeral for 10. How about 0123456789XYZ?

[dvgrn]

Nice ideas!

I like the roman numeral for 10. How about 0123456789XYZ?

You know, that definitely has a certain elegance to it. Sure, I'll vote for that one.

[rowett]

Build 318 is now available on the lazyslug server

Enhancements in this build:

• triangular rules now support three neighbourhoods - test
  • Triangular (postfix "T") with 12 neighbours (touching triangle edges and vertices)
    • neighbourhood digits are "0123456789XYZ" where X, Y and Z represent 10, 11 and 12 respectively
  • Triangular Edges (postfix "TE") with 3 neighbours (touching triangle edges)
    • neighbourhood digits are "0123"
  • Triangular Vertices (postfix "TV") with 9 neighbours (touching triangle vertices)
    • neighbourhood digits are "0123456789"
• cells can now have a border
  • new Border button in bottom-right menu
  • hotkey Alt and "X" to toggle setting
  • new script command [[ CELLBORDERS ]] to turn cell borders on

Fixes in this build:

• drawing cells wasn't correctly updating tile map
• triangular rules now ignore [[ HEXDISPLAY ]] script command
• check bounded grid width and height are even for triangular rules

[rowett]

Build 319 is now available on the lazyslug server

Enhancements in this build:

• triangular rules now support B0

Fixes in this build:

• improved triangular cell alignment

[rowett]

Build 320 is now available on the lazyslug server

Fixes in this build:

• further improvements to triangular cell alignment
• triangular patterns may be padded with a blank row and/or column on copy to ensure even/odd alignment

This build is a Release Candidate.

[rowett]

Build 321 is now available on the lazyslug server

Fixes in this build:

• changed triangular rule postfixes from T, TE and TV to L, LE and LV

This build is a Release Candidate.

[rowett]

Build 322 is now available on the lazyslug server

Fixes in this build:

• improved hexagonal cell drawing
• fix for LV neighbourhood

This build is a Release Candidate.

[dvgrn]

Aha, LifeViewer has become the gold standard!

Any interest in supporting Lua-script pattern format? It doesn't actually require being able to execute arbitrary Lua code; what recognizer.py puts out is just a very very predictable subset of the language, describing orientation and position of the various named structures.

[rowett]

Aha, LifeViewer has become the gold standard!

Splendid

I've certainly seen interest in various rule families increase (or reawaken) when LifeViewer (finally) introduces support for them.

Any interest in supporting Lua-script pattern format? It doesn't actually require being able to execute arbitrary Lua code; what recognizer.py puts out is just a very very predictable subset of the language, describing orientation and position of the various named structures.

Sure. I presume the rule is always Conway's Life?

[rowett]

Is there a standard library of components? If so then they wouldn't need to be defined in the script (which would further reduce its size). Also those components could become pattern editor primitives.

I've often looked at some of the amazing constructions but decided the barrier to entry was too high. My poor brain has enough other things to store. If I had a component based editor where all I needed to do was glue together pre-defined pieces I'd be much more likely to have a go.

[dvgrn]

Is there a standard library of components? If so then they wouldn't need to be defined in the script (which would further reduce its size). Also those components could become pattern editor primitives.

Yes, there's a standard library -- or rather, there are several standard libraries, depending on what you're building. The library for things like the glider-to-weekender converter is the Elementary Conduits Collection, which I managed to get organized some years ago in such a way that standard systematic names could be assigned to new discoveries. That has worked out very well, and Freywa has recently taken over maintenance (yay!). There's an archive of separate pattern files, one for each component, and a script that builds a big stamp collection out of them.

"Chain reaction" structures, like the self-destruct mechanism in a loopship, use a splitter and turner library instead. There the identifiers haven't been assigned yet, but they need to be.

Of course Herschel conduits can be strung together with the Herschel conduit collection, which also has a standard nomenclature.

There are some practical complications, of course. New improved versions of conduits occasionally appear, that can replace most but not all instances of the older versions. If named components started getting referenced from these various collections, we'd have to be careful to add improvements under new names, and keep the old names the same. Luckily we pretty much do that already... and it would become pretty simple to replace "fx119a" with "fx119d" in a Lua pattern script, recreate the pattern and just see if it works with the new variant.

The angle that's being pursued by the, um, CA Discussion Group/Secret Cabal that's been meeting on Google Hangouts on Sundays for the last couple of months is some kind of Puzzle Editor for Project von Neumann puzzles. The latest suggestion from Adam seems like a good simplification, allowing the puzzles to come first and editor functionality to follow along afterward (we hope).

The next Secret Cabal meeting is on April 28th -- would you be interested in making an appearance? We (so far it's just Michael Simkin, Paul Callahan, Martin Grant/Extrementhusiast, and me) usually start with a video/voice hangout, but then mostly shift to text Google Chat since it leaves a better record of the discussion.

[dvgrn]

I've often looked at some of the amazing constructions but decided the barrier to entry was too high. My poor brain has enough other things to store. If I had a component based editor where all I needed to do was glue together pre-defined pieces I'd be much more likely to have a go.

Well, that's definitely the big issue. A lot of people over the years have wished for a component-based editor, but nobody has quite wanted to write one! One of the big sidelines of this Project von Neumann idea is to figure out a design for a puzzle browser.

If it's done right it could make it a lot easier for new people to snap together pre-packaged components into a working Life-pattern solution, which would instantly give these Project vN puzzles a much wider potential audience.

On the other hand, there's a reason why a component-based editor hasn't been done yet. Paul Chapman did a lot of work along these lines in the mid-2000s, for example, but got bogged down by feature creep. It's very easy to cast too wide a net and try to support too much.

Trombone-Slide Example
For example, my mock-up screenshot shows pairs of Snarks used as "trombone slides" to adjust the timing of output gliders. It'd be nice to be able to lock two Snarks together and click-and-drag to move them together, diagonally.

But then, in one of the actual common uses of this kind of circuitry, in the gun collection, the Snarks are sometimes replaced with bouncer or bumper reflectors, with periodic oscillators attached. Ideally it would be great to support those, too -- but then when you click-and-drag, the phases of the oscillators should shift automatically so that the reflector will still work when the gliders get to the new location.

Then when a Snark or bumper or bouncer or semi-Snark or semi-cenark or syringe or what have you gets close to another mechanism, there's another whole library of welded combinations -- different spacings need different welds. It would be _really_ awesome if the click-and-drag operation could apply or remove those welds automatically as they're needed.

(And so on.)

Feature Creep Doesn't Have To Win
However, even just the simplest possible component-based editor -- anything, for example, that can read a Lua pattern-script, allow simple non-welding adjustments, and write changes to the same format -- would be a huge improvement over the current status quo.

EDIT: One minor concern is that recursive pattern-script format is a very efficient way of representing huge patterns in a small number of characters -- and LifeViewer isn't really designed to handle the largest strata of Life patterns; that's more of a HashLife thing. (One of my long-delayed projects is to fit the Caterpillar into probably about 100K of Lua pattern-script format.)

Still, it's plenty good enough to handle the glider-to-weekender (just added the RLE), at a pinch, so probably there's not really much to worry about.

[dvgrn]

Any interest in supporting Lua-script pattern format? It doesn't actually require being able to execute arbitrary Lua code; what recognizer.py puts out is just a very very predictable subset of the language, describing orientation and position of the various named structures.

Sure. I presume the rule is always Conway's Life?

At the moment that's all recognizer.py has been used for. But the scripts themselves (the recognizer script, plus the auxiliary script that registers patterns and maintains the library file) are fairly rule-agnostic. I think they could handle recognizing oscillators in other rules just as well as Life, with only minor code changes needed if any at all.

So the Lua pattern-script format should probably be extended to include a standard g.setrule("B3/S23") line at the top, in lieu of the usual RLE header.

[rowett]

The angle that's being pursued by the, um, CA Discussion Group/Secret Cabal that's been meeting on Google Hangouts on Sundays for the last couple of months is some kind of Puzzle Editor for Project von Neumann puzzles. The latest suggestion from Adam seems like a good simplification, allowing the puzzles to come first and editor functionality to follow along afterward (we hope).

Yes that looks good.

The next Secret Cabal meeting is on April 28th -- would you be interested in making an appearance? We (so far it's just Michael Simkin, Paul Callahan, Martin Grant/Extrementhusiast, and me) usually start with a video/voice hangout, but then mostly shift to text Google Chat since it leaves a better record of the discussion.

I'd be happy to participate. What time is the meeting? I'm based in the UK.

[rowett]

So the Lua pattern-script format should probably be extended to include a standard g.setrule("B3/S23") line at the top, in lieu of the usual RLE header.

Perfect. I'll update my test case accordingly.

[rowett]

When you assemble patterns from components is it always true that the components are enough or do you sometimes have to add arbitrary other cells?

i.e. Could an editor assume the only required drawing primitives were the components in the library.

If true then is it also true that components don't overlap when placed?

[dvgrn]

When you assemble patterns from components is it always true that the components are enough or do you sometimes have to add arbitrary other cells?

i.e. Could an editor assume the only required drawing primitives were the components in the library.

If true then is it also true that components don't overlap when placed?

I just wrote a little bit about this in the Project von Neumann thread, with a chunk of RLE as a candidate input for a Puzzle Editor.

The simplest possible Puzzle Editor could definitely show puzzles that were limited to the given components, with no extra adjustments allowed and no overlaps permitted. If the puzzles were designed with that in mind, adding extraneous cells wouldn't be possible but also would never be useful. The sample puzzle in the link is an example.

With that limitation, the editor could probably only serve up Beginner-level puzzles. But it would be easy to work within that limitation and make hundreds or thousands of Beginner puzzles, in long sequences that would teach a lot of the basics of signal circuitry, rake-building, glider constructions, and so on. So there's a lot that could be done before we'd really have to worry about overlaps or drawing or erasing cells. If that was as far as a Puzzle Editor got, it would still be eminently worthwhile.

The first need for drawing comes when you're adjusting two pieces of circuitry to the closest possible distance, and you have to do custom welding, which generally involves both adding and removing cells.

I'm just making this up as I go along, but the simplest way I can see to teach something about welding without overwhelming people by making them go set up their own search problems in JLS... would be to include "XOR patches" as a component. For example:

Code: Select all

x = 90, y = 90, rule = LifeHistory
90D$D31.D56.D$D31.D56.D$D31.D56.D$D31.D7.2A13.2D7.D4.2A18.D$D31.D7.AD
13.CA7.D4.CD18.D$D31.D8.3A4.5D3.C2D3.5D3.C2A16.D$D11.2A18.D8.D.DA11.A
.CA4.D5.D.CD15.D$D11.A.A17.D8.2A2.A2.5D4.A2.A3.D6.D2.D14.D$D13.A4.2A
11.D7.A2.2A13.2A12.2D15.D$D9.4A.2A2.A2.A9.D7.2A47.D$D9.A2.A.A.A.A.2A
9.D56.D$D11.BABABA.A12.D56.D$D12.B2ABA.A12.58D$D13.2B.BA13.D56.D$D12.
3B16.D56.D$D3.2A6.4B16.D7.2A15.2D8.D4.2A15.D$D4.A6.B2A3B14.D7.A16.D9.
D4.A16.D$D4.A.AB3.B2A3B14.D8.3A6.5D3.3D4.5D3.3A13.D$D5.2AB.10B12.D10.
DA14.AC6.D6.DC13.D$D7.13B11.D8.3AD5.5D5.A6.D7.D13.D$D7.14B10.D8.A2.3A
13.A.2A11.D.2D10.D$D7.15B9.D11.A2.A13.A2.A11.D2.D9.D$D9.8B2.4B8.D12.
2A15.2A13.2D10.D$D9.6B5.4B7.D56.D$D8.9B4.4B6.D56.D$D7.4B4.2A5.4B5.58D
$D6.4B5.A7.4B4.D56.D$D5.4B7.3A5.3BD3.D56.D$D4.4B10.A6.3BD2.D7.2A17.2D
7.D4.2A14.D$D3.4B19.3D2.D7.A3.A14.D8.D4.A15.D$D2.3DB21.2B2.D8.4A15.3D
3.5D3.3A12.D$D2.2BD23.B2.D19.5D5.D5.D7.A12.D$D2.BD27.D10.2A17.2A4.D7.
2D11.D$D31.D11.A7.5D6.A13.D11.D$D31.D11.A.2A15.A.2A10.D.2D8.D$D31.D
12.A2.A15.A2.A10.D2.D7.D$D31.D13.2A17.2A12.2D8.D$D31.D56.D$D31.D56.D$
90D$D88.D$D88.D$D88.D$D88.D$D43.2B2D41.D$D44.2D2B40.D$D45.BD2B39.D$D
46.4B38.D$D47.4B37.D$D48.4B36.D$D49.4B35.D$D50.4B34.D$D51.4B33.D$D52.
4B32.D$D53.4B31.D$D54.4B30.D$D11.D43.4B29.D$D12.D23.A19.4B28.D$D10.3D
B22.3A12.B.3B.4B27.D$D11.4B24.A10.18B20.D$D12.4B10.A11.2A3.B5.2B2A11B
.4B19.D$D13.4B7.3A11.8B3.2B2A9B3.4B19.D$D14.4B5.A16.8B.13B.B.4B19.D$D
15.4B4.2A15.22B.6B19.D$D8.2A6.9B14.15B.2B2.10B4.A14.D$D9.A7.6B14.17B
8.7B3.A.A13.D$D9.A.2A5.6B3.B2.2B2.19B11.5B3.A.A13.D$D10.A2.A4.19B.15B
20.A14.D$D11.2AB3.20B.B.4B.7B36.D$D12.14B2A9B3.13B35.D$D13.13B2A11B.
14B34.D$D14.29B2.8B35.D$D14.17B.4B11.6B35.D$D15.15B3.2B12.5B36.D$D15.
15B3.B14.4B36.D$D16.13B5.A3.2A8.3B37.D$D18.13B2.A.A3.A9.4B35.D$D17.8B
4.2A.A.A3.A12.2A35.D$D17.6B6.2ABA4.A13.A36.D$D17.5B8.B2.5A.A12.3A33.D
$D17.B.B5.2A.A.2A.A4.A.A13.A33.D$D18.3B4.A.2A.A2.A.2A2.A48.D$D17.B2AB
11.2A.A.2A49.D$D18.2A68.D$D88.D$D88.D$D88.D$D88.D$90D!

This would hand people the solution to specific welding problems on a silver platter, so to speak. But "common knowledge" welds like these really shouldn't have to be re-invented every time they're needed, anyway -- or at least that should be a separate puzzle, in the "welding" section.

Of course another alternative would be a puzzle that includes all the possible useful welds between each component and all the other components in the puzzle, and an editor that applies those welds automatically whenever they overlap. For beginner puzzles, maybe only the welds that will actually be useful for that specific puzzle would be included.

Then we'd have to figure out how best to convey that information. If we went the route of just using LifeHIstory patterns as puzzle specifications, then available welds could be summarized in a table, maybe something like this:

Code: Select all

x = 316, y = 197, rule = LifeHistory
316D$D103.2D103.3D103.D$D103.2D103.3D103.D$D103.2D103.3D103.D$D103.2D
103.3D103.D$D18.2A83.2D57.2B2D42.3D18.2A37.2B2D42.D$D18.A.A82.2D58.2D
2B41.3D18.A.A37.2D2B41.D$D20.A4.2A76.2D59.BD2B40.3D20.A4.2A32.BD2B40.
D$D16.4A.2A2.A2.A74.2D60.4B39.3D16.4A.2A2.A2.A31.4B39.D$D16.A2.A.A.A.
A.2A74.2D61.4B38.3D16.A2.A.A.A.A.2A32.4B38.D$D18.BABABA.A77.2D62.4B
37.3D18.BABABA.A36.4B37.D$D19.B2ABA.A77.2D63.4B36.3D19.B2ABA.A37.4B
36.D$D20.2B.BA78.2D64.4B35.3D20.2B.BA39.4B35.D$D19.3B81.2D65.4B34.3D
19.3B43.4B34.D$D10.2A6.4B81.2D66.4B33.3D10.2A6.4B44.4B33.D$D11.A6.B2A
3B79.2D67.4B32.3D11.A6.B2A3B43.4B32.D$D11.A.AB3.B2A3B79.2D68.4B31.3D
11.A.AB3.B2A3B44.4B31.D$D12.2AB.10B77.2D25.D43.4B30.3D12.2AB.9BD43.4B
30.D$D14.13B76.2D26.D23.A19.4B29.3D14.12BD23.A19.4B29.D$D14.14B75.2D
24.3DB22.3A12.B.3B.4B28.3D14.10B3DB22.3A12.B.3B.4B28.D$D14.15B74.2D
25.4B24.A10.18B21.3D14.15B24.A10.18B21.D$D16.8B2.4B73.2D26.4B10.A11.
2A3.B5.2B2A11B.4B20.3D16.8B2.4B10.A11.2A3.B5.2B2A11B.4B20.D$D16.6B5.
4B72.2D27.4B7.3A11.8B3.2B2A9B3.4B20.3D16.6B5.4B7.3A11.8B3.2B2A9B3.4B
20.D$D15.9B4.4B71.2D28.4B5.A16.8B.13B.B.4B20.3D15.9B4.4B5.A16.8B.13B.
B.4B20.D$D14.4B4.2A5.4B70.2D29.4B4.2A15.22B.6B20.3D14.4B4.2A5.4B4.2A
15.22B.6B20.D$D13.4B5.A7.4B69.2D22.2A6.9B14.15B.2B2.10B4.A15.3D13.4B
5.AD6.9B14.15B.2B2.10B4.A15.D$D12.4B7.3A5.3BD68.2D23.A7.6B14.17B8.7B
3.A.A14.3D12.4B7.3A5.6B14.17B8.7B3.A.A14.D$D11.4B10.A6.3BD67.2D23.A.
2A5.6B3.B2.2B2.19B11.5B3.A.A14.3D11.4B8.D.DA5.6B3.B2.2B2.19B11.5B3.A.
A14.D$D10.4B19.3D67.2D24.A2.A4.19B.15B20.A15.3D10.4B9.2A2.A4.19B.15B
20.A15.D$D9.3DB21.2B67.2D25.2AB3.20B.B.4B.7B37.3D9.3DB9.A2.2AB3.20B.B
.4B.7B37.D$D9.2BD23.B67.2D26.14B2A9B3.13B36.3D9.2BD10.2A2.14B2A9B3.
13B36.D$D9.BD92.2D27.13B2A11B.14B35.3D9.BD16.13B2A11B.14B35.D$D103.2D
28.29B2.8B36.3D28.29B2.8B36.D$D103.2D28.17B.4B11.6B36.3D28.17B.4B11.
6B36.D$D103.2D29.15B3.2B12.5B37.3D29.15B3.2B12.5B37.D$D103.2D29.15B3.
B14.4B37.3D29.15B3.B14.4B37.D$D103.2D30.13B5.A3.2A8.3B38.3D30.13B5.A
3.2A8.3B38.D$D103.2D32.13B2.A.A3.A9.4B36.3D32.13B2.A.A3.A9.4B36.D$D
103.2D31.8B4.2A.A.A3.A12.2A36.3D31.8B4.2A.A.A3.A12.2A36.D$D103.2D31.
6B6.2ABA4.A13.A37.3D31.6B6.2ABA4.A13.A37.D$D103.2D31.5B8.B2.5A.A12.3A
34.3D31.5B8.B2.5A.A12.3A34.D$D103.2D31.B.B5.2A.A.2A.A4.A.A13.A34.3D
31.B.B5.2A.A.2A.A4.A.A13.A34.D$D103.2D32.3B4.A.2A.A2.A.2A2.A49.3D32.
3B4.A.2A.A2.A.2A2.A49.D$D103.2D31.B2AB11.2A.A.2A50.3D31.B2AB11.2A.A.
2A50.D$D103.2D32.2A69.3D32.2A69.D$D103.2D103.3D103.D$D103.2D103.3D
103.D$D103.2D103.3D103.D$D103.2D103.3D103.D$316D$D103.2D103.3D103.D$D
103.2D103.3D103.D$D16.2A85.2D103.3D16.2A85.D$D16.A.A84.2D103.3D16.A.A
84.D$D18.A4.2A78.2D57.2B2D42.3D18.A4.2A32.2B2D42.D$D14.4A.2A2.A2.A76.
2D58.2D2B41.3D14.4A.2A2.A2.A31.2D2B41.D$D14.A2.A.A.A.A.2A76.2D59.BD2B
40.3D14.A2.A.A.A.A.2A32.BD2B40.D$D16.BABABA.A79.2D60.4B39.3D16.BABABA
.A36.4B39.D$D17.B2ABA.A79.2D61.4B38.3D17.B2ABA.A37.4B38.D$D18.2B.BA
80.2D62.4B37.3D18.2B.BA39.4B37.D$D17.3B83.2D63.4B36.3D17.3B43.4B36.D$
D8.2A6.4B83.2D64.4B35.3D8.2A6.4B44.4B35.D$D9.A6.B2A3B81.2D65.4B34.3D
9.A6.B2A3B43.4B34.D$D9.A.AB3.B2A3B81.2D66.4B33.3D9.A.AB3.B2A3B44.4B
33.D$D10.2AB.10B79.2D67.4B32.3D10.2AB.9BD43.4B32.D$D12.13B78.2D68.4B
31.3D12.12BD43.4B31.D$D12.14B77.2D25.D43.4B30.3D12.10B3DB43.4B30.D$D
12.15B76.2D26.D23.A19.4B29.3D12.15B23.A19.4B29.D$D14.8B2.4B75.2D24.3D
B22.3A12.B.3B.4B28.3D14.8B2.4B22.3A12.B.3B.4B28.D$D14.6B5.4B74.2D25.
4B24.A10.18B21.3D14.6B5.4B24.A10.18B21.D$D13.9B4.4B73.2D26.4B10.A11.
2A3.B5.2B2A11B.4B20.3D13.9B4.4B10.A11.2A3.B5.2B2A11B.4B20.D$D12.4B4.
2A5.4B72.2D27.4B7.3A11.8B3.2B2A9B3.4B20.3D12.4B4.2A5.4B7.3A11.8B3.2B
2A9B3.4B20.D$D11.4B5.A7.4B71.2D28.4B5.A16.8B.13B.B.4B20.3D11.4B5.A7.
4B5.A16.8B.13B.B.4B20.D$D10.4B7.3A5.3BD70.2D29.4B4.2A15.22B.6B20.3D
10.4B7.3A5.4B4.2A15.22B.6B20.D$D9.4B10.A6.3BD69.2D22.2A6.9B14.15B.2B
2.10B4.A15.3D9.4B11.A5.9B14.15B.2B2.10B4.A15.D$D8.4B19.3D69.2D23.A7.
6B14.17B8.7B3.A.A14.3D8.4B9.3A7.6B14.17B8.7B3.A.A14.D$D7.3DB21.2B69.
2D23.A.2A5.6B3.B2.2B2.19B11.5B3.A.A14.3D7.3DB10.A2.3A5.6B3.B2.2B2.19B
11.5B3.A.A14.D$D7.2BD23.B69.2D24.A2.A4.19B.15B20.A15.3D7.2BD14.A2.A4.
19B.15B20.A15.D$D7.BD94.2D25.2AB3.20B.B.4B.7B37.3D7.BD16.2AB3.20B.B.
4B.7B37.D$D103.2D26.14B2A9B3.13B36.3D26.14B2A9B3.13B36.D$D103.2D27.
13B2A11B.14B35.3D27.13B2A11B.14B35.D$D103.2D28.29B2.8B36.3D28.29B2.8B
36.D$D103.2D28.17B.4B11.6B36.3D28.17B.4B11.6B36.D$D103.2D29.15B3.2B
12.5B37.3D29.15B3.2B12.5B37.D$D103.2D29.15B3.B14.4B37.3D29.15B3.B14.
4B37.D$D103.2D30.13B5.A3.2A8.3B38.3D30.13B5.A3.2A8.3B38.D$D103.2D32.
13B2.A.A3.A9.4B36.3D32.13B2.A.A3.A9.4B36.D$D103.2D31.8B4.2A.A.A3.A12.
2A36.3D31.8B4.2A.A.A3.A12.2A36.D$D103.2D31.6B6.2ABA4.A13.A37.3D31.6B
6.2ABA4.A13.A37.D$D103.2D31.5B8.B2.5A.A12.3A34.3D31.5B8.B2.5A.A12.3A
34.D$D103.2D31.B.B5.2A.A.2A.A4.A.A13.A34.3D31.B.B5.2A.A.2A.A4.A.A13.A
34.D$D103.2D32.3B4.A.2A.A2.A.2A2.A49.3D32.3B4.A.2A.A2.A.2A2.A49.D$D
103.2D31.B2AB11.2A.A.2A50.3D31.B2AB11.2A.A.2A50.D$D103.2D32.2A69.3D
32.2A69.D$D103.2D103.3D103.D$D103.2D103.3D103.D$D103.2D103.3D103.D$D
103.2D103.3D103.D$316D$D103.2D103.3D103.D$D15.2A86.2D103.3D15.2A86.D$
D15.A.A85.2D103.3D15.A.A85.D$D17.A4.2A79.2D103.3D17.A4.2A79.D$D13.4A.
2A2.A2.A77.2D57.2B2D42.3D13.4A.2A2.A2.A31.2B2D42.D$D13.A2.A.A.A.A.2A
77.2D58.2D2B41.3D13.A2.A.A.A.A.2A32.2D2B41.D$D15.BABABA.A80.2D59.BD2B
40.3D15.BABABA.A36.BD2B40.D$D16.B2ABA.A80.2D60.4B39.3D16.B2ABA.A37.4B
39.D$D17.2B.BA81.2D61.4B38.3D17.2B.BA39.4B38.D$D16.3B84.2D62.4B37.3D
16.3B43.4B37.D$D7.2A6.4B84.2D63.4B36.3D7.2A6.4B44.4B36.D$D8.A6.B2A3B
82.2D64.4B35.3D8.A6.B2A3B43.4B35.D$D8.A.AB3.B2A3B82.2D65.4B34.3D8.A.A
B3.B2A3B44.4B34.D$D9.2AB.10B80.2D66.4B33.3D9.2AB.9BD43.4B33.D$D11.13B
79.2D67.4B32.3D11.12BD43.4B32.D$D11.14B78.2D68.4B31.3D11.10B3DB43.4B
31.D$D11.15B77.2D25.D43.4B30.3D11.15B43.4B30.D$D13.8B2.4B76.2D26.D23.
A19.4B29.3D13.8B2.4B23.A19.4B29.D$D13.6B5.4B75.2D24.3DB22.3A12.B.3B.
4B28.3D13.6B5.4B22.3A12.B.3B.4B28.D$D12.9B4.4B74.2D25.4B24.A10.18B21.
3D12.9B4.4B24.A10.18B21.D$D11.4B4.2A5.4B73.2D26.4B10.A11.2A3.B5.2B2A
11B.4B20.3D11.4B4.2A5.4B10.A11.2A3.B5.2B2A11B.4B20.D$D10.4B5.A7.4B72.
2D27.4B7.3A11.8B3.2B2A9B3.4B20.3D10.4B5.A3.A3.4B7.3A11.8B3.2B2A9B3.4B
20.D$D9.4B7.3A5.3BD71.2D28.4B5.A16.8B.13B.B.4B20.3D9.4B7.4A4.4B5.A16.
8B.13B.B.4B20.D$D8.4B10.A6.3BD70.2D29.4B4.2A15.22B.6B20.3D8.4B17.4B4.
2A15.22B.6B20.D$D7.4B19.3D70.2D22.2A6.9B14.15B.2B2.10B4.A15.3D7.4B11.
2A6.9B14.15B.2B2.10B4.A15.D$D6.3DB21.2B70.2D23.A7.6B14.17B8.7B3.A.A
14.3D6.3DB13.A7.6B14.17B8.7B3.A.A14.D$D6.2BD23.B70.2D23.A.2A5.6B3.B2.
2B2.19B11.5B3.A.A14.3D6.2BD14.A.2A5.6B3.B2.2B2.19B11.5B3.A.A14.D$D6.B
D95.2D24.A2.A4.19B.15B20.A15.3D6.BD16.A2.A4.19B.15B20.A15.D$D103.2D
25.2AB3.20B.B.4B.7B37.3D25.2AB3.20B.B.4B.7B37.D$D103.2D26.14B2A9B3.
13B36.3D26.14B2A9B3.13B36.D$D103.2D27.13B2A11B.14B35.3D27.13B2A11B.
14B35.D$D103.2D28.29B2.8B36.3D28.29B2.8B36.D$D103.2D28.17B.4B11.6B36.
3D28.17B.4B11.6B36.D$D103.2D29.15B3.2B12.5B37.3D29.15B3.2B12.5B37.D$D
103.2D29.15B3.B14.4B37.3D29.15B3.B14.4B37.D$D103.2D30.13B5.A3.2A8.3B
38.3D30.13B5.A3.2A8.3B38.D$D103.2D32.13B2.A.A3.A9.4B36.3D32.13B2.A.A
3.A9.4B36.D$D103.2D31.8B4.2A.A.A3.A12.2A36.3D31.8B4.2A.A.A3.A12.2A36.
D$D103.2D31.6B6.2ABA4.A13.A37.3D31.6B6.2ABA4.A13.A37.D$D103.2D31.5B8.
B2.5A.A12.3A34.3D31.5B8.B2.5A.A12.3A34.D$D103.2D31.B.B5.2A.A.2A.A4.A.
A13.A34.3D31.B.B5.2A.A.2A.A4.A.A13.A34.D$D103.2D32.3B4.A.2A.A2.A.2A2.
A49.3D32.3B4.A.2A.A2.A.2A2.A49.D$D103.2D31.B2AB11.2A.A.2A50.3D31.B2AB
11.2A.A.2A50.D$D103.2D32.2A69.3D32.2A69.D$D103.2D103.3D103.D$D103.2D
103.3D103.D$D103.2D103.3D103.D$D103.2D103.3D103.D$316D$D103.2D103.3D
103.D$D103.2D103.3D103.D$D103.2D103.3D103.D$D103.2D103.3D103.D$D38.D
2B62.2D57.2B2D42.3D38.D2B16.2B2D42.D$D23.A13.BDBD62.2D58.2D2B41.3D23.
A13.BDBD17.2D2B41.D$D23.3A10.2B2D63.2D59.BD2B40.3D23.3A10.2B2D19.BD2B
40.D$D26.A8.4B64.2D60.4B39.3D26.A8.4B21.4B39.D$D25.2A7.4B65.2D61.4B
38.3D25.2A7.4B23.4B38.D$D25.5B3.4B66.2D62.4B37.3D25.5B3.4B25.4B37.D$D
27.3B2.4B67.2D63.4B36.3D27.3B2.4B27.4B36.D$D17.2A7.9B68.2D64.4B35.3D
17.2A7.9B29.4B35.D$D17.A8.8B69.2D65.4B34.3D17.A8.8B31.4B34.D$D14.2A.A
.B3.10B70.2D66.4B33.3D14.2A.A.B3.10B33.4B33.D$D14.A2.3AB.2B2A7B70.2D
67.4B32.3D14.A2.3AB.2B2A7B34.4B32.D$D15.2A2.BA3B2A7B70.2D68.4B31.3D
15.2A2.BA3B2A7B35.4B31.D$D17.4A12B70.2D25.D43.4B30.3D17.4A12B36.4B30.
D$D17.A.2B3.7B.B2A68.2D26.D23.A19.4B29.3D17.A.2B3.7B.B2A15.A19.4B29.D
$D18.3AB2.7B.BA.A67.2D24.3DB22.3A12.B.3B.4B28.3D18.3AB2.7B.BA.A2.2A
10.3A12.B.3B.4B28.D$D21.A3.5B5.A67.2D25.4B24.A10.18B21.3D21.A3.5B5.A
2.A14.A10.18B21.D$D16.5A5.4B5.2A66.2D26.4B10.A11.2A3.B5.2B2A11B.4B20.
3D16.5A5.4B5.3A2.A11.2A3.B5.2B2A11B.4B20.D$D16.A10.4B72.2D27.4B7.3A
11.8B3.2B2A9B3.4B20.3D16.A10.4B7.3A11.8B3.2B2A9B3.4B20.D$D18.A9.4B71.
2D28.4B5.A16.8B.13B.B.4B20.3D18.A9.4B5.A16.8B.13B.B.4B20.D$D17.2A10.
4B70.2D29.4B4.2A15.22B.6B20.3D17.2A10.4B4.2A15.22B.6B20.D$D30.4B69.2D
22.2A6.9B14.15B.2B2.10B4.A15.3D22.2A6.9B14.15B.2B2.10B4.A15.D$D31.4B
68.2D23.A7.6B14.17B8.7B3.A.A14.3D23.A7.6B14.17B8.7B3.A.A14.D$D32.4B
67.2D23.A.2A5.6B3.B2.2B2.19B11.5B3.A.A14.3D23.A.2A5.6B3.B2.2B2.19B11.
5B3.A.A14.D$D33.4B66.2D24.A2.A4.19B.15B20.A15.3D24.A2.A4.19B.15B20.A
15.D$D34.3BD65.2D25.2AB3.20B.B.4B.7B37.3D25.2AB3.6BD13B.B.4B.7B37.D$D
35.DBDB64.2D26.14B2A9B3.13B36.3D26.9BDBD2B2A9B3.13B36.D$D36.2D2B63.2D
27.13B2A11B.14B35.3D27.9B2D2B2A11B.14B35.D$D103.2D28.29B2.8B36.3D28.
29B2.8B36.D$D103.2D28.17B.4B11.6B36.3D28.17B.4B11.6B36.D$D103.2D29.
15B3.2B12.5B37.3D29.15B3.2B12.5B37.D$D103.2D29.15B3.B14.4B37.3D29.15B
3.B14.4B37.D$D103.2D30.13B5.A3.2A8.3B38.3D30.13B5.A3.2A8.3B38.D$D103.
2D32.13B2.A.A3.A9.4B36.3D32.13B2.A.A3.A9.4B36.D$D103.2D31.8B4.2A.A.A
3.A12.2A36.3D31.8B4.2A.A.A3.A12.2A36.D$D103.2D31.6B6.2ABA4.A13.A37.3D
31.6B6.2ABA4.A13.A37.D$D103.2D31.5B8.B2.5A.A12.3A34.3D31.5B8.B2.5A.A
12.3A34.D$D103.2D31.B.B5.2A.A.2A.A4.A.A13.A34.3D31.B.B5.2A.A.2A.A4.A.
A13.A34.D$D103.2D32.3B4.A.2A.A2.A.2A2.A49.3D32.3B4.A.2A.A2.A.2A2.A49.
D$D103.2D31.B2AB11.2A.A.2A50.3D31.B2AB11.2A.A.2A50.D$D103.2D32.2A69.
3D32.2A69.D$D103.2D103.3D103.D$D103.2D103.3D103.D$D103.2D103.3D103.D$
D103.2D103.3D103.D$316D!

(Rectangles all exactly the same size, double and triple lines between rectangles to say Rect1 PLUS Rect2 EQUALS Rect3, and the exact position of the object in each rectangle showing how the overlap works. Something like that...?)

[dvgrn]

Here's another potential feature request for a Puzzle Editor, based on Goldtiger997's sample puzzle on the PvN thread.

I don't have good specific ideas yet about how a GUI would work that can keep sets of gliders grouped together, all in the same Life universe with other groups of gliders, and easily fast-forward or rewind one group while leaving other groups in place. I guess the ideal would be a click-and-drag on a glider, where moving the mouse a quarter cell diagonally changes the phase of the glider by one tick, and also makes the same change to any other gliders in the same group with that one.

Another really really useful trick would be to have gliders colored green if they are able to collide with other gliders in their group, but have them turn red if their paths would intersect with gliders from another group. With that kind of feedback, a newcomer to glider syntheses would suddenly find it a lot easier to shuffle multiple components into place in this kind of puzzle, in a way that lets all the gliders get past each other.

I think this wouldn't actually require instant-simulating the entire synthesis after every rewind or fast-forward operation (though for reasonable-sized syntheses that could probably be done, along the lines of the Seeds of Destruction Game). The required math is a little bit headache-inducing, but not too bad -- write a little function that knows whether two gliders have conflicting paths, and call it for every (glider that moves) x (every unmoved glider on the board).

Oscillators in a Puzzle Editor also need a rephasing mechanism, but in that case maybe it should be (select component) then keyboard shortcut -- < to step back by one tick, > to step forward. Dragging an oscillator around wouldn't rephase it necessarily... except if the Puzzle Editor is handling things like bumper and bouncer reflectors connected to a glider source, where moving the reflector farther away from the glider source rephases the period-N oscillator by +4 mod N.

[rowett]

Build 323 is now available on the lazyslug server

Fixes in this build:

• fixed Wolfram rules
• drawing on a triangular grid is now more accurate
• fixed an issue with Triangular B0 rules
• updated Neighbourhood in Help information with triangular neighbourhood
• AutoFit now works better on bounded grids with an infinite dimension
• canonical alias names are now displayed

This build is a Release Candidate.

[dvgrn]

I'm running into an odd display bug in Build 323. It showed up in an attempt to build a nice labeled explanation of the 0E0P metacell. Just hit 'J' to cycle through the stages:

Code: Select all

#C [[ COLOR 1 White COLOR 2 Green COLOR 3 Yellow COLOR 4 Cyan COLOR 5 Blue ]]
#C [[ COLOR 6 Purple COLOR 7 Orange COLOR 8 Red COLOR 9 LightGray ]]
#C [[ POI X -150 Y -20 Z 32 POITRANS 0 ]]
#C [[ LABEL -150 -10 32 "Here's where it all starts" ]]
#C [[ POI X -120 Y -20 Z 32 POITRANS 0 ]]
#C [[ POI X -90 Y -20 Z 32 POITRANS 0 ]]
#C [[ POI X -60 Y -20 Z 32 POITRANS 0 ]]
#C [[ POI X -30 Y -20 Z 32 POITRANS 0 ]]
#C [[ POI X 0 Y -20 Z 32 POITRANS 0 ]]
#C [[ POI X 30 Y -20 Z 32 POITRANS 0 ]]
#C [[ POI X 60 Y -20 Z 32 POITRANS 0 ]]
#C [[ POI X 90 Y -20 Z 32 POITRANS 0 ]]
#C [[ POI X 120 Y -20 Z 32 POITRANS 0 ]]
#C [[ POI X 150 Y -20 Z 32 POITRANS 0 ]]
#C [[ POI X -150 Y 20 Z 32 POITRANS 0 ]]
#C [[ POI X -120 Y 20 Z 32 POITRANS 0 ]]
#C [[ POI X -90 Y 20 Z 32 POITRANS 0 ]]
#C [[ POI X -60 Y 20 Z 32 POITRANS 0 ]]
#C [[ POI X -30 Y 20 Z 32 POITRANS 0 ]]
#C [[ POI X 0 Y 20 Z 32 POITRANS 0 ]]
#C [[ POI X 30 Y 20 Z 32 POITRANS 0 ]]
#C [[ POI X 60 Y 20 Z 32 POITRANS 0 ]]
#C [[ POI X 90 Y 20 Z 32 POITRANS 0 ]]
#C [[ POI X 120 Y 20 Z 32 POITRANS 0 ]]
#C [[ POI X 150 Y 20 Z 32 POITRANS 0 ]]
#C [[ WIDTH 656 VIEWONLY ]]
x = 331, y = 62, rule = 012345678//10
331I$I29.I29.I29.I29.I29.I29.I29.I29.I29.I29.I29.I$I29.I29.I29.I29.I
29.I29.I29.I29.I29.I29.I29.I$I29.I29.I29.I29.I29.I29.I29.I29.I29.I29.
I29.I$I29.I29.I29.I29.I29.I29.I29.I29.I29.I29.I29.I$I29.I29.I29.I29.I
29.I29.I29.I29.I29.I29.I29.I$I29.I29.I29.I29.I29.I29.I29.I29.I29.I29.
I29.I$I29.I29.I29.I29.I29.I29.I29.I29.I29.I29.I29.I$I12.I.I.I12.I12.I
.I.I12.I12.I.I.I12.I12.I.I.I12.I12.I.I.I12.I12.I.I.I12.I12.I.I.I12.I
12.I.I.I12.I12.I.I.I12.I12.I.I.I12.I12.I.I.I12.I$I13.I.I13.I13.I.I13.
I13.I.I13.I13.I.A13.I13.A.A13.I13.A.A13.I13.A.A13.I13.B.B13.I13.C.C
13.I13.E.E13.I13.E.E13.I$I12.I.E.I12.I12.I.F.I12.I12.I.F.I12.I12.I.F.
I12.I12.I.F.I12.I12.I.F.I12.I12.I.G.I12.I12.I.H.I12.I12.I.I.I12.I12.I
.I.I12.I12.I.I.I12.I$I13.I.I13.I13.I.I13.I13.I.A13.I13.I.A13.I13.I.A
13.I13.A.A13.I13.A.A13.I13.B.B13.I13.C.C13.I13.E.E13.I13.E.E13.I$I12.
I.I.I12.I12.I.I.I12.I12.I.I.I12.I12.I.I.I12.I12.I.I.I12.I12.I.I.I12.I
12.I.I.I12.I12.I.I.I12.I12.I.I.I12.I12.I.I.I12.I12.I.I.I12.I$I29.I29.
I29.I29.I29.I29.I29.I29.I29.I29.I29.I$I29.I29.I29.I29.I29.I29.I29.I
29.I29.I29.I29.I$I29.I29.I29.I29.I29.I29.I29.I29.I29.I29.I29.I$I29.I
29.I29.I29.I29.I29.I29.I29.I29.I29.I29.I$I29.I29.I29.I29.I29.I29.I29.
I29.I29.I29.I29.I$I29.I29.I29.I29.I29.I29.I29.I29.I29.I29.I29.I$I29.I
29.I29.I29.I29.I29.I29.I29.I29.I29.I29.I$I29.I29.I29.I29.I29.I29.I29.
I29.I29.I29.I29.I$331I19$331I$I29.I29.I29.I29.I29.I29.I29.I29.I29.I
29.I29.I$I29.I29.I29.I29.I29.I29.I29.I29.I29.I29.I29.I$I29.I29.I29.I
29.I29.I29.I29.I29.I29.I29.I29.I$I29.I29.I29.I29.I29.I29.I29.I29.I29.
I29.I29.I$I29.I29.I29.I29.I29.I29.I29.I29.I29.I29.I29.I$I29.I29.I29.I
29.I29.I29.I29.I29.I29.I29.I29.I$I29.I29.I29.I29.I29.I29.I29.I29.I29.
I29.I29.I$I12.I.I.I12.I12.I.I.I12.I12.I.I.I12.I12.I.A.A12.I12.A.A.A
12.I12.A.A.A12.I12.A.A.A12.I12.B.B.B12.I12.C.C.C12.I12.H.H.H12.I12.I.
I.I12.I$I13.E.E13.I13.F.F13.I13.F.F13.I13.F.F13.I13.F.F13.I13.F.F13.I
13.G.G13.I13.H.H13.I13.I.I13.I13.I.I13.I13.I.I13.I$I12.I.I.I12.I12.I.
I.I12.I12.I.A.A12.I12.I.A.A12.I12.A.A.A12.I12.A.A.A12.I12.A.A.A12.I
12.B.B.B12.I12.C.C.C12.I12.H.D.H12.I12.I.E.I12.I$I13.E.E13.I13.F.F13.
I13.F.F13.I13.F.F13.I13.F.F13.I13.F.F13.I13.G.G13.I13.H.H13.I13.I.I
13.I13.I.I13.I13.I.I13.I$I12.I.I.I12.I12.I.I.I12.I12.I.A.A12.I12.I.A.
A12.I12.I.A.A12.I12.A.A.A12.I12.A.A.A12.I12.B.B.B12.I12.C.C.C12.I12.H
.H.H12.I12.I.I.I12.I$I29.I29.I29.I29.I29.I29.I29.I29.I29.I29.I29.I$I
29.I29.I29.I29.I29.I29.I29.I29.I29.I29.I29.I$I29.I29.I29.I29.I29.I29.
I29.I29.I29.I29.I29.I$I29.I29.I29.I29.I29.I29.I29.I29.I29.I29.I29.I$I
29.I29.I29.I29.I29.I29.I29.I29.I29.I29.I29.I$I29.I29.I29.I29.I29.I29.
I29.I29.I29.I29.I29.I$I29.I29.I29.I29.I29.I29.I29.I29.I29.I29.I29.I$I
29.I29.I29.I29.I29.I29.I29.I29.I29.I29.I29.I$331I!

The problem is that those white cells are all actually state 9 in the RLE, but they're being reported and colored as state 1. Also it looks like the state 7 cells (supposed to be orange) are coming out yellow just like the actual state 1 cells, which were supposed to be white.

Probably as usual this is partly something I'm doing wrong... but what? Now attempting various tests and workarounds --

[rowett]

I'm running into an odd display bug in Build 323. It showed up in an attempt to build a nice labeled explanation of the 0E0P metacell.

Ah yes. This one is my fault. Under the covers the cell states get reversed for Generations algo patterns since it makes the algo simpler and faster. Unfortunately I'm not also reversing the custom colours. I'll need to fix it...

[dvgrn]

I'm running into an odd display bug in Build 323. It showed up in an attempt to build a nice labeled explanation of the 0E0P metacell.

Ah yes. This one is my fault. Under the covers the cell states get reversed for Generations algo patterns since it makes the algo simpler and faster. Unfortunately I'm not also reversing the custom colours. I'll need to fix it...

I don't really want to be using Generations when I'm doing this kind of pattern, with multiple states with custom colors. Is there something I could set the rule string to, so that I wouldn't get the "Invalid rule" message at the bottom?

One side effect of having to use a Generations rule is that if I don't have any state-1 cells in the pattern, I end up with a message I don't want about not having any alive cells. I _want_ all these cells to be alive -- it's just that they're in a multi-state rule that LifeViewer doesn't support.

I tried "JvN29" and "Hutton32", but got the same complaint from LifeViewer. Maybe those known rule names could just get some appropriate colors applied, with no error message? Or maybe some command could say "just display the pattern and let people copy it out and into Golly -- it's okay to not know this rule name."

Almost done with a very nice LifeViewer POI summary of the BCC automaton emulation layer in a 0E0P metacell, by the way. Will add link here when it's posted.

EDIT: Here it is. POIs and labels are working great -- except for the slight weirdness that the label coordinates are offset from the cell coordinates used in the POIs. No doubt there's a good reason for that, I just can't remember what it is.

Here's a related issue I've run into a few times: now that labels are a thing, it's sometimes a little awkward to have the maximum ZOOM value capped at 32. I would actually have zoomed in a bit farther if I could have. It would make it easier to add a few more labels to this 0E0P explanation, with associated arrows pointing to parent cell / child cells / whatever. Is 32 just an arbitrary number, or are there technical difficulties with bumping it up to something ridiculous like 1024?

There's a similar problem I've run into with wanting to zoom out farther than LifeViewer allows. I think I ran into that mostly with very wide patterns with MAXGRIDSIZE set to 14.

[rowett]

Build 324 is now available on the lazyslug server

Enhancements in this build:

• increased maximum zoom to 64x
• hotkey Shift and "3" sets 64x zoom

Fixes in this build:

• custom colours for Generations rules were in reverse order - test

This build is a Release Candidate.

[rowett]

I don't really want to be using Generations when I'm doing this kind of pattern, with multiple states with custom colors. Is there something I could set the rule string to, so that I wouldn't get the "Invalid rule" message at the bottom?

Good idea I'll ponder this one. In the mean time I've fixed the Generations colour order in build 324. I haven't released it because you'll need to update your pattern comments first.

Here it is. POIs and labels are working great -- except for the slight weirdness that the label coordinates are offset from the cell coordinates used in the POIs. No doubt there's a good reason for that, I just can't remember what it is.

Very nice! The cells are "offset" because labels are horizontally centred around the cell X coordinate.

Here's a related issue I've run into a few times: now that labels are a thing, it's sometimes a little awkward to have the maximum ZOOM value capped at 32.

This is no issue increasing the max ZOOM. I picked 32 for two reasons: 1) it's Golly's max zoom and 2) the LifeViewer window is normally fairly small so bigger zooms show very few cells (for example at 128x ZOOM you'd only get 16 (4x4) cells on the window).

What maximum do you suggest? (I increased it to 64x in Build 324 as an example).

There's a similar problem I've run into with wanting to zoom out farther than LifeViewer allows. I think I ran into that mostly with very wide patterns with MAXGRIDSIZE set to 14.

There is a technical issue with increasing the minimum zoom. If it's a big issue let me know and I'll take a look.