LifeSuper rule

For general discussion about Conway's Game of Life.
User avatar
dvgrn
Moderator
Posts: 6734
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

LifeSuper rule

Post by dvgrn » January 26th, 2020, 5:51 pm

Putting this in General Discussion because it's not exactly about any particular pattern, and it's technically an OCA rule but at the same time it's really just plain old Life.

EDIT: renamed "SuperLH" to "LifeSuper" for reasons given here

I've been using LifeHistory as usual to work on adding new Herschel climbers to the waterbear recipe-in-progress. As the distance from gliders' starting locations to their targets gradually increased, it got harder and harder to make small adjustments to gliders after putting them in place. LifeHistory lets you mark the gliders with a couple different colors, circle them, add labels, etc. -- but of course all that annotation just gets left behind as soon as the pattern starts running.

Often what I really want to do is adjust an adjustable glider in some other sub-recipe that conflicts with the one I just placed. So then I have to figure out that other recipe's original glider locations, based on where they end up several thousand ticks later. With dozens or hundreds of gliders flying every which way in the waterbear recipe, crashing into things and disappearing, this kind of thing gets to be difficult to sort out.

So I'm experimenting with adding a bunch more states to LifeHistory, somewhat along the lines of Life4C / QuadLife (see also this page, but with some extra bells and whistles, and without worrying much about what happens when different colors collide.

LifeSuper states 0 through 6 still do the same thing as in LifeHistory, but several additional colors and label states have been added. Some of these might be useful for large glider syntheses and maybe other similar construction projects. In particular, I can color a glider at T=0 and have it keep that color until it gets close to its collision site.

Sample multi-stage glider synthesis: (EDIT: updated to use all seven LifeSuper no-trail states)

Code: Select all

x = 386, y = 395, rule = LifeSuper
7.O.O$8.2O$8.O2$383.O.O$383.2O$384.O$13.O.O$14.2O$14.O4$378.U.U$17.U
360.2U$11.O.O4.U360.U$12.2O2.3U$12.O6$37.M$35.M.M$36.2M2$31.S343.M$
32.S338.O2.M$30.3S336.2O3.3M$359.S10.2O$357.2S$358.2S12$58.Q.Q$59.2Q$
59.Q291.Q.Q$351.2Q$62.Q.Q287.Q$63.2Q$63.Q7$346.S$344.2S$345.2S$78.S$
79.2S$78.2S$359.Q$343.S14.Q$342.S15.3Q$342.3S4.S$348.S$348.3S4$345.S$
343.2S$344.2S$84.M.M$85.2M$85.M229.M$313.2M$314.2M2$80.M.M$81.2M$81.M
4$87.W217.S$88.W215.S$86.3W215.3S3$106.Q$107.2Q$106.2Q$305.Q$85.M218.
Q$83.M.M218.3Q$84.2M11$305.O.O$305.2O$306.O$292.S$291.S$291.3S6$296.S
$296.S.S$296.2S4$286.U$285.U$285.3U2$283.U$281.2U$282.2U5$129.Q147.Q$
127.Q.Q135.S.S9.Q.Q$128.2Q135.2S10.2Q$266.S$244.M$244.M.M$244.2M7$
257.O$256.O$256.3O45$204.2H.2H$200.H.3H3.H$200.2H4.2H$203.2H.H$204.H
3.H$200.2H2.H2.2H$200.H.H.2H$202.H2.H.2H$202.2H2.H.H29$245.2M$245.M.M
$245.M6$252.2M$251.2M$253.M4$259.3O$259.O$260.O$136.M$136.2M$135.M.M
4$145.2M$146.2M$145.M120.S$265.2S$265.S.S2.2pA$144.2S114.2S8.pA.pA$
143.S.S113.2S9.pA$145.S115.S2$150.2S$149.S.S$151.S$264.S$131.2Q130.2S
9.2Q$132.2Q3.2Q124.S.S7.2Q$131.Q4.Q.Q136.Q$138.Q2$268.2Q$268.Q.Q$268.
Q$287.U$286.2U$286.U.U$129.2Q$128.Q.Q146.3U$124.2U4.Q146.U$125.2U151.
U8.2M3.2S$124.U162.M.M.2S6.2S$287.M5.S5.S.S$299.S3$301.3O$301.O$302.O
$307.3Q$307.Q$308.Q9$90.2W$89.W.W$91.W9$77.M$77.2M$76.M.M8$81.2M$82.
2M228.2M$81.M229.2M$313.M6$347.2S$347.S.S$347.S3$342.S$341.2S$341.S.S
$74.2S$75.2S$74.S2$333.3S$333.S$334.S2$77.3S$79.S$78.S277.2Q$356.Q.Q$
51.Q304.Q$51.2Q3.Q311.3O$50.Q.Q3.2Q310.O$29.3S23.Q.Q295.3Q13.O7.2M$
31.S321.Q23.M.M$30.S323.Q22.M2$55.Q5.2Q$42.Q12.2Q5.2Q$42.2Q10.Q.Q4.Q$
41.Q.Q20$7.3O$9.O$8.O6$3O$2.O$.O!
[[ THUMBNAIL THUMBSIZE 2 HEIGHT 640 ZOOM 4 PAUSE 2 AUTOSTART LOOP 840 ]]
Following an old convention from MCell, the odd-numbered states are the ON states, and even-numbered states are OFF. There's a new pair of "marked cell" states 7 and 8 (used in the center of the above pattern). There are a couple of new ON states paired with different colors of OFF states, so now there are three possible history colors. There are also four new ON states that don't leave any trails at all, and several OFF states intended for use as labels, with various properties.

Color assignments are a work in progress; suggestions are welcome, preferably in the form of a replacement for the current @COLORS section of the rule table. (Fair warning, I'll probably just end up ignoring suggestions if they mean I have to think too hard.)

With changes by me and mostly muzik as of 1/28/2020:

Code: Select all

@COLORS

1    0  255  255  # standard ON (cyan)
2    0    0  255  # history state OFF (blue)
3  216  255  255  # marked ON with trail (looks like white)
4    0  128  192  # marked OFF with trail (pale sky blue)
5  255  128  255  # marked ON alternate (pink)
6   64   64   96  # boundary cell (dark bluish purple)
7  220  255  220  # marked ON no-trail filter (off white)
8    0  192    0  # marked OFF no-trail filter (green)
9    0  191  255  # ON with trail alt#1 (deep sky blue)
10   0   64  128  # OFF trail alt#1 (not-so-green teal)
11   0  255  192  # ON with trail (greener turquoise)
12   0  128   64  # OFF trail alt#2 (bluish green)
13 192  255  192  # ON no-trail #1 (pale green)
14 255   99   71  # OFF disappearing label (tomato)
15 255  128  128  # ON no-trail #2 (salmon-ish)
16 219  112  147  # OFF vanishing label (pale violet red)
17 255  192  128  # ON no-trail #3 (pale orange)
18 245  222  179  # OFF cycling label #1 (wheat)
19 255  255  128  # ON no-trail #4 (pale yellow)
20 150   50  204  # OFF cycling label #2 (dark orchid)
21 192  255  128  # ON no-trail #5 (yellow green) 
22 255  182  193  # OFF cycling label #3 (light pink)
23   0  255  127  # ON no-trail #6 (brighter green)
24   1    1    1  # hidden label (stealthy near-black)
25 255    0  127  # ON no-trail #7 (red magenta)
The new marked "no-trail" state is designed to allow the LifeHistory envelope for any moving pattern to be turned off, by sending the pattern through a barrier made of these "no-trail" cells. The old state-3 marked cells can then be used to turn history back on again:

Code: Select all

x = 279, y = 133, rule = LifeSuper
6.A3.A.2A$6.3A.A3.A18.3A$5.2A4.3A3.2A15.2A2.2A$5.A3.A6.2A14.A2.A.A$A
3.A4.2A.A3.A2.A.A11.A4.A.A$.A.3A5.3A2.A4.A13.A4.2A$.A3.4A.A.2A3.A.2A.
A2.3A2.A3.A.A4.A.A.2A$6.3A2.A2.2A5.2A2.2A.A3.2A2.2A3.A.A.2A$7.2A2.A2.
2A5.2A2.2A.A.A.2A4.A2.A11.2A$12.A.A6.2A2.A2.A.2A.A5.A.2A4.A5.A.A$21.A
.A.2A.2A3.2A3.2A2.2A3.A5.A3.A$20.A5.3A5.A.2A.A4.A2.A5.A3.4A$20.A3.3A
8.A9.2A3.A2.A3.A5.3A$20.A24.A.3A.A6.A2.A$22.A22.3A3.A10.A.A.2A$45.2A
2.2A3.A3.2A.4A.A.A2.2A$46.A.3A.A5.A5.A7.A$45.2A2.2A.A6.A.A4.A5.3A$52.
2A6.A.A.A3.A4.2A$47.A.A4.2A.A.2A2.3A.2A.2A.2A$48.A11.4A.A4.2A.2A2$68.
A6.2A$68.A6.A.A$68.A3.A2.A$69.A.A.A4.A$71.A.A2.3A$67.A3.A2.A23.H$67.A
3.A.2A23.H$69.A2.A25.H$70.A27.H$98.H$98.H$98.H$98.H$98.H$98.H$98.H$
98.H$98.H$98.H$98.H$98.H$98.H$98.H$98.H$98.H$98.H$98.H40.H$98.H40.HD$
98.H40.HD$98.H40.HD$98.H40.HD$98.H40.HD$98.H40.HD$139.HD$139.HD$139.H
D$139.HD$139.HD$139.HD$139.HD19.7P$139.HD19.3P2.3P$139.HD19.3P2.3P$
139.HD19.3P2.3P.3P3.3P.7P$139.HD19.3P2.3P.3P3.3P.3P.3P$139.HD19.6P3.
3P3.3P.2P3.3P$139.HD19.3P.3P2.3P3.3P.2P3.3P$139.HD19.3P2.3P.3P3.3P.2P
3.3P$139.HD19.3P2.3P2.2P3.3P.2P3.3P$139.HD19.3P2.4P.3P.4P.2P3.3P$139.
HD19.3P3.3P.8P.2P3.3P$139.HD$139.HD$139.HD$139.HD42.2P6.4P$140.D42.2P
6.4P$177.3P3.2P$177.3P3.2P$176.6P.7P2.3P.5P$177.3P3.3P.3P2.6P.3P$177.
3P3.2P3.3P.6P$177.3P3.2P3.3P.3P.4P$177.3P3.2P3.3P.3P3.4P$177.3P3.2P3.
3P.3P4.3P$177.3P3.2P3.3P.5P2.3P$178.4P.2P3.3P.3P.5P5$194.3P2.3P2.3P2.
5P2.3P3.3P$194.3P2.3P2.3P.2P2.3P.3P2.3P$194.3P.5P.2P6.3P.3P2.3P$195.
11P2.7P2.6P$195.11P.4P.3P2.6P$195.5P.4P2.3P2.3P3.5P$196.4P.4P2.3P2.3P
3.4P3.3P$196.4P.4P3.7P3.4P3.3P$218.4P3.3P$218.3P3.3P$217.3P4.2P4$229.
4P$222.6P.4P$221.4P.3P$221.3P$221.3P6.3P.6P$222.4P4.3P.3P$223.5P2.3P.
3P$225.4P.3P.2P$226.3P.3P.2P$226.3P.3P.2P$221.3P.4P.3P.2P$222.6P2.3P.
2P5$253.2P6.4P11.3P$233.7P13.2P6.4P11.3P$233.3P2.3P12.2P21.3P$233.3P
2.3P12.2P21.3P$233.3P2.3P3.6P3.7P2.3P.7P3.3P$233.3P2.3P2.3P2.3P2.3P.
4P.3P.3P.3P3.3P$233.6P3.3P4.3P.3P2.3P.3P.2P3.3P2.3P$233.3P.3P2.3P4.3P
.2P3.3P.3P.2P3.3P2.3P$233.3P2.3P.3P4.3P.2P3.3P.3P.2P3.3P2.3P$233.3P2.
3P.3P4.3P.3P2.3P.3P.2P3.3P$233.3P2.4P.3P2.3P2.3P.3P2.3P.2P3.3P2.3P$
233.3P3.3P2.6P3.7P2.3P.2P3.3P2.3P!
Here's another sample pattern with more of the new colors and labels demonstrated:

Code: Select all

x = 216, y = 193, rule = LifeSuper
2.3D26.5D21.3D6.3D18.3D4.6D17.3D4.7D16.3D3.9D15.3D5.5D$5D25.3D.3D18.
5D4.5D16.5D4.2D2.3D14.5D4.3D18.5D9.3D13.5D4.3D.3D$5D24.3D3.3D17.5D4.
5D16.5D8.3D14.5D4.3D18.5D8.3D14.5D3.3D3.3D$2.3D24.3D3.3D19.3D6.3D18.
3D8.3D16.3D4.3D20.3D8.3D16.3D3.3D3.3D$2.3D24.3D3.3D19.3D6.3D18.3D7.4D
16.3D4.6D17.3D7.3D17.3D3.3D3.3D$2.3D24.4D.4D19.3D6.3D18.3D4.6D17.3D8.
3D16.3D7.3D17.3D3.4D.4D$2.3D25.8D19.3D6.3D18.3D8.3D16.3D9.3D15.3D6.4D
17.3D4.8D$2.3D30.3D19.3D6.3D18.3D8.4D15.3D9.3D15.3D6.3D18.3D9.3D$2.3D
29.3D20.3D6.3D18.3D8.4D15.3D8.4D15.3D6.3D18.3D8.3D$2.3D28.4D20.3D6.3D
18.3D3.3D2.3D16.3D3.3D2.3D16.3D5.3D19.3D7.4D$8D21.6D20.8D.8D13.8D.6D
15.15D15.8D2.3D17.14D2$206.2A$206.A.A.2A.A$208.A.A.2A$208.2A3$.5A25.
5I25.5K25.5M25.5O25.5Q25.5S25.2A$A4.A24.I4.I24.K4.K24.M4.M24.O4.O24.Q
4.Q24.S4.S25.2A$5.A29.I29.K29.M29.O29.Q29.S$A3.A25.I3.I25.K3.K25.M3.M
25.O3.O25.Q3.Q25.S3.S$2.A29.I29.K29.M29.O29.Q29.S17$129.7N58.4N$129.
7N58.4N$129.3N$129.3N$125.7N.3N.5N3.5N3.7N2.7N3.6N3.5N3.9N.7N2.8N$
124.3N.4N.6N.3N.2N2.3N2.3N.4N.3N.4N.3N.4N.2N2.3N2.3N3.3N.3N.3N.3N2.3N
$123.3N3.3N.6N9.3N2.3N2.3N.3N2.6N3.3N5.3N2.3N3.3N.2N3.6N2.3N$123.3N3.
3N.3N.4N3.7N2.2N3.3N.2N3.12N.7N2.2N4.3N.2N3.6N2.3N$123.3N3.3N.3N3.8N.
3N2.2N3.3N.2N3.6N6.4N.3N2.2N4.3N.2N3.10N$123.3N3.3N.3N4.6N2.3N2.3N2.
3N.3N2.6N6.3N2.3N2.2N4.3N.2N3.6N$124.3N.4N.5N2.6N2.3N2.3N.3N.4N.3N2.
3N2.6N2.3N2.2N4.3N.2N3.11N$124.8N.3N.5N2.16N2.7N3.6N2.11N4.3N.2N3.6N
2.4N$153.2N7.2N43.3N3.3N$153.2N7.2N43.3N2.3N$153.2N7.2N44.6N5$145.3N
10.2N16.3N$145.3N10.2N16.3N$145.3N10.2N16.3N$145.3N10.2N16.3N$145.3N
2.5N3.7N3.6N2.3N.5N$145.3N.2N2.3N2.3N.4N.3N.4N.6N.3N$145.3N5.3N2.3N2.
6N3.3N.6N$145.3N.7N2.2N3.12N.3N.4N$145.7N.3N2.2N3.6N7.3N3.4N$145.6N2.
3N2.3N2.6N7.3N4.3N$145.6N2.3N2.3N.3N2.3N2.3N.5N2.3N$145.3N.16N3.6N2.
3N.5N8$140.20D6$84.3P61.2P7.3P$84.3P61.2P7.3P$84.3P17.3P26.3P12.2P7.
3P$84.3P17.3P26.3P12.2P7.3P$80.7P2.6P2.5P.6P.8P3.3P2.5P.6P2.5P3.7P2.
3P2.6P$79.3P.4P.3P.7P.3P.3P3.3P2.3P3.3P.3P.3P.3P3.2P2.3P2.3P.4P.3P.3P
.4P$78.3P3.6P3.6P5.3P3.3P2.3P3.6P6.3P7.3P2.3P2.3P.6P3.3P$78.3P3.12P.
4P3.3P3.2P3.3P3.6P6.3P3.7P2.2P3.3P.12P$78.3P3.6P9.4P.3P3.2P3.3P3.6P6.
3P2.4P.3P2.2P3.3P.6P$78.3P3.6P10.3P.3P3.2P4.2P3.6P6.3P2.3P2.3P2.3P2.
3P.6P$79.3P.4P.3P2.5P2.3P.3P3.2P4.3P.4P.3P.3P.3P2.3P2.3P2.3P.3P.4P.3P
2.3P$79.8P2.6P2.5P3.7P4.8P2.5P3.4P.16P.4P2.6P6$100.3P10.2P16.3P$100.
3P10.2P16.3P$100.3P10.2P16.3P$100.3P10.2P16.3P$100.3P2.5P3.7P3.6P2.3P
.5P$100.3P.2P2.3P2.3P.4P.3P.4P.6P.3P$100.3P5.3P2.3P2.6P3.3P.6P$100.3P
.7P2.2P3.12P.3P.4P$100.7P.3P2.2P3.6P7.3P3.4P$100.6P2.3P2.3P2.6P7.3P4.
3P$100.6P2.3P2.3P.3P2.3P2.3P.5P2.3P$100.3P.16P3.6P.4P.5P6$100.20H9$
73.3R11.4R$73.3R11.4R$73.3R$73.3R$64.7R2.3R3.5R2.5R.6R$64.3R.4R.3R2.
2R2.3R3.3R.3R2.2R$64.3R2.3R.3R6.3R3.3R.3R3.2R$64.2R3.3R.3R2.7R3.3R.2R
4.2R$64.2R3.3R.3R.4R.3R3.3R.2R4.2R$64.3R2.3R.3R.3R2.3R3.3R.2R4.2R$64.
3R.3R2.3R.3R2.3R3.3R.2R4.2R$64.7R2.3R2.9R.3R.2R4.2R$64.2R$64.2R$64.2R
5$60.3R12.2R17.3R$60.3R12.2R17.3R$60.3R12.2R17.3R$60.3R12.2R17.3R$60.
3R3.5R4.7R4.6R2.3R2.5R$60.3R2.2R2.3R3.3R.4R2.3R.4R.3R.3R.3R$60.3R6.3R
3.3R2.3R.3R3.3R.3R.3R$60.3R2.7R3.2R3.3R.9R.3R2.4R$60.3R.4R.3R3.2R3.3R
.3R7.3R4.4R$60.3R.3R2.3R3.3R2.3R.3R7.3R5.3R$60.3R.3R2.3R3.3R.3R3.3R2.
3R.3R.2R2.3R$60.3R2.9R.7R4.6R2.3R2.5R33$37.2A$38.A$35.3A$35.A!
Based on the glider-synth experiment above, I'm thinking four no-trail colors really aren't quite enough. Maybe eight of those, plus a fourth state with a colored history trail?

The toLife.lua script (Alt+J) in Golly could easily be adjusted to downconvert a LifeSuper pattern correctly into two-state Life, and a replacement for toLifeHistory.lua (Alt+H) could allow a similarly easy conversion to standard LifeHistory. Neither of them do quite the right thing at the moment.

If anyone might be interested in trying out pattern editing using a multi-color Life rule along these lines, I'd be happy to take suggestions for minor rule adjustments. I don't want to spend too much more time on this rule, though, so anyone who really wants a major new feature should probably just go ahead and implement it.

muzik
Posts: 3786
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: LifeSuper rule

Post by muzik » January 26th, 2020, 6:04 pm

Now this is an interesting case. Would there be any particular downsides for this rule becoming the "default" LifeHistory packaged with Golly? I can see this becoming borderline revolutionary if it's set as the new default, standard LifeHistory.
Last edited by muzik on January 27th, 2020, 2:29 pm, edited 1 time in total.
Bored of using the Moore neighbourhood for everything? Introducing the Range-2 von Neumann isotropic non-totalistic rulespace!

User avatar
dvgrn
Moderator
Posts: 6734
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: LifeSuper rule

Post by dvgrn » January 26th, 2020, 7:35 pm

muzik wrote:
January 26th, 2020, 6:04 pm
Now this is an interesting case. Would there be any particular downsides for this rule becoming the "default" LifeHistory packaged with Golly? I can see this becoming borderline revolutionary if it's set as the new default, standard LifeHistory.
Well... I guess that wouldn't be completely impossible, since the new rule would be backward-compatible with the old seven-state rule.

The main problem I can think of is efficiency. LifeViewer can run the @TABLE-only version of this okay, but slowly. The @TREE version of this would be over 5MB already, even without adding any more states. Probably Golly is somewhat less speedy with this 20-state rule as compared to LifeHistory. It's not clear that it would be a good idea to slow down all the plain-vanilla LifeHistory patterns out there by some significant margin, just to be able to do these extra specialized tricks which we can do perfectly well with a new rule with a different name.

What's in LifeSuper at the moment is just a sample of some possible extra annotation functionality. At the moment I'd rather be able to make adjustments to this rule as ideas come up, maybe even without worrying about strict backward compatibility with the old LifeHistory rule.

muzik
Posts: 3786
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: LifeSuper rule

Post by muzik » January 26th, 2020, 7:42 pm

On a closely related note, I've had an idea on mind for the past month or so regarding LifeHistory that could fit snugly into this new, budding pattern analysis machine: Why not merge cells from ExtendedLife (and rules derived from it) into SuperLH?

These cells are fun to play with by themselves, but could also be used for more serious analysis, such as for displaying the currently yet to be stabilised p41 wick, as well as for allowing things like these low-period sparkers, which could come in handy for stabilizing certain patterns until a pure Life solution can be found, like with this p12 that uses a well-known reaction I'm not sure has actually been tamed yet.

I would have added these cells to the rule by myself, but it appears that ExtendedLife uses a ruletree whereas SuperLH uses a ruletable, so I don't know how to convert between the two.

----

Since SuperLH currently uses cells 0-19, here are suggested specifications for the subsequent additions (with an on cell considered state 1):
  • #20: Blocker cell - acts like a cell which is permanently off. Does not interact with cells other than the fact that cells cannot be born into the space it occupies. ExtendedLife #5, extendedlifefancy #5, StateInvestigator #5
  • #21: Reactor cell - acts like a cell which is permanently off. Counts towards birth and survival conditions of surrounding cells, and three of these cells can themselves birth a live cell. ExtendedLife #6, extendedlifefancy #6, StateInvestigator #4
  • #22: Catalyst cell - identical behaviour to #21 with the sole exception that three of these cells cannot create live cells on their own, and at least one true live cell must be present. ExtendedLife_7 #7
  • #23: On deathforcer cell - acts identically to LifeHistory's border cells, with the exception of the fact that these cells are counted as alive when considering cell birth. extendedlifefancy #8, StateInvestigator #2
  • #24: On birthforcer cell - any cell neighbouring this cell which is off in the current generation will be turned on in subsequent generations. Counts as a live cell for calculating survival conditions. extendedlifefancy #2
  • #25: Off birthforcer cell - any cell neighbouring this cell which is off in the current generation will be turned on in subsequent generations. Does not count as a live cell for calculating survival conditions. ExtendedLife #2, extendedlifefancy #7
  • #26: Birthforcer-deathforcer cell - any live cells touching this cell will be killed in the next generation and any dead cells touching it will be alive in the next generation, effectively inverting all the cells around it. ExtendedLife #4, extendedlifefancy #4
  • #27: P2 killer on cell - Behaves identically to state #23, with the exception that it immediately evolves into a state 28 cell on the next generation. StateInvestigator #6
  • #28: P2 killer off cell - Behaves identically to state #6, with the exception that it immediately evolves into a state 26 cell on the next generation. This oscillation allows for a strong period-4 sparker. StateInvestigator #7
----

I personally would really like to see these states make it into SuperLH so that the analytical capabilities of these cells (as well as their fun value) can be fully harnessed by the Life community without having to install two separate ruletables and having to pick between the benefits of one or the other (and also, the standardisation of these cells should also help put to rest a minor disagreement regarding extendedlifefancy and stateinvestigator).

Does anyone else have any suggestions? There's probably way more states that could be added for generality's sake, but I don't want to bloat this rule with too many cell states that haven't been used before in existing rules (and 29 states will end up being hard to memorize as is, unless we can come up with some good icons for cells, not to mention the ginormous ruletree size these additions alone would likely already result in). But I can definitely see these being a very handy asset to the Lifenthusiast.
Last edited by muzik on January 27th, 2020, 2:29 pm, edited 2 times in total.
Bored of using the Moore neighbourhood for everything? Introducing the Range-2 von Neumann isotropic non-totalistic rulespace!

User avatar
Moosey
Posts: 3293
Joined: January 27th, 2019, 5:54 pm
Location: A house, or perhaps the OCA board. Or [click to not expand]
Contact:

Re: SuperLH rule

Post by Moosey » January 26th, 2020, 7:53 pm

Is this intended behavior?

Code: Select all

x = 15, y = 4, rule = SuperLH
9.5I$9.I4.I$H8.I$10.I!
(Also, here's something interesting:)

Code: Select all

x = 5, y = 4, rule = SuperLH
.A3M$A3.M$4.M$A2.A!
(Challenge: make an object that changes the color of an XWSS if and only if it is an even number of cells away when facing upwards)

EDIT:
Another demo pattern:

Code: Select all

x = 45, y = 72, rule = SuperLH
23.M$22.M$22.M$22.M2.M$22.3M7$19.M$20.M$20.M$17.M2.M$18.3M30$5.2M$6.M
$6.M.M7.12H$7.2M7.H9.DH$2M14.H7RVTDH5.4M$.M14.HR7.TDH5.M3.M$.M.M12.H
7R.RDH5.M$2.2M12.H6.R.VDH6.M$16.H7R.TDH12.4M$16.HR7.RDH12.M3.M$16.H7R
.VDH12.M$16.H6.R.VDH6.M6.M$16.H7R.TDH5.M$16.HR7.TDH5.M3.M$16.H9RDH5.
4M$7.2M7.H9.DH$6.M.M7.12H$6.M$5.2M4$16.2M$17.M7.2M$14.3M8.M$14.M11.3M
$28.M!
Last edited by Moosey on January 27th, 2020, 2:03 pm, edited 1 time in total.
I am a prolific creator of many rather pathetic googological functions

My CA rules can be found here

Also, the tree game
Bill Watterson once wrote: "How do soldiers killing each other solve the world's problems?"

muzik
Posts: 3786
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: LifeSuper rule

Post by muzik » January 26th, 2020, 8:05 pm

dvgrn wrote:
January 26th, 2020, 7:35 pm
The main problem I can think of is efficiency. LifeViewer can run the @TABLE-only version of this okay, but slowly. The @TREE version of this would be over 5MB already, even without adding any more states. Probably Golly is somewhat less speedy with this 20-state rule as compared to LifeHistory. It's not clear that it would be a good idea to slow down all the plain-vanilla LifeHistory patterns out there by some significant margin, just to be able to do these extra specialized tricks which we can do perfectly well with a new rule with a different name.
Are there any good benchmarking patterns I can use to test this? On the iOS version of golly, I ran bunnies in both SuperLH and the bundled LifeHistory, both at 8^2, and they ran to completion with no difference in time I could detect.
Moosey wrote:
January 26th, 2020, 7:53 pm
Is this intended behavior?

Code: Select all

x = 15, y = 4, rule = SuperLH
9.5I$9.I4.I$H8.I$10.I!
Proper handling of multiple Life states combining hasn't been considered yet, as is said in OP, so I can't be sure.
Last edited by muzik on January 27th, 2020, 2:28 pm, edited 1 time in total.
Bored of using the Moore neighbourhood for everything? Introducing the Range-2 von Neumann isotropic non-totalistic rulespace!

User avatar
dvgrn
Moderator
Posts: 6734
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: LifeSuper rule

Post by dvgrn » January 26th, 2020, 9:50 pm

Moosey wrote:
January 26th, 2020, 7:53 pm
Is this intended behavior?

Code: Select all

x = 15, y = 4, rule = SuperLH
9.5I$9.I4.I$H8.I$10.I!
Thanks for pointing that out. Yes, pretty much -- it's a consequence of the rule lines about mixing colors:

"# any mix of ON with trail goes to lowest state with history"

I didn't spend any time trying to come up with all the ways that the ON colors could interact, so basically any mixing of colors will turn new ON cells to a predictable state. We could add a pile of extra rules to let the majority color win in cases like this. But I'm not too interested in adding all that complexity. The above is a non-standard use of the state-7 brown cell, and basically if you misuse it you get whatever you get and that's okay. To make state-7 cells act as a filter for moving patterns-with-history, they should form a complete wall across the path of the spaceship:

Code: Select all

x = 15, y = 7, rule = LifeSuper
H$H$H8.5I$H8.I4.I$H8.I$H9.I$H!
However, notice that when the spaceship first touches the state-8 wall, it converts back to state 1 according to the above rule. For slow spaceships you can get a huge patch of wrong-color on the upstream side of the wall. I'll probably add a few more rule lines to fix that, so the behavior of LifeViewer with these patterns may change any time -- check the edit history for Rule:LifeSuper in the next day or so.

EDIT: these problems are only somewhat fixable by adjusting the rules. The workaround is to have a double-width wall, state 4 and state 8, in the appropriate order to do a clean conversion:

Code: Select all

x = 26, y = 42, rule = LifeSuper
D$D$D$D15.3W$D15.W.2W$D15.4W.W$D21.W$D20.2W$D21.4W$D19.W.W$D18.W2.W$D
18.W2.W$D19.W.W$D21.4W$D20.2W$D21.W$D15.4W.W$D15.W.2W$D15.3W$D$D$D$DH
$DH$DH14.3W$DH14.W.2W$DH14.4W.W$DH20.W$DH19.2W$DH20.4W$DH18.W.W$DH17.
W2.W$DH17.W2.W$DH18.W.W$DH20.4W$DH19.2W$DH20.W$DH14.4W.W$DH14.W.2W$DH
14.3W$DH$DH!
muzik wrote:
January 26th, 2020, 7:42 pm
On a closely related note, I've had an idea on mind for the past month or so regarding LifeHistory that could fit snugly into this new, budding pattern analysis machine: Why not merge cells from ExtendedLife (and rules derived from it) into [LifeSuper]?
I'm planning to use LifeSuper specifically to annotate complex Life patterns, so I'll probably avoid adding any cell types that allow for non-B3/S23 behavior. The gray boundary cells were bad enough in that department. Right now it's pretty easy to pick a new color for a group of gliders by choosing a high odd-numbered state. Seems like these extra states would add a lot of clutter that I don't personally want to have there.
muzik wrote:
January 26th, 2020, 7:42 pm
I would have added these cells to the rule by myself, but it appears that ExtendedLife uses a ruletree whereas [LifeSuper] uses a ruletable, so I don't know how to convert between the two.
Are you looking at Rule:Extendedlife on the wiki? Hit the Edit button and you'll see there's a perfectly good table definition there. Most of the automatically converted rules in the LifeWiki Rule namespace will have a @TREE section followed by a @TABLE section, but this was one of the early manual conversions so the order is reversed. Might be worth swapping them to standard order.

Don't Let Me Stop You!
Please do feel free to come up with a new rule name and add those extra cell states -- I don't mind the competition at all, it's just I don't want the extra clutter in the rule I'll be using. If your LifeUltra rule ends up getting a whole lot of use, the Golly scripts toLife.lua and toLifeHistory.lua can certainly be adjusted to handle them correctly, and new toLifeUltra.lua and/or toLifeSuper.lua scripts could be added if necessary. (This could mostly be just a matter of mapping a keyboard shortcut directly to the rule file, though.)

...But Maybe Don't Start Modding Quite Yet
It might be a good idea to wait until the LifeSuper definition settles down a bit more before adding extra states, though. I'm currently thinking I'll stop at 25 or 26 states, adding three more no-trail ON states, and fill in with even-numbered label states with some other interesting behavior. That way the multistate RLE can still represent every cell type with one uppercase letter.
muzik wrote:
January 26th, 2020, 7:42 pm
There's probably way more states that could be added for generality's sake, but I don't want to bloat this rule with too many cell states ...
That's my problem right there. There are already enough cell states to make editing a bit awkward, and yet I still want to add those additional no-trail colors -- four doesn't seem to be quite enough for clarity, even in the small sample synthesis I posted.

muzik
Posts: 3786
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: LifeSuper rule

Post by muzik » January 26th, 2020, 10:27 pm

A suggestion for the default colours of the life-with-trails states, based on three of LifeViewer's default themes:

Code: Select all

x = 7, y = 23, rule = SuperLH colorsuggestion1
2.2A$A4.A$6.A$A5.A$.6A5$2.2I$I4.I$6.I$I5.I$.6I5$2.2K$K4.K$6.K$K5.K$.
6K!
If we're allowed to redefine the original LifeHistory state colours, we can have them all share an overall blue theme while still being notably distinct:

Code: Select all

x = 7, y = 23, rule = SuperLH colorsuggestion2
2.2A$A4.A$6.A$A5.A$.6A5$2.2I$I4.I$6.I$I5.I$.6I5$2.2K$K4.K$6.K$K5.K$.
6K!
If these aren't received horribly I'll extend these suggestions to account for no trails versions and other states.
Last edited by muzik on January 27th, 2020, 2:29 pm, edited 1 time in total.
Bored of using the Moore neighbourhood for everything? Introducing the Range-2 von Neumann isotropic non-totalistic rulespace!

User avatar
dvgrn
Moderator
Posts: 6734
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: SuperLH rule

Post by dvgrn » January 26th, 2020, 11:25 pm

muzik wrote:
January 26th, 2020, 10:27 pm
If we're allowed to redefine the original LifeHistory state colours, we can have them all share an overall blue theme while still being notably distinct:

Code: Select all

x = 7, y = 23, rule = SuperLH colorsuggestion2
2.2A$A4.A$6.A$A5.A$.6A5$2.2I$I4.I$6.I$I5.I$.6I5$2.2K$K4.K$6.K$K5.K$.
6K!
If these aren't received horribly I'll extend these suggestions to account for no trails versions and other states.
Now that you mention it, I think it's probably a good idea to make the new rule visually distinct from the old LifeHistory. The behavior of states 0 through 6 should stay the same, but it's fine if they look different because it's a different rule.

So I'll vote for your suggestion2, or something like it. Maybe just keep editing that rule, if you want to add ideas for no-trails and so on. Or at some point you could just go ahead and edit the SuperLH colors table directly, and save a step -- I could always revert a change if something goes horribly wrong.

I'll throw in the seven additional no-trails states tomorrow, with any luck; I'm out of time for today. Thanks!

Pavgran
Posts: 31
Joined: June 12th, 2019, 12:14 pm

Re: SuperLH rule

Post by Pavgran » January 27th, 2020, 6:07 am

I like that rule already!
Editing signal circuitry is a lot easier with labeling and making history envelope contained.

I'd suggest adding 4 more converter states (marked on/off with and w/o trail) so that you could annotate outputs with different colors.

User avatar
dvgrn
Moderator
Posts: 6734
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: LifeSuper rule

Post by dvgrn » January 27th, 2020, 8:51 am

Pavgran wrote:
January 27th, 2020, 6:07 am
I like that rule already!
Editing signal circuitry is a lot easier with labeling and making history envelope contained.

I'd suggest adding 4 more converter states (marked on/off with and w/o trail) so that you could annotate outputs with different colors.
That does sound nice to have, but I think I'm going to stop at 26 states. It's already possible to use state 3-and-4 and state 7-and-8 to mark outputs with different colors, though if you want no-trail output you'll have to line the state 4 with state 8.

There are also lots and lots of OFF label colors now that can be placed along the edges of any output lane -- or in the output lane if you don't mind them getting run over when the pattern runs. None of the OFF states have any effect on the evolution of the pattern. So that should be another workable way of annotating outputs.

I've added the extra no-trail states, and have fixed the conversion-to-state-1 problem that Moosey pointed out.

Code: Select all

x = 27, y = 79, rule = LifeSuper
12.H$12.H$12.H8.5A$12.H8.A4.A$12.H8.A$12.H9.A$12.H9$21.5A$21.A4.A$12.
H8.A$22.A3$2K$2K7$12.H$12.H$12.H8.5I$12.H8.I4.I$12.H8.I$12.H9.I$12.H
9$21.5I$21.I4.I$12.H8.I$22.I3$2A$2A5$12.H$12.H$12.H8.5K$12.H8.K4.K$
12.H8.K$12.H9.K$12.H9$21.5K$21.K4.K$12.H8.K$22.K3$2I$2I!
If anyone sees any more (unintentional) weird behavior, let me know.

As far as deliberate weird behavior goes, I'm slightly embarrassed by the last three label types -- it's kind of like adding a <BLINK> tag to Conway's Life. All I can say is, if you don't like the effect, just don't let label states 18, 20, and 22 touch each other:

Code: Select all

x = 237, y = 173, rule = LifeSuper
197.4X7.2X$148.4X3.3X39.4X7.2X$148.4X3.3X42.X.3X3.2X$148.5X2.3X42.X.
3X3.2X$148.6X.3X2.6X2.3X2.3X2.3X4.3X2.3X2.12X.7X$148.6X.3X.3X2.3X.3X
2.3X2.3X4.3X2.3X2.6X.3X3.3X.3X$148.3X.9X4.6X.5X.2X5.3X.5X.2X.3X.3X3.
2X3.3X$148.3X.9X4.3X.11X6.11X.3X.3X3.2X3.3X$148.3X2.8X4.3X.11X6.11X.
3X.3X3.2X3.3X$148.3X2.8X4.3X.5X.4X7.5X.4X2.3X.3X3.2X3.3X$148.3X3.4X.
3X2.3X3.4X.4X8.4X.4X2.3X.3X3.2X3.3X$148.3X4.3X2.6X4.4X.4X8.4X.4X2.3X
2.7X3.3X$169.X42.X$168.X44.X$156.3X7.2X11.3X10.2X16.3X$86.12R58.3X7.
2X11.3X10.2X16.3X$80.6R11.R34.3X21.3X.3X3.2X11.3X10.2X16.3X$74.6R18.R
33.3X21.3X.3X3.2X11.3X10.2X16.3X$67.7R25.R25.5X.6X2.6X3.5X3.9X.7X6.3X
2.5X3.7X3.6X2.3X.5X$64.3R33.2R22.3X.3X.3X3.3X.4X.2X2.3X2.3X.3X3.3X.3X
6.3X.2X2.3X2.3X.4X.3X.4X.6X.3X$61.3R38.R21.3X5.3X2.3X3.3X5.3X2.3X.3X
3.2X3.3X5.3X5.3X2.3X2.6X3.3X.6X$56.5R42.R21.4X3.3X2.9X.7X2.3X.3X3.2X
3.3X5.3X.7X2.2X3.12X.3X.4X$52.4R48.R22.4X.3X2.3X6.4X.3X2.3X.3X3.2X3.
3X5.7X.3X2.2X3.6X7.3X3.4X$50.2R52.R23.3X.3X2.3X6.3X2.3X2.3X.3X3.2X3.
3X5.6X2.3X2.3X2.6X7.3X4.3X$45.5R55.R18.2X2.3X.3X3.3X2.6X2.3X2.3X.3X3.
2X3.3X5.6X2.3X2.3X.3X2.3X2.9X2.3X.3X2.3X2.3X$42.3R60.R19.5X3.5X.6X2.
12X2.7X3.3X5.3X.16X3.6X2.3X.5X.14X$39.3R64.R67.5X$36.3R67.R68.X$35.R
71.2R65.X$34.R74.R55.2A6.X$34.R75.R54.2A5.X$33.R76.R$32.R78.R$31.R32.
14R34.R$30.R28.5R14.2R32.R$30.R24.4R20.2R32.R$29.R24.2R25.R32.R$28.R
24.2R27.3R29.R84.4R$27.R24.2R31.5R25.R77.6R4.R$27.R23.R37.2R25.R76.R
10.2R$26.R24.R38.3R24.R74.2R12.2R$26.R24.R41.R24.R71.2R16.3R$24.2R25.
R42.2R23.R68.2R21.2R$23.R27.R43.3R22.R65.2R25.2R$23.R27.R46.2R20.R63.
2R29.2R$22.R28.R47.2R20.2R59.2R33.4R$22.R28.R48.2R21.R54.4R38.2R$21.R
29.R49.R21.2R50.3R44.2R$21.R29.R50.2R21.2R46.2R48.2R$20.R29.2R52.3R
20.46R51.2R$19.R31.R54.3R117.R$18.R32.3R54.2R117.T$18.R34.2R55.R117.T
$17.R36.2R11.3R10T31.R116.2T$16.R39.4R3.6R11.T30.2R116.2T$16.R42.5R
17.T30.R117.2T$15.R66.T30.2R116.2T$14.R67.T31.2R116.2T$13.R69.T32.2R
115.2T$13.R69.2T32.4R66.7V40.T$12.R71.3T33.3R56.8V6.2V39.2T$12.R73.T
35.3R51.4V14.2V39.T$11.R75.2T35.2R47.3V19.V39.T$11.R76.3T34.3R28.17V
22.2V38.T$10.R79.4T33.3R9.17V40.V38.T$10.R82.2T34.6R2.3V56.V38.2T$9.R
84.3T37.2RV59.V39.T$8.R87.5T94.2V39.T$7.2R55.15V22.2T92.V40.T$6.V54.
3V14.4V21.3T88.V41.T$5.2V50.4V20.3V22.T85.2V42.T$5.V46.5V26.2V22.T82.
3V42.2T$5.V45.2V32.2V21.T79.3V44.T$4.V44.2V36.2V19.T75.4V46.2T$4.V42.
3V39.2V18.T70.4V50.T$3.2V42.V42.2V17.2T66.3V53.T$3.V41.2V44.2V17.2T
62.3V55.2T$3.V41.V46.2V17.T59.3V57.2T$3.V41.V47.V17.2T56.3V58.2T$3.V
40.V48.V18.T54.2V60.2T$3.V39.2V48.V18.T52.2V59.3T$3.V38.2V48.V19.T50.
3V58.3T$3.V37.V49.V20.T48.2V59.3T$4.V34.2V49.V21.T46.2V60.2T$4.2V32.V
50.2V21.T45.2V59.2T$5.2V30.V50.V23.T44.2V21.4T29.6T$6.2V28.V50.2V22.T
45.V21.2T2.4T6.20T$8.3V24.V51.V23.T44.2V20.2T7.6T$10.4V20.2V50.V24.T
44.V21.T$14.3V16.V51.2V23.T45.V20.T$17.4V10.2V50.3V24.T44.2V19.T$21.
11V50.2V26.T44.V20.T$80.2V27.T45.V19.T$79.2V26.3T45.V18.2T$78.2V26.2T
47.V18.T$78.2V26.T48.V18.T$79.2V23.2T49.V18.T$80.2V21.2T50.V17.T$82.V
16.4T52.V17.T$83.2V12.2T56.V17.T$85.2V9.2T57.V18.T$86.3V4.2VT59.V18.
2T$89.5V.T59.2V18.2T13.2T$156.V19.2T7.5T.4T$156.V21.7T8.2T$156.V37.2T
$156.V38.T$157.V37.2T$157.V38.T$158.V37.T$158.2V36.2T$159.V37.T$159.V
37.T$159.V37.T$159.V37.T$160.V36.T$160.V36.T$160.V36.T$160.V34.2T$
161.V30.3T$161.2V27.2T$162.V24.3T$162.V21.3T$162.2V17.3T$163.V13.4T$
163.2V9.3T$164.2V5.4T$165.7T2$58.3I$60.I$59.I20$3G$2.G$.G11$168.3A$
168.A2.A$168.A$168.A$169.A.A2$99.3pA$101.pA$100.pA!
The pop-up labels are a lot more stealthy in LifeViewer than they are in Golly (since Golly's default background is dark gray, not black). That's deliberate, since I'm thinking a lot of viewing of LifeSuper patterns might happen in LifeViewer, but most of the editing will probably be done in Golly.

Simulation speed may end up being a serious issue in LifeViewer, though. A @TREE version of the table might speed things up by an order of magnitude or so, but it would be something like 10MB, well beyond the intended capacity of the Rule namespace on LifeWiki.

JP21
Posts: 1003
Joined: October 26th, 2019, 5:39 am
Location: PH

Re: SuperLH rule

Post by JP21 » January 27th, 2020, 10:09 am

There is only one reason why I am here... this.
Wow, this is a recent rule and it is great. Does anybody think this rule will spread throughout the entire forum?
Here is something (took 30 minutes) (Edit: Maybe 1 hour and 15 minutes after seeing the last post):

Code: Select all

x = 135, y = 68, rule = SuperLH
45.90F12$33.90H12$21.90D6$15.90X2$13.90V2$11.90T2$9.90R2$7.90P2$5.90L
2$3.90J2$.90B3$3C.3E6$4.3K2.3I2.3A$6.K4.I4.A$5.K4.I4.A4$4.3W2.3U2.3S
2.3Q2.3pA2.3O$6.W4.U4.S4.Q4.pA4.O$5.M4.M4.M4.M4.M4.M4$4.3K2.3I2.3pA2.
3W2.3U2.3S2.3Q2.3pA2.3O$6.K4.I4.pA4.W4.U4.S4.Q4.pA4.O$5.A4.A4.A4.A4.A
4.A4.A4.A4.A!
Attachments
Find the difference.gif
Find the difference.gif (5.42 KiB) Viewed 5530 times
A 13 year old guy that have useless discoveries about life and other rules.

Code: Select all

x = 13, y = 20, rule = B3/S23
11b2o$11b2o4$8b2o$8b2o2$2o$2o3$3b2o$3b2o2$11b2o$10b2o$12bo$3b2o$3b2o!

muzik
Posts: 3786
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: LifeSuper rule

Post by muzik » January 27th, 2020, 12:44 pm

Since I don't know much about ruletables, here's my shot at adding a blocker cell. Not seeing any bugs with it right now, can anyone find any?

Code: Select all

x = 26, y = 7, rule = LifeUltra
11.I$11.I.I$11.2I9.K$.pB19.K$8.pB12.K3.K$.A19.4K$3A.pB!
EDIT by dvgrn: Changed name of rule to keep SuperLH from getting any more horribly complicated.
Last edited by muzik on January 27th, 2020, 2:29 pm, edited 1 time in total.
Bored of using the Moore neighbourhood for everything? Introducing the Range-2 von Neumann isotropic non-totalistic rulespace!

User avatar
dvgrn
Moderator
Posts: 6734
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: SuperLH rule

Post by dvgrn » January 27th, 2020, 1:07 pm

muzik wrote:
January 27th, 2020, 12:44 pm
Since I don't know much about ruletables, here's my shot at adding a blocker cell. Not seeing any bugs with it right now, can anyone find any?

Code: Select all

x = 26, y = 7, rule = LifeUltra
11.I$11.I.I$11.2I9.K$.pB19.K$8.pB12.K3.K$.A19.4K$3A.pB!
EDIT by dvgrn: Changed name of rule to keep SuperLH from getting any more horribly complicated.
I definitely don't want any more states added to SuperLH, as I mentioned at the bottom of this much-too-long-so-my-apologies post. SuperLH has an awkwardly large number of states already, and adding even more extra states at the end will make the no-trail ON states a lot harder for me to use.

So I've created a new rule name for your planned combination of Extended Life and SuperLH. It's currently called "LifeUltra", because Chris Rowett has pointed out that this kind of thing is theoretically supportable across a large rulespace, if the rule name consists of a known alias plus some distinctive suffix. LifeViewer already does this for arbitrary {rule name}History rules.

So I'm currently moving SuperLH to a name that works that way, "LifeSuper". Will try to get people using that and deprecate "SuperLH", though it should continue to work as an alias.

muzik
Posts: 3786
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: LifeSuper rule

Post by muzik » January 27th, 2020, 2:09 pm

dvgrn wrote:
January 27th, 2020, 1:07 pm
I definitely don't want any more states added to SuperLH, as I mentioned at the bottom of this much-too-long-so-my-apologies post. SuperLH has an awkwardly large number of states already, and adding even more extra states at the end will make the no-trail ON states a lot harder for me to use.
My original plan was to have the Extended Life and extensions cells be built into SuperLH (or LifeSuper as it's now called) by default, with a link to a subpage at the very top of the rule table, linking to an identically named version of LifeSuper which doesn't have any of the extended cells, intended for use by anyone who utilises the rule for such large-scale constructions and wouldn't find the extended states useful. With it being identically named patterns from the no-extended version of it would be compatible with the extended version, without having to go to the hassle of changing the rule in the RLE in the post or using the lifeviewer change rule function. Although, having typed this out, I don't think I quite see the point of that anymore.
dvgrn wrote:
January 27th, 2020, 1:07 pm
So I've created a new rule name for your planned combination of Extended Life and SuperLH. It's currently called "LifeUltra", because Chris Rowett has pointed out that this kind of thing is theoretically supportable across a large rulespace, if the rule name consists of a known alias plus some distinctive suffix. LifeViewer already does this for arbitrary {rule name}History rules.

So I'm currently moving SuperLH to a name that works that way, "LifeSuper". Will try to get people using that and deprecate "SuperLH", though it should continue to work as an alias.
Where was this mentioned?

I, for one, would absolutely LOVE to see LifeViewer officially supporting general LifeSuper/LifeUltra rules for as far as it can currently go with [R]History. (I had actually suggested general ExtendedLife support about a month ago, and since then had been thinking about some way to merge ExtendedLife and its extensions into [R]History as to allow for general support of these new states across rulespaces while still reaping the benefits of existing LifeHistory functionality.)

If LifeSuper (or LifeUltra) were declared the new, officially recognised (or at least agreed-on) successor to LifeHistory, the viewer could simply have all of these cell states added to it by default, potentially even collapsing down any existing ExtendedLife, extendedlifefancy and StateInvestigator patterns down to the new LifeHistory spec and running them as such, allowing for never-before-seen levels of dexterity in pattern exploration...

...but that's just my imagination, and will probably never happen.

It might be a tad confusing, but perhaps let's lay down some preliminary definitions just in case: the specification for the rule tables could be LifeSuper and LifeUltra for your extensions and Extended Life cells respectively, and when run by LifeViewer, both of these would be converted to a rule called LifeHistory, which would have all the cells of LifeUltra. For copying out of LifeViewer, there could be three copy buttons: one to copy exclusively classic LifeHistory cells, one for only LifeSuper cells, and one for the whole LifeUltra experience. Again this is all thinking ahead for a situation that might not ever happen, but if anyone has anything they want to add do feel welcome.
Bored of using the Moore neighbourhood for everything? Introducing the Range-2 von Neumann isotropic non-totalistic rulespace!

User avatar
dvgrn
Moderator
Posts: 6734
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: LifeSuper rule

Post by dvgrn » January 27th, 2020, 3:33 pm

muzik wrote:
January 27th, 2020, 2:09 pm
My original plan was to have the Extended Life and extensions cells be built into SuperLH (or LifeSuper as it's now called) by default, with a link to a subpage at the very top of the rule table, linking to an identically named version of LifeSuper which doesn't have any of the extended cells, intended for use by anyone who utilises the rule for such large-scale constructions and wouldn't find the extended states useful. With it being identically named patterns from the no-extended version of it would be compatible with the extended version, without having to go to the hassle of changing the rule in the RLE in the post or using the lifeviewer change rule function.
I think I see where you're coming from, but that particular solution scares me quite a bit.

My past experience says that Horrible Things Happen fairly reliably whenever two different rules are given the same name -- especially two rules with different numbers of states. The Golly error messages are huge and hideous if a pattern has more states than (your version of) the rule is supposed to have, and you end up not being able to open the pattern at all.

Now, we should probably fix Golly so that there's a convenient option to open the pattern and collapse the illegal states down to the highest legal state, or something like that, but that's another feature request for another day (or year). Right now the workaround is to just use regular Ctrl+V starting from an empty universe set to the rule that you want to convert to (instead of attempting Ctrl+Shift+O).
muzik wrote:
January 27th, 2020, 2:09 pm
dvgrn wrote:
January 27th, 2020, 1:07 pm
Chris Rowett has pointed out that this kind of thing is theoretically supportable across a large rulespace...
Where was this mentioned?
On a Google Hangout this morning... just your usual dastardly behind-the-scenes plotting session, nothing to see here, move along --
muzik wrote:
January 27th, 2020, 2:09 pm
I, for one, would absolutely LOVE to see LifeViewer officially supporting general LifeSuper/LifeUltra rules for as far as it can currently go with [R]History. (I had actually suggested general ExtendedLife support about a month ago, and since then had been thinking about some way to merge ExtendedLife and its extensions into [R]History as to allow for general support of these new states across rulespaces while still reaping the benefits of existing LifeHistory functionality.)
It's not entirely clear yet how generalizable LifeSuper or LifeUltra will end up being across larger rulespaces -- especially since LifeUltra doesn't really exist yet! It seems possible that [arbitrary-rule]Super will be quite a bit easier to support than [arbitrary-rule]Ultra, just because a Super rule is really just plain-vanilla-rule with lots of colors on top -- well, except for those dratted gray cells, but that's an old LifeHistory embarrassment. The proposed new ExtendedLife states can actually make a pattern's ON and OFF cells behave very differently from what they'd do in the plain-vanilla rule, so that adds some complexity.
muzik wrote:
January 27th, 2020, 2:09 pm
If LifeSuper (or LifeUltra) were declared the new, officially recognised (or at least agreed-on) successor to LifeHistory...
Well, I've long ago given up on trying to get anything declared to be Officially Recognized. That just makes people want to argue about details, and add more stuff, and take out stuff they don't like, and so on. So now I just build things that I like, or try to help other people build them ... and then a few years later if lots of people are using something, then that means that when nobody was looking it must have sneakily acquired its Officially Recognized Seal of Approval.

muzik
Posts: 3786
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: LifeSuper rule

Post by muzik » January 27th, 2020, 4:33 pm

dvgrn wrote:
January 27th, 2020, 3:33 pm
muzik wrote:
January 27th, 2020, 2:09 pm
I, for one, would absolutely LOVE to see LifeViewer officially supporting general LifeSuper/LifeUltra rules for as far as it can currently go with [R]History. (I had actually suggested general ExtendedLife support about a month ago, and since then had been thinking about some way to merge ExtendedLife and its extensions into [R]History as to allow for general support of these new states across rulespaces while still reaping the benefits of existing LifeHistory functionality.)
It's not entirely clear yet how generalizable LifeSuper or LifeUltra will end up being across larger rulespaces -- especially since LifeUltra doesn't really exist yet! It seems possible that [arbitrary-rule]Super will be quite a bit easier to support than [arbitrary-rule]Ultra, just because a Super rule is really just plain-vanilla-rule with lots of colors on top -- well, except for those dratted gray cells, but that's an old LifeHistory embarrassment. The proposed new ExtendedLife states can actually make a pattern's ON and OFF cells behave very differently from what they'd do in the plain-vanilla rule, so that adds some complexity.
For now I suppose the logical thing to do would be to look at the rule families LifeViewer currently supports [R]History for, which appears to be outer-totalistic, isotropic non-totalistic, non-isotropic, and alternating versions of these:

Code: Select all

x = 11, y = 10, rule = alternlifeHistory
D2.D2$3.D5$7.E2.E2$10.E!
[[ STOP 476 ]]

Code: Select all

x = 3, y = 9, rule = 2CellSlugHistory
D.D4$E.E4$D.D!
[[ STOP 44 ]]
This narrows the rules we have to deal with down to a rather manageable subset. (It seems as though [R]History support isn't yet implemented for HROT nor Margolus, which seems odd given they're two-state, but I suppose that means we don't have to deal with as much cases right now.) For these rules I don't think there should be too many issues with implementing the ExtendedLife cell states, as they only affect the cells directly adjacent to them (or one cell further in the case of how triangular rules are simulated).

The only real problem I can see would be with B0 rules, as the new states may work differently with simulations of "true" B0 as opposed to an equivalent alternating rule that simulates that B0 rule. I'm sure that shouldn't be awful to figure out but it's something to consider. Otherwise, from what I can see, ExtendedLife should generalise across all LifeHistory-supported rulespaces nicely. And if any major issues do show up - implement Super, ask questions about Ultra later. Seems like a good idea to me.

Of course, there's other problems that will need to be dealt with if LifeViewer supports general LifeSuper in the future. We may need to make states 1, 9 and 11, alongside their trails 2, 10 and 12, use 32 longevity/history states as opposed to the usual 64, and having no-trail states simply not age at all, in order to keep the characteristic fading effect but still leaving enough space for in this case up to 64 more cell states to exist, which should accommodate our 26/35 nicely.
dvgrn wrote:
January 27th, 2020, 3:33 pm
muzik wrote:
January 27th, 2020, 2:09 pm
If LifeSuper (or LifeUltra) were declared the new, officially recognised (or at least agreed-on) successor to LifeHistory...
Well, I've long ago given up on trying to get anything declared to be Officially Recognized. That just makes people want to argue about details, and add more stuff, and take out stuff they don't like, and so on. So now I just build things that I like, or try to help other people build them ... and then a few years later if lots of people are using something, then that means that when nobody was looking it must have sneakily acquired its Officially Recognized Seal of Approval.
I'd like to think that the community in its current state is sufficiently small such that any glaring issues anyone finds with LifeSuper will be swiftly reported here, but of course we'd need people to actually have experience with using the rule in order to make informed comments about it. Does anyone have any ideas for ways to promote LifeSuper to the rest of the community to gather opinions?
Bored of using the Moore neighbourhood for everything? Introducing the Range-2 von Neumann isotropic non-totalistic rulespace!

muzik
Posts: 3786
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: LifeSuper rule

Post by muzik » January 27th, 2020, 4:50 pm

Some colour changes I've made to some states. Do these work, or are they godawful?

Also, yes, state 3 behaviour does need fixing so we don't get blue on the input side.

Code: Select all

x = 18, y = 15, rule = LifeSuper
14.E$14.E.E$14.2E2$10.C$10.C.C$10.2C2$6.A8.M$6.A.A6.M.M$6.2A7.2M4$4H
5.4D!
Bored of using the Moore neighbourhood for everything? Introducing the Range-2 von Neumann isotropic non-totalistic rulespace!

User avatar
dvgrn
Moderator
Posts: 6734
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: LifeSuper rule

Post by dvgrn » January 27th, 2020, 5:36 pm

muzik wrote:
January 27th, 2020, 4:50 pm
Some colour changes I've made to some states. Do these work, or are they godawful?
Not sure yet. The colors you've chosen are probably nicer to look at than the horrible flat clash-y colors from LifeHistory.

On the other hand, my first reaction was definitely super confusion. Seems like there's a good argument for keeping states 3 through 6 the same color as they are in LifeHistory, because that way, people can easily guess from looking at them that they're LifeHistory states 3 through 6. If you just pick new totally colors and there's no commonality, you can't guess any of the functionality until you've memorized a whole new set of colors. That might not be necessary -- red could just stay a (reasonably similar shade of) red.

That said, I don't see a problem with trying out different color schemes for a while. That's especially for states 1 and 2 -- because it's also good to be able to tell at a glance that the pattern is LifeSuper and not LifeHistory! Changing states 1 and 2 so they're different but maybe still recognizable (as you have) seems like a good way to do that.

I'm most interested in coming up with a set of maximally distinct colors for the seven no-trail ON states. Then the three with-trail pairs of states are second priority, but those are already fine as far as I'm concerned. The no-trail boundary marker states (ON and OFF) should probably be something different, but I"m not sure what; maybe a darker color for the no-trail OFF, just so it can be used to mark the target object of a synthesis, while still making it easy to see a partially constructed intermediate state that overlaps that target. (?)
muzik wrote:
January 27th, 2020, 4:50 pm
Also, yes, state 3 behaviour does need fixing so we don't get blue on the input side.

Code: Select all

x = 18, y = 15, rule = LifeSuper
14.E$14.E.E$14.2E2$10.C$10.C.C$10.2C2$6.A8.M$6.A.A6.M.M$6.2A7.2M4$4H
5.4D!
A no-trail glider hitting state 4 is a particular case of "no-trail cells touching with-trail cells". When that happens, because the parents aren't all the same color or type, the new cell drops back to the standard state-1 Life cell.

If you don't like seeing those state-2 cells on the input side of the state-4 wall, the workaround is to line the input side of the wall with state 8:

Code: Select all

x = 18, y = 15, rule = LifeSuper
14.E$14.E.E$14.2E2$10.C$10.C.C$10.2C2$6.A8.M$6.A.A6.M.M$6.2A7.2M3$10.
4H$4H5.4D!
Fixing this by adding special cases to the rule looks potentially ugly, and maybe not generalizable very cleanly to other [R]Super or [R]Ultra rules. I'm not sure it's worth doing. What do you think? I haven't tried really hard to work out the required changes, because of the above workaround. Maybe it's only about four more rule lines, come to think of it.

muzik
Posts: 3786
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: LifeSuper rule

Post by muzik » January 27th, 2020, 5:51 pm

dvgrn wrote:
January 27th, 2020, 5:36 pm
muzik wrote:
January 27th, 2020, 4:50 pm
Also, yes, state 3 behaviour does need fixing so we don't get blue on the input side.

Code: Select all

x = 18, y = 15, rule = LifeSuper
14.E$14.E.E$14.2E2$10.C$10.C.C$10.2C2$6.A8.M$6.A.A6.M.M$6.2A7.2M4$4H
5.4D!
A no-trail glider hitting state 4 is a particular case of "no-trail cells touching with-trail cells". When that happens, because the parents aren't all the same color or type, the new cell drops back to the standard state-1 Life cell.

If you don't like seeing those state-2 cells on the input side of the state-4 wall, the workaround is to line the input side of the wall with state 8:

Code: Select all

x = 18, y = 15, rule = LifeSuper
14.E$14.E.E$14.2E2$10.C$10.C.C$10.2C2$6.A8.M$6.A.A6.M.M$6.2A7.2M3$10.
4H$4H5.4D!
Fixing this by adding special cases to the rule looks potentially ugly, and maybe not generalizable very cleanly to other [R]Super or [R]Ultra rules. I'm not sure it's worth doing. What do you think? I haven't tried really hard to work out the required changes, because of the above workaround. Maybe it's only about four more rule lines, come to think of it.
I'd assume that if a cell is eligible to be born, and its valid neighbours are state 3 cells and some other Life cell with or without a trail, it should assume the state of the "some other Life cell". If there is more than one distinct type of "some other Life cell", just make the birth a state 1. Should work from my understanding.

Also, state 5 can be safely treated as state 3 for these cases.
Bored of using the Moore neighbourhood for everything? Introducing the Range-2 von Neumann isotropic non-totalistic rulespace!

muzik
Posts: 3786
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: LifeSuper rule

Post by muzik » January 27th, 2020, 6:03 pm

dvgrn wrote:
January 27th, 2020, 5:36 pm
muzik wrote:
January 27th, 2020, 4:50 pm
Some colour changes I've made to some states. Do these work, or are they godawful?
Not sure yet. The colors you've chosen are probably nicer to look at than the horrible flat clash-y colors from LifeHistory.

On the other hand, my first reaction was definitely super confusion. Seems like there's a good argument for keeping states 3 through 6 the same color as they are in LifeHistory, because that way, people can easily guess from looking at them that they're LifeHistory states 3 through 6. If you just pick new totally colors and there's no commonality, you can't guess any of the functionality until you've memorized a whole new set of colors. That might not be necessary -- red could just stay a (reasonably similar shade of) red.

That said, I don't see a problem with trying out different color schemes for a while. That's especially for states 1 and 2 -- because it's also good to be able to tell at a glance that the pattern is LifeSuper and not LifeHistory! Changing states 1 and 2 so they're different but maybe still recognizable (as you have) seems like a good way to do that.

I'm most interested in coming up with a set of maximally distinct colors for the seven no-trail ON states. Then the three with-trail pairs of states are second priority, but those are already fine as far as I'm concerned. The no-trail boundary marker states (ON and OFF) should probably be something different, but I"m not sure what; maybe a darker color for the no-trail OFF, just so it can be used to mark the target object of a synthesis, while still making it easy to see a partially constructed intermediate state that overlaps that target. (?)
I changed state 4 to a dark cyan as to look more like state 1. Since we have a cell state for changing a trail Life state to a no trail Life state, and it has roughly the same colour as the state it turns it into, I decided making state 4 do the same made more sense. If people agree it's fugly and an absolutely awful change then I can definitely undo it, but I figured keeping the scheme somewhat consistent was an interesting idea to propose at least.

My main reason for changing the main alive state to cyan was to more closely mimic LifeViewer's default blues theme, so that if this does become the standard version of LifeHistory the community uses, LifeViewer can use the Blues theme on LifeHistory patterns from now on (with the old LifeHistory theme kept for legacy purposes so we can still experience the good old days). The other trail state colours are based on my proposals for 3-state outer-totalistic rule support (which LifeHistory should not apply to, for now).

As for state 5, this is the one I'm least certain of, and is most subject to change, since it does look quite out of order.

Defining sufficiently distinct extra Life states is definitely next on the list of things to do, so we can reach a solid LifeSuper base for developing LifeUltra on top of.
Bored of using the Moore neighbourhood for everything? Introducing the Range-2 von Neumann isotropic non-totalistic rulespace!

User avatar
dvgrn
Moderator
Posts: 6734
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: LifeSuper rule

Post by dvgrn » January 27th, 2020, 7:29 pm

muzik wrote:
January 27th, 2020, 5:51 pm
I'd assume that if a cell is eligible to be born, and its valid neighbours are state 3 cells and some other Life cell with or without a trail, it should assume the state of the "some other Life cell". If there is more than one distinct type of "some other Life cell", just make the birth a state 1.
On second look, I can improve things somewhat, but there are some cases where there's no possible way the rule could know locally what color to use. So some escape of state 1 to the wrong side of the line is inevitable. Lining the border with state 8 is definitely the way to go here:

Code: Select all

x = 144, y = 43, rule = LifeSuper
6$31.M5.M43.M5.M43.M5.M$30.M5.2M42.M5.2M42.M5.2M$30.M3.M45.M3.M45.M3.
M$31.M4.M44.M4.M44.M4.M$31.M8.2M39.M8.2M39.M8.2M$27.2M3.M5.M.M36.2M3.
M5.M.M36.2M3.M5.M.M$26.M2.M4.2M40.M2.M4.2M40.M2.M4.2M$25.M5.M3.M3.M
35.M5.M3.M3.M35.M5.M3.M3.M$18.2M4.M.M4.2M35.2M4.M.M4.2M35.2M4.M.M4.2M
$18.2M6.M6.M2.M31.2M6.M6.M2.M31.2M6.M6.M2.M$22.M3.M6.2M2.2M2.M30.M3.M
6.2M2.2M2.M30.M3.M6.2M2.2M2.M$16.M4.M2.2M13.2M25.M4.M2.2M13.2M25.M4.M
2.2M13.2M$5.2D9.M.M.2M13.M30.M.M.2M13.M30.M.M.2M13.M$6.2D8.2M2.M.M13.
M29.2M2.M.M13.M29.2M2.M.M13.M$7.2D27.M49.M49.M$8.2D21.3M.M45.3M.M45.
3M.M$9.2D19.M3.M45.M3.M45.M3.M$10.2D18.M2.M46.M2.M46.M2.M$11.2D$12.2D
14.M2.M46.M2.M46.M2.M$13.2D14.2M48.2M48.2M$14.2D12.2M48.2M48.2M$15.2D
15.2M48.2M48.2M$16.2D11.M2.2M45.M2.2M45.M2.2M$17.2D9.M49.M49.M$18.2D
8.3M47.3M47.3M$19.2D$20.2D$21.2D$22.2D$23.2D65.47H$24.120D!
(Will post the somewhat-improved rule later.)

muzik
Posts: 3786
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: LifeSuper rule

Post by muzik » January 27th, 2020, 8:48 pm

Some colour ideas for the no-history states:

Code: Select all

x = 61, y = 7, rule = LifeSuper
D34.H11.C2.C6.E2.E$D34.H10.C9.E$D34.H10.C3.C5.E3.E$D34.H10.4C6.4E$D3.
O4.Q4.S4.U4.W4.pA5.H$4.O.O2.Q.Q2.S.S2.U.U2.W.W2.pA.pA$4.2O3.2Q3.2S3.
2U3.2W3.2pA!
Also, I would add the LifeUltra states, but I don't have sufficient knowledge of rule tables to effectively do so, and also I have important work to be catching up with, so here's the updated specification should anyone desire to implement the states:

State 26: Blocker (state 5 in extendedlife, extendedlifefancy and stateinvestigator)
State 27: Reactor (state 6 in extendedlife and extendedlifefancy and state 4 in stateinvestigator)
State 28: Catalyst (identical to Reactor but 3 of these cells alone cannot birth new cells)
State 29: On-deathforcer (state 8 in extendedlifefancy and state 2 in stateinvestigator)
State 30: On-birthforcer (state 2 in extendedlifefancy)
State 31: Off-birthforcer (state 2 in extendedlife and state 7 in extendedlifefancy)
State 32: Birthforcer-deathforcer (state 4 in extendedlife and extendedlifefancy)
State 33: p2 killer on cell (state 6 in stateinvestigator)
State 34: p2 killer off cell (state 7 in stateinvestigator)
Bored of using the Moore neighbourhood for everything? Introducing the Range-2 von Neumann isotropic non-totalistic rulespace!

JP21
Posts: 1003
Joined: October 26th, 2019, 5:39 am
Location: PH

Re: SuperLH rule

Post by JP21 » January 28th, 2020, 5:04 am

JP21 wrote:
January 27th, 2020, 10:09 am
There is only one reason why I am here... this.
Wow, this is a recent rule and it is great. Does anybody think this rule will spread throughout the entire forum?
Here is something (took 30 minutes) (Edit: Maybe 1 hour and 15 minutes after seeing the last post):

Code: Select all

x = 135, y = 68, rule = SuperLH
45.90F12$33.90H12$21.90D6$15.90X2$13.90V2$11.90T2$9.90R2$7.90P2$5.90L
2$3.90J2$.90B3$3C.3E6$4.3K2.3I2.3A$6.K4.I4.A$5.K4.I4.A4$4.3W2.3U2.3S
2.3Q2.3pA2.3O$6.W4.U4.S4.Q4.pA4.O$5.M4.M4.M4.M4.M4.M4$4.3K2.3I2.3pA2.
3W2.3U2.3S2.3Q2.3pA2.3O$6.K4.I4.pA4.W4.U4.S4.Q4.pA4.O$5.A4.A4.A4.A4.A
4.A4.A4.A4.A!
The rule isn't SuperLH anymore you stupid.
Why the name of the rule keeps being changed?
A 13 year old guy that have useless discoveries about life and other rules.

Code: Select all

x = 13, y = 20, rule = B3/S23
11b2o$11b2o4$8b2o$8b2o2$2o$2o3$3b2o$3b2o2$11b2o$10b2o$12bo$3b2o$3b2o!

User avatar
Entity Valkyrie 2
Posts: 549
Joined: February 26th, 2019, 7:13 pm
Location: Hijuatl, Zumaland
Contact:

Re: LifeSuper rule

Post by Entity Valkyrie 2 » January 28th, 2020, 7:03 am

By the way, please update Rule:StateInvestigator (This is v2.1):

Code: Select all

@RULE StateInvestigator
@TABLE
n_states:17
neighborhood:Moore
symmetries:permute

var a1 = {1,2,4,6,8,10,12,15,16}
var a2 = {1,2,4,6,8,10,12,15,16}
var a3 = {1,2,4,6,8,10,12,15,16}
var a4 = {1,2,4,6,8,10,12,15,16}
var b1 = {0,3,5,7,9,11,13}
var b2 = {0,3,5,7,9,11,13}
var b3 = {0,3,5,7,9,11,13}
var b4 = {0,3,5,7,9,11,13}
var b5 = {0,3,5,7,9,11,13}
var b6 = {0,3,5,7,9,11,13}
var b7 = {0,3,5,7,9,11,13}
var c1 = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16}
var c2 = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16}
var c3 = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16}
var c4 = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16}
var c5 = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16}
var c6 = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16}
var c7 = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16}
var c8 = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16}
var d1 = {2,3,6,7,14,16}
var d2 = {8,9,12,13,14}
var e1 = {1,2,4,6,8,10,12}
var e2 = {1,2,4,6,8,10,12}
var e3 = {1,2,4,6,8,10,12}


0, 1,a1,a2,b1,b2,b3,b4,b5, 1
0, e1,e2,e3,b1,b2,b3,b4,b5, 1
1, c1,b1,b2,b3,b4,b5,b6,b7, 0
1, a1,a2,a3,a4,c1,c2,c3,c4, 0


1, d1,c1,c2,c3,c4,c5,c6,c7, 0
0, d2,c1,c2,c3,c4,c5,c6,c7, 1


6, c1,c2,c3,c4,c5,c6,c7,c8, 7
7, c1,c2,c3,c4,c5,c6,c7,c8, 6
10, c1,c2,c3,c4,c5,c6,c7,c8, 11
11, c1,c2,c3,c4,c5,c6,c7,c8, 10
12, c1,c2,c3,c4,c5,c6,c7,c8, 13
13, c1,c2,c3,c4,c5,c6,c7,c8, 12

@COLORS
1    0  236   91
2    0  192  254
3  254    0    0
4  254  254  254
5   75   75   75
6  254    0  254
7   64    0  128
8  254  230    0
9  128   128 0
10 130  200    0
11   0  120   40
12 254  140    0  
13 140   70    0
14   0    0  254  
15 192  192  192
16 128  128  128



8 egg on
9 egg off
10 11 p2 on off
12 13 p2 egg
14 inverter
15 catalyst
16 catalyst killer

After this update, StateInvestigator is oficially bigger than ExtendedLifeFancy.
Last edited by Entity Valkyrie 2 on January 28th, 2020, 8:00 pm, edited 3 times in total.
The ENEERG-y of the EVAD is watching.
The 70th NAI-ve guy is watching.

Please click here for my own pages.

Also, please apgsearch B34t5y7/S23 (B-life)

Post Reply