Binary slow salvos

[Macbi]

This only affects viewpoint positioning, which is not limited to +/- 1B.

I have often thought of raising the limit on editing from +/-1B to +/- 1E18, but it's a pretty big undertaking and may introduce new bugs, so I'm a bit leery. Is this something that people need? If we did this it would probably require a long beta period, and it would likely only work on 64-bit platforms (or rather, platforms that have a 64-bit signed integer type).

As of now the limit of +/- 1B on editing remains.

I think it's only worth raising the limit if you can increase it to infinity. The way that I end up wanting to edit outside the +/- 1B box is by running a pattern in Hashlife for a long time. But then it's probably bigger than +/- 1E18 too! I think it would be pretty rare for the pattern size to be larger than one and not the other.

[rokicki]

Ahh, that introduces a whole new level of complexity then. It's *possible* but I'd need to make my bigint class a lot more robust.

[Macbi]

Ahh, that introduces a whole new level of complexity then. It's *possible* but I'd need to make my bigint class a lot more robust.

I'm not saying it's a good idea. There's only been a handful of times I've wanted to draw outside the box. Just that there's been even fewer times I've wanted to draw between the two boxes.

[dvgrn]

I have often thought of raising the limit on editing from +/-1B to +/- 1E18, but it's a pretty big undertaking and may introduce new bugs, so I'm a bit leery. Is this something that people need?

I've hit that limitation on very rare occasions, mostly while fiddling around with RCT stuff or infinite-novelty experiments. I can't say that I've personally ever been terribly inconvenienced by the limitation.

Changing the limit from 1E9 to 1E18 wouldn't actually be a very useful improvement, I think. Mostly it would just increase the chance that people would get themselves into trouble by trying operations that would take an estimated 25000 days to complete.

From the scripting side of things, as mentioned above, you really can't do anything useful with mega-metacell patterns anyway (besides setting the viewpoint).

What I _have_ wanted occasionally, and have been somewhat tempted to try implementing as a Python library, is the ability to manipulate macrocell tiles directly -- the ability to build large objects like the above RCT sample pattern in Golly's memory, and then save the patterns in .mc format. One of the previous times that this has come up is here.

Macrocell format isn't particularly difficult or mysterious, so it's not terribly painful to write out text files and then open them when we need that kind of thing. However, direct scriptable control of hashtiles would certainly come in handy more often for me than an increased editing limit would.

[rokicki]

I'd be happy to consider doing something like you describe with hashtiles. Adam's lifelib has a pretty nice API for quadtree patterns including many editing operations (see https://gitlab.com/apgoucher/lifelib/bl ... editing.md) so there is already code to look at and possibly work from (although his architecture lends itself to this sort of thing a bit more than Golly's does, I'm afraid).

What sort of API are you thinking for macrocell editing? Perhaps adding a single call (bigshift(x, y)) which shifts the entire universe by a delta x and y, and then you can use the existing setpos/getpos with +/- 1e9 would suffice (although be perhaps a bit crude)? Or would you actually require being able to cut/copy/paste mega (or giga) sized chunks of the universe?

-tom

[dvgrn]

What sort of API are you thinking for macrocell editing? Perhaps adding a single call (bigshift(x, y)) which shifts the entire universe by a delta x and y, and then you can use the existing setpos/getpos with +/- 1e9 would suffice (although be perhaps a bit crude)? Or would you actually require being able to cut/copy/paste mega (or giga) sized chunks of the universe?

I suppose the bigshift(x,y) implementation would be a good minimum improvement -- you could use it to build a moderate RCT salvo like calcyman's, with a fairly simple Golly script.

However, for working with bigger patterns like the p1 megacell example linked above, or for recursively defined patterns like a larger version of this one, it would be nice to be able to build large macrocells out of smaller ones, and then eventually save any macrocell structure as an .mc file, and/or (maybe?) paste a macrocell object into the Golly universe, or at least open a macrocell object in a new Golly universe.

The key is to be able to work with various sizes of macrocell objects without ever having to convert them to cell lists -- since that will very often not be possible.

The more ambitious version of this is highly non-trivial. There are various Golly functions that could theoretically support macrocell objects as inputs, along with cell lists -- g.transform() and so on. But it's a bit tricky to flag a list of integers as being a macrocell-format list instead of a (two-state or multi-state) cell list... I guess if the first N numbers in the list were all zeroes or 2147483647s or some such, that would be a reliable signal that the list wasn't a valid cell list and a macrocell definition was going to follow -- but that seems kind of kludgey.

Anyway, does the basic idea make any kind of sense? Something like

Code: Select all

macrocellA = g.macrocell("bobb$bbob$3o!")
macrocellB = g.macrocell(macrocellA, macrocellA, macrocellA,macrocellA)
macrocellC = g.macrocell(macrocellB, macrocellB, 0, 0)
g.note("macrocellC logdiam: " + str(g.mclogdiam(macrocellC)))
g.note("macrocellC population: " + g.mcpop(macrocellC))

could produce

Code: Select all

x = 17, y = 9, rule = B3/S23
$2bo3bo3bo3bo$3bo3bo3bo3bo$b3ob3ob3ob3o2$2bo3bo3bo3bo$3bo3bo3bo3bo$b3o
b3ob3ob3o!

and would display macrocellC logdiam: 4 followed by macrocellC population: "40", since macrocellC is 2^4 = 16 cells wide and contains eight gliders.

[calcyman]

The key is to be able to work with various sizes of macrocell objects without ever having to convert them to cell lists -- since that will very often not be possible.

That is pretty much an exact description of why lifelib was created, and how it works internally.

EDIT: For example, you can create a meta^8-caterpillar (with 0E0P metacells) in a matter of seconds, which would be impossible if it used cell lists at any point:

Code: Select all

$ ipython
Python 3.8.12 (default, Dec 23 2021, 20:18:35) 
Type 'copyright', 'credits' or 'license' for more information
IPython 7.30.1 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import lifelib

In [2]: lt = lifelib.load_rules('b3s23').lifetree(n_layers=1)

In [3]: meta = lt.load('b3s23metacell.mc').centre() # aligns the centre of the metacell with the origin

In [4]: meta
Out[4]: <Pattern(logdiam=18, beszel_index=1, ulqoma_index=0, rule=b3s23) owned by <lifelib.pythlib.session.Lifetree object at 0x7fa14ddd6430>>

In [5]: caterpillar = lt.load('caterpillar.mc')

In [6]: %time m8c = caterpillar * (meta ** 8)
CPU times: user 8.8 s, sys: 59.5 ms, total: 8.86 s
Wall time: 8.86 s

In [7]: m8c.population
Out[7]: 174945000241114852725752689795889535142433903155019101722780569319

In [8]: m8c
Out[8]: <Pattern(logdiam=164, beszel_index=1, ulqoma_index=0, rule=b3s23) owned by <lifelib.pythlib.session.Lifetree object at 0x7fa14ddd6430>>

In [9]: m8c.save('meta8caterpillar.mc.gz')

Here, the logdiam is equivalent to your 'size': it's the base-2 logarithm of the sidelength of the minimal origin-centred hashtile containing the pattern. Small patterns have a logdiam of 5, because lifelib's leaf hashtiles are 16x16 and the smallest origin-centred hashtile is a single nonleaf with four leaves: one in each quadrant.

I'm currently on a train so can't upload the .mc.gz (it's 72 megabytes, and the on-train free wifi has a limit of 50).

EDIT 2: it's also worth mentioning that you can shift a pattern by using p(x, y), where x and y are arbitrary Python integers. The shillelagh RCT was built using exactly this method, by taking a (much smaller) template file, separating it into constituent parts, and then shifting them in the appropriate directions:

Code: Select all

import lifelib

class RCTBuilder(object):

    def __init__(self, lt=None):

        if lt is None:
            lt = lifelib.load_rules('b3s23').lifetree(n_layers=1)

        template = lt.pattern('''x = 48822, y = 49168, rule = B3/S23
2bo$obo$b2o542$132bo$133bo$131b3o290$135b2o$134bobo$136bo$431b2o$430b
2o$432bo17$105bo$105b2o$104bobo23945$48819bobo$48819b2o$48820bo17$
24553bo$24554b2o$24553b2o$48789bo$48789bobo$48789b2o23896$99bobo$100b
2o$100bo17$427bo$425b2o$426b2o$131bo$129bobo$130b2o90$481bobo$481b2o$
482bo198$126b3o$128bo$127bo18$48792b3o$48792bo$48793bo74$478b3o$478bo$
479bo$187b2o$186bobo$188bo25$501b2o$500b2o$502bo!''').centre()

        middle = template[-8192:8192, -8192:8192]
        northwest = template[:-8192, :-8192](24576, 24576)
        east = template[8192:, -8192:8192](-24576, 0)
        southeast = template[8192:, 8192:](-24576, -24576)
        southwest = template[:-8192, 8192:](24576, -24576)

        assert(middle.population == 5)
        assert(northwest.population == 25)
        assert(east.population == 10)
        assert(southeast.population == 5)
        assert(southwest.population == 40)

        seventeenth = northwest[:, :northwest.bounding_box[1]+3]
        northwest -= seventeenth

        assert(northwest.population == 20)
        assert(seventeenth.population == 5)

        self.parts  =  {'middle': middle,
                        'northwest': northwest,
                        'east': east,
                        'southeast': southeast,
                        'southwest': southwest,
                        'seventeenth': seventeenth}

    def from_binstring(self, x):

        assert(x[:2] == '11') # avoids escaping gliders

        number = '0b' + x[1:].replace('2', '0')[::-1]
        number = int(number, base=2) * 192

        p = self.parts['middle'] + self.parts['east'](number, 0) + self.parts['southeast'](number, number)
        p = p + self.parts['southwest'](-number, number) + self.parts['northwest'](-number, -number)
        return p + self.parts['seventeenth'](-number, -number)

For the shillelagh, the recipe that I provided to from_binstring was '1111212212221111221121221121121121121111121121121121111211112211111211211111211121112112121121121121121122121121112112111211211211221121121211211211211221121121211211122222111211111211121112112112112112112112112112112112111121111111222221111121121121121122112211121121111121121121121111121121121121111211112211111211211111211211211111111211211111221112112112112112112111112112112121112112112112111112112112112211211212112112211111212111121211211111211211111211211111211211111211211111211211111211211112112112112112112112112112112111121121121121111211112121211121122221111221111211211211112112112112112112112112111111112112112112112122211211211111111111111111222212122221121111121121111211211112112112112112112211211111112211112211211112112112112111111211121222121111122211111122122112112112112112112112112112221121121211111211121112212122211211211211211111211121112111111221211221121112122121121121121121121121121111121121121222111112111211111111111121112111111212112112112112112112112112112111112112112122211111211211111112112112112212122221121111121121121121121121121121121122112112211111112112112121121122112112121121122112211112111211121111111221121121111121121121121121121121122111121121112211221122211112112112112112112112121212111112111212121211211211211221121122111222112111112112112112111121121121121121121111211211212212112112112112112112112211211212211211211122111111111111111221121111121121111211211211211211211211221111121121122211211211211111211121211222222111211222111212212112111112112112112112112111121121112122211211211211111211211211211211211211211122221121121121111211112221121121121121111112122112111112112111112112112112111111211211211211111112112112112112112111111112112112122121221121111121121121121121121121122112112211111112112112121121121121122112112121121122112111112112121121112111111111111121121121111121121121121121121111211211211211112111121211211211111211211211211111121121121222122111111221112111211111111121211211111211211112112112112112112112112112112211211221111111211211221111211211122211112211121122'

[dvgrn]

That is pretty much an exact description of why lifelib was created, and how it works internally.

Yup, this is currently a very good reason to reach for lifelib whenever I want to do this kind of thing.

I'd guess ideally I'd still like to see Golly have some native support for these operations -- it seems a little odd that it can do so much amazing stuff with macrocell files, but can't interact with them programmatically very much at all.

EDIT: Here's a reduced copy of the template file from the previous post, that fits in LifeViewer. This labeling method leaves you free to zoom around and look at what's happening -- you should be able to stop and start, and (especially) pick out the Bit-Reading Gliders and their return signals fairly easily.

Code: Select all

x = 15926, y = 16272, rule = B3/S23
2bo$obo$b2o542$132bo$133bo$131b3o290$135b2o$134bobo$136bo$431b2o$430b
2o$432bo17$105bo$105b2o$104bobo7497$15923bobo$15923b2o$15924bo17$8105b
o$8106b2o$8105b2o$15893bo$15893bobo$15893b2o7448$99bobo$100b2o$100bo
17$427bo$425b2o$426b2o$131bo$129bobo$130b2o90$481bobo$481b2o$482bo198$
126b3o$128bo$127bo18$15896b3o$15896bo$15897bo74$478b3o$478bo$479bo$
187b2o$186bobo$188bo25$501b2o$500b2o$502bo!
#C [[ MAXGRIDSIZE 14 STEP 64 THEME Mono ]]
#X [[ T 1 ]]
#C [[ T 15600 "GPSE streams from NW and SW\nare heading for epicentre" ]]
#C [[ T 32000 "SE GPSE constructed\nAll glider streams heading for epicentre" ]]
#C [[ T 40430 "Bit-Reading Glider #1 heading for SE GPSE" ]]
#C [[ T 48380 "'1' signal heading NW to epicentre" ]]
#C [[ T 52390 "Bit-Reading Glider #2 heading for SE GPSE" ]]
#C [[ T 56170 "'2' signal heading NW to epicentre" ]]
#C [[ T 59120 "Bit-Reading Glider #3 heading for SE GPSE" ]]
#C [[ T 60660 "'1' signal heading NW to epicentre" ]]
#C [[ T 61610 "Bit-Reading Glider #4 heading for SE GPSE" ]]
#C [[ T 62200 "'1' signal heading NW to epicentre" ]]
#C [[ T 62900 "GPSE crashes\nNo more workable Bit-Reading Gliders" ]]
#C [[ STOP 63000 ]]

In this pattern,
at T=32000 the glider streams reach the epicentre, and produce the first Bit-Reading Glider headed southeast, and also a glider going northeast to help make an initial target for the construction arm;
at T=40430 the Bit-Reading Glider reaches the southeast GPSE, reads its current phase, and produces (in this case) a "1" signal, which is an extra glider heading northwest;
at T=48380 the "1" signal has reached the epicentre, where it is about to produce a singleton construction-arm glider heading northwest, plus a new Bit-Reading Glider -- and an extra glider heading northwest, but that one has no useful effect (it's harmlessly absorbed when it gets to the northeast GPSE);
at T=52390, the Bit-Reading Glider is just reaching the southeast GPSE again. This time the relative phase is different, so a "2" signal is created, in the form of a gap in the northwest-traveling GPSE glider stream -- not an extra glider this time;
at T=56170, the "2" gap signal has reached the epicenter, where it is about to produce a pair of construction-arm gliders heading northeast, plus a new Bit-Reading Glider.
at T=59120, the Bit-Reading Glider reaches the southeast GPSE, finds that it's back in the "1" phase this time, and produces an extra "1" glider;
at T=60660, the "1" signal has reached the epicenter, where it has the same effect as before (1 glider heading northwest);
at T=61610, the next Bit-Reading Glider finds the southeast GPSE in state "2", and sends back a gap in the glider stream;
at T=62200, the gap has almost reached the epicenter, where it has the same effect as before (2 gliders heading northwest).

Technically another "1" glider is created after that, but it doesn't exactly count: by the time that bit gets read, the southeast GPSE has reached the epicenter and made a big mess. A real RCT recipe will prevent that from happening by catching that GPSE, and the other two, with one-time objects constructed by the recipe.

Encoding "1" and "2" Bits In An Exponential Distance
The lifelib script in the previous post can encode an arbitrarily long string of "1"s and "2"s into the initial positions of the GPSEs, by calculating exactly the right distance to place the GPSEs away from the epicenter. The script has a version of the above pattern embedded in it, a little bit bigger. If you run that pattern --

Code: Select all

x = 48822, y = 49168, rule = B3/S23
2bo$obo$b2o542$132bo$133bo$131b3o290$135b2o$134bobo$136bo$431b2o$430b
2o$432bo17$105bo$105b2o$104bobo23945$48819bobo$48819b2o$48820bo17$
24553bo$24554b2o$24553b2o$48789bo$48789bobo$48789b2o23896$99bobo$100b
2o$100bo17$427bo$425b2o$426b2o$131bo$129bobo$130b2o90$481bobo$481b2o$
482bo198$126b3o$128bo$127bo18$48792b3o$48792bo$48793bo74$478b3o$478bo$
479bo$187b2o$186bobo$188bo25$501b2o$500b2o$502bo!

-- in Golly, you'll see that its location decodes to a series of half a dozen "2" signals -- no "1"s, except for the initial one that helps build the constructor arm's target.

This is just a random sample showing how the bits read by the Bit-Reading Glider will change depending on the initial location of the GPSEs. These samples are both too small to actually have the "1" and "2" signals make up any part of a valid recipe. For that, see calcyman's shillelagh post later in this thread.

[rokicki]

How about if we simply add the following two operations:

mccopy(sx, sy, dx, dy, sz) ;

copy the cells from (sx, sy) to (sx + sz, sy + sz) to (dx, dy) + (dx + sz, dy + sz);
sz must be a power of two;
all four coordinates must be a multiple of that power of two.

and

mcclear(sx, sy, sz) ;

clear all the cells from (sx, sy) to (sx + sz, sy + sz); constraints same as above.

All values bigints.

This lets you manipulate "macrocells" (without really needing to know they are
macrocells). It's probably easy to implement (no complex code or caching of
operations needed). If that suffices for most of the stuff you do, it's a possibility.

Implementing lifelib operations requires a hash cache of operation results which
gets into golly's memory limit code, not to mention there are at least two distinct
hashlife implementations in golly that would need separate implementations).

I don't think Golly needs to be everything; I think having additional tools like
lifelib and lifeviewer that have a different "take" on things and excel in different
ways is healthy. But if just smashing together macrocell tiles (as the above code
would do) is useful, that's pretty easy to implement.

[dvgrn]

How about if we simply add the following two operations:

mccopy(sx, sy, dx, dy, sz) ;

copy the cells from (sx, sy) to (sx + sz, sy + sz) to (dx, dy) + (dx + sz, dy + sz);
sz must be a power of two;
all four coordinates must be a multiple of that power of two.

That sounds very good, except for a weird coordinate system detail in Golly:

The total universe represented by a macrocell file is that of the last node in the file (the root node), which also must be the single node with the largest size. By convention, the upper left cell of the southeast child of the root node is at coordinate position (x=0,y=1).

So I think it would probably work better if sy and dy were one more than a power of two. (?)

I don't think Golly needs to be everything; I think having additional tools like
lifelib and lifeviewer that have a different "take" on things and excel in different
ways is healthy. But if just smashing together macrocell tiles (as the above code
would do) is useful, that's pretty easy to implement.

Yup, no point in trying to duplicate lifelib, but there are occasional macrocell-related things that I'd like to be able to do in a Golly script, and mccopy() would take care of a fairly good fraction of them.

By "copy" do you mean blanking out the relevant hashtile and replacing it with the other hashtile? Or could an "or" type copy/paste be an option (with the caveat that it might be horribly slow for some types of large overlaps?) How about "xor" -- same story there?

[calcyman]

Yup, no point in trying to duplicate lifelib, but there are occasional macrocell-related things that I'd like to be able to do in a Golly script, and mccopy() would take care of a fairly good fraction of them.

It's also worth noting that they're not two mutually exclusive worlds where you need to decide between one or the other: a Golly script is just a Python script, and it can import lifelib just like any other script. You can move a universe from Golly to lifelib, and vice-versa, by using temporary macrocell files.

If there's enough interest in such a thing, I'll probably add some "Golly convenience functions" to lifelib which abstract away the use of the filesystem -- say, pattern = lt.from_golly() and pattern.to_golly().

That sounds very good, except for a weird coordinate system detail in Golly:

The total universe represented by a macrocell file is that of the last node in the file (the root node), which also must be the single node with the largest size. By convention, the upper left cell of the southeast child of the root node is at coordinate position (x=0,y=1).

So I think it would probably work better if sy and dy were one more than a power of two. (?)

Right, that's going to introduce an annoying one-cell discrepancy between lifelib and Golly's coordinate systems. (Why does Golly have this weird coordinate system detail, anyway?) I suppose that my from_golly and to_golly functions could do the one-cell shift so that both coordinate systems match exactly, which seems like a desirable property to have.

[dvgrn]

(Why does Golly have this weird coordinate system detail, anyway?) I suppose that my from_golly and to_golly functions could do the one-cell shift so that both coordinate systems match exactly, which seems like a desirable property to have.

Or... now that we have lifelib as a competing standard, maybe we should actually think about whether it makes sense to have Golly 4.2 load macrocell files at (0,0) instead of (1,0).

It seems like a rather wonky "implementation detail"... offhand I can't think of any code that relies on the current loading behavior. The one annoying thing is that all the coordinate values in the Life textbook would end up being off by one in the Y direction -- but those coordinates are mostly pointing out large features, so being off by one isn't usually even noticeable. If someone finds the edge of a glider instead of the middle of a glider, they're still looking at the right glider.

[rokicki]

Wow, changing the way we load macrocells (and how mc files are mapped to coordinates) sounds scary!

The reason Golly works the way it does is because when I originally wrote the hashlife engine, I had positive y going *up* the screen. Then, the root 16x16 macrocell had NE (quadrant I) as (0,0)..(7,7), and the other four quadrants completed a (-8,-8)..(7,7) square.

(Quicklife was like that too, I believe.)

But with a lot of discussion and angst and grief it was somehow decided that positive y should go *down* the screen. I think this was because of
RLE compatibility, where things were essentially defined that way. (This y going down the screen in Golly bothers me to this day, frankly, but
it is what it is.)

The "fix" was just to negate the y coordinate going into and out of the computing engines.

A better fix, almost certainly, would have been to *complement* the y coordinate, which would then have had the effect that the SE base 8x8 would have been at (0,0)..(7,7) (and then SE would have been, in some sense, quadrant I).

If we make this change, we have the possibility of breaking scripts that load and save MCs and manipulate them using current coordinates. Do the benefits outweigh the drawbacks? I can't judge.

Oh, and I mean mccopy will *smash*. Any existing cells in the destination will be cleared, and then the contents of the source rectangle will be copied into the destination. No or, no xor, or and, or, or buts.

[dvgrn]

If we make this change, we have the possibility of breaking scripts that load and save MCs and manipulate them using current coordinates. Do the benefits outweigh the drawbacks? I can't judge.

I think this might be one of the cases where it's better to apologize and ask for forgiveness, than to worry about it ahead of time.

There definitely aren't a whole lot of scripts that load macrocells out there, precisely because as soon as you need macrocells to store a pattern, you can't really manipulate the loaded pattern with Golly's cell lists anyway. There might be one or two Golly Python scripts out there that I'm not thinking of, that do something-or-other with macrocells -- but if so, presumably they can be fixed by adding a "+1" or a "-1" somewhere, so that really doesn't seem too scary.

Even megafier.py doesn't do anything too exciting with macrocells, it turns out. With the new coordinates everything will get created in a shifted location, but it should still work fine -- and anyway we'd immediately rewrite it for Golly 4.2, because it would run so much faster with the new functionality! (Read down a few posts from the link to see the problem with the current megafier script.)

I really can't think of any Golly scripts that would be affected... not that there aren't any, just that I'm willing to help fix however many there are.

The other possible problem is a communication problem: if some people are running pre-4.2 Golly and others are running Golly 4.2, they'll disagree about the precise coordinates of any pattern loaded from a macrocell. Again, like the coordinates in Chapter 12 of the Life textbook, I can't think of a lot of situations where anyone would quote actual coordinates. What you'd really do is post a copy with a LifeHistory red cell in it, and say "the red cell".

This proposed change is definitely several orders of magnitude less scary than going from Python 2 to Python 3, anyway, and we've done that with no more than the expected amount of confusion!

Maybe @calcyman can be given a deciding vote, since the change would slightly simplify the implementation of the hypothetical from_golly() and to_golly() functions.

Personally I'd definitely like to have the change happen. I've already lost quite a lot of time trying to figure out why my math was wrong in some macrocell-related calculation, only to realize it was because . I'm fairly confident that I'll spend significantly less time fixing hypothetical problems associated with the change, than I would spend troubleshooting and/or reminding people that Golly macrocells start at (0,1) where lifelib macrocells start at (0,0).

[Jormungant]

I was wondering if there is anything settled as far as producing these salvos, I see lengthy discussion about python scripts to explore useful reactions and emulating the expected behavior, but I was wondering if any completed pattern that use binary salvo has been made. I just had this wierd idea of storing the salvo data in some think of mod-3 single lane glider stream, and have a oscillator selectively ignoring all mod3 glider:

Code: Select all

x = 227, y = 80, rule = LifeHistory
3$14.A5.A73.A5.A73.A5.A$13.BAB3.BAB71.BAB3.BAB71.BAB3.BAB$14.2A3.2A
73.2A3.2A73.2A3.2A$11.B2.B.B.B.B2.B67.B2.B.B.B.B2.B67.B2.B.B.B.B2.B$
10.3AB.2A.2A.B3A65.3AB.2A.2A.B3A65.3AB.2A.2A.B3A$11.BA.A.A.A.A.AB67.B
A.A.A.A.A.AB67.BA.A.A.A.A.AB$13.B2A3.2AB71.B2A3.2AB71.B2A3.2AB2$13.B
2A3.2AB71.B2A3.2AB71.B2A3.2AB$11.BA.A.A.A.A.AB67.BA.A.A.A.A.AB67.BA.A
.A.A.A.AB$10.3AB.2A.2A.B3A65.3AB.2A.2A.B3A65.3AB.2A.2A.B3A$11.B2.B.B.
B.B2.B67.B2.B.B.B.B2.B67.B2.B.B.B.B2.B$14.2A3.2A14.B58.2A3.2A14.B58.
2A3.2A14.B$13.BAB3.BAB12.3B56.BAB3.BAB12.3B56.BAB3.BAB12.3B$14.A5.A
11.6B56.A5.A11.6B56.A5.A11.6B$26.4B2.7B3.B63.4B2.7B3.B63.4B2.7B3.B$
17.B2.2B2.19B54.B2.2B2.19B54.B2.2B2.19B$16.11BD23B45.11BD23B45.11BD
23B$12.B2.12BDBD21B.3B37.B2.12BDBD21B.3B37.B2.12BDBD21B.3B$11.2AB.B2A
9B3DB2A22B36.2AB.B2A9B3DB2A22B36.2AB.B2A9B3DB2A22B$11.2A3B2A11BDB2A
21B2A35.2A3B2A11BDB2A21B2A35.2A3B2A11BDB2A21B2A$12.B.38B.B2A36.B.38B.
B2A36.B.38B.B2A$14.7B.B5.23B3.B39.7B.B5.23B3.B39.7B.B5.23B3.B$13.7B
10.B2.18B42.7B10.B2.18B42.7B10.B2.18B$12.8B3.3B7.17B42.8B3.3B7.17B42.
8B3.3B7.17B$12.8B2.4B7.17B42.8B2.4B7.17B42.8B2.4B7.17B$9.3B.8B.6B5.
19B37.3B.8B.6B5.19B37.3B.8B.6B5.19B$9.19B6.18B37.19B6.18B37.19B6.18B$
8.2A18B6.4B2.12B36.2A18B6.4B2.12B36.2A18B6.4B2.12B$8.2A5BD10B2A12.11B
37.2A5BD10B2A12.11B37.2A5BD10B2A12.11B$9.B.3B3D9B2A12.8B41.B.3B3D9B2A
12.8B41.B.3B3D9B2A12.8B$11.5BD10B13.10B41.5BD10B13.10B41.5BD10B13.10B
$12.10B.5B8.A.2AB.4B2.2A42.10B.5B8.A.2AB.4B2.2A42.10B.5B8.A.2AB.4B2.
2A$12.9B13.3AB2AB7.A43.9B13.3AB2AB7.A43.9B13.3AB2AB7.A$12.11B10.A4.B
10.3A40.11B10.A4.B10.3A40.11B10.A4.B10.3A$13.10B11.3A.2A11.A41.10B11.
3A.2A11.A41.10B11.3A.2A11.A$12.12B12.A.A53.12B12.A.A53.12B12.A.A$11.
14B11.A.A52.14B11.A.A52.14B11.A.A$8.17B12.A50.17B12.A50.17B12.A$7.2A
15B63.2A15B63.2A15B$7.2A15B63.2A15B63.2A15B$8.17B63.17B63.17B$12.16B
29.B34.16B29.B34.16B29.B$13.16B27.3B34.16B27.3B34.16B27.3B$13.16B26.
4B34.16B26.4B34.16B26.4B$14.16B13.A10.4B36.16B13.A10.4B36.16B13.A10.
4B$11.20B12.3A7.4B34.20B12.3A7.4B34.20B12.3A7.4B$11.20B15.A5.4B35.20B
15.A5.4B35.20B15.A5.4B$10.20B15.2A4.4B35.20B15.2A4.4B35.20B15.2A4.4B$
9.22B14.9B6.2A27.22B14.9B6.2A27.22B14.9B6.2A$9.24B14.6B7.A28.24B14.6B
7.A28.24B14.6B7.A$10.26B2.2B2.B3.6B5.2A.A29.26B2.2B2.B3.6B5.2A.A29.
26B2.2B2.B3.6B5.2A.A$8.10B.13BD19B4.A2.A28.10B.13BD19B4.A2.A28.10B.
13BD14BC4B4.A2.A$8.2A4.2B2.7B.4BDBD13BCB.4B3.B2A29.2A4.2B2.7B.4BDBD
13BCBC4B3.B2A29.2A4.2B2.7B.4BDBD13BCB.4B3.B2A$9.A4.B4.B.3B2.4B3D9B2A
2BC.C9B31.A4.B4.B.3B2.4B3D9B2A2B2C10B31.A4.B4.B.3B2.4B3D9B2A2B3C9B$6.
3A4.2A3.2A2B4.4BD11B2A2B2C9B29.3A4.2A3.2A2B4.4BD11B2A3BC9B29.3A4.2A3.
2A2B4.4BD11B2A3B.9B$6.A6.A4.A2.AB4.29B30.A6.A4.A2.AB4.29B30.A6.A4.A2.
AB4.29B$11.A.A5.3A12.4B.17B35.A.A5.3A12.4B.17B35.A.A5.3A12.4B.17B$11.
2A22.2B3.15B36.2A22.2B3.15B36.2A22.2B3.15B$19.3A12.3B3.15B44.3A12.3B
3.15B44.3A12.3B3.15B$18.A2.A8.2A.2BA5.13B44.A2.A8.2A.2BA5.13B44.A2.A
8.2A.2BA5.13B$18.2A10.A.2BA.A2.13B46.2A10.A.2BA.A2.13B46.2A10.A.2BA.A
2.13B$31.A2.BA.A.2A4.8B58.A2.BA.A.2A4.8B58.A2.BA.A.2A4.8B$32.A4.AB2A
6.6B59.A4.AB2A6.6B59.A4.AB2A6.6B$30.A.5A2.B8.5B57.A.5A2.B8.5B57.A.5A
2.B8.5B$29.A.A4.A.2A.A.2A5.B.B56.A.A4.A.2A.A.2A5.B.B56.A.A4.A.2A.A.2A
5.B.B$30.A2.2A.A2.A.2A.A4.3B58.A2.2A.A2.A.2A.A4.3B58.A2.2A.A2.A.2A.A
4.3B$31.2A.A.2A11.B2AB58.2A.A.2A11.B2AB58.2A.A.2A11.B2AB$50.2A78.2A
78.2A!

Then one would need to have 2 such filters whose input is a forked from a single stream, and then the output set at the desired offset. If the pulsar phase is selected to differ in the 2 filter, the merged stream would have either one glider, or even both (there is some block pull that could be some with a single two glider salvo right?). In any case, I just wanted to throw this idea here so I know if it is a relevant idea at all.

[calcyman]

I was wondering if there is anything settled as far as producing these salvos, I see lengthy discussion about python scripts to explore useful reactions and emulating the expected behavior, but I was wondering if any completed pattern that use binary salvo has been made.

Did you see the shillelagh.mc post? That builds a shillelagh using a ~ 2000-bit binary slow salvo: viewtopic.php?f=2&t=4415&start=125#p144315

Just to be clear, the current basis that we're using (because it's the one produced by MathAndCode's 17-glider RCT) is this:

Code: Select all

x = 403, y = 391, rule = LifeHistory
400.3C72$256.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.
D.D.D.D2$256.D61.D2$256.D61.D2$256.D61.D2$256.D61.D2$256.D61.D2$256.D
53.3A5.D$312.A$256.D54.A6.D2$256.D61.D2$256.D61.D2$256.D61.D2$256.D
61.D2$256.D61.D2$256.D61.D2$256.D61.D2$256.D61.D2$256.D61.D2$256.D61.
D2$256.D61.D2$256.D61.D$298.5D$256.D40.7D14.D$296.3D3.3D$256.D39.2D5.
2D13.D$303.2D$256.D46.2D13.D$302.3D$256.D44.3D14.D$300.3D$256.D42.3D
16.D$298.3D$256.D40.3D18.D$296.3D$256.D39.9D13.D$263.2A31.9D$256.D5.A
.A53.D$264.A$256.D61.D2$256.D61.D2$256.D61.D2$256.D.D.D.D.D.D.D.D.D.D
.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D194$D.D.D.D.D.D.D.D.D.D.D
.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D2$D61.D2$D61.D2$D61.D2$D61.
D2$D61.D2$D61.D2$D61.D2$D61.D2$D61.D2$D61.D2$D61.D2$D61.D2$D61.D2$D
61.D2$D61.D2$D61.D2$D61.D2$D61.D2$D61.D$43.3D$D41.4D16.D$41.5D$D39.3D
.2D16.D$40.2D2.2D$D43.2D16.D$44.2D$D43.2D16.D$44.2D$D43.2D16.D$44.2D$
D43.2D16.D$44.2D$D39.9D13.D$7.2A31.9D$D5.A.A53.D$8.A$D61.D2$D61.D2$D
61.D2$D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D.D
!

so a 'binary slow salvo' specifically refers to a sequence of these '1's and '2's, where the gaps between successive bits are a sufficiently large multiple of 256 generations. (I realise that the first post in this thread is massively outdated; maybe we need to move to a new RCT17-specific thread?)

Also, binary slow salvos aren't primarily intended to be produced by Herschel tracks; they're emitted by a specific pair of glider-producing switch-engines:

Code: Select all

x = 108, y = 147, rule = B3/S23
obo$b2o$bo17$30bobo$33bo$29bo2bo$28b3o91$87bo$86bobo2$85bo2bo$85b2o$
85bo26$106b2o$105b2o$107bo!

[Jormungant]

I see, I guess the topic diverged to RCT at some point, but I did not read every post from 2020 do see that transition indeed. Well yes, I thought the idea was about self-construction, and proposing a less costly solution than plain single lane slow salvos allows, in terms of nb glider or construction time. Thanks you for the precision.

[gameoflifemaniac]

I'm currently on a train so can't upload the .mc.gz (it's 72 megabytes, and the on-train free wifi has a limit of 50).

Are you able to post it now?

[calcyman]

I'm currently on a train so can't upload the .mc.gz (it's 72 megabytes, and the on-train free wifi has a limit of 50).

Are you able to post it now?

Yes; thanks for reminding me: http://files.hatsya.co.uk/gol/meta8caterpillar.mc.gz

[dvgrn]

I'm currently on a train so can't upload the .mc.gz (it's 72 megabytes, and the on-train free wifi has a limit of 50).

Are you able to post it now?

Yes; thanks for reminding me: http://files.hatsya.co.uk/gol/meta8caterpillar.mc.gz

Wow. That needs some kind of video made of the zoom-in process... though something like a waterbear might be better -- more recognizable at full-scale and not just YABSL (Yet Another Boring Straight Line). As it stands, this one makes me really want to optimize the caterpillar.

[Macbi]

Danielle has been searching glider collisions to find a way to make the glider-pair stream from the south west in only 7G. She came up with this result:

Code: Select all

x = 340, y = 438, rule = B3/S23
obo$b2o$bo150$337bobo$337b2o$338bo47$139bo$137b2o$138b2o$131bo$129bobo
$130b2o2$126b3o$128bo$127bo222$334b3o$334bo$335bo$59b2o$58bobo$60bo!

There are 4 'dirty' gliders produced at the front that don't fit the pattern of the glider-pair stream. I tried all collisions with the first of these gliders to find collisions that cleanly reduce them to a constellation that could act as a target. I found 14 such collisions. Do any of the following suffice for our universal toolkit?

Code: Select all

x = 5224, y = 383, rule = B3/S23
362bo356bobo376bo378bo379bo373bo$363b2o355b2o375bo379bobo375b2o372b2o$
362b2o356bo376b3o377b2o377b2o372b2o8$2603b2o2617bo$2603bobo2615b2o$
359bo364bo360bo373bo379bo377bo373bo11bo361bo373bo373bo373bo373bo373bo
12bo360bo11bobo$359b2o363b2o359b2o372b2o378b2o376b2o372b2o372b2o372b2o
372b2o372b2o372b2o372b2o10b2o360b2o$358bobo362bobo358bobo371bobo377bob
o375bobo371bobo371bobo371bobo371bobo371bobo371bobo11bo359bobo10bobo
358bobo$2977b2o747b2o372bo372b2o$2977bobo745b2o372b2o372bobo$2977bo
373b3o373bo371bobo$3351bo$3352bo82$273b2o363b2o359b2o372b2o378b2o376b
2o372b2o372b2o372b2o372b2o372b2o372b2o372b2o372b2o$272bobo362bobo358bo
bo371bobo377bobo375bobo371bobo371bobo371bobo371bobo371bobo371bobo371bo
bo371bobo$274bo364bo360bo373bo379bo377bo373bo373bo373bo373bo373bo373bo
373bo373bo63$217b2o363b2o359b2o372b2o378b2o376b2o372b2o372b2o372b2o
372b2o372b2o372b2o372b2o372b2o$218b2o363b2o359b2o372b2o378b2o376b2o
372b2o372b2o372b2o372b2o372b2o372b2o372b2o372b2o$217bo364bo360bo373bo
379bo377bo373bo373bo373bo373bo373bo373bo373bo373bo6$23bo364bo360bo373b
o379bo377bo373bo373bo373bo373bo373bo373bo373bo373bo$21bobo362bobo358bo
bo371bobo377bobo375bobo371bobo371bobo371bobo371bobo371bobo371bobo371bo
bo371bobo$22b2o363b2o359b2o372b2o378b2o376b2o372b2o372b2o372b2o372b2o
372b2o372b2o372b2o372b2o62$87bo364bo360bo373bo379bo377bo373bo373bo373b
o373bo373bo373bo373bo373bo$85bobo362bobo358bobo371bobo377bobo375bobo
371bobo371bobo371bobo371bobo371bobo371bobo371bobo371bobo$86b2o363b2o
359b2o372b2o378b2o376b2o372b2o372b2o372b2o372b2o372b2o372b2o372b2o372b
2o12$128b3o362b3o358b3o371b3o377b3o375b3o371b3o371b3o371b3o371b3o371b
3o371b3o371b3o371b3o$130bo364bo360bo373bo379bo377bo373bo373bo373bo373b
o373bo373bo373bo373bo$129bo364bo360bo373bo379bo377bo373bo373bo373bo
373bo373bo373bo373bo373bo39$81b2o363b2o359b2o372b2o378b2o376b2o372b2o
372b2o372b2o372b2o372b2o372b2o372b2o372b2o$80bobo362bobo358bobo371bobo
377bobo375bobo371bobo371bobo371bobo371bobo371bobo371bobo371bobo371bobo
$82bo364bo360bo373bo379bo377bo373bo373bo373bo373bo373bo373bo373bo373bo
18$154b2o363b2o359b2o372b2o378b2o376b2o372b2o372b2o372b2o372b2o372b2o
372b2o372b2o372b2o$154bobo362bobo358bobo371bobo377bobo375bobo371bobo
371bobo371bobo371bobo371bobo371bobo371bobo371bobo$154bo364bo360bo373bo
379bo377bo373bo373bo373bo373bo373bo373bo373bo373bo$64b3o362b3o358b3o
371b3o377b3o375b3o371b3o371b3o371b3o371b3o371b3o371b3o371b3o371b3o$66b
o364bo360bo373bo379bo377bo373bo373bo373bo373bo373bo373bo373bo373bo$65b
o364bo360bo373bo379bo377bo373bo373bo373bo373bo373bo373bo373bo373bo39$
17b2o363b2o359b2o372b2o378b2o376b2o372b2o372b2o372b2o372b2o372b2o372b
2o372b2o372b2o$16bobo362bobo358bobo371bobo377bobo375bobo371bobo371bobo
371bobo371bobo371bobo371bobo371bobo371bobo$18bo364bo360bo373bo379bo
377bo373bo373bo373bo373bo373bo373bo373bo373bo18$218b2o363b2o359b2o372b
2o378b2o376b2o372b2o372b2o372b2o372b2o372b2o372b2o372b2o372b2o$218bobo
362bobo358bobo371bobo377bobo375bobo371bobo371bobo371bobo371bobo371bobo
371bobo371bobo371bobo$218bo364bo360bo373bo379bo377bo373bo373bo373bo
373bo373bo373bo373bo373bo$3o362b3o358b3o371b3o377b3o375b3o371b3o371b3o
371b3o371b3o371b3o371b3o371b3o371b3o$2bo364bo360bo373bo379bo377bo373bo
373bo373bo373bo373bo373bo373bo373bo$bo364bo360bo373bo379bo377bo373bo
373bo373bo373bo373bo373bo373bo373bo!

If so then I believe this reduces the RCT to 16G.

EDIT: Actually the 2nd and 4th 'dirty' gliders line up with where a clean glider would be, but this doesn't affect the validity of the above collisions.

[calcyman]

Danielle has been searching glider collisions to find a way to make the glider-pair stream from the south west in only 7G. She came up with this result:

Code: Select all

x = 340, y = 438, rule = B3/S23
obo$b2o$bo150$337bobo$337b2o$338bo47$139bo$137b2o$138b2o$131bo$129bobo
$130b2o2$126b3o$128bo$127bo222$334b3o$334bo$335bo$59b2o$58bobo$60bo!

There are 4 'dirty' gliders produced at the front that don't fit the pattern of the glider-pair stream. I tried all collisions with the first of these gliders to find collisions that cleanly reduce them to a constellation that could act as a target. I found 14 such collisions. Do any of the following suffice for our universal toolkit?

Yes, the rightmost collision is the beginning of the standard honeyfarm crystal (with some extra irrelevant junk*), and I have a mechanism (which appears in shillelagh.mc) for converting the standard honeyfarm crystal into the versatile blinker elbow.

Code: Select all

x = 550, y = 542, rule = B3/S23
548bo$547b2o$535bo11bobo$535b2o$534bobo87$449b2o$448bobo$450bo63$393b
2o$394b2o$393bo6$199bo$197bobo$198b2o62$263bo$261bobo$262b2o12$304b3o$
306bo$305bo39$257b2o$256bobo$258bo18$330b2o$330bobo$330bo$240b3o$242bo
$241bo39$193b2o$192bobo$194bo18$394b2o$394bobo$394bo$176b3o$178bo$177b
o39$129b2o$128bobo$130bo62$65b2o$64bobo$66bo62$b2o$obo$2bo!

* in the worst-case scenario, we can use slow^3 gliders to eliminate that extra junk.

If so then I believe this reduces the RCT to 16G.

Confirmed! Congratulations to you and Danielle for improving the RCT constant to a nice round power of two!

[Pavgran]

And the third option from the left also makes a honeyfarm plus less junk.

Code: Select all

x = 1940, y = 1926, rule = B3/S23
22bo$23b2o$22b2o62$86bo$87b2o$86b2o62$150bo$151b2o$150b2o62$214bo$215b
2o$214b2o62$278bo$279b2o$278b2o62$342bo$343b2o$342b2o62$406bo$407b2o$
406b2o62$470bo$471b2o$470b2o62$534bo$535b2o$534b2o62$598bo$599b2o$598b
2o17$1259bobo$1259b2o$1260bo43$662bo$663b2o$662b2o62$726bo$727b2o$726b
2o62$790bo$791b2o$790b2o20$1063b2o$1062bobo$1064bo40$854bo$855b2o$854b
2o45$977b2o$978b2o$977bo63$921b3o$923bo$922bo81$1042b2o$1041b2o$833bo
209bo$833b2o$832bobo40$785b2o$786b2o$785bo18$1106b2o$1105b2o$769bo337b
o$769b2o$768bobo40$721b2o$722b2o$721bo18$1170b2o$1169b2o$1171bo42$657b
2o$658b2o$657bo18$1234b2o$1233b2o$1235bo42$593b2o$594b2o$593bo18$1298b
2o$1297b2o$1299bo42$529b2o$530b2o$529bo18$1362b2o$1361b2o$1363bo42$
465b2o$466b2o$465bo18$1426b2o$1425b2o$1427bo42$401b2o$402b2o$401bo18$
1490b2o$1489b2o$1491bo42$337b2o$338b2o$337bo18$1554b2o$1553b2o$1555bo
42$273b2o$274b2o$273bo18$1618b2o$1617b2o$1619bo42$209b2o$210b2o$209bo
18$1682b2o$1681b2o$1683bo42$145b2o$146b2o$145bo18$1746b2o$1745b2o$
1747bo42$81b2o$82b2o$81bo18$1810b2o$1809b2o$65bo1745bo$65b2o$64bobo40$
17b2o$18b2o$17bo18$1874b2o$1873b2o$bo1873bo$b2o$obo60$1938b2o$1937b2o$
1939bo!

[calcyman]

And the third option from the left also makes a honeyfarm plus less junk.

Great! This one can be cleaned up to a standard blinker elbow in approximately 250 bits, without involving any slow^3 gliders or suchlike:

Code: Select all

x = 129318, y = 129320, rule = B3/S23
129316bo$129315bo$129315b3o10$129303bo$129303b2o$129302bobo87$129217b
2o$129216bobo$129218bo63$129161b2o$129162b2o$129161bo84$129072b3o$
129074bo$129073bo39$129025b2o$129024bobo$129026bo510$128513b2o$128512b
obo$128514bo510$128001b2o$128000bobo$128002bo510$127489b2o$127488bobo$
127490bo510$126977b2o$126976bobo$126978bo510$126465b2o$126464bobo$
126466bo510$125953b2o$125952bobo$125954bo510$125441b2o$125440bobo$
125442bo510$124929b2o$124928bobo$124930bo510$124417b2o$124416bobo$
124418bo510$123905b2o$123904bobo$123906bo510$123393b2o$123392bobo$
123394bo469$122928b3o$122930bo$122929bo39$122881b2o$122880bobo$122882b
o469$122416b3o$122418bo$122417bo39$122369b2o$122368bobo$122370bo510$
121857b2o$121856bobo$121858bo469$121392b3o$121394bo$121393bo39$121345b
2o$121344bobo$121346bo469$120880b3o$120882bo$120881bo39$120833b2o$
120832bobo$120834bo510$120321b2o$120320bobo$120322bo469$119856b3o$
119858bo$119857bo39$119809b2o$119808bobo$119810bo510$119297b2o$119296b
obo$119298bo510$118785b2o$118784bobo$118786bo510$118273b2o$118272bobo$
118274bo469$117808b3o$117810bo$117809bo39$117761b2o$117760bobo$117762b
o510$117249b2o$117248bobo$117250bo469$116784b3o$116786bo$116785bo39$
116737b2o$116736bobo$116738bo510$116225b2o$116224bobo$116226bo510$
115713b2o$115712bobo$115714bo469$115248b3o$115250bo$115249bo39$115201b
2o$115200bobo$115202bo510$114689b2o$114688bobo$114690bo469$114224b3o$
114226bo$114225bo39$114177b2o$114176bobo$114178bo510$113665b2o$113664b
obo$113666bo469$113200b3o$113202bo$113201bo39$113153b2o$113152bobo$
113154bo510$112641b2o$112640bobo$112642bo469$112176b3o$112178bo$
112177bo39$112129b2o$112128bobo$112130bo510$111617b2o$111616bobo$
111618bo510$111105b2o$111104bobo$111106bo469$110640b3o$110642bo$
110641bo39$110593b2o$110592bobo$110594bo510$110081b2o$110080bobo$
110082bo469$109616b3o$109618bo$109617bo39$109569b2o$109568bobo$109570b
o510$109057b2o$109056bobo$109058bo510$108545b2o$108544bobo$108546bo
469$108080b3o$108082bo$108081bo39$108033b2o$108032bobo$108034bo510$
107521b2o$107520bobo$107522bo510$107009b2o$107008bobo$107010bo469$
106544b3o$106546bo$106545bo39$106497b2o$106496bobo$106498bo510$105985b
2o$105984bobo$105986bo510$105473b2o$105472bobo$105474bo469$105008b3o$
105010bo$105009bo39$104961b2o$104960bobo$104962bo510$104449b2o$104448b
obo$104450bo510$103937b2o$103936bobo$103938bo469$103472b3o$103474bo$
103473bo39$103425b2o$103424bobo$103426bo510$102913b2o$102912bobo$
102914bo510$102401b2o$102400bobo$102402bo469$101936b3o$101938bo$
101937bo39$101889b2o$101888bobo$101890bo510$101377b2o$101376bobo$
101378bo510$100865b2o$100864bobo$100866bo469$100400b3o$100402bo$
100401bo39$100353b2o$100352bobo$100354bo510$99841b2o$99840bobo$99842bo
510$99329b2o$99328bobo$99330bo469$98864b3o$98866bo$98865bo39$98817b2o$
98816bobo$98818bo510$98305b2o$98304bobo$98306bo510$97793b2o$97792bobo$
97794bo510$97281b2o$97280bobo$97282bo510$96769b2o$96768bobo$96770bo
510$96257b2o$96256bobo$96258bo510$95745b2o$95744bobo$95746bo469$95280b
3o$95282bo$95281bo39$95233b2o$95232bobo$95234bo510$94721b2o$94720bobo$
94722bo510$94209b2o$94208bobo$94210bo469$93744b3o$93746bo$93745bo39$
93697b2o$93696bobo$93698bo510$93185b2o$93184bobo$93186bo510$92673b2o$
92672bobo$92674bo469$92208b3o$92210bo$92209bo39$92161b2o$92160bobo$
92162bo510$91649b2o$91648bobo$91650bo510$91137b2o$91136bobo$91138bo
469$90672b3o$90674bo$90673bo39$90625b2o$90624bobo$90626bo510$90113b2o$
90112bobo$90114bo510$89601b2o$89600bobo$89602bo510$89089b2o$89088bobo$
89090bo510$88577b2o$88576bobo$88578bo469$88112b3o$88114bo$88113bo39$
88065b2o$88064bobo$88066bo510$87553b2o$87552bobo$87554bo510$87041b2o$
87040bobo$87042bo510$86529b2o$86528bobo$86530bo510$86017b2o$86016bobo$
86018bo510$85505b2o$85504bobo$85506bo510$84993b2o$84992bobo$84994bo
469$84528b3o$84530bo$84529bo39$84481b2o$84480bobo$84482bo510$83969b2o$
83968bobo$83970bo510$83457b2o$83456bobo$83458bo469$82992b3o$82994bo$
82993bo39$82945b2o$82944bobo$82946bo510$82433b2o$82432bobo$82434bo510$
81921b2o$81920bobo$81922bo510$81409b2o$81408bobo$81410bo510$80897b2o$
80896bobo$80898bo510$80385b2o$80384bobo$80386bo469$79920b3o$79922bo$
79921bo39$79873b2o$79872bobo$79874bo510$79361b2o$79360bobo$79362bo510$
78849b2o$78848bobo$78850bo469$78384b3o$78386bo$78385bo39$78337b2o$
78336bobo$78338bo510$77825b2o$77824bobo$77826bo510$77313b2o$77312bobo$
77314bo469$76848b3o$76850bo$76849bo39$76801b2o$76800bobo$76802bo469$
76336b3o$76338bo$76337bo39$76289b2o$76288bobo$76290bo510$75777b2o$
75776bobo$75778bo510$75265b2o$75264bobo$75266bo510$74753b2o$74752bobo$
74754bo469$74288b3o$74290bo$74289bo39$74241b2o$74240bobo$74242bo510$
73729b2o$73728bobo$73730bo510$73217b2o$73216bobo$73218bo469$72752b3o$
72754bo$72753bo39$72705b2o$72704bobo$72706bo510$72193b2o$72192bobo$
72194bo469$71728b3o$71730bo$71729bo39$71681b2o$71680bobo$71682bo510$
71169b2o$71168bobo$71170bo510$70657b2o$70656bobo$70658bo469$70192b3o$
70194bo$70193bo39$70145b2o$70144bobo$70146bo510$69633b2o$69632bobo$
69634bo510$69121b2o$69120bobo$69122bo469$68656b3o$68658bo$68657bo39$
68609b2o$68608bobo$68610bo510$68097b2o$68096bobo$68098bo510$67585b2o$
67584bobo$67586bo469$67120b3o$67122bo$67121bo39$67073b2o$67072bobo$
67074bo510$66561b2o$66560bobo$66562bo510$66049b2o$66048bobo$66050bo
469$65584b3o$65586bo$65585bo39$65537b2o$65536bobo$65538bo510$65025b2o$
65024bobo$65026bo510$64513b2o$64512bobo$64514bo469$64048b3o$64050bo$
64049bo39$64001b2o$64000bobo$64002bo469$63536b3o$63538bo$63537bo39$
63489b2o$63488bobo$63490bo510$62977b2o$62976bobo$62978bo510$62465b2o$
62464bobo$62466bo469$62000b3o$62002bo$62001bo39$61953b2o$61952bobo$
61954bo510$61441b2o$61440bobo$61442bo510$60929b2o$60928bobo$60930bo
469$60464b3o$60466bo$60465bo39$60417b2o$60416bobo$60418bo469$59952b3o$
59954bo$59953bo39$59905b2o$59904bobo$59906bo510$59393b2o$59392bobo$
59394bo510$58881b2o$58880bobo$58882bo510$58369b2o$58368bobo$58370bo
510$57857b2o$57856bobo$57858bo510$57345b2o$57344bobo$57346bo510$56833b
2o$56832bobo$56834bo469$56368b3o$56370bo$56369bo39$56321b2o$56320bobo$
56322bo510$55809b2o$55808bobo$55810bo510$55297b2o$55296bobo$55298bo
469$54832b3o$54834bo$54833bo39$54785b2o$54784bobo$54786bo510$54273b2o$
54272bobo$54274bo510$53761b2o$53760bobo$53762bo469$53296b3o$53298bo$
53297bo39$53249b2o$53248bobo$53250bo510$52737b2o$52736bobo$52738bo510$
52225b2o$52224bobo$52226bo469$51760b3o$51762bo$51761bo39$51713b2o$
51712bobo$51714bo510$51201b2o$51200bobo$51202bo510$50689b2o$50688bobo$
50690bo469$50224b3o$50226bo$50225bo39$50177b2o$50176bobo$50178bo510$
49665b2o$49664bobo$49666bo510$49153b2o$49152bobo$49154bo469$48688b3o$
48690bo$48689bo39$48641b2o$48640bobo$48642bo510$48129b2o$48128bobo$
48130bo510$47617b2o$47616bobo$47618bo469$47152b3o$47154bo$47153bo39$
47105b2o$47104bobo$47106bo510$46593b2o$46592bobo$46594bo510$46081b2o$
46080bobo$46082bo510$45569b2o$45568bobo$45570bo510$45057b2o$45056bobo$
45058bo469$44592b3o$44594bo$44593bo39$44545b2o$44544bobo$44546bo510$
44033b2o$44032bobo$44034bo510$43521b2o$43520bobo$43522bo469$43056b3o$
43058bo$43057bo39$43009b2o$43008bobo$43010bo510$42497b2o$42496bobo$
42498bo469$42032b3o$42034bo$42033bo39$41985b2o$41984bobo$41986bo469$
41520b3o$41522bo$41521bo39$41473b2o$41472bobo$41474bo510$40961b2o$
40960bobo$40962bo510$40449b2o$40448bobo$40450bo510$39937b2o$39936bobo$
39938bo510$39425b2o$39424bobo$39426bo510$38913b2o$38912bobo$38914bo
469$38448b3o$38450bo$38449bo39$38401b2o$38400bobo$38402bo510$37889b2o$
37888bobo$37890bo510$37377b2o$37376bobo$37378bo510$36865b2o$36864bobo$
36866bo469$36400b3o$36402bo$36401bo39$36353b2o$36352bobo$36354bo469$
35888b3o$35890bo$35889bo39$35841b2o$35840bobo$35842bo510$35329b2o$
35328bobo$35330bo510$34817b2o$34816bobo$34818bo510$34305b2o$34304bobo$
34306bo510$33793b2o$33792bobo$33794bo510$33281b2o$33280bobo$33282bo
510$32769b2o$32768bobo$32770bo469$32304b3o$32306bo$32305bo39$32257b2o$
32256bobo$32258bo510$31745b2o$31744bobo$31746bo510$31233b2o$31232bobo$
31234bo469$30768b3o$30770bo$30769bo39$30721b2o$30720bobo$30722bo510$
30209b2o$30208bobo$30210bo510$29697b2o$29696bobo$29698bo469$29232b3o$
29234bo$29233bo39$29185b2o$29184bobo$29186bo510$28673b2o$28672bobo$
28674bo510$28161b2o$28160bobo$28162bo469$27696b3o$27698bo$27697bo39$
27649b2o$27648bobo$27650bo510$27137b2o$27136bobo$27138bo510$26625b2o$
26624bobo$26626bo469$26160b3o$26162bo$26161bo39$26113b2o$26112bobo$
26114bo510$25601b2o$25600bobo$25602bo510$25089b2o$25088bobo$25090bo
469$24624b3o$24626bo$24625bo39$24577b2o$24576bobo$24578bo510$24065b2o$
24064bobo$24066bo510$23553b2o$23552bobo$23554bo469$23088b3o$23090bo$
23089bo39$23041b2o$23040bobo$23042bo510$22529b2o$22528bobo$22530bo510$
22017b2o$22016bobo$22018bo469$21552b3o$21554bo$21553bo39$21505b2o$
21504bobo$21506bo510$20993b2o$20992bobo$20994bo510$20481b2o$20480bobo$
20482bo469$20016b3o$20018bo$20017bo39$19969b2o$19968bobo$19970bo510$
19457b2o$19456bobo$19458bo510$18945b2o$18944bobo$18946bo469$18480b3o$
18482bo$18481bo39$18433b2o$18432bobo$18434bo510$17921b2o$17920bobo$
17922bo510$17409b2o$17408bobo$17410bo469$16944b3o$16946bo$16945bo39$
16897b2o$16896bobo$16898bo510$16385b2o$16384bobo$16386bo469$15920b3o$
15922bo$15921bo39$15873b2o$15872bobo$15874bo510$15361b2o$15360bobo$
15362bo510$14849b2o$14848bobo$14850bo510$14337b2o$14336bobo$14338bo
510$13825b2o$13824bobo$13826bo510$13313b2o$13312bobo$13314bo510$12801b
2o$12800bobo$12802bo469$12336b3o$12338bo$12337bo39$12289b2o$12288bobo$
12290bo510$11777b2o$11776bobo$11778bo510$11265b2o$11264bobo$11266bo
469$10800b3o$10802bo$10801bo39$10753b2o$10752bobo$10754bo510$10241b2o$
10240bobo$10242bo510$9729b2o$9728bobo$9730bo469$9264b3o$9266bo$9265bo
39$9217b2o$9216bobo$9218bo510$8705b2o$8704bobo$8706bo469$8240b3o$8242b
o$8241bo39$8193b2o$8192bobo$8194bo469$7728b3o$7730bo$7729bo39$7681b2o$
7680bobo$7682bo510$7169b2o$7168bobo$7170bo510$6657b2o$6656bobo$6658bo
469$6192b3o$6194bo$6193bo39$6145b2o$6144bobo$6146bo510$5633b2o$5632bob
o$5634bo469$5168b3o$5170bo$5169bo39$5121b2o$5120bobo$5122bo469$4656b3o
$4658bo$4657bo39$4609b2o$4608bobo$4610bo510$4097b2o$4096bobo$4098bo
510$3585b2o$3584bobo$3586bo469$3120b3o$3122bo$3121bo39$3073b2o$3072bob
o$3074bo510$2561b2o$2560bobo$2562bo510$2049b2o$2048bobo$2050bo510$
1537b2o$1536bobo$1538bo510$1025b2o$1024bobo$1026bo469$560b3o$562bo$
561bo39$513b2o$512bobo$514bo510$b2o$obo$2bo!

[dvgrn]

And the third option from the left also makes a honeyfarm plus less junk.

Great! This one can be cleaned up to a standard blinker elbow in approximately 250 bits, without involving any slow^3 gliders or suchlike...

Will there be a revised builder script for 16G soon, then, and/or maybe a revised shillelagh.mc and associated display script?

I've just been adding some notes to the post after that one, so that I can link to it from an RCT-explained-in-painful-detail blog post. It's useful to have a "template" pattern in LifeViewer for easy copying.

The new template will have a dot at eight of the nine likely locations, right? -- everywhere except top center?

One of the details I haven't dug up yet is why the NW and SW GPSEs get built so much earlier than the SE one. Any reminders or pointers would be appreciated.