CAViewer - A Cellular Automaton Simulator written in Java

[MathAndCode]

BTW, is there a Golly script for loading patterns written in apgcodes?

Here's one from early 2016: apgcode-to-clipboard-RLE.py. Hard to believe that apgcodes have been around that long.

What about the other way around?

[dvgrn]

BTW, is there a Golly script for loading patterns written in apgcodes?

Here's one from early 2016: apgcode-to-clipboard-RLE.py. Hard to believe that apgcodes have been around that long.

What about the other way around?

The comments in that script include a pointer to biggiemac's script which converts a Golly selection to an apgcode (and opens the relevant Catagolue page for you).

[MathAndCode]

The comments in that script include a pointer to biggiemac's script which converts a Golly selection to an apgcode (and opens the relevant Catagolue page for you).

Ah; thank you. I was about to start typing one myself when I saw that you had replied.

[lemon41625]

Update 2.4:

• Rule Support
  • Added support for regenerating generations
  • Added support for [R]Symbiosis
  • Added support for INT rules (Moore, Hexagonal, Far Corners, Far Edges, R2 Cross, Knight)
  • Added support for custom rules (*.rule)
    • SQC Ruletables
    • Golly Ruletables
    • Golly Ruletrees
• GUI / Editing Improvements
  • Clearing cells cache is faster
  • Fixed rotate clockwise and anticlockwise.

Documentation: https://jedlimlx.github.io/Cellular-Automaton-Viewer
Wiki: https://jedlimlx.github.io/Cellular-Aut ... /Home.html

Precompiled Binaries: https://github.com/jedlimlx/Cellular-Au ... r/releases

[Yoel]

Where can I read a detailed description of the apgcode format?

Anything like that that isn't on the LifeWiki, certainly ought to be. In this case the coverage is fairly good.

Do you know how linear growth patterns are encoded? The LifeWiki page doesn't explain it. For example, a couple of days ago I discovered a new natural puffer in standard Life by apgsearching (no so new really, a reaction of two well known puffers). Its apgcode is as follows:


yl1152_1_339_9141fc3314f83e5b956ec6958426db33

It appears in this soup:

Code: Select all

x = 16, y = 16, rule = B3/S23
booooooooobbobbo$
obbbbooobobbbobb$
bobooooobbobboob$
oobbbbobooobooob$
bbbbbobobobboobb$
bbbbooobbobobboo$
obbooobbbbooboob$
bbobbobobobboooo$
oooobbbooooboobo$
ooooobobbbbbbooo$
oobbobbooboooboo$
obboobbbobbbbbbo$
obbooobobboboooo$
obbobobobooooobb$
oobboobbbooboobb$
obboobobooobbbbo!

However, if I try to parse it by the Python script, although it is standard Life, it reads the aphanumeric line as a normal apgcode and produces mess that seems totally unrelated to the pattern:

Code: Select all

x = 35, y = 8, rule = Life
2$b2ob2ob3obobob4o4b2o4b4o$5bob2o2bob2obo2b2obo4b2ob3o$3bob2o3b2o2b2o
2b5obobob2o$bo3b2o4b2obob2o2b2obobo3b2o!

The encoding is entirely different from the extended Wechsler format. It's obviously plain hex, because no other letters besides a-f appear in those codes, and it's always 32 symbols, i.e. 16 bytes. Linear growth patterns in multistate rules are also encoded the same way, as a 16 byte hex line. However, they are not internal server IDs of the patterns either, because if I don't upload hauls to Catagolue or run Apgsearch disconnected from the network, it still systematically logs the same codes for the same patterns on my computer.

[Moosey]

Do you know how linear growth patterns are encoded? The lifeWiki page doesn't explain it...

iirc yl apgcodes are something like yl(period of the puffer, more or less & depending on the ash but I forget how)_(period of the ash I think)_(I have no clue)_(hash of the ash, rhyme unintended)

[Schiaparelliorbust]

Do you know how linear growth patterns are encoded? The lifeWiki page doesn't explain it...

iirc yl apgcodes are something like yl(period of the puffer, more or less & depending on the ash but I forget how)_(period of the ash I think)_(I have no clue)_(hash of the ash, rhyme unintended)

I think it's the period of the population of the ash, so if the puffer has glide symmetry or any other way for it's ash's population to have a period smaller than the puffer's period, then that will be after yl.

[lemon41625]

Features added since last update:

• Rule support
  • Added [R]DeadlyEnemies
  • Added Multi-state Cyclic HROT
  • Added Alternating Rules
  • Revamped apgtable generation (looks alot cleaner now)
• GUI / Editing Improvements
  • Better undo / redo support
  • Ability to view population graph
  • Ability to modify random soup generation settings
• Search Program
  • New catalyst search program (with support for multiple catalysts)

Documentation: https://jedlimlx.github.io/Cellular-Automaton-Viewer
Wiki: https://jedlimlx.github.io/Cellular-Aut ... /Home.html

Precompiled Binaries: https://github.com/jedlimlx/Cellular-Au ... r/releases

EDIT:
It appears there were some bugs with undo / redo and the multi-state cyclic HROT rules. They are fixed now.
Download from https://github.com/jedlimlx/Cellular-Au ... /333652086

===================================

@Yoel
CAViewer supports multi-state cyclic rules according to my notation. I'll get the other notation done soon.
So I guess you can try it out and let me know if there are any issues.

A useful function that CAViewer has is the ability to simulate extended neighbourhood rules.
For a multi-state cyclic rule, the extended neighbourhood notation is something like R2,C3,B4,0,0,3,1,2,2,1,M2,2,S2,l-2,3,l-0,NB.

CAViewer can also generate apgtables (for both extended neighbourhoods and R1 moore rules) for apgsearch to use. To run them in Golly, you will need to replace the neighbourhood with the Golly supported neighbourhood aliases.

A *.zip file (rules.zip) containing some other rules that can be run in CAViewer can be found https://github.com/jedlimlx/Cellular-Au ... r/releases.

[lemon41625]

Update v2.6:

• Rule support
  • Added support for rulestring canonisation and min, max rule generation in INT rules
  • Added support for [R]History and [R]E(x)nergetic for INT rules
  • Added INT generations support, including B0 rules
  • Added bounded grid (specifically toroidal grids)
• GUI / Editing Improvements
  • Ability to simulation inside and outside selection
  • Improved rendering
• Search Program
  • New brute force search program
  • Ability to flip and rotate catalysts in catalyst search program
  • Ability to call catalyst search program from CLI

Documentation: https://jedlimlx.github.io/Cellular-Automaton-Viewer
Wiki: https://jedlimlx.github.io/Cellular-Aut ... /Home.html

Precompiled Binaries: https://github.com/jedlimlx/Cellular-Au ... r/releases

[Yoel]

Hi!

Yesterday your CAViewer killed the PSU in my computer! I'm kidding. For about a month it was humming like a drill and heating up like an iron. However, the last drop was trying to load a relatively large pattern into CAV (a tiling of 7 Rule 100 units for Brians' Brain, 50,488 cells on a 2688-wide cylinder), while apgsearching in parallel mode in the background. This caused a spectacular explosion of a capacitor inside the power supply!

First, a couple of small things:

1. chmod +x can be preset in .zip and .tar.gz archives as well as on Github:

https://stackoverflow.com/questions/409 ... ile-in-git

One way to ensure Linux compatibility, if you don't have a Linux box at hand, is to install a full testing distro under VirtualBox.

3. I preconfigured colors in Gluons, Gluonic etc. as RGB for obvious aesthetic reasons. It would be nice to add a state coloring menu and store color preferences for each rule.

4. Does RuleLoader actually work in CAViewer? I could not figure out how to insert custom rule tables.

Now, there is recurring thread synchronization bug, ConcurrentModificationException in updateCells, which leaves persistent cells that disrupt the whole thing. As far as I can see, this issue occurs very often when you step through by keeping the space pressed down, and only occasionally, but often enough, when you run a pattern or step only once and wait for the update. Opening a new pattern does not help to get rid of them. Once CAV is desynchonized, one must kill it and rerun again. Sometimes this bug does not throw an exception and remains unnoticed, which make pattern updates unreliable.

In case it's OS-specific, which I doubt:

$ uname -a
Linux hibou 5.4.0-4-amd64 #1 SMP Debian 5.4.19-1 (2020-02-13) x86_64 GNU/Linux
$ java -version
openjdk version "14-ea" 2020-03-17
OpenJDK Runtime Environment (build 14-ea+36-Debian-2)
OpenJDK 64-Bit Server VM (build 14-ea+36-Debian-2, mixed mode, sharing)

That's the main problem I see so far. Otherwise, cyclical multistate rules seem to work correctly, although I didn't try different neighborhoods yet.

I am sure you know that all sorts of other exceptions are thrown by CAV all the time, but I don't know whether they cause any problems.

BTW, is there a zoom option in CAV? And what's the default and maximum grid size?

[lemon41625]

Hi!

Yesterday your CAViewer killed the PSU in my computer! I'm kidding. For about a month it was humming like a drill and heating up like an iron. However, the last drop was trying to load a relatively large pattern into CAV (a tiling of 7 Rule 100 units for Brians' Brain, 50,488 cells on a 2688-wide cylinder), while apgsearching in parallel mode in the background. This caused a spectacular explosion of a capacitor inside the power supply!

CAViewer isn't really supposed to run large patterns. But, I won't really expect the capacitor to explode...

I preconfigured colors in Gluons, Gluonic etc. as RGB for obvious aesthetic reasons. It would be nice to add a state coloring menu and store color preferences for each rule.

Okay, I'll get that done.

4. Does RuleLoader actually work in CAViewer? I could not figure out how to insert custom rule tables.

You can place the rule file in a rules folder in the same folder as the CAViewer binary. You can also upload the rule to the LifeWiki:Rule namespace. Then, click on set rule and enter the rule's name.

Now, there is recurring thread synchronization bug, ConcurrentModificationException in updateCells, which leaves persistent cells that disrupt the whole thing. As far as I can see, this issue occurs very often when you step through by keeping the space pressed down, and only occasionally, but often enough, when you run a pattern or step only once and wait for the update. Opening a new pattern does not help to get rid of them. Once CAV is desynchonized, one must kill it and rerun again. Sometimes this bug does not throw an exception and remains unnoticed, which make pattern updates unreliable.

I'm aware of this bug and it happens on my computer too. Unfortunately, I haven't been able to fix it but I'll keep trying.

BTW, is there a zoom option in CAV? And what's the default and maximum grid size?

To zoom use the scroll wheel like in Golly.

The maximum grid size is infinite but you can only edit patterns in a grid of 4096x4096 (I think). It can be adjusted by using a bounded grid, but I haven't gotten to adding in lines to denote where the bounds of the bounded grid are. Also if there are cells that are too far away from the origin (this generally doesn't happen unless a large pattern is intentionally loaded into the thing), the zoom kind of starts glitching.

[Yoel]

You can place the rule file in a rules folder in the same folder as the CAViewer binary. You can also upload the rule to the LifeWiki:Rule namespace. Then, click on set rule and enter the rule's name.

I see, very useful! I would make a separate subdirectory for rules though, to avoid mess, or add an option to choose a different default path for rules and patterns like in Golly. Perhaps, looking for the user's default Golly rule directory (usually ~/.golly/Rules) could also be useful, to avoid unnecessary copying of the tables.

To zoom use the scroll wheel like in Golly.

Ah... gotcha! I was not actually aware of this wheel feature (or forgot about it). I always use Ctl+[ and Ctl+] for zooming in Golly,

I see that you also use extended Wolfram codes. Did you see this post? For 2-color and 3-color cyclic 1D rules I use a different notation, which is humanly comprehensible, unlike Wolfram codes:

1DRB[births]-[survivals/mutations] and 1DRGB[births]-[survivals/mutations], where the code is written as a sequence of ternary digits for 2-color rules and 4-base digits for 3-color, which encodes all possible unique color combinations possible in isotropic cyclical 1D: 2/6 for 2 colors and 3/10 for 3 colors. Some of these rules resemble W54 or W110 with gliders, puffers etc. Unfortunately, Golly don't support larger neighborhoods with >2 states (besides Generations). I'll try to check up such rules in CAViewer.

[Yoel]

You can place the rule file in a rules folder in the same folder as the CAViewer binary. You can also upload the rule to the LifeWiki:Rule namespace. Then, click on set rule and enter the rule's name.

What's the specification of your second version of multi-state cyclic HROT with custom neighborhoods? I mean, when I press the help button in your menu, it mentions "R<range>,C<states>,B<birth>,M<mutate>,M<mutate2>,...,S<survival>,N<neighborhood>".

I assume that neighborhoods are encoded the same way as in Golly 4.0? For example, how do you rewrite the rulestring for Gluonic with the explicit neighborhood? When I try to define a custom neighborhood, it does not save the setting in .rle files. Also, let's say I wish to redefine Gluonic with all cells weighted as 16. Is there way to do it?

[lemon41625]

I assume that neighborhoods are encoded the same way as in Golly 4.0?

Yes, neighbourhoods are encoded in a similiar way to Golly.

When I try to define a custom neighborhood, it does not save the setting in .rle files.

Oops... That was my mistake. I forgot to implement the methods to save the stuff as comments in the RLE files. I'll have that fixed.

For example, how do you rewrite the rulestring for Gluonic with the explicit neighborhood?

The Gluonic rulestring with the explicit neighbourhood would be R1,C4,B0,0,2,0,2,1,M,M,S0,0,0,0,1,1,3,0,0,0,3,0,0,0,3,1,2,0,0,1,2,2,0,1,2,1,0,0,2,1,1,0,2,1,1,1,NM.

Note that commas are needed to seperate the numbers since for rules with larger neighbourhoods, the number of cells is larger than 10.

Also, let's say I wish to redefine Gluonic with all cells weighted as 16. Is there way to do it?

That would be R1,C4,B0,0,32,0,32,16,M,M,S0,0,0,0,16,16,48,0,0,0,48,0,0,0,48,16,32,0,0,16,32,32,0,16,32,16,0,0,32,16,16,0,32,16,16,16,NW101010100010101010.

But, it appears that there is a bug parsing such high weights so it won't work in the application. I'll go and fix it.

[lemon41625]

Update 2.7:

• Rule support
• 3x speed improvement for INT rule range generation
  • Add range 2 von neumann, checkerboard and r3 cross INT support
  • Add apgtable generation to Integer HROT and HROT generations with state weights
  • Add naive rules ([R]:T100:NO)
  • Compute heat, temperature and volatility in identification function
• GUI / Editing Improvements
  • Allow setting of rule directory
  • Allow changing rule colours (tied to individual rulestrings)
  • Add increase / decrease step size button
• Bugfixes
  • Pattern should update correctly now
  • No more ConcurrentModificationExceptions
  • Fixed bug where neighbourhoods where not generated in the RLE
  • Fixed bug involving parsing weights higher than 8

Documentation: https://jedlimlx.github.io/Cellular-Automaton-Viewer
Wiki: https://jedlimlx.github.io/Cellular-Aut ... /Home.html

Precompiled Binaries: https://github.com/jedlimlx/Cellular-Au ... r/releases

[muzik]

How can I create and run a rule table which operates on, for example, a higher-range Moore neighbourhood? I've been wondering what range-9 mod-3 replication looks like, since 1D parity rules look less messy when the number of copies is a perfect power of the number of states.

Also, how are B0 Generations rules emulated? I remember there was an effort to implement these into Golly circa 2016, but this was later abandoned.

[lemon41625]

How can I create and run a rule table which operates on, for example, a higher-range Moore neighbourhood? I've been wondering what range-9 mod-3 replication looks like, since 1D parity rules look less messy when the number of copies is a perfect power of the number of states.

It’s the same as a normal rule table but you can specify the neighbourhood like [(-5, 5), …].

Also idk what symmetry you want to use but if it’s not permute I think you will need to use lifelib’s disjoint cycles thing. There should be something on it on lifelib’s gitlab page.

Also, how are B0 Generations rules emulated? I remember there was an effort to implement these into Golly circa 2016, but this was later abandoned.

See https://jedlimlx.github.io/Cellular-Aut ... pport.html (at the bottom)

[confocaloid]

[...]
Also idk what symmetry you want to use but if it’s not permute I think you will need to use lifelib’s disjoint cycles thing. There should be something on it on lifelib’s gitlab page.
[...]

I found this:

[...]
The rule format accepts arbitrary neighbourhoods (as lists of coordinate pairs) and symmetry groups (as lists of generators, each expressed as a list of disjoint cycles). For instance, instead of:

Code: Select all

neighborhood:Moore
symmetries:rotate4reflect

you can write:

Code: Select all

neighborhood:[(0,0), (0,-1), (1,-1), (1,0), (1,1), (0,1), (-1,1), (-1,0), (-1,-1), (0,0)]
symmetries:[[(1, 3, 5, 7), (2, 4, 6, 8)], [(2, 8), (3, 7), (4, 6)]]

In particular, the neighbourhood on which a cell can depend is allowed to be an arbitrary subset of the 17x17 square centred on that cell. (Compare this with the Moore neighbourhood, which is a mere 3x3 square.) As such, each coordinate in each pair in the neighbourhood is allowed to range from -8 to 8, inclusive.
[...]

[pifricted]

?

[lemon41625]

?

Could you send me the full error shown when the program is run?

[pifricted]

Could you send me the full error shown when the program is run?

[lemon41625]

There should be a file in the same directory as the .exe file named settings.json. Delete it and the application should start normally.

[R2INT]

Here is a triangular INT rulespace that I am very interested in:

Here is a Triangular Biohazard INT notation proposal (that can also be applied to Triangular Vertecies INT):

Code: Select all

# [[ COLOR ALIVE 255 255 255 COLOR DYING 0 0 255 COLOR DYINGRAMP 255 192 0 COLOR DEAD 0 0 96 ]]
x = 136, y = 157, rule = 0123456789xyz//5L
17.7C7.5C5.7C3.7C7.C5.C7.7C7.9C3.7C5.9C3.7C$16.2C5.2C9.2C4.2C4.2C8.2C
6.2C4.2C6.2C12.2C16.2C4.2C6.2C2.2C4.2C$15.2C7.2C7.2C10.2C8.2C6.8C6.8C
6.2C16.2C4.2C6.2C3.7C$15.2C7.2C6.2C4.8C5.6C11.2C12.2C6.9C9.2C4.10C8.2C
$16.2C5.2C6.2C4.2C17.2C9.2C12.2C6.2C6.2C8.2C4.2C6.2C8.2C$17.7C3.7C3.7C
7.7C9.C7.7C7.9C8.2C5.9C8.2C2$126.5B$17.5B103.2BDBD2B$16.2B.B.2B101.2B
2DA2D2B$15.2B2.A2.2B100.3B3D3B$15.3B3.3B101.7B$16.7B2$11.5C13.5B7.5B7.
5B7.5B7.5B7.5B7.5B7.5B$10.2C3.2C11.2B.B.2B5.2B.B.2B5.2B.B.2B5.2B.B.2B
5.2BDBD2B5.2BDBD2B5.2BDBD2B5.2BDBD2B$9.8C10.2B2.A2.2B3.2B.DA2.2B3.2B.
DAD.2B3.2B.DAD.2B3.2BD.A.D2B3.2BD.A.D2B3.2BD.A2D2B3.2B2DA2D2B$9.2C16.
3B.D.3B3.3B.D.3B3.3B.D.3B3.3B.2D3B3.3BD2.3B3.3BD.D3B3.3BD.D3B3.3BD.D3B
$10.7C11.7B5.7B5.7B5.7B5.7B5.7B5.7B5.7B2$11.5C13.5B7.5B7.5B7.5B7.5B7.
5B7.5B7.5B$10.2C3.2C11.2B.B.2B5.2B.B.2B5.2B.BD2B5.2B.BD2B5.2BDB.2B5.2B
DB.2B5.2BDBD2B5.2BDBD2B$10.2C3.2C10.2B2.A2.2B3.2B2.A.D2B3.2B2.A.D2B3.
2B2.A.D2B3.2B2DAD.2B3.2B2DAD.2B3.2B2DAD.2B3.2B2DA2D2B$11.5C11.3BD2.3B
3.3B2.D3B3.3B2.D3B3.3BD.D3B3.3B.D.3B3.3B2D.3B3.3B2D.3B3.3B.2D3B$28.7B
5.7B5.7B5.7B5.7B5.7B5.7B5.7B2$11.5C25.5B7.5B7.5B7.5B7.5B7.5B$15.2C23.
2B.B.2B5.2B.B.2B5.2B.BD2B5.2BDB.2B5.2BDBD2B5.2BDBD2B$9.8C22.2B2.A2.2B
3.2BD.A2.2B3.2B2.AD.2B3.2B2DA.D2B3.2B.DA2D2B3.2B2DA2D2B$8.2C4.2C23.3B
.2D3B3.3B2D.3B3.3B2D.3B3.3B2.D3B3.3B2.D3B3.3BD2.3B$8.7C25.7B5.7B5.7B5.
7B5.7B5.7B2$13.C27.5B7.5B7.5B7.5B7.5B7.5B$40.2B.BD2B5.2B.B.2B5.2B.B.2B
5.2BDBD2B5.2BDBD2B5.2BDB.2B$11.2C26.2B2.A2.2B3.2B2.A2.2B3.2B2.A2D2B3.
2B2DA2.2B3.2B2DA2D2B3.2B2DA2D2B$10.2C27.3B.D.3B3.3B3D3B3.3B.2D3B3.3BD
2.3B3.3B3.3B3.3BD.D3B$9.2C29.7B5.7B5.7B5.7B5.7B5.7B2$11.2C28.5B7.5B7.
5B7.5B7.5B7.5B$10.2C28.2B.B.2B5.2BDB.2B5.2BDB.2B5.2B.BD2B5.2B.BD2B5.2B
DBD2B$9.2C2.2C24.2B2.A.D2B3.2B2.AD.2B3.2B2.AD.2B3.2B2DA.D2B3.2B2DA.D2B
3.2B2DAD.2B$8.4C27.3B.D.3B3.3B.D.3B3.3B.2D3B3.3BD2.3B3.3BD.D3B3.3BD.D
3B$7.2C2.2C27.7B5.7B5.7B5.7B5.7B5.7B2$9.5C27.5B7.5B7.5B7.5B7.5B7.5B$8.
2C2.2C26.2B.B.2B5.2B.B.2B5.2B.B.2B5.2BDBD2B5.2BDBD2B5.2BDBD2B$7.2C2.2C
26.2B2.A2.2B3.2B2.A2D2B3.2B2.AD.2B3.2B2DA.D2B3.2B2DA2.2B3.2B2DA2D2B$6.
2C2.2C27.3BD.D3B3.3B.D.3B3.3B3D3B3.3B3.3B3.3BD.D3B3.3B.D.3B$5.2C2.2C29.
7B5.7B5.7B5.7B5.7B5.7B2$7.9C25.5B7.5B7.5B7.5B7.5B7.5B$6.2C2.2C2.2C24.
2B.BD2B5.2BDB.2B5.2BDB.2B5.2B.BD2B5.2B.BD2B5.2BDB.2B$5.2C2.2C2.2C24.2B
2.A2.2B3.2B2.A.D2B3.2B2.A.D2B3.2B2DAD.2B3.2B2DAD.2B3.2B2DA2D2B$4.2C2.
2C2.2C25.3B2.D3B3.3B2.D3B3.3BD.D3B3.3B.D.3B3.3B2D.3B3.3B2D.3B$4.C6.2C
27.7B5.7B5.7B5.7B5.7B5.7B2$9.5C27.5B7.5B7.5B7.5B7.5B7.5B$8.2C2.2C26.2B
DB.2B5.2B.BD2B5.2BDBD2B5.2B.B.2B5.2BDB.2B5.2B.BD2B$7.6C26.2B2.A2.2B3.
2BD.A2.2B3.2B2.A2.2B3.2B2DA2D2B3.2B.DA2D2B3.2B2DA2D2B$6.2C31.3B2.D3B3.
3B2.D3B3.3BD.D3B3.3B.D.3B3.3B2D.3B3.3B2D.3B$6.C33.7B5.7B5.7B5.7B5.7B5.
7B$12.2C$11.2C2.C37.5B7.5B7.5B7.5B$10.3C.2C36.2B.BD2B5.2B.BD2B5.2BDB.
2B5.2BDB.2B$9.2C.3C36.2B2.AD.2B3.2B2.AD.2B3.2B2DA.D2B3.2B2DA.D2B$8.2C
2.2C37.3B.D.3B3.3B.2D3B3.3BD2.3B3.3BD.D3B$7.2C2.2C39.7B5.7B5.7B5.7B2$
13.2C38.5B7.5B7.5B7.5B$12.2C38.2B.BD2B5.2B.B.2B5.2BDBD2B5.2BDB.2B$11.
2C38.2B2.A2.2B3.2BD.A.D2B3.2B.DAD.2B3.2B2DA2D2B$11.2C38.3BD.D3B3.3BD.
D3B3.3B.D.3B3.3B.D.3B$11.3C38.7B5.7B5.7B5.7B2$13.C39.5B7.5B7.5B7.5B$52.
2B.B.2B5.2B.BD2B5.2BDB.2B5.2BDBD2B$11.2C38.2B2.A.D2B3.2B2.A.D2B3.2B2D
AD.2B3.2B2DAD.2B$10.2C39.3B2D.3B3.3B2D.3B3.3B2.D3B3.3B2.D3B$7.4C41.7B
5.7B5.7B5.7B2$7.5C41.5B7.5B7.5B7.5B$6.2C2.2C40.2B.BD2B5.2B.BD2B5.2BDB
.2B5.2BDB.2B$6.5C40.2B2.A2.2B3.2B2.A2.2B3.2B2DA2D2B3.2B2DA2D2B$8.2C2.
C38.3B2D.3B3.3B3D3B3.3B3.3B3.3B2.D3B$8.5C39.7B5.7B5.7B5.7B2$9.C43.5B7.
5B7.5B7.5B$8.5C39.2BDB.2B5.2B.B.2B5.2BDBD2B5.2B.BD2B$7.2C3.C38.2B2.A2.
2B3.2B2.A.D2B3.2B2DAD.2B3.2B2DA2D2B$6.2C43.3B2D.3B3.3B3D3B3.3B3.3B3.3B
2.D3B$5.2C45.7B5.7B5.7B5.7B2$11.2C40.5B7.5B7.5B7.5B$8.6C38.2BDB.2B5.2B
DBD2B5.2B.B.2B5.2B.BD2B$9.2C40.2B2.A.D2B3.2B2.A2.2B3.2B2DA2D2B3.2B2DA
D.2B$8.2C41.3B.D.3B3.3B2D.3B3.3B2.D3B3.3BD.D3B$7.2C43.7B5.7B5.7B5.7B2$
9.2C2.2C38.5B7.5B7.5B7.5B$8.2C2.2C38.2B.BD2B5.2BDBD2B5.2B.B.2B5.2BDB.
2B$7.2C2.2C38.2B2.A.D2B3.2B2.A.D2B3.2B2DAD.2B3.2B2DAD.2B$6.6C39.3B.D.
3B3.3B.D.3B3.3BD.D3B3.3BD.D3B$52.7B5.7B5.7B5.7B2$6.2C3.2C40.5B7.5B7.5B
7.5B$7.2C.2C40.2B.B.2B5.2B.B.2B5.2BDBD2B5.2BDBD2B$8.3C40.2BD.A.D2B3.2B
D.A.D2B3.2B.DAD.2B3.2B.DAD.2B$9.C41.3B.D.3B3.3B2D.3B3.3B2.D3B3.3BD.D3B
$52.7B5.7B5.7B5.7B$6.2C2.C$6.2C.2C42.5B7.5B7.5B7.5B$7.3C42.2BDBD2B5.2B
DB.2B5.2B.BD2B5.2B.B.2B$3.C3.2C42.2B2.A2.2B3.2B2.A.D2B3.2B2DAD.2B3.2B
2DA2D2B$3.5C43.3B.D.3B3.3B2D.3B3.3B2.D3B3.3BD.D3B$52.7B5.7B5.7B5.7B2$
7.4C54.5B7.5B$6.2C56.2BDB.2B5.2B.BD2B$5.2C56.2B.DA.D2B3.2B2DA.D2B$5.4C
54.3B.D.3B3.3B2.D3B$64.7B5.7B2$11.C53.5B7.5B$10.2C52.2B.BD2B5.2BDB.2B
$5.6C52.2BD.A.D2B3.2B.DAD.2B$4.2C2.2C53.3B.D.3B3.3BD.D3B$4.5C55.7B5.7B
2$7.5C53.5B7.5B$6.2C2.2C52.2BDB.2B5.2B.BD2B$5.3C55.2BD.A2.2B3.2B.DA2D
2B$4.2C.2C54.3B2D.3B3.3B2.D3B$4.C59.7B5.7B2$7.5C53.5B7.5B$6.2C2.2C52.
2B.B.2B5.2BDBD2B$6.5C52.2BD.AD.2B3.2B.DA.D2B$8.2C53.3B2D.3B3.3B2.D3B$
4.5C55.7B5.7B2$3.C3.C3.C53.5B7.5B$2.2C2.2C2.2C52.2B.BD2B5.2BDB.2B$.2C
2.2C2.2C52.2BD.A2.2B3.2B.DA2D2B$.9C53.3B2D.3B3.3B2.D3B$64.7B5.7B$4.C5.
C$4.2C3.2C54.5B7.5B$5.5C54.2BDB.2B5.2B.BD2B$5.2C.2C53.2BD.AD.2B3.2B.D
A.D2B$4.2C3.2C52.3B.D.3B3.3BD.D3B$64.7B5.7B$3.6C$7.2C56.5B7.5B$6.2C56.
2B.B.2B5.2BDBD2B$5.2C56.2BD.AD.2B3.2B.DA.D2B$5.6C52.3B.2D3B3.3BD2.3B$
64.7B5.7B!

[...]
Using this notation, here are some examples of rules supporting spaceships in this rulespace:

Code: Select all

#C Hexagonally-restricted spaceship
x = 6, y = 6, rule = B2o/S2m34LB
$2bo$bo3bo$4bo$bobo$o!

Code: Select all

#C p2 spaceship
x = 12, y = 5, rule = B3ai5ru/S2a3nLB
$2bo$bo2bo5b2o$b3o4b3o$10bo!

It is possible to emulate all hexagonal rules using this rulespace, thus guaranteeing that it is at least as interesting as the hexagonal rulespace.

Can this rulespace be implemented in CAViewer? I would certainly like to be able to find an interesting rule in this rulespace!