I6_I6 wrote: November 16th, 2025, 11:08 am
The RLE in that link is really weird; I've never seen it before (but that's probably because I'm relatively new to CA). I don't see any width, height or rule specifications and has lines starting with #P everywhere. Somehow it still works in Golly and LifeViewer.
That's because it isn't an RLE but rather a Life 1.05 file. Because this format was used widely and a lot of patterns (such as the one in the link) are still in this format, Golly and LV are compatible with it. It was used before OCA were popular, which should be why there is not rule specification in the format. In general, this format consists of chunks that are given in ./* format and the #P lines tell where to put these chunks. This allows it to get a good compression for patterns people are interested in sharing (because lots of empty space can be removed).
I6_I6 wrote: November 16th, 2025, 11:08 am
My question is:
How does X-to-G naming scheme work? The explanation in
NW31 is a bit unclear.
To find the lane of the output glider, you have to figure out how far it is relative to the input, but which cell should you choose from? Is there a canonical center cell for herschels and other conduit signals?
Can someone please explain clearly how to name X-to-Gs?
The standard centers and starting generations for the recognized conduit regions back in 2015 (RBHWCP) are given in
this post. The canonical shapes and centers for the various glider orientations are in
this post.
Now, for an X-to-G converter, we first take the center cell of the input in canonical orientation. For NW31, the center cell of the H is marked below and I've also drawn the vertical "centerline" containing the central cell:
Code: Select all
x = 32, y = 49, rule = LifeSuper
3.4B3.L$4.4B2.L$5.4B.L$6.4BL$7.3BL$8.2BLB$9.BL2B$10.L3B$10.L4B$10.L.
4B$10.L2.4B$10.L3.4B$10.L4.4B$10.L5.4B$10.L6.4B$10.L7.4B$10.L8.4B$10.
L9.4B$10.L9.4B$10.L9.5B$10.L8.9B$10.L8.9B$10.L8.9B$10.L7.10B$10.L6.
12B$7.2A.L6.13B$8.A.L7.11B$8.A.AB4.12B$9.2AB.15B$10.L17B$10.L17B$10.L
.17B.B$10.L19B2A$9.BL17B.B2A$7.3BL15B4.B$7.2BDL15B$6.3BDLD4B.9B$7.2BD
CD4B2.7B$6.4BLD4B2.7B$5.5BL4B4.6B$4.4B2.L7.7B$4.3B3.L8.6B$2.4B4.L8.7B
$2.2A6.L8.6B$3.A6.L8.5B$3A7.L7.6B$A9.L7.4B$10.L7.2B2AB$10.L9.2A!
Now let us look at the lane and the orientation of the output glider, forgetting about timing. We then draw a canonical glider in the same orientation and lane but is centered on the vertical centerline. In the following diagram I've extended the lane backwards in green and marked the matching canonical glider and its center:
Code: Select all
x = 32, y = 49, rule = LifeSuper
3.4J3.L$4.4J2.L$5.4J.L$6.4JL$7.3JL$8.J3A$9.AV2J$10.A3J$10.L4J$10.L.4J
$10.L2.4J$10.L3.4J$10.L4.4J$10.L5.4J$10.L6.4J$10.L7.4J$10.L8.4J$10.L
9.4J$10.L9.B4J$10.L9.2B4J$10.L8.4B4JB$10.L8.5B4J$10.L8.6B4J$10.L7.8B
4J$10.L6.10B4J$7.2A.L6.11B4J$8.A.L7.11B3J$8.A.AB4.12B2.2J$9.2AB.15B3.
J$10.L17B$10.L17B$10.L.17B.B$10.L19B2A$9.BL17B.B2A$7.3BL15B4.B$7.2BDL
15B$6.3BDLD4B.9B$7.2BDCD4B2.7B$6.4BLD4B2.7B$5.5BL4B4.6B$4.4B2.L7.7B$
4.3B3.L8.6B$2.4B4.L8.7B$2.2A6.L8.6B$3.A6.L8.5B$3A7.L7.6B$A9.L7.4B$10.
L7.2B2AB$10.L9.2A!
We see that the glider is travelling northwest, so we get NW for the orientation. The center of the canonical glider is 31 cells above the center of the input, so we get the lane 31. Now we will find the timing. To do this, we run the X-to-G and this canonical glider and compare the timings:
Code: Select all
x = 32, y = 44, rule = TripleB3S23
9.3D$9.D$10.D18$7.2B$8.B$8.B.B$9.2B4$30.2B$30.2B2$9.B$9.B.B$9.3B$11.B
5$2.2B$3.B$3B$B$20.2B$20.2B!
#C [[ STOP 73 ]]
If we run this until the output glider appears, we see that the output glider is 120 ticks behind the canonical glider. So the timing number is 120, giving the full name NW31T120.
In practice nobody actually calculates labels; most work is done by the script in
this post (again). If I need to find the label of a "missing" X-to-G I want to complete something, I usually just paste in a converter I know the label of, run it, and then compare what this produces to what I actually need.