ConwayLife.com

Posted: **April 8th, 2025, 3:44 pm**

Vlev2 wrote: April 8th, 2025, 3:26 pm i have finally achieved my FIRST MULTISTATE RULE :D

Looks good! What does that top line of LifeViewer scripting commands do for you? It just causes errors to be shown for me, when I pull up LifeViewer.

You'll be able to simplify that rule table by quite a lot, I think, as confocaloid has mentioned at the bottom of the previous page of this thread.

Here's another suggestion to help get you more familiar with how ruletables work. Now that you've got it working, try removing all of the transition-table lines that end in "0", like

Code: Select all

1, 0,0,0,0,0,0,0,0, 0

That specific case, and all of the others ending in "0", should get caught perfectly well by the later "catch-all" transition-table line

Code: Select all

a1, a2,a3,a4,a5,a6,a7,a8,a9, 0

You've got maybe a little bit of confusion about using "a1" as if it means "state 1" and "a2" as if it means "state 2", down in those last few catch-all lines. Both "a1" and "a2" actually just mean "any valid state, independent of each other". Those nine variables could equally well be renamed to just plain "a" through "i", or "r" through "z" or whatever you want; the numbers don't mean anything that has to do with specific state values.

Here's a previous rule-building request that might be worth working through in combination with the LifeWiki rule-building tutorial. It starts with a non-working ruletable definition, and with careful analysis you can follow the progress as issues get fixed, until it finishes with a fairly standard form. For example, it follows the very common pattern that variables are all defined first, followed by transition table lines, grouped together with comments where possible for better readability.

Posted: **April 8th, 2025, 4:31 pm**

Sometimes there can be indication of something not working as intended, even if it's unknown how it was intended to work. (For example, two lines that are different as character strings, but defining the same rule.)

(The ruletable format *could* be more user-friendly for beginners. On the other hand, to me at least, existing attempts to create a better format appear to be steps in the wrong direction. Remarkably complicated behaviour/dynamics can be determined by rules expressed in a simple intuitive way, and of course this is a large part of what makes cellular automata interesting. Making the definitions more and more esoteric seems to me to be a mistake.)

In the event you have enough time and enough curiosity, I believe it's worth writing down all of the update rules you have in mind explicitly, in a human-readable way, for example like this:

if a state-0 cell has precisely three state-1 neighbours and no state-2 neighbours, then the cell will become state-1 in the next generation,
otherwise, if a state-1 cell has eight state-1 neighbours, then the cell will become state-2 in the next generation,
otherwise, if a state-0 cell has precisely three state-2 neighbours and no state-1 neighbours, then the cell will become state-2 in the next generation,
otherwise, ...

(You could find a simpler way to express the same rules; the important part is that it must remain human-readable and human-understandable.)

When written in this form, each of those "if-then" rules can later become a single line in the ruletable. Some of advantages are that

it would likely help you to understand better the idea you have in mind (and possibly simplify it into fewer rules, using variables or otherwise),
it would be easier to explain to other people "how the CA works", by putting the human-readable version in the comments:

Code: Select all

# If a state-0 cell has precisely three state-1 neighbours and no state-2 neighbours, then the cell will become state-1 in the next generation
# If a state-0 cell has precisely three state-2 neighbours and no state-1 neighbours, then the cell will become state-2 in the next generation
0, 1,1,1,0,0,0,0,0, 1
0, 2,2,2,0,0,0,0,0, 2
# If a state-1 cell has eight state-1 neighbours, then the cell will become state-2 in the next generation,
1, 1,1,1,1,1,1,1,1, 2
# ...

Posted: **April 12th, 2025, 12:37 am**

Citation needed wrote: April 12th, 2025, 12:04 am
confocaloid wrote: April 11th, 2025, 9:09 pm [...] Thou shalt not cause Paradoxes by changing transitions in specific Spacetime points. [...]
As far as I know, this can be done without LifeViewer commands. Please see below. [...]

The problem is doing that reliably and efficiently, for an arbitrary finite input.

Suppose you have some finite "sequence of frames" that you would like to capture. All "frames" are the same size. Each "frame" is a rectangle with W columns and H rows. There are (T+1) such "frames". Inside the "frame", every cell is either dead (state-0) or alive (state-1). Outside the "frame", every cell is dead (state-0).

The problem is to find

a cellular automaton A with N cellstates 0, 1, ..., N - 1 defined using the (range-1) Moore neighbourhood,
an initial configuration P (of the cellular automaton A), with finitely many nonzero cells,
and a function f from the set of cellstates of A to the set {0,1},
Code: Select all
```
f : {0, 1, ..., N-1} => {0,1}
f(0) = 0
f(1) = 1
```

such that the given sequence of "two-state frames" is reproduced exactly by evolving the configuration P for T ticks according to the rules of the cellular automaton A, and replacing every cellstate x by f(x) in every resulting generation 0, 1, ..., T.

What could be an algorithm to do that? (Assume W > 0, H > 0, T > 0)
What could be an algorithm to do that, if the cellular automaton A is required to be isotropic?
What could be an algorithm to do that with as few cellstates as possible?

Posted: **April 12th, 2025, 3:42 am**

dvgrn wrote: April 8th, 2025, 3:44 pm Looks good! What does that top line of LifeViewer scripting commands do for you? It just causes errors to be shown for me, when I pull up LifeViewer.

Those commands are appended in LifeViewer embedded in ConwayLife homepage. I hate how "Clear LifeViewer" leave those scripting commands that no newcomers could understand and leave it there.

Posted: **April 12th, 2025, 5:34 am**

b-engine wrote: April 12th, 2025, 3:42 am Those commands are appended in LifeViewer embedded in ConwayLife homepage. I hate how "Clear LifeViewer" leave those scripting commands that no newcomers could understand and leave it there.

Ah, thanks! That's why I've never seen them. It seems I've actually never used "Clear LifeViewer". I've always gone to "Show Advanced Options" and pasted in whatever RLE I wanted to work with.

Ctrl+Shift+O would be a somewhat faster way to do the same thing -- hadn't thought of that. That doesn't really address the "newcomers" use case, of course, but if "Clear LifeViewer" is used without "Show Advanced Options", the custom color commands only show up when RLE is actually copied out to be used elsewhere. If you do use "Show Advanced Options", you can delete out those extra commands pretty quickly, and then update.

Oddly enough, Life32 and Golly both also have a mode where RLE is generated with an extra often-unwanted header line. Must be a tradition!

Posted: **April 12th, 2025, 6:42 am**

This is an active region that could be catalyzed by a beehive push catalyst:

Code: Select all

x = 6, y = 11, rule = B3/S23
4bo$3bobo$3bobo$4bo3$b2o$o2b2o$bob2o$bo3bo$b4o!

However all beehive push catalysts mentioned in LifeWiki doesn't work with this thing. Is there anything that could work?

Posted: **April 12th, 2025, 11:59 am**

b-engine wrote: April 12th, 2025, 6:42 am [...] Is there anything that could work?

While this wouldn't count as a catalyst, it would count as "anything":

Code: Select all

x = 36, y = 25, rule = B3/S23
4bo$3bobo$2bo3bo$2bo3bo$2bo3bo22b4o$2bo3bo22bo3bo$2bo3bo22bob2o$2bo3bo
21bo2b2o$3bobo23b2o$4bo3$32bo$30b2obo$4bo25b2ob2o$3bobo23b3ob2o$3bobo
23b2o$4bo23b2o$28bobo$29b2o2b2o$b2o28bo3bo$o2b2o26bo$bob2o27b3o$bo3bo$
b4o!

Depending on what is the use (i.e. what is the bigger pattern that would contain the interaction), a pentadecathlon pushing the beehive back or a second instance of the same interaction "from the other side" might work.

Posted: **April 20th, 2025, 1:19 am**

Does there exist a CGoL simulator in bf?

Posted: **April 20th, 2025, 4:44 pm**

For a given speed above c/2 orthogonal or c/4 diagonal, how far can a pattern fitting within an MxN box travel "above" that speed? For example, is the limit for a 10x10 box and c orthogonal 10 cells, or could one make something which travels farther than 10 cells at c orthogonal before slowing down that fits in that region?

Posted: **April 21st, 2025, 3:47 am**

LuveelVoom wrote: April 20th, 2025, 4:44 pm For a given speed above c/2 orthogonal or c/4 diagonal, how far can a pattern fitting within an MxN box travel "above" that speed? For example, is the limit for a 10x10 box and c orthogonal 10 cells, or could one make something which travels farther than 10 cells at c orthogonal before slowing down that fits in that region?

It sounds like you would need to (re)define "travel" to clarify the question, and that would probably lead to an overly generous definition of travel.

Maybe "how far can a pattern reach" would work better.

Can you provide an explicit example for the second sentence? So far, I can't seem to find anything that would count as "5 cells" or more:

Code: Select all

x = 10, y = 10, rule = B3/S23
10o$obo4bobo$10o$obob2obobo$ob6obo$ob6obo$obob2obobo$10o$obo4bobo$10o!

Posted: **April 21st, 2025, 5:24 am**

LuveelVoom wrote: April 20th, 2025, 4:44 pm For a given speed above c/2 orthogonal or c/4 diagonal, how far can a pattern fitting within an MxN box travel "above" that speed? For example, is the limit for a 10x10 box and c orthogonal 10 cells, or could one make something which travels farther than 10 cells at c orthogonal before slowing down that fits in that region?

Mostly Mc/M or Nc/N, depending on which is larger, M or N.

Posted: **April 27th, 2025, 4:32 pm**

I am making my third ever multistate rule table using the von neumann neighborhood called Vlev2_Test_3
The rule is used to simulate sand and water physics.
but i ask a question.
how do i make it so water and sand moves orthogonally downward? [basically gravity]
and does it require extra cellstates above the water or sand?

Posted: **April 27th, 2025, 8:49 pm**

Vlev2 wrote: April 27th, 2025, 4:32 pm I am making my third ever multistate rule table using the von neumann neighborhood called Vlev2_Test_3
The rule is used to simulate sand and water physics.
but i ask a question.
how do i make it so water and sand moves orthogonally downward? [basically gravity]
and does it require extra cellstates above the water or sand?

That would depend on details (how you want it to work, interactions, etc. etc.)
but here is one possibility. This uses

Code: Select all

symmetries:reflect_horizontal

because what you wrote so far only requires distinguishing "up" from "down". In general, if you want to do something more complicated (e.g. distinguishing "left" from "right"), you might need "symmetries:none". See this page for which symmetry types are supported:
https://github.com/GollyGang/ruletabler ... cd0f768208

Here is a demo. The .rule file content is appended after the pattern data; look for the header line "@RULE Testing210752" in the code snippet below.

Lines beginning with '#' are just comments, they don't affect how things work.

Code: Select all

#C [[ GRID ]]
x = 13, y = 22, rule = Testing210752
11.C2$10.C$11.C2$11.D$12.C$10.D$11.C2$10.CD2$11.CD$10.C$11.D$12.D4$.A
9.B$2.A9.B$3A7.3B!

@RULE Testing210752

See discussion around https://conwaylife.com/forums/viewtopic.php?p=210752#p210752

@NAMES
1 something
2 ground
3 sand
4 water

@TABLE
n_states:5
neighborhood:vonNeumann
symmetries:reflect_horizontal

var sand_or_water={3,4}
var x={0,1,2,3,4}
var x1=x
var x2=x
var x3=x
var x4=x

# The following rule says that, if there is empty space (cellstate 0)
# below a "sand" or "water" cell, then the cell will change to state 0:
sand_or_water,  x1,x2, 0,x4,  0

# The following rule says that, in all other cases,
# a "sand" or "water" cell will remain unchanged:
sand_or_water,  x1,x2,x3,x4,  sand_or_water

# The following rule says that, if there is "sand" (cellstate 3) or "water" (cellstate 4)
# above an empty cell (cellstate 0), then the empty cell will change to the state
# of the cell above it:
0,  sand_or_water,x2,x3,x4,  sand_or_water

# The following rule says that a "ground" cell (cellstate 2)
# never changes no matter what:
2,  x1,x2,x3,x4,  2

# The following rule says that,
# in all other conditions not covered by any of the preceding rules,
# every nonzero cell becomes zero, and every zero cell stays zero:
x,  x1,x2,x3,x4,  0

A summary of the rules (extracted from the comments above):

if there is empty space (cellstate 0) below a "sand" or "water" cell, then the cell will change to state 0
in all other cases, a "sand" or "water" cell will remain unchanged
if there is "sand" (cellstate 3) or "water" (cellstate 4) above an empty cell (cellstate 0), then the empty cell will change to the state of the cell above it
a "ground" cell (cellstate 2) never changes no matter what
in all other conditions not covered by any of the preceding rules, every nonzero cell becomes zero, and every zero cell stays zero

Posted: **April 27th, 2025, 9:25 pm**

Vlev2 wrote: April 27th, 2025, 4:32 pm I am making my third ever multistate rule table using the von neumann neighborhood called Vlev2_Test_3
The rule is used to simulate sand and water physics.
but i ask a question.
how do i make it so water and sand moves orthogonally downward? [basically gravity]
and does it require extra cellstates above the water or sand?

Basic implementation:

Code: Select all

x = 18, y = 9, rule = Testet
15.2B$8.2A3.3B.B$4.5A4.B3.B$3.6A4.5B$.5A4.4B2.2B$4A4.A4.3B.B$2.7A5.B2.
B$15.B.B$16.2B!


@RULE Testet
@TABLE
n_states:4
neighborhood:vonNeumann
symmetries:none
var a = {0,1,2,3}
var a1=a
var a2=a
var a3=a

0,1,a,a1,a2,1
1,1,a,a1,a2,1
1,2,a,a1,a2,2
1,0,a,a1,a2,0
0,2,a,a1,a2,2
2,2,a,a1,a2,2
2,1,a,a1,a2,1
2,0,a,a1,a2,0

@COLORS
1 0 0 255
2 255 200 128

Note that this rule is non-isotropic, which makes distinction between rotations.

Posted: **April 29th, 2025, 10:13 am**

hotcrystal0 wrote: April 20th, 2025, 1:19 am Does there exist a CGoL simulator in bf?

This is neither an advanced question, nor is it even really a question about CGoL.
However, there is a simple answer to your question: https://brainfuck.org/life.b

Posted: **May 3rd, 2025, 11:09 pm**

confocaloid wrote: April 12th, 2025, 12:37 am [...] The problem is doing that reliably and efficiently, for an arbitrary finite input.

Suppose you have some finite "sequence of frames" that you would like to capture. [...]

Here is another problem, which could be seen as related. How would you attempt to solve this?

Suppose one would like to know whether or not there exists a finite evolutionary sequence of a certain kind, somewhere in the space of all 2^102 two-state isotropic cellular automata with Moore neighbourhood. The restrictions are expressed by saying which cells are allowed to be alive in some generation of the evolutionary sequence, which cells are allowed to be alive in the initial generation (T = 0), and which cells are allowed to be alive in the final generation.

For instance, I might want to know whether there is a nonempty finite evolutionary sequence such that

in the initial generation, all alive cells must be inside one of two regions marked with LifeHistory state 4 (and at least one cell must be alive),
in the final generation, all alive cells must be inside the other region marked with LifeHistory state 4 (and at least one cell must be alive),
LifeHistory state 0 cells aren't allowed to be alive in any generation of the evolutionary sequence,

in some 2-state isotropic CA with Moore neighbourhood.
The number of ticks of time between the initial generation (T = 0) and the final generation is left unspecified.
There are no "must be alive" cells.

What would be possible ways to attempt to answer such questions?

Code: Select all

x = 178, y = 107, rule = B12345678/S012345678History
115.24B$114.26B$112.29B$111.31B$110.33B$108.35B$108.36B$107.37B$106.
39B$104.41B$104.41B$101.44B$94.52B$92.54B$91.55B$89.57B$88.58B$88.58B
$88.37B3.18B$86.38B4.19B$85.38B6.18B$84.38B7.19B$84.37B9.19B$83.37B
10.20B$83.36B11.21B$83.35B12.22B$82.33B16.21B$82.26B23.23B$82.24B25.
24B$82.23B26.25B$82.21B28.25B$82.21B28.26B$82.21B28.27B$82.20B30.28B$
82.18B32.28B$82.19B32.27B$82.21B30.28B$82.21B32.27B$82.22B32.27B$82.
22B33.26B$82.23B32.26B$82.24B32.25B$82.25B33.23B$82.26B33.22B$82.27B
32.22B$83.26B33.21B$84.26B33.20B$85.25B34.20B$85.26B34.20B$86.26B33.
21B$87.25B34.22B$88.25B34.23B$89.25B34.30D$89.25B34.30D$90.24B34.30D$
91.24B33.30D$31.18B43.23B33.30D$27.24B42.22B33.30D$24.29B41.21B33.30D
$23.31B40.21B33.30D$21.34B40.20B33.30D$19.37B39.20B34.29D$18.39B39.
19B35.28D$17.40B40.18B36.27D$16.42B39.18B37.26D$14.44B40.17B39.24D$
13.45B41.16B41.22D$12.47B39.17B43.19D$11.48B39.17B45.16D$10.49B38.18B
$9.51B36.19B$9.52B35.19B$9.53B34.19B$8.55B32.20B$7.30B2.25B31.20B$6.
29B6.25B28.20B$6.27B8.27B26.20B$5.27B10.27B24.21B$5.26B11.29B21.22B$
5.25B13.30B18.23B$4.24B15.32B15.24B$4.23B16.36B10.24B$3.23B18.43B.25B
$3.22B19.68B$3.21B21.67B$2.22B21.66B$2.22B22.65B$.22B24.63B$.21B26.
62B$.20B29.59B$.20B30.58B$.19B33.55B$19DB35.52B$19DB37.49B$19D40.46B$
19D42.43B$18D47.38B$18D55.29B$18D$17D$17D$16D$16D$16D$16D$16D$15D!

Posted: **May 10th, 2025, 8:18 am**

Is there any glider "guns" that have period smaller than 14? This means that this "gun" could emit glider once, but get destroyed unless the glider is removed beforehand (maybe via eaters).

Posted: **May 10th, 2025, 8:29 am**

b-engine wrote: May 10th, 2025, 8:18 am Is there any glider "guns" that have period smaller than 14? This means that this "gun" could emit glider once, but get destroyed unless the glider is removed beforehand (maybe via eaters).

Previous discussion: viewtopic.php?p=206151#p206151 Re: "p13" "gun"

Posted: **May 10th, 2025, 11:05 pm**

Is there any inverse growing/shrinking spaceship?

An inverse growing/shrinking spaceship is a spaceship that:
The back end creates a puffer that's faster than both the front end and back end.
The puffer catches up the front end while the back end clears up the debris.
The front end destroys the puffer and optionally ignites a fuse.
The backend detects that the debris is no more, then creates another puffer to restart the process.

Such spaceships must be necessarily slower than c/2, as the puffer needs to be faster than the front end.

Posted: **May 11th, 2025, 8:36 am**

b-engine wrote: May 10th, 2025, 11:05 pm Such spaceships must be necessarily slower than c/2, as the puffer needs to be faster than the front end.

This all sounds very similar to the design of the Speed Demonoid and Speed Orthogonal Loopship and so on -- especially the part about "creates another puffer to restart the process". It's probably easiest to do this kind of thing with some kind of escorted single-channel construction recipes.

Posted: **May 11th, 2025, 10:50 am**

dvgrn wrote: May 11th, 2025, 8:36 am This all sounds very similar to the design of the Speed Demonoid and Speed Orthogonal Loopship and so on -- especially the part about "creates another puffer to restart the process". It's probably easiest to do this kind of thing with some kind of escorted single-channel construction recipes.

Sounds like macro-spaceships, but this is actually not close to that.
Whatever I'm talking about is similar to growing/shrinking spaceships, but the front instead of the back ignites the fuse.

Posted: **May 12th, 2025, 7:34 am**

A pattern that emerged naturally, being identified as zz_EXPLOSIVE. Its growth patterns are highly chaotic, and I guess that similar to certain patterns in life, Every cell is alive some time and never becomes periodic.
Can anybody explain?

Code: Select all

x = 16, y = 16, rule = B3-q4w/S2-i34i
5o3b2ob5o$2b5obobo3bo$2bob2o2b2o2bo$2ob4o3b4obo$b2o2b4obobob2o$2bo2b2o
bo2b2o2bo$bo4b2o2b6o$bo2b6obob2o$4bo7bob2o$2b3o3bobobob2o$4b3o3bo2bob
o$b4o2b2o2b3obo$2o3bobo2b2o2b2o$3o3b10o$3b2ob2obo2bobo$4b2o4b2ob3o!

Posted: **May 12th, 2025, 9:07 am**

dl-rs wrote: May 12th, 2025, 7:34 am Every cell is alive some time and never becomes periodic.

I'm not sure this is true. After 200k generations it turns into this highly chaotic mess:

: viewed at scale 2^6:1; 211832_200k.png (204.37 KiB) Viewed 5446 times

Posted: **May 12th, 2025, 9:43 am**

Indeed @wirehead. I got the same result. Can it be proven to be a pattern of the said properties, or Is it that we can't predict its growth conformation?

Posted: **May 12th, 2025, 9:59 am**

dl-rs wrote: May 12th, 2025, 9:43 am Can it be proven to be a pattern of the said properties, or Is it that we can't predict its growth conformation?

I ran it another 100k generations (took forever even using hashlife because of the chaotic), and it looks like the highly messy region in the middle just keeps expanding. There is a very small chance that if run forever, this middle region might turn into a high-period agar, but I think it is too chaotic to really be able to find out.

ConwayLife.com

Thread for advanced questions

Re: Thread for advanced questions

Re: Thread for advanced questions

Re: Thread for advanced questions

Re: Thread for advanced questions

Re: Thread for advanced questions

Re: Thread for advanced questions

Re: Thread for advanced questions

Re: Thread for advanced questions

Re: Thread for advanced questions

Re: Thread for advanced questions

Re: Thread for advanced questions

Re: Thread for advanced questions

Re: Thread for advanced questions

Re: Thread for advanced questions

Re: Thread for advanced questions

Re: Thread for advanced questions

Re: Thread for advanced questions

Re: Thread for advanced questions

Re: Thread for advanced questions

Re: Thread for advanced questions

Re: Thread for advanced questions

Re: Thread for advanced questions

Re: Thread for advanced questions

Re: Thread for advanced questions

Re: Thread for advanced questions