Life tag testing

Post by **rowett** » May 26th, 2019, 2:44 pm

Build 338 is now available on the lazyslug server

Enhancements in this build:

patterns that are too big for LifeViewer but have [[ PASTE ]] commands will ignore the pattern and just run the pastes - test
- You can still copy the whole pattern to the clipboard with Ctrl-Shift-C
- Using Ctrl-C at T=0 will give you the initial PASTEd pattern
performance improvement to setting cells

Post by **rowett** » May 26th, 2019, 2:46 pm

Build 338 automatically detects patterns that are too big for LifeViewer but have [[ PASTE ]] commands. In this case the pattern is ignored and the [[ PASTE ]] commands are run.
I could, if you prefer, only allow this if enabled with a script command. Let me know your preference.

Post by **dvgrn** » May 26th, 2019, 3:03 pm

rowett wrote:You can still copy the whole pattern to the clipboard with Ctrl-Alt-C...

Ctrl+Shift+C seems to be what works for that. That seems to be what the Help advertises. Ctrl+Alt+C gets me the current pattern plus all the comments, as usual.

rowett wrote:Build 338 automatically detects patterns that are too big for LifeViewer but have [[ PASTE ]] commands. In this case the pattern is ignored and the [[ PASTE ]] commands are run.
I could, if you prefer, only allow this if enabled with a script command. Let me know your preference.

No need for an extra script command that I can see. Things all look really good just as they are. I've rolled out Build 338 via the moderator control panel, so I can try posting the Snarkmaker pattern on the 0E0P thread, and probably to the Snarkmaker article on the LifeWiki.

Post by **rowett** » May 26th, 2019, 3:04 pm

Yes I meant Ctrl-Shift-C

Post by **rowett** » May 27th, 2019, 9:25 am

Now we have RLE and PASTE is it possible to define a set of library components along with entry and exit points (for a glider)? With the entry and exit points defined alignment and timing could be computed for component assembly.

Post by **dvgrn** » May 27th, 2019, 10:47 am

rowett wrote:Now we have RLE and PASTE is it possible to define a set of library components along with entry and exit points (for a glider)? With the entry and exit points defined alignment and timing could be computed for component assembly.

I can certainly put an initial set of components together. Should they be just for gliders, or might it make sense to generalize to other input and output types, especially Herschels?

We already have a well-organized collection of Herschel conduits, so it might just be a matter of coloring the output Herschel a different color from the input Herschel, and providing the timing for each conduit somehow. Maybe like this?

Code: Select all

Fx77,77,8.A$8.3A12.B.3B.B$11.A10.13B$10.2A3.B5.2B2A11BD$10.8B3.2B2A9B3DB$12.8B.13BDBD$12.22BD$11.15B.2B2.2B$9.17B$7.18B$7.2BC15B$6.3BCBC4B.7B$7.2B3C13B$6.5BC14B$5.10B2.8B$4.4B11.6B$4.3B12.5B$2.4B14.4B$2.2A16.3B$3.A17.4B$3A20.2A$A22.A$24.3A$26.A!
F116,116,17.A$17.3A$20.A$19.2A4.2B$15.B3.8B$13.4B4.7B$12.6B.9B$12.6B.10B$11.19B$10.19B$10.17B$11.15B$9.17B$7.21B$7.2BC21B3.2B2.2B$6.3BCBC4B.24BD$7.2B3C4B2.23BDBD$6.5BC4B2.23B3DB$5.10B4.24BD$4.4B10.24B$4.3B12.16B.4B$2.4B13.12B5.3B$2.2A15.9B6.4B$3.A14.11B5.2A$3A16.7B.B2A5.A$A20.4B2.BA.A.3A$20.B2A2B5.A.A$21.2A7.2A!
etc.

It's easy to collect the input and output coordinates and orientation to add to the data, either manually or by automatically recognizing the state-5 clusters.

The library could be even more ambitious, allowing for optional signal outputs something like this:

Code: Select all

x = 60, y = 71, rule = LifeHistory
23.A$23.3A12.B.3B.B$26.A10.13B$25.2A3.B5.2B2A11BD$25.8B3.2B2A9B3DB$
27.8B.13BDBD$25.24BD$26.15B.2B2.2B$24.17B$22.18B$22.2BC15B$21.3BCBC4B
.7B$22.2B3C13B$21.5BC14B$20.10B2.8B$19.4B11.6B$18.4B12.5B$17.4B14.4B$
16.B2EB15.3B$15.3BE17.4B$14.B3E20.2A$13.2BEB21.A$12.4B23.3A$11.D3B26.
A$10.D3B$10.3D6$32.A$32.3A$35.A$34.2A4.2B$30.B3.8B$28.4B4.7B$27.6B.9B
$27.6B.10B$26.19B$25.19B$25.17B$26.15B$24.17B$22.21B$22.2BC21B3.2B2.
2B$21.3BCBC4B.24BD$22.2B3C4B2.23BDBD$21.5BC4B2.23B3DB$20.10B4.24BD$
19.4B10.24B$18.4B12.16B.4B$17.4B13.12B5.3B$16.B2EB14.9B6.4B$15.3BE14.
11B5.2A$14.B3E16.7B.B2A5.A$13.2BEB19.4B2.BA.A.3A$12.4B19.B2A2B5.A.A$
11.4B21.2A7.2A$10.4B$9.4B$8.4B$7.4B$6.4B$5.4B$4.4B$3.4B$2.4B$.BD2B$2D
2B$.2D!

Glider outputs are different from Herschels -- the given position really just means "glider appears along this output lane, including at this position at this time". It's not particularly useful to backtrack the glider to the first tick where it appears and register that, because that first appearance is usually in the middle of the conduit where there's no way to make any use of it.

Anyway, assuming you really just want gliders for now, I think the turner collection might be an interesting place to start a library. One-time conduits should be just as assemble-able as multi-use components.

Code: Select all

x = 90, y = 98, rule = B3/S23
o19bo19bo19bo19bo$b2o18b2o18b2o18b2o18b2o$2o18b2o18b2o18b2o18b2o6b2o$
88b2o2$4b2o13b2o20bo22bo$3bobo12bobo19bobo20bo2bo16b2o$4bo13bo22bobo19b
o2bo16b2o$17b2o23b2o21bo12$o19bo19bo5b2o32bo$b2o18b2o18b2o3b2o33b2o$2o
18b2o18b2o38b2o3$2bo20b2o58b2o$bobo18bobo17b2o37bo2bo$obo18bobo18b2o37b
2o$2o19b2o12$o19bo$b2o8bo9b2o5b2o50bo$2o8bobo7b2o5bobo51b2o$9bobo16bo
51b2o$9b2o75b2o$86b2o2$6b2o$5bo2bo$5bo2bo74b2o$6b2o17b2o55bobo$16bo7b
o2bo53bobo$14b2o9b2o53bobo$15b2o64bo2$44b3o$44bo$45bo28$o39bo19bo19bo
$b2o38b2o18b2o18b2o$2o38b2o18b2o18b2o2$10bo36bo$4b2o3bobo29bo4bobo11b
o17b2o$3bobo4bobo27bobo3b2o11bobo16b2o$4bo6b2o28bobo14bo2bo$42b2o15b2o
$84bo$83bobo$67b2o14b2o$67b2o!

Here again there's some ambiguity. Will the assembly system be able to handle a component with a single input and multiple outputs? Or multiple inputs and a single output, even worse?

With a single input at least the relative timing of the outputs is known, but multiple inputs probably have to be synchronized in some way -- maybe exact synchronization, maybe just correct phase mod 2, maybe a limited range of relative timings, maybe "any time after T is okay".

Should we start with just single-input, single-output? Or is single-input, multi-output okay also?

Post by **dvgrn** » May 27th, 2019, 5:15 pm

Besides the old XLife format, the other main effort to register and use a library of components was Eugene Langvagen's PLife. Golly's glife package was heavily based on this, even including the same sample scripts -- bricklayer.py, gun_demo.py, pd_glider.py, etc.

Langvagen's track.py is long gone, since we have a lot more than just eight Herschel conduits now. But we still have herschel.py hiding in the glife folder:

Code: Select all

from glife.base import *

herschel_ghost = pattern ("""
***
.
.*.*
""")

# A Herschel conduit is represented by its pattern and
# the transformation it applies to the Herschel.
# Hence the additional .transform field.

hc64 = block (14, -8) + block (9, -13) + block (13, -15) + block (7, -19)
hc64.transform = (-9, -9, rccw)

hc77 = block (9, -13) + eater (10, 0, swap_xy) + eater (-7, -12, swap_xy_flip)
hc77.transform = (10, -25, flip_x)

hc112 = block (16, -10) + block (-3, -11) + aircraft_carrier (13, -3, swap_xy) + \
        eater (10, 1) + eater (-3, -14, flip) + eater (9, -16, flip_y)
hc112.transform = (35, -12, rcw)

hc117 = eater (10, 1) + eater (13, -9, swap_xy) + eater (0, -12, swap_xy_flip) + block (8, -22) + snake (15, -19)
hc117.transform = (6, -40, identity)

hc119 = block (-14, -3) + block (-13, -8) + block (-19, -9) + eater (-17, -2, rcw)
hc119.transform = (-12, -20, flip_x)

hc156 = eater (10, 0, swap_xy) + eater (12, -9, swap_xy) + eater (0, -12, swap_xy_flip) + eater (17, -21, flip_y) + \
        snake (21, -5, rccw) + block (24, -15) + tub (11, -24)
hc156.transform = (43, -17, rcw)

hc158 = eater (-2, -13, flip) + eater (-3, -8, rcw) + eater (20, -19, rccw) + pattern ("""
.....**
.....*.*
.......*
.......*.*.**
..**.*.*.**.*
..**.**.*
........*
..**.***
...*.*
...*.*
**.**
*.*
..*
..**
""", 14, -12)
hc158.transform = (7, -27, flip_x)

hc190 = eater (-3, -8, rcw) + eater (-10, -12, swap_xy) + eater (-3, -12, swap_xy_flip) + \
        eater (-8, -17) + eater (11, -27, flip_y) + block (2, -25) + snake (5, -31, rccw) + \
        pattern ("""
..**.*
..**.***
........*
..**.***
...*.*
...*.*
**.**
*.*
..*
..**
""", 14, -8)
hc190.transform = (-16, -22, rccw)

And the "compose" function is hiding in __init__.py:

Code: Select all

def compose(S, T):
    """\
 Return the composition of two transformations S and T.
 A transformation is a tuple of the form (x, y, A), which denotes
 multiplying by matrix A and then translating by vector (x, y).
 These tuples can be passed to pattern.__call__()."""
    x = S[0]; y = S[1]; A = S[2]
    s = T[0]; t = T[1]; B = T[2]
    return (x * B[0] + y * B[1] + s, x * B[2] + y * B[3] + t,
       (A[0] * B[0] + A[2] * B[1], A[1] * B[0] + A[3] * B[1],
        A[0] * B[2] + A[2] * B[3], A[1] * B[2] + A[3] * B[3]))

I just mention it because of the extra ".transform" attribute that Langvagen added to each defined conduit. My recognizer scripts basically use the glife syntax inherited from Langvagen's project, but I've never made any use of that .transform idea. Here's how it was used:

Code: Select all

# track.py
from lib.herschel import *

text = """This file reproduces 'BTRACK' from Alan Hensel's collection
(without boxes and labels, though).
The conduits are passed in the following order:
77, 112, 158, 190, 119, 117, 156, 77, 64, 64 and 112.
What 'BTRACK' says is the following:

 All 8 of David Buckingham's Herschel conduits demonstrated.

 A Herschel is the 20th generation of the B-heptomino (see BHEPTO).
 Various combinations of still life can be made to assist the
 forward propagation of a Herschel, and with Buckingham's complete
 set, a glider gun of any period greater than 61 can be constructed.
 This period-1246 loop demonstrates all of them. Each conduit in
 this pattern is boxed off and labeled, and future Herschel
 positions are marked by ghost Herschels. See also STILLREFLECTOR, GUN256B.
 
 Gens Type      Tightest Compression; Notes
 ---- ----      ---------------------------
 64   90 degree 153 (also 73, 74, 77); 1 glider, aimed inward.
 77   move+flip  61; 1 glider (natural b-heptomino glider).
 112  90 degree  61; 1 glider, aimed outward.
 117  move       63; 1 glider. Can be perturbed by single-spark oscs.
 119  move+flip 231; 3 gliders.
 156  90 degree  62; 2 gliders: Normal B-hepto glider + one more.
 158  move+flip 176 (also 101, 102, 109, 111, 159); 1 glider.
 190  90 degree 107; 1 glider, aimed inward.
"""

path = ( hc77, hc112, hc158, hc190, hc119, hc117, hc156, hc77, hc64, hc64, hc112, )

A = herschel + eater (-20, 24, flip_x) + eater (1, 46, swap_xy_flip) + eater (8, 60, rcw)
T = (10, -24, swap_xy_flip)

all = A (*T)

for hc in path:
	all += hc (*T) + herschel_ghost (*T)
	T = compose (hc.transform, T)

all.save ("track.lif", text)

Which resulted in this:

Code: Select all

#C track.lif
#C This file reproduces 'BTRACK' from Alan Hensel's collection
#C (without boxes and labels, though).
#C The conduits are passed in the following order:
#C 77, 112, 158, 190, 119, 117, 156, 77, 64, 64 and 112.
#C What 'BTRACK' says is the following:
#C 
#C  All 8 of David Buckingham's Herschel conduits demonstrated.
#C 
#C  A Herschel is the 20th generation of the B-heptomino (see BHEPTO).
#C  Various combinations of still life can be made to assist the
#C  forward propagation of a Herschel, and with Buckingham's complete
#C  set, a glider gun of any period greater than 61 can be constructed.
#C  This period-1246 loop demonstrates all of them. Each conduit in
#C  this pattern is boxed off and labeled, and future Herschel
#C  positions are marked by ghost Herschels. See also STILLREFLECTOR, GUN256B.
#C  
#C  Gens Type      Tightest Compression; Notes
#C  ---- ----      ---------------------------
#C  64   90 degree 153 (also 73, 74, 77); 1 glider, aimed inward.
#C  77   move+flip  61; 1 glider (natural b-heptomino glider).
#C  112  90 degree  61; 1 glider, aimed outward.
#C  117  move       63; 1 glider. Can be perturbed by single-spark oscs.
#C  119  move+flip 231; 3 gliders.
#C  156  90 degree  62; 2 gliders: Normal B-hepto glider + one more.
#C  158  move+flip 176 (also 101, 102, 109, 111, 159); 1 glider.
#C  190  90 degree 107; 1 glider, aimed inward.
x = 126, y = 123, rule = B3/S23
36b2o$36b2o5b2o$43b2o3$12b2o27b2o$12b2o27b2o$47b2o$47b2o$6b2o$6b2o
$10b2o$10b2o15bo$29bo$27bobo$29bo$5b2o$5b2o3$51bo62b2o$49b3o62bo
$39bobo6bo63bobo$48b2o20bo37b2o2b2o$18b3o17b3o11b2o16b3o35b2o$53b
o19bo$17bobo31bo20b2o11b2o11bo$51b2o32b2o9bobo$12b2o84bo$13bo82b
o$10b3o$10bo2$54b2o15bo$2o33b2o17b2o15bobo$bo25b2o6b2o34b3o40b2o
$bobo15b2o6bo45bo22b2o16bobo$2b2o15b2o7b3o64bobo18bo$30bo3b2o59b
o20b2o$35bo58b2o4b2o$32b3o12b2o49bo2bo$32bo14bo50b2o$48b3o56b2o$
50bo34b2o20b2o$85bo$86b3o$88bo3$10b3o7b2o$20bobo$11bobo8bo$22b2o
4$48b2o$47bobo$47bo$46b2o59bobo$93b2o$94bo13b3o$94bobo$92b2ob2o$
91bobo$91bobo$89b3ob2o20b2o$12b2o74bo26bo$12b2o74bob2ob2o18bobo$
84bob2obobob2o18b2o$19bob2o61b2obobo$19b2obo66bo$3b2o84bobo$4bo85b
2o$4bobo105b2o$5b2o105bo$113b3o$21bo93bo$19b3o$18bo11bo$3bo14b2o
8b3o17b2o39b2o$2bobo22bo20bo39bobo$3bo23b2o20bo11bo26bo$48b2o9b3o
25b2o$58bo$58b2o10b2o$70bo33bobo$68bobo48b2o$68b2o33b3o13bo$29bo
15b2o70bobo$27bo17b2o41bo28b2ob2o$27bobo48b2o6b3o31bobo$14b2o11b
o50b2o5bo34bobo$15bo69b2o10b2o20b2ob3o$12b3o83bo26bo$12bo56bo28b
obo18b2ob3o$67bo16b2o13b2o18b2obo$67bobo9b2o3b2o9b2o$54b2o11bo11b
2o14bo$55bo37bobo$52b3o38b2o4b2o$52bo45bobo$98bo$96b3o$95bo$95b2o
5$87bo$87bobo$87bo17b2o$89bo15b2o2$114b2o$114bo$115b3o$117bo$108b
2o$109bo$108bo$108b2o!

I'm not sure if this is relevant at all, especially since splitters would need two or more different .transforms, and again glider outputs are less well-defined than Herschel connections. You'd have to supply a parameter to say what distance to connect at -- maybe measured in half-diagonals or quarter-diagonals, since that would avoid having to describe the orientation at all. A connection an odd number of half-diagonals away would automatically be the opposite orientation from an even number of half-diagonals.

Post by **rowett** » May 29th, 2019, 4:41 am

Build 339 is now available on the lazyslug server

Enhancements in this build:

new script command [[ KILLGLIDERS ]] will delete escaping boundary gliders - test
better Paste information in "Help" -> "Info" -> "Pattern"

Fixes in this build:

fixed [[ PASTET EVERY ]]

This build is a Release Candidate.

Post by **rowett** » May 29th, 2019, 11:02 am

dvgrn wrote:... very close to the way single-channel recipes are stored. Here are a few examples of the syntax:

Code: Select all

channel-blocking integral:
0,109,47,94,21,89,152,15,14,17,117,55,91,15,14,113,38,168,45,14,21,135,27,17,29,47,107,54

channel-blocking eater:
0,109,47,94,21,88,95,57,14,111,55,37,145,57,141,26,17,25,97,14,116,30,15,56,16,14,97

135-degree LWSS:
0,109,47,95,125,120,110,17,126,66,149,117,35,107,101,14,52,14,91,42
45-degree LWSS:
0,93,79,116,37,131,61,95,189,160,159,119,70,111,184,63,117,36,19,14,14,27,102,29
45-degree HWSS:
0,109,47,94,21,89,95,57,14,175,14,153,45,14,106,68,14,144,36,56,64,36,15,106,19,116,83

Would it be helpful to have a command which lets you define each single-channel recipe which you could then string together in a PASTET command?

For example:

Code: Select all

[[ RLERECIPE channel-blocking-integral 109 47 94 21 89 152 15 14 17 117 55 91 15 14 113 38 168 45 14 21 135 27 17 29 47 107 54 ]]
[[ RLERECIPE 135-degree-LWSS 109 47 95 125 120 110 17 126 66 149 117 35 107 101 14 52 14 91 42 ]]
[[ PASTET 0 channel-blocking-integral 200 135-degree-LWSS 150 135-degree-LWSS ]]
[[ PASTE glider 254 200 ]]

Post by **dvgrn** » May 29th, 2019, 2:14 pm

rowett wrote:Would it be helpful to have a command which lets you define each single-channel recipe which you could then string together in a PASTET command?

That would certainly come in handy. Could be just RECIPE, since there isn't really any RLE involved.

Your example shows one way to handle the spacings between single-channel recipes, with a delay number following each defined chunk in the PASTET command where the recipes are combined.

However, the standard method is to include that delay number in each recipe. It's always the same number, no matter what other recipe might follow, so it's really part of the recipe. Standard single channel recipes sometimes don't include the initial "0" (though it doesn't hurt to have it there, it just overwrites the previous glider if it's following another recipe, and that way it works correctly as a standalone recipe also). The final number in each recipe gives the safe following distance.

This way you can concatenate recipes directly and automatically get the minimum spacing for the whole combined recipe. The only drawback is that at the end of the combined recipe, there's always an annoying extra glider that shouldn't really be there, so you end up with a pi explosion instead of an elbow block.

-- Or in this case you just end up with an extra glider that you don't really need:

Code: Select all

x = 1, y = 1, rule = B3/S23
b!
[[ X 15 Y 15 Z 4 STEP 64 STOP 5653 ]]
[{ RECIPE elbow-to-hand 109 91 93 90 132 115 127 91 90 91 95 90 114 162 233 159 90 155 126 93 118 90 91 90 90 }]
[{ RECIPE channel-blocking-eater 109 91 94 91 90 95 91 90 111 91 91 145 91 141 90 91 91 97 90 116 90 91 90 90 90 97 }]
[{ PASTET 100 elbow-to-hand channel-blocking-eater 13 }]
[[ PASTET 0 ]]
#C [[ RLE block 2o$2o! ]]
#C [[ RLE glider 2o$obo$o! ]]
#C [[ PASTE block ]]
#C [[ PASTEMODE OR ]]
#C the "256" is the dividing line between the two recipes -- could be reduced to 90
[[ PASTET 0 109 91 93 90 132 115 127 91 90 91 95 90 114 162 233 159 90 155 126 93 118 90 91 90 256 109 91 94 91 90 95 91 90 111 91 91 145 91 141 90 91 91 97 90 116 90 91 90 90 90 97 ]]
#C [[ PASTE glider 54 50 ]]

Luckily -- I just made this up, but it can be a standard convention I think -- if you drop a glider 13 ticks after another glider, they both cleanly self-destruct, no matter what phase the glider is in.

So we can just append a "13" after the final named sub-recipe, and that will take care of the unwanted trailing glider:

Code: Select all

x = 1, y = 1, rule = B3/S23
b!
[[ X 15 Y 15 Z 4 STEP 64 STOP 5653 ]]
[{ RECIPE elbow-to-hand 109 91 93 90 132 115 127 91 90 91 95 90 114 162 233 159 90 155 126 93 118 90 91 90 }]
[{ RECIPE channel-blocking-eater 109 91 94 91 90 95 91 90 111 91 91 145 91 141 90 91 91 97 90 116 90 91 90 90 90 97 }]
[{ PASTET 100 elbow-to-hand channel-blocking-eater 13 }]
[[ PASTET 0 ]]
#C [[ RLE block 2o$2o! ]]
#C [[ RLE glider 2o$obo$o! ]]
#C [[ PASTE block ]]
#C [[ PASTEMODE OR ]]
#C the "256" is the dividing line between the two recipes -- could be reduced to 90
[[ PASTET 0 109 91 93 90 132 115 127 91 90 91 95 90 114 162 233 159 90 155 126 93 118 90 91 90 256 109 91 94 91 90 95 91 90 111 91 91 145 91 141 90 91 91 97 90 116 90 91 90 90 90 97 13 ]]
#C [[ PASTE glider 54 50 ]]

(The "RECIPE" stuff it the top is just fake comment-commands showing how this _would_ work if your suggestion were already implemented.)

Post by **rowett** » May 30th, 2019, 6:08 am

Build 340 is now available on the lazyslug server

Enhancements in this build:

new script command [[ RECIPE ]] creates a named list to be used by the [[ PASTET ]] command - test
- syntax is [[ RECIPE name <1..>+ ]]
- [[ PASTET <0..> (name|<1..>+)* ]]
[[ PASTET EVERY ]] now has optional end generation (as well as optional start generation)
- [[ PASTET EVERY interval (start (end)) ]]
- if specified then end must be at least interval + start
[[ RLE ]] and [[ RECIPE ]] names can not be script command names
display actual STEP size if specified size can not be achieved

This build is a Release Candidate.

Post by **rowett** » May 30th, 2019, 8:14 pm

Build 341 is now available on the lazyslug server

Fixes in this build:

[[ KILLGLIDERS ]] now fades dead gliders

This build is a Release Candidate.

Post by **rowett** » May 30th, 2019, 8:15 pm

Build 342 is now available on the lazyslug server

Enhancements in this build:

hotkey Ctrl "S" now saves pattern to source document node

This build is a Release Candidate.

Post by **dvgrn** » June 3rd, 2019, 5:20 pm

It just occurred to me that there's something missing from the spec for defining RLE chunks and then using the same chunk in different locations and orientations. Not too surprisingly, this is something that I also never got around to supporting in my recognizer script.

Very often the most compact representation of a pattern will require a recursive definition:

RLE syringev1 {rle}
RLE NW31 {rle}
RLE NW31splitter COMBINE syringev1[1] 0 0 NW31 20 0 FLIPY

(Or it could be an equation with newname = name1 + name2, or parentheses or whatever, instead of COMBINE.
You wouldn't really need the above [1] on a syringe, so that's just to show that the option should be available.)

There's a more ambitious extension of this idea, which there isn't any market for at the moment because no existing tool produces recursive definitions like this. Some combinations of circuits, such as a Snark followed by a syringe for example, need a patch applied to their overlapping cells to stabilize the connection.

Sometimes welding just involves adding cells, but often cells need to be subtracted as well, so the simplest way to define this kind of weld is probably with an XOR patch pattern:

RLE Snark {rle}
RLE syringev1 {rle}
RLE Snarksyringeweld1 {rle}
RLE Snark-plus-syringev1 Snark syringev1 10 5 FLIPX Snarksyringeweld1 7 6 XOR

(The offsets and orientations are just made up, though I guess I could make them correct by picking the right RLE for the various pieces.)

Result -- pre-patch on left, patched on right:

Code: Select all

x = 95, y = 40, rule = LifeHistory
22.2A48.2A$21.B2AB11.2A.A.2A28.B2AB11.2A.A.2A$22.3B4.A.2A.A2.A.2A2.A
28.3B4.A.2A.A2.A.2A2.A$21.B.B5.2A.A.2A.A4.A.A26.B.B5.2A.A.2A.A4.A.A$
21.5B8.B2.5A.A27.5B8.B2.5A.A$21.6B6.2ABA4.A29.6B6.2ABA4.A$21.8B4.2A.A
.A3.A28.8B4.2A.A.A3.A$22.13B2.A.A3.A28.13B2.A.A3.A$20.13B5.A3.2A26.
13B5.A3.2A$19.15B35.15B$19.15B35.15B$18.17B.B31.17B.B$18.24B26.24B$
17.9B2D2B2A11BD23.9B2D2B2A11BD$16.9BDBD2B2A9B3DB17.2A2.9BDBD2B2A9B3DB
$15.2AB3.6BD13BDBD18.A2.2AB3.6BD13BDBD$4B10.A2.A4.19BD8.4B9.2A2.A4.
19BD$.4B8.A.2A5.6B3.B2.2B2.2B11.4B11.A5.6B3.B2.2B2.2B$2.4B7.3A5.6B25.
4B7.3A5.6B$3.4B5.2A6.9B24.4B5.A7.9B$4.4B4.2A5.4B4.2A25.4B4.2A5.4B4.2A
$5.9B4.4B5.A27.9B4.4B5.A$6.6B5.4B7.3A25.6B5.4B7.3A$6.4BD3B2.4B10.A25.
4BD3B2.4B10.A$4.7BD7B35.7BD7B$4.5B3D6B36.5B3D6B$4.13B37.13B$2.2AB.10B
36.2AB.10B$.A.AB3.B2A3B37.A.AB3.B2A3B$.A6.B2A3B37.A6.B2A3B$2A6.4B38.
2A6.4B$9.3B47.3B$10.2B.BA45.2B.BA$9.B2ABA.A43.B2ABA.A$8.BABABA.A42.BA
BABA.A$6.A2.A.A.A.A.2A37.A2.A.A.A.A.2A$6.4A.2A2.A2.A37.4A.2A2.A2.A$
10.A4.2A43.A4.2A$8.A.A47.A.A$8.2A48.2A!

So this would be the XOR patch

Code: Select all

#C Snarksyringeweld1
x = 4, y = 6, rule = B3/S23
2o$o$bo$bobo2$bo!

Post by **rowett** » June 13th, 2019, 12:45 pm

dvgrn wrote:It just occurred to me that there's something missing from the spec for defining RLE chunks and then using the same chunk in different locations and orientations. Not to surprisingly, this is something that I also never got around to supporting in my recognizer script.

I've put it on the backlog.

Post by **rowett** » June 13th, 2019, 12:51 pm

Build 343 is now available on the lazyslug server

Enhancements in this build:

Undo/Redo
- hotkey Ctrl "Z" for undo edit
- hotkey Ctrl+Shift "Z" for redo edit
[R]History display toggle
- hotkey Alt "J" disables [R]History display
- hotkey Alt "H" enables [R]History display
- only works for [R]History rules
- this is only a display toggle: state 6 processing still happens
- however: copy RLE to clipboard will honour current settings
Escaping gliders
- hotkey Alt "K" toggles deleting escaping gliders
- new "Kill" button in navigation menu to toggle deleting escaping gliders
- number of deleted gliders is shown in "Help" -> "Info" -> "Grid"

Fixes in this build:

editor now works with step back

This build is a Release Candidate.

Post by **dvgrn** » June 13th, 2019, 1:40 pm

rowett wrote:
[R]History display toggle

hotkey Alt "J" disables [R]History display

hotkey Alt "H" enables [R]History display

only works for [R]History rules

this is only a display toggle: state 6 processing still happens

however: copy RLE to clipboard will honour current settings

Nice! Was this inspired by Paul Callahan's recent LifeHistory comments?

Post by **rowett** » June 13th, 2019, 2:19 pm

Post by **rowett** » June 14th, 2019, 9:33 am

Build 344 is now available on the lazyslug server

Fixes in this build:

fixed undo/redo records persisting across patterns

This build is a Release Candidate.

Post by **rowett** » June 17th, 2019, 2:47 pm

Build 345 is now available on the lazyslug server

Enhancements in this build:

new "[R]History" button in navigation menu to toggle [R]History display
new previous and next POI button on main screen if POIs defined - test

Fixes in this build:

fixed [R]History state 6 regression in editor

This build is a Release Candidate.

Post by **rowett** » June 18th, 2019, 3:04 am

Build 346 is now available on the lazyslug server

Fixes in this build:

fixed a bug where the playback controls were disappearing after reset

This build is a Release Candidate.

Post by **rowett** » June 18th, 2019, 7:17 am

Next item on the backlog is selections. Here are my current thoughts:

Making a selection:

Rectangular selection tool lets you drag a rectangle.
Pick cell tool lets you select a cell and then all connected cells form the selection.
Named selection tool lets you select a named pattern from a list (defined by [[ RLE ]] script commands and/or the Name tool, below).

Naming a selection:

Name tool lets you name the current selection (maybe A-Z or 1-9).
Shortcut keys can select a previously named selection.

Copying the selection to the buffer:

Copy cells tool copies the selected cells to the paste buffer.
Cut cells tool copies the selected cells to the paste buffer and then removes the cells from the pattern.

The buffer is displayed as a semi-opaque overlay over the pattern.

Manipulating the buffer:

Flip X, Flip Y, Rotate CW and Rotate CCW tools do as expected.
Random tool replaces the cells in the buffer with random cells.
- For non-rectangular selections only cells originally alive are candidates for replacement.
Density slider sets the Random percentage.
The buffer may be moved either by dragging or with the arrow keys.
Home tool moves the buffer to its original position.
Clicking outside the buffer or on the Hide tool hides the buffer.
Clicking on the Reveal tool shows the buffer.

Setting the paste mode:

Or, And, Xor and Copy tools set the paste mode.

Pasting to the grid:

Paste tool copies the buffer to the current position on the grid.
The buffer stays visible until hidden (see above).
Reveal tool shows the last buffer and allows repeat paste.

Please let me know what is confusing, wrong or missing!

Post by **rowett** » June 19th, 2019, 1:08 pm

I'd like to increase the minimum LifeViewer width by 80 pixels from 480 to 560. Do you think that will be an issue?

Post by **dvgrn** » June 19th, 2019, 1:21 pm

rowett wrote:I'd like to increase the minimum LifeViewer width by 80 pixels from 480 to 560. Do you think that will be an issue?

Seems like that's probably survivable, but if we don't want the new LifeViewer to start throwing errors in old messages, we'll have a bit of editing to do.

Let's see, this won't apply if the NOGUI keyword is present?

Post by **rowett** » June 19th, 2019, 1:26 pm

dvgrn wrote:
rowett wrote:I'd like to increase the minimum LifeViewer width by 80 pixels from 480 to 560. Do you think that will be an issue?
Seems like that's probably survivable, but if we don't want the new LifeViewer to start throwing errors in old messages, we'll have a bit of editing to do.

It won't complain about WIDTHs >= 480 and < 560. It will just silently set them to 560.

dvgrn wrote:Let's see, this won't apply if the NOGUI keyword is present?

Correct, it won't apply to NOGUI. But it will apply to AUTOHIDEGUI.

ConwayLife.com

Life tag testing

Re: Life tag testing

Re: Life tag testing

Re: Life tag testing

Re: Life tag testing

Re: Life tag testing

Re: Life tag testing

Re: Life tag testing

Re: Life tag testing

Re: Life tag testing

Re: Life tag testing

Re: Life tag testing

Re: Life tag testing

Re: Life tag testing

Re: Life tag testing

Re: Life tag testing

Re: Life tag testing

Re: Life tag testing

Re: Life tag testing

Re: Life tag testing

Re: Life tag testing

Re: Life tag testing

Re: Life tag testing

Re: Life tag testing

Re: Life tag testing

Re: Life tag testing