ConwayLife.com

Posted: **July 9th, 2026, 4:17 pm**

This is a new pattern editor I made based on dvgrn's ideas here, it lets you edit patterns as groups of cells (and other groups), as opposed to just cells.

It's accessible here.

This is a very early prototype version; it's missing lots of features (such as running patterns even, turns out that doing this while preserving the grouping is quite hard) and probably has many bugs.

Discord discussion thread: here

Edit: Source code is available here

Posted: **July 10th, 2026, 3:39 pm**

Don't think of it as a bit editor. It's an object oriented editor of an array of LifeObject elements, that at some point can be converted to a bitarray that can then be used as the source for a cellular automata. Keep the data separate from the presentation.

Your first order of business should probably be to define what that LifeObject is and its data structure. Start with an apgcode (or similar canonical reference) along with the transformation needed to place the object on the bitarray field in the proper location, orientation, and phase. Any bitpattern can and should be generated from that information, and not be a part of the object data structure.

Also need to handle grouping/ungrouping of objects and how to transform a group of objects as a whole. (Rotation, for example) Another separate pair of operations would be the taking of a list objects and combining them into one object, or partitioning an object into smaller, sub-objects. Inserting/deleting from the group, as well as re-ordering, should also be supported.

As for the editor, you need to concentrate on selecting/moving/editing/manipulating objects. Think of them as a bunch of opaque shapes (rectangles most likely) that appear on the screen. Emulate your favorite drawing program.

Bitpatterns should only be generated when you need to display a pattern or actually generate the next generation. If you do want to generate the next generation in parallel, you would need to figure out when they start to overlap. That's going to be a lot of unnecessary work.

If the user does want to edit the indivdual bits, then that is done within the object, in a "biteditor mode", and should only affect the selected object.

You might want to put all that into a library along with unit-tests. Maybe add a second library to handle display, with emphasis on formatting and User Interface elements.

That's what I've done in my Life editor program, and it works fairly well. (Worst case, if I need to do some serious bit-editing, I copy the objects as a bitmap and paste in Golly, then paste the result back and perform a "partition" operation if necessary.)

You can also perform some placement validation. For example, I added a mode where the objects are Period-2 rotor segments, and the editor checks that various parts are in the proper phase and location to ensure that the result is also valid.

Posted: **July 10th, 2026, 3:57 pm**

hkoenig wrote: July 10th, 2026, 3:39 pm Don't think of it as a bit editor. It's an object oriented editor of an array of LifeObject elements, that at some point can be converted to a bitarray that can then be used as the source for a cellular automata. Keep the data separate from the presentation.

Your first order of business should probably be to define what that LifeObject is and its data structure. Start with an apgcode (or similar canonical reference) along with the transformation needed to place the object on the bitarray field in the proper location, orientation, and phase. Any bitpattern can and should be generated from that information, and not be a part of the object data structure.

Also need to handle grouping/ungrouping of objects and how to transform a group of objects as a whole. (Rotation, for example) Another separate pair of operations would be the taking of a list objects and combining them into one object, or partitioning an object into smaller, sub-objects. Inserting/deleting from the group, as well as re-ordering, should also be supported.

As for the editor, you need to concentrate on selecting/moving/editing/manipulating objects. Think of them as a bunch of opaque shapes (rectangles most likely) that appear on the screen. Emulate your favorite drawing program.

Bitpatterns should only be generated when you need to display a pattern or actually generate the next generation. If you do want to generate the next generation in parallel, you would need to figure out when they start to overlap. That's going to be a lot of unnecessary work.

If the user does want to edit the indivdual bits, then that is done within the object, in a "biteditor mode", and should only affect the selected object.

You might want to put all that into a library along with unit-tests. Maybe add a second library to handle display, with emphasis on formatting and User Interface elements.

We appear to have reinvented similar ways of doing this. Well, my structure is slightly different, I have "RPFPattern" objects which represent individual patterns (such as Snarks), then "RPFReference" objects which represent "There is a Snark at (x, y) with the given rotation."

I've already implemented grouping/ungrouping and pattern manipulation (you can click on objects to select them):

: Screenshot 2026-07-10 155133.png (8.67 KiB) Viewed 817 times

Generation running is going to be extremely optimized. It does not compute bit patterns unless it is truly needed, and it can even be set to warn if this happens, because in a pattern consisting of only circuitry this will often happen when circuitry breaks.

For instance, let's say you want to run a L156 with a Herschel in it:

Code: Select all

x = 29, y = 47, rule = B3/S23
19b2o$19bo$17b3o16$17b2o$17b2o2$8b2obo$8bob2o$26b2o$26bo$24bobo$24b2o
2$9bo$9b3o$o11bo$3o8b2o14bo$3bo22bobo$2b2o23bo7$bo$bobo$b3o$3bo11b2o$
15bo$16b3o$18bo!

Instead of running the pattern itself, it recognizes that the Herschel is "expected" and treats it as a signal, this is added to the RPFReference, so it becomes like "L156 at (x, y) with rotation F and a Herschel in it at generation 0", then all the possible states it can be in are precomputed (they're really saved when the object was created) and then it simply runs it by incrementing it, retrieving the desired state from the cache, and displaying it.

Now, let's say you for some reason didn't want to compute everything for the L156. You could instead precompute for the HLx69R, RF28B, and BFx59H, then the renderer would extract those and put them together to form the complete pattern image.

hkoenig wrote: July 10th, 2026, 3:39 pm You can also perform some placement validation. For example, I added a mode where the objects are Period-2 rotor segments, and the editor checks that various parts are in the proper phase and location to ensure that the result is also valid.

I don't really understand how this can be generalized, do you mind explaining some more?

Posted: **August 13th, 2026, 2:09 pm**

speedydelete wrote: July 10th, 2026, 3:57 pm
Instead of running the pattern itself, it recognizes that the Herschel is "expected" and treats it as a signal, this is added to the RPFReference, so it becomes like "L156 at (x, y) with rotation F and a Herschel in it at generation 0"

Is this a good time to elaborate on my proposed conduit naming scheme or no?

Posted: **August 13th, 2026, 3:37 pm**

Anivec wrote: August 13th, 2026, 2:09 pm
speedydelete wrote: July 10th, 2026, 3:57 pm
Instead of running the pattern itself, it recognizes that the Herschel is "expected" and treats it as a signal, this is added to the RPFReference, so it becomes like "L156 at (x, y) with rotation F and a Herschel in it at generation 0"
Is this a good time to elaborate on my proposed conduit naming scheme or no?

Yes, perhaps it is.

My current system looks something like (look at the #conduit's):

Code: Select all

snark:
#conduit 29 43+ input glider 9 6 F output glider 14 8 Fx 24
#envelope 0 0 y5gggsq23zy0ssvvvvvvuusssz8e133011fvvv7711zy2ogku7vmf1u08ozy4643y011
#manualverified speedydelete 2025-07-09
eater_1 0 10 Bx
eater_1 12 0 L
block 9 11
*oggs2uge1u08ozw643y011 6 15

BFx59H:
#conduit 54 53+ input B-heptomino output herschel 21 1 Fx
#envelope -2 -2 0gssvvvvvvvuvuuuususssssoogz33fvvvvvvfff73337733773311zxcn11zx11
#manualverified speedydelete 2025-07-08
block 4 3
snake 1 10 R

But, I'm interested to learn more about yours...

Posted: **August 14th, 2026, 9:00 am**

speedydelete wrote: August 13th, 2026, 3:37 pm
My current system looks something like (look at the #conduit's):

Code: Select all

snark:
#conduit 29 43+ input glider 9 6 F output glider 14 8 Fx 24
#envelope 0 0 y5gggsq23zy0ssvvvvvvuusssz8e133011fvvv7711zy2ogku7vmf1u08ozy4643y011
#manualverified speedydelete 2025-07-09
eater_1 0 10 Bx
eater_1 12 0 L
block 9 11
*oggs2uge1u08ozw643y011 6 15

BFx59H:
#conduit 54 53+ input B-heptomino output herschel 21 1 Fx
#envelope -2 -2 0gssvvvvvvvuvuuuususssssoogz33fvvvvvvfff73337733773311zxcn11zx11
#manualverified speedydelete 2025-07-08
block 4 3
snake 1 10 R

But, I'm interested to learn more about yours...

First step I took is renaming the orientations, here’s the new orientation renaming:
F -> 0
Fx -> 1
R -> 2
Rx -> 3
B -> 4
Bx -> 5
L -> 6
Lx -> 7

I also have decided to include the symmetry type for each object, that being the Catagolue standard symmetry naming, this also includes new names for glide symmetric spaceships. This makes orientations more specific. The origin of an object is now measured from its origin (bottom left corner) in its standard orientation, which is the orientation Catagolue provides for any given object in rle format. Every object name is provided by the Catagolue naming scheme in its standard orientation.
For the conduit input and output details, we will follow the naming scheme provided, where the strings inside the parentheses will be replaced by a number that is the specified value, excluding the continuous repeat time, which is indicated with a plus before the number.

I(Input object initial, Symmetry type)
O(Output object initial, Symmetry type)
R(Orientation number)
X(Output offset on the x axis)
Y(Output offset on the y-axis)
T(Time of formation of output)
C(Overclock time 1, Overclock time 2,…, Overclock time n, Continuous repeat time)

If any more elaboration on this is needed, I’ll be more than happy to share.

Posted: **August 19th, 2026, 7:10 pm**

Anivec wrote: August 14th, 2026, 9:00 am I also have decided to include the symmetry type for each object, that being the Catagolue standard symmetry naming, this also includes new names for glide symmetric spaceships. This makes orientations more specific. The origin of an object is now measured from its origin (bottom left corner) in its standard orientation, which is the orientation Catagolue provides for any given object in rle format.

Updates:
The offset is now measured from the bottom left regardless of orientation of the input/output objects.
The standard orientation is now defined as the following:
The direction the object tends to grow in its first few generations must facing to the top left (simply the top for symmetrical objects) of the grid in order to be considered as the standard orientation. Note that this only applies to methuselahs.
I also decided to move the overclock times to the middle in between the orientation and the output, as well as replace the overclock times with overclocking intervals denoted as
(Overclockstart1-Overclockend1, Overclockstart2-Overclockend2,..., + Continuousoverclock)
When theres an interval of only single overclock generation, it is simply the generation the overclock can happen.
The conduit when taking measurements has an orientation that aligns with the input's standard orientation.

Posted: **August 19th, 2026, 8:41 pm**

Anivec wrote: August 14th, 2026, 9:00 am First step I took is renaming the orientations, here’s the new orientation renaming:
F -> 0
Fx -> 1
R -> 2
Rx -> 3
L -> 4
Lx -> 5
B -> 6
Bx -> 7

Why rename the orientations? Aren't they fine as is? (I'm not trying to shut you down, I just want to hear your reasoning.)

Also, what about multi-input and/or multi-output conduits?

Posted: **September 14th, 2026, 5:18 pm**

speedydelete wrote: August 19th, 2026, 8:41 pm
Anivec wrote: August 14th, 2026, 9:00 am First step I took is renaming the orientations, here’s the new orientation renaming:
F -> 0
Fx -> 1
R -> 2
Rx -> 3
L -> 4
Lx -> 5
B -> 6
Bx -> 7

Why rename the orientations? Aren't they fine as is? (I'm not trying to shut you down, I just want to hear your reasoning.)

Consider this H-to-S, it is definitely not F, but it is also not Bx.

Code: Select all

x = 29, y = 30, rule = LifeHistory
23.2A$23.A$24.A$21.4A$21.A$23.B3A$7.2A14.BA2.A$8.A12.4B.A.A$8.A.AB7.7B
.A$9.2AB.3B3.7B$11.15B$11.16B$12.15B$11.15B$9.17B$7.19B$7.2BC15B$6.3B
CBC4B.10B$7.2B3C4B2.9B$6.5BC4B2.9BD$5.10B4.7B2DB$4.4B10.7B2D2B$4.3B12.
6BDB$2.4B13.7B$2.2A16.4B$3.A14.5B$3A15.2A$A18.A$16.3A$16.A!

The abbreviations (F is forward, R is right, L is left, B is back) start to lose their meaning with objects like this. If we define the objects symmetry, we would have to use more abbreviations, unless we map the orientations to specific values.

speedydelete wrote: August 19th, 2026, 8:41 pm Also, what about multi-input and/or multi-output conduits?

Add another object specification after the first one but before the overclock times:
I(Input object initial, Symmetry type)O(Output object initial1, Symmetry type1)R(Orientation number1)X(Output offset on the x axis1)Y(Output offset on the y-axis1)T(Time of formation of output1)O(Output object initial2, Symmetry type2)R(Orientation number2)X(Output offset on the x axis2)Y(Output offset on the y-axis2)T(Time of formation of output2)C(Overclockstart1-Overclockend1, Overclockstart2-Overclockend2,..., + Continuousoverclock)

Posted: **September 16th, 2026, 10:31 am**

Anivec wrote: September 14th, 2026, 5:18 pm
speedydelete wrote: August 19th, 2026, 8:41 pm Why rename the orientations? Aren't they fine as is? (I'm not trying to shut you down, I just want to hear your reasoning.)
Consider this H-to-S, it is definitely not F, but it is also not Bx.

I see the problem, but I don't see the solution. The lookup table you've given only maps F through Bx to arbitrary numbers 0 through 7. That doesn't seem like an improvement, since it doesn't give any help in explaining what that H-to-S example is supposed to map to -- apparently it isn't 0 or 7, but what is it?

Posted: **September 18th, 2026, 4:31 pm**

dvgrn wrote: September 16th, 2026, 10:31 am I see the problem, but I don't see the solution. The lookup table you've given only maps F through Bx to arbitrary numbers 0 through 7. That doesn't seem like an improvement, since it doesn't give any help in explaining what that H-to-S example is supposed to map to -- apparently it isn't 0 or 7, but what is it?

I decided to combine the original with a modified version of the original version of my naming scheme to get this:

Code: Select all

x = 48, y = 29, rule = LifeHistory
11.3D8.D8.3D7.3D$10.D3.D6.2D7.D3.D5.D3.D$10.D3.D5.D.D11.D9.D$10.D3.D7.
D10.D8.2D$10.D3.D7.D9.D11.D$10.D3.D7.D8.D8.D3.D$11.3D6.5D5.5D6.3D2$7.
41F$7.F9.F9.F9.F9.F$4.D2.F9.F9.F9.F9.F$3.D3.F9.F9.F3.A5.F9.F$3.D3.F3.
A5.F4.3A2.F3.3A3.F3.3A3.F$2.D4.F3.A.A3.F5.A3.F3.A.A3.F3.A5.F$.D5.F3.3A
3.F3.3A3.F5.A3.F2.3A4.F$.D5.F5.A3.F9.F9.F9.F$D6.F9.F9.F9.F9.F$7.F9.F9.
F9.F9.F$7.41F$7.F9.F9.F9.F9.F$D6.F9.F9.F9.F9.F$.D5.F5.A3.F9.F9.F9.F$.
D5.F3.3A3.F3.3A3.F5.A3.F2.3A4.F$2.D4.F3.A.A3.F5.A3.F3.A.A3.F3.A5.F$3.
D3.F3.A5.F4.3A2.F3.3A3.F3.3A3.F$3.D3.F9.F9.F3.A5.F9.F$4.D2.F9.F9.F9.F
9.F$7.F9.F9.F9.F9.F$7.41F!

Forward slash means unflipped object, backslash means the object is flipped. Increasing the number by one rotates the object 90 degrees counterclockwise, up to 270 degrees counterclockwise from its standard orientation. If the object orientation has backslash, it should be physically flipped vertically after the rotation(s) have been preformed. If one or more of these 4 rotations are the same, choose the smaller number. If the flipped version is the same as the original, then use the forward slash instead. The order of orientations is 0/, 1/, 2/, 3/, 0\, 1\, 2\, 3\, so the first matching orientation in this sequence is the one in the conduit name.

By this congruence, we have the mappings:

C1:(0/, 1/, 2/, 3/, 0\, 1\, 2\, 3\)
C2:(0/, 1/, 0/, 1/, 0\, 1\, 0\, 1\)
C4:(0/, 0/, 0/, 0/, 0\, 0\, 0\, 0\)
D2_+:(0/, 1/, 2/, 3/, 0/, 1/, 2/, 3/)
D2_x:(0/, 1/, 2/, 3/, 1/, 0/, 3/, 2/)
D4_+:(0/, 1/, 0/, 1/, 0/, 1/, 0/, 1/)
D4_x:(0/, 1/, 0/, 1/, 1/, 0/, 1/, 0/)
D4:(0/, 0/, 0/, 0/, 0/, 0/, 0/, 0/)

ConwayLife.com

Grouping pattern editor

Grouping pattern editor

Re: Grouping pattern editor

Re: Grouping pattern editor

Re: Grouping pattern editor

Re: Grouping pattern editor

Re: Grouping pattern editor

Re: Grouping pattern editor

Re: Grouping pattern editor

Re: Grouping pattern editor

Re: Grouping pattern editor

Re: Grouping pattern editor