dvgrn wrote:Another option [for a Geminoid replicator unit with a 10hd construction arm]: 68 Spartan still lifes (or thereabouts) with a high proportion of blocks, but with a couple of eaters in the danger zone...

I've looked over the technology a little more, and I think that for a diagonal Geminoid design, it will be better not to put any obstructions within half a dozen lanes of the construction arm. The 68-still-life layout would work fine for a Geminoid that travels obliquely, but the constraints are a bit tougher for the diagonal version.

Here's a 87-still-life 10hd Geminoid design that I think stays a safe distance from the construction lanes. The only thing that comes within a dozen lanes is a single eater in Circuit B, part of an Fx77 conduit -- and that eater can be constructed last, so there shouldn't be any problem.

It looks as if 10hd construction arms are about one-third more efficient than 9hd construction arms, in terms of elbow operations and/or the total number of glider pairs in the average recipe. This seems to be because the 10hd toolkit includes longer INC and DEC operations and a wider variety of glider outputs. I'm still working on the details, but it seems pretty clear that there's a significant advantage -- so at this point I'm officially switching over to developing 10hd technology.

The original reason to investigate 10hd glider pairs is that 10hd is compatible with semi-Snarks, whereas 9hd isn't. This may eventually be useful somehow, but construction difficulties showed up several posts back: at least one semi-Snark would have to be built right on the construction arm's glider-pair lanes. That's certainly possible, but it would take new technology to do it efficiently. So for now the jury is still out on semi-Snark-assisted layouts, at least for diagonal Geminoids.

There's one other big reason that I prefer the above layout to the smaller 10hd designs. In this version, Circuit A and Circuit B both contain an F166 conduit, which is trivial to switch on and off as this design requires. The one-time switching circuitry is all included in the 87 still lifes, so the only thing not shown is a construction-arm elbow block.

-- Except for the seeds for the self-destruct circuitry, of course. Anyone want to try their hand at getting this replicator unit to self-destruct? It's lots of fun for those who like impressive explosions (and who doesn't, after all?)

Here's a template for the 10hd Geminoid R.U. that can be pasted in as a puzzle to the latest Seeds of Destruction Game alpha. If you'd prefer a different starting point for the puzzle, the glider can be moved southeast some distance, as long as the one-time-turner/eater combination in the southeast is adjusted to match it.

Unfortunately the latest SODGame still has the bug where the Copy button doesn't work for newly pasted puzzles. It works fine for the pre-set puzzles, though -- so for now, I'll try to put together an alpha with this puzzle as one of the built-in options.

dvgrn wrote:Anyone want to try their hand at getting this replicator unit to self-destruct? It's lots of fun for those who like impressive explosions (and who doesn't, after all?)

Here's an upper bound for the self-destruct problem. This is a seriously sub-optimal job of seeding, put together as quickly as possible just to get a working prototype -- 92 seeds to destroy 82 still lifes. A good solution should at least be able to beat one seed per still life, and that's if the seeds are mostly blocks.

There are only 82 still lifes to destroy instead of 87, because the elbow block and one-time turners are already gone by the self-destruct stage. The Circuit A and Circuit B switches are also in different positions from their starting states. The original block locations are marked in red:

Below I've strung together three Geminoids to show how the self-destruction works. When the Geminoid is in full working order, there will never be more than two replicator units in a row. For now you just have to imagine the NW and SE replicator units are much much farther apart, with a construction recipe strung out between them -- and that the gliders going through each R.U. are doing the work of constructing the next one in line to the northeast.

Having spent a little time with the Seeds of Destruction game now, I get the feeling that there are probably self-destruct seedings out there with fewer than fifty additional seeds -- or sixty, if they're all blocks.

Here's a new line of investigation for 10hd construction arms: oblique Geminoids!

It turns out that with 10-cell separation between the two construction-arm lanes, it's possible to put together a complete Geminoid with less than 50 still lifes per replicator unit (RU). The design below has a single Silver reflector to do the 180-degree reflection of the recipe between RUs, and four of Guam's semi-Snarks to decode the recipe into channels -- two for each RU:

Instead of using one-time switching mechanisms and sending each channel's gliders in an uninterrupted stream, this Geminoid design uses encoded pairs of pairs of gliders, (AB)(CD), on a single channel. A and B are the NW coding gliders and the SE reset gliders. Conversely, C and D are the NW reset gliders and the SE coding gliders.

An odd feature of this design is that in the SE RU, the elbow has to bend in the opposite direction relative to the input. To put it another way, both elbows have to do their constructions around a left-hand turn, even though the R.U.s are almost exact mirror images of each other (the only difference is that blocks in two of the semi-Snarks are in different positions).

This means that the NW and SE P2 slow glider salvos will be almost identical -- but the glider-pair recipes that build those two slow salvos won't match up at all! This design would theoretically allow completely different circuitry to be constructed at the NW and SE ends, as long as the two glider-pair recipes are exactly the same length.

Programming these constructor arms will require solving a few new problems, though. There's still some searching and sorting to be done to find a universal elbow-operation toolkit that works with this layout. As with the original two-arm Geminoid, singleton gliders are forbidden here, and glider pairs strictly between 27 and 65 in my numbering system [see the 10hd builder script] can't be used because of the inevitable semi-Snark signal crossing.

Side note: actually that crossing may not be inevitable after all. A Herschel period quadrupler and glider inserter could be used instead of one of the semi-Snark pairs, maybe at the cost of a few more still lifes.

Singletons would still be forbidden, but there are two possible hacks for that also. There are almost certainly elbow operations that can simulate the most important kind of singleton glider, the kind that will switch the chirality of the elbow -- i.e., move the block with a (2,1) pull to its mirror-image lane.

There may also be ways of deliberately colliding one or more A and B signals, so that the resulting debris suppresses one glider, lets the other one through, and -- maybe, after the next set of A and B signals? -- allows the semi-Snarks to return to their correct phases. The simple vanish reactions won't do this (they allow two singleton gliders through, one after the other, which isn't much use) but there are lots of possibilities involving blinkers and traffic lights.

Here's a series of four oblique Geminoids with a knightship offset, (-110,220). It may be necessary to add a few self-destruct seeds to this version, since the outlying semi-Snarks can't be reached with southbound *WSSes generated directly by the elbow. Direct LWSS cleanup should work above a (-146,256) offset or so.

It would also work (at any offset) to bend the constructor-arm elbow backwards and use it as a destructor arm, with a secondary "slow elbow". Exponentially more expensive, but perfectly workable -- and with an RU this size, the cleanup won't need all that many gliders in any case. As with the LWSS cleanup method, there will be some possible signal crossing problems in the NW RU, but nothing serious.

Anyway, I'll still finish the diagonal Geminoid first, since it doesn't have any of these new difficulties with signal crossings or singleton gliders. This oblique Geminoid will have to wait in the wings for a while yet, along with the spiral-growth Geminoid and the linear replicator -- unless someone else wants to give one of those a try, of course!

Wha'ts the release date of the geminoid? Hashlife doesn't like gemino, so a lighter constructir would be welcome.

Besides, I just got an idea for the linear replicator:to build the tape, why not launching a flottilla to build a cordership, then another to destroy it later? This would allow to build thing miles away without a single effort!The idea came seeing gemini struggling and taking millions geneartions to push a block.

This is game of life, this is game of life!Loafin' ships eaten with a knife!

towerator wrote:Wha'ts the release date of the geminoid? Hashlife doesn't like gemino, so a lighter constructir would be welcome.

There aren't too many hours of programming left on the slow-salvo compiler now, I think, but there's still quite a bit of sorting and searching left, to get a few more slow-salvo and glider-pair recipes into their respective libraries.

It's not clear yet when the Geminoid will actually fly. These days I'm only working on it for a few late-night hours at a time, mostly as a cure for insomnia... volunteer help with the project has been a bit scarce lately.

towerator wrote:I just got an idea for the linear replicator:to build the tape, why not launching a flottilla to build a cordership, then another to destroy it later? This would allow to build thing miles away without a single effort!The idea came seeing gemini struggling and taking millions geneartions to push a block.

That option has been around for a good while. There's actually a new option now for a slow object chased by a fast one, which might be somewhat cheaper to build: construct a loafer, then chase it with a few spaceships, produce a glider, and crash it into another glider to produce a faraway elbow block.

Unfortunately, for either Corderships or loafers, I think it will take a lot of delay circuitry to wait around for many thousands of ticks and then send a timed following signal out. You almost might as well just build a block-pushing gun and run it for a similar length of time, and skip all the extra construction circuitry.

As the link above notes, your Cordership might be somewhat better in this regard. You can get longer and longer delays by bouncing gliders off a receding Cordership, but I don't think there's going to be a way to bounce *WSSes off a loafer!

Anyway, I don't think Hashlife is going to be entirely happy with these new smallest-possible Geminoids, either, because the spatial and temporal repeat rates are going to be powers of two. Oddly enough, it might be necessary to build a much bigger Geminoid to get pure 2^N spacetime repetition and a really fast run rate. The Blockic-seed loafer gun was an experiment along these lines. Golly is easily able to "run away" with the long skinny version of the gun, since everything ends up being a nice simple power of two -- whereas the double-spiral version has far too many different hash tiles.

I think that a four-cornered, diamond-shaped Geminoid might be the best for keeping the number of hashtiles down -- the biggest explosion of hashtiles seems to happen when a glider data stream doubles back closely on itself. But it doesn't seem right to cater to Hashlife too much, somehow, so for now I'm optimizing the number of still lifes in the replicator unit, rather than the speed that Golly can simulate a replication cycle.

Hmm...The tape problem of a 1 arm geminoid is unsolvable without a cordership or something:to build the reflector at the other end of the tape, a geminoid may need to extend an XXL arm.problem:to build the arm, one needs a longer tape than the arm in the tape (as 1 glider = the block gets pushed 1 time)and therefore, one needs a flottilla of G to push this block to the desired sopt.but it needs an even bigger tape to code.And so, if you manage to push the block to x, the tape has to be nx, where n > 1

Another possibility: a gun which reapeats the steps until the block reaches the desired position, where the block gets destroyed.

This is game of life, this is game of life!Loafin' ships eaten with a knife!

{Scroll to the bottom for a 44.5-still-life Geminoid replicator unit...!}

towerator wrote:Hmm...The tape problem of a 1 arm geminoid is unsolvable without a cordership or something...if you manage to push the block to x, the tape has to be nx, where n > 1

Well, but that's one of the key points in Andrew Wade's original Gemini spaceship: the reflector at the other end is its own replicator unit. Each end of the tape independently makes a shifted copy of itself, so there's no need to shove a block all the way from one to the other.

Another stroke of genius was that Andrew just threw away the whole static-memory-tape part of the old 2003 prototype universal constructor. Instead, all of the timing information for pairs of colliding gliders was encoded directly in a huge glider loop... or rather twelve loops... well, they're not really loops -- more like zigzags.

[Sometimes it's really hard to avoid gratuitous use of the word "boustrophedonic".]

Geminoid designs shamelessly borrow this same trick and take it one step further. It turns out that a construction elbow can be moved forward and back, and gliders can be sent out from the elbow on any lane in either direction, by salvos consisting of pairs of gliders on just two lanes. The best spacing seems to be 9 or 10 cells between lanes.

So Geminoid replicator units have only two channels instead of the Gemini's twelve, and each channel is just an exact copy of the gliders that have to be sent toward the elbow, down one of the two parallel lanes in the construction arm.

Then there are various ways of encoding the two channels into one -- so you end up with a single stream of gliders that can be trivially reflected or copied, but that still encodes a construction for a complete replicator unit.

towerator wrote:Another possibility: a gun which repeats the steps until the block reaches the desired position, where the block gets destroyed.

Yes that's the non-Geminoid way to do it. It's certainly possible to create special-purpose circuitry to repeat operations many times, delay for exponentially many ticks, store sub-programs in static or glider-loop memory to make constructions more efficient, and so on.

But for self-constructing circuitry, each new efficiency-increasing circuit is another complex object that then has to be constructed! For the Geminoid project I've been exploring in the exact opposite direction, to try to design replicator units with the absolute minimum size.

Here's my best effort so far, following up on yesterday's 49-cell Geminoid replicator unit. Taking out one pair of semi-Snarks and replacing it with a 4H-to-G gets rid of the entire signal-crossing problem -- and reduces the replicator unit to 44.5 still lifes:

This sample pattern includes both replicator units -- just imagine that they're hundreds of thousands of cells farther apart, with a complete construction recipe for both units strung out between them. There may be something still smaller than this, but I think it may be necessary to invent a new Herschel period quadrupler (or a new stable G-to-H) to get below 40 still lifes.

In this design each cycle is a four-glider signal, ABCD, instead of just two gliders. But nothing goes to waste: the A and B gliders run the construction arm in the NW replicator unit, and C and D gliders run the southeast one. AB and CD recipes will be totally different, because the arm has to fire gliders in the opposite direction, and the pulse-divider blocks in the semi-Snarks and the 4H-to-G have to be built in different places. But the only requirement is that the two recipes have to be exactly the same length, and I think that should be easy enough to arrange.

First of all, sincere congratulations to your great success! A geminoid made of just 44(.5) still-lifes is really beyond any expectations!

dvgrn wrote:There may be something still smaller than this, but I think it may be necessary to invent a new Herschel period quadrupler (or a new stable G-to-H) to get below 40 still lifes.

I'm sorry, if I'm asking something stupid, but I got this idea quite a while ago, and since then I've been wondering, if it could make a geminoid smaller, if one used glider pairs instead of single gliders as elements of the instruction tape. In such a way one could get a Herschel without a hassle, using one of standard Herschel receivers and then restore an element with a Herschel transmitter.

I'm sorry, if I'm asking something stupid, but I got this idea quite a while ago, and since then I've been wondering, if it could make a geminoid smaller, if one used glider pairs instead of single gliders as elements of the instruction tape.

It's not a stupid question at all; Dave Greene and I spent a considerable amount of time trying out the various possible geometries for tandem gliders, but the transceivers ended up larger than the single-glider counterparts.

What do you do with ill crystallographers? Take them to the mono-clinic!

calcyman wrote:It's not a stupid question at all; Dave Greene and I spent a considerable amount of time trying out the various possible geometries for tandem gliders, but the transceivers ended up larger than the single-glider counterparts.

Unfortunately that still seems to be true, even with this new design that could construct completely different replicator units at the SE and NW ends. The layout does seem to work out a bit better if you can match up Guam's transceiver with one of the old standard transceivers:

But then four period doublers still have to be added at each end, probably by appending more Herschel conduits with glider outputs. To avoid the semi-Snark signal-crossing problem, the NW Herschel could be split into two Herschels instead, to connect to the next spark-coil transmitter and to a period-quadrupling glider inserter... but I think that already brings the count up over 40 still lifes per RU.

So I agree -- tandem gliders should work better! Just can't seem to come up with a really good layout.

I don't think that a semi-Snark signal crossing will actually invalidate very many 10hd elbow operations -- will know more about that soon. If a signal crossing is allowed, tandem gliders definitely start to be competitive. Here's a 46-still-life replicator unit that can decode a glider stream about three times faster than a Silver reflector:

That looks fairly minimal to me, though -- anyone see any possible improvements? Besides the signal-crossing limitation, there's that awkward dead spark coil. That's not an impossible one-arm construction problem, but it's probably equivalent to building 10-20 Spartan still lifes, unless Glue can find a good slow-salvo recipe for it. Nothing like that has appeared yet, so it probably has to be done by constructing and detonating a seed constellation that builds it out of two synchronized gliders. That would be much easier with a two-arm Geminoid design...

Anyway, the 44.5-still-life Spartan Geminoid would definitely have a lower total population -- but this layout would probably have a smaller bounding box, because of the better compression of the data. It all depends on what you're optimizing.

I'm looking for a way to permanently block a glider lane in a self-constructing circuit. The ideal solution would be a small easy-to-construct constellation of small still lifes. A single glider collision would convert the constellation into an eater (or some still life that eats gliders, anyway!) It doesn't much matter which direction the trigger glider comes from, and it's okay to leave some extra junk lying around as long as it doesn't get in the way of incoming gliders.

The main point is that the entire eater-seed constellation should be a safe distance from the glider lane being blocked. For the project I'm working on now, the lane is a Geminoid construction-arm lane. When the reaction is complete, the constructed object should absorb any further incoming gliders on that lane.

Let's define 'clearance' as the largest orthogonal distance that a constellation can be moved toward a glider lane without interfering with gliders on the lane. It turns out that the minimum safe distance is 5 half-diagonals (hd) -- see below.

Given any P2 slow unidirectional glider salvo, it's fairly trivial to construct a chain of blocks that serves as a single-glider seed for that salvo. The pattern below is a small experiment with these "freeze-dried" slow salvos. It can serve as an upper bound for the high-clearance-eater-seed problem:

This implies that there's no upper limit on clearance, for an eater seed or any other kind of seed. For example, you could add more gliders to the beginning of the above freeze-dried slow salvo, to push the initial target block some distance toward the glider lane before starting the eater construction.

There are many other approaches, of course. For example, the following slow-salvo eater recipes imply the existence of seeds with 8hd and 19hd clearance:

But these are more expensive salvos, and the expense is unnecessary -- 5hd clearance is wide enough to allow a universal set of elbow-move operations. Even 5hd is only needed on one side of the construction arm; known 9hd recipes can push and pull an elbow block past an obstacle with only 2hd clearance on the other side.

---------------------------------------------

So the current Geminoid Challenge is this: what's the smallest Spartan constellation with 5hd clearance or more, that can be triggered by a single glider to create a permanent stable glider eater? "Smallest" could be measured by population or by Spartan still-life count. Is there something significantly smaller than the freeze-dried monstrosity above?

Note: In some cases it may be possible to use the final glider (only) on the lane to be blocked, as part of the recipe. And in many Geminoid designs, it will only be necessary for the eater to eat pairs of gliders, so a boat-bit catcher will be perfectly okay. Here's a possibility along these lines with unlimited clearance:

The white gliders are the pair being blocked. But this particular design will require building a four-glider synchronized seed -- and synchronizing gliders is expensive! So I'm not sure that the resulting constellation will end up being much smaller than my freeze-dried slow salvo.

Looks good on the still-life count, but the pond has only 2hd clearance. So this seed can be used on one side of the constructor arm, but not on the high-clearance side. Known elbow recipes need 5hd of space to be able to push an elbow block past.

-- Huh, come to think of it, 2hd clearance could probably be made to work in an emergency: if the two eater seeds are offset diagonally by a little distance, it would be technically possible to use, say, INC7 to get past one bottleneck, and then INC7R (mirror-image INC7) to get past the other one. Mirror-symmetric construction arms definitely come in handy sometimes!

So the biggest problem with this 10sL seed is constructibility. It shouldn't be difficult to build any of those blocks [using glider pairs on the eater's lane plus a lane 9hd farther away] -- the nearest one has 10hd clearance. But the pond is definitely in the danger zone.

The easiest way to build a pond using a single construction arm is to move a blinker to the right place, then hit it with a final glider from the elbow. At only 2hd clearance, this can still be done, but it will probably need some customized fiddling around with glider-output recipes:

Above 10hd clearance or so, a simple automated compiler can safely do all the work of choosing the elbow operations without worrying about these kinds of conflicts. So in the design stage I'd like to keep all still lifes out of at least the 5hd-clearance danger zone, and hopefully mostly out of the 10hd zone. No doubt I'll hit plenty of awkward snags in the construction recipe without adding any more headaches...

Now I'm thinking even this can probably be cut down a little more. The basic reaction here involves a beehive plus a constructed traffic light, so it's just a matter of finding a 1G traffic-light seed with a good offset. Here's a 9-still-life attempt that's a little too messy, though with 11 still lifes it seems just about good enough:

There's really no harm in leaving a little stable junk lying around off to the side. It might not be so good to have leftover blinkers, but the block in the 11sL version has plenty of clearance.

On the other hand, there must be a cleaner smaller better recipe out there still -- probably one that doesn't require splitting the input into multiple gliders at all. As I mentioned, constructing an eater in this orientation isn't a requirement. Just for example, it would work fine to use the other end of an eater, especially since the gliders always travel in pairs on both lanes. The above seed wouldn't work, since the clearance would go down to 3hd. The 7B4+2B5+pond eater seed can beat that (!) -- using the other end of the eater improves its clearance to 4hd.

It would work fine to use an aircraft carrier, snake, shillelagh, or any available debris that has a boat-bit-catching end; the seed just has to have 5hd clearance or better from the input glider lane... Oddly enough, the 9sL seed above has 5hd clearance for catching a boat-bit with the business end of the eater.

The snake seed above has 5hd clearance potential if some of the extra junk can be suppressed. I'm guessing three still lifes might be the minimum for a boat-bit-catcher seed with 5hd clearance -- but quite possibly a gencols search could prove me wrong.

codeholic wrote:Is it good enough or shall I rather try to find a purely blockic seed?EDIT: Unfortunately, blinker clean-up doesn't work in the other phase. Is it a show-stopper for your goal?

That's a nice one! Plenty good enough for now, I think -- it should be possible to send a final glider pair in with the correct phase to clean up a blinker on each construction lane.

I think that pretty much disproves my conjecture that it would take three still lifes to achieve 5hd clearance. This is a 2sL seed with a clearance of 12hd! And it only takes one more block to clean it up completely:

-- Yes, that's definitely so good that it's time to move on to the next challenge...!

Next I have to come up with a unidirectional p2 slow salvo construction of a Silver reflector, offset from the previous reflector by say (0,-256). The starting point is a hand block next to the previous copy of the reflector, shown in the following pattern as state 5 (yellow). The target location for the copy is shown in red, with the original in green:

EDIT: The salvo will be coming in from the northwest -- a first sample glider is shown. [2013/10/23: updated pattern to match the latest replicator body: two extra blocks instead of four.]

Extrementhusiast wrote:What's the purpose of those four "unused" blocks in the lower left?

I think they may be catalysts for destruction of the old copy. Seriously, I'm new to this thread, so please bear with me.

Good question, and a good guess. A Geminoid spaceship may certainly end up having various parts of itself "seeded for destruction" -- but probably a few more than four blocks will be needed to finish the job for the Silver reflector.

However, I've been working on oblique Geminoid designs recently -- and an oblique spaceship may not need self-destruct circuits. Instead, each replicator unit can be shot down directly by LWSSes from the next R.U.'s construction arm.

Then I realized this last week that it was fairly straightforward to construct a true phase-shifted linear replicator instead of a Geminoid spaceship...! A linear replicator doesn't need any self-destruct circuits at all, but it does (usually) need some switching circuitry to use a recipe in two different ways -- first to build a copy of itself, and second to send a copy of the same recipe to the new memory loop.

So... those four blocks are two 90-degree one-time reflectors in series. They're intended to be part of a very long delay circuit, which will turn off the copying phase so that the replicator doesn't try to copy the same glider twice.

I think I'll probably end up using just a simple two-block reflector, but haven't figured out exactly how to use the return glider yet:

The replicator isn't programmed yet, so for now the only thing it actually constructs is the single glider that triggers the switch from BUILD mode to COPY mode. But once the right sequence of gliders has been added to the memory loop to build those 117 still lifes (give or take a dozen), it should work just fine...!

It's going to take a lot of gliders. Each slow-salvo glider emitted by the construction elbow will be produced by maybe ten glider pairs aimed at the elbow. And it might take ten slow-salvo gliders to produce each constructed still life. So that could be 25,000 gliders or more in the loop, in a bounding box about three million cells on a side, almost as big the original Gemini spaceship. I suspect the replicator will run considerably faster in Golly, though -- there will be many fewer hashtiles, mostly because there's only one data channel doubling back on itself instead of twelve.

dvgrn wrote:I think I'll probably end up using just a simple two-block reflector [at the southeast end]

I did cut that one-time reflector down to two blocks, for no really good reason. There are so many choices of ways to handle the switching circuitry that it's very hard to decide which one will be the most efficient. I've used both Extrementhusiast's and codeholic's contributions, in different places in the switching circuitry.

In any case, the next task is still to produce a one-arm construction for that revised southeast corner. The locations of the one-time turner and the construction hand (yellow block) are more or less arbitrary.

Here's a walkthrough to go with the design posted this morning for a "Mark 1" Geminoid replicator. Actually, though it was definitely inspired by the Gemini spaceship, the design seems to have evolved to where it's only semi-Geminoid -- one replicator unit is needed instead of a matching pair, with just one construction arm instead of two, and one encoded data channel instead of twelve.

The first three steps, marked with asterisks, aren't completed yet. I have a semi-automated compiler that can accept an arbitrary constellation of well-separated still lifes, and produce a unidirectional P2 slow glider salvo that constructs that constellation. So far it only works really well on Blockic constellations... but the project has been continuing to move along, slowly but steadily!

Self-replicator, Mark 1 -- 85 still lifes:

Start with Old NW RU, Old SE Reflector, Old Disabled Output Copier, Old Construction Stopper, Elbow Block and three hand blocks -- Old NW Hand, Old SE Hand, and Old Center Hand. Old NW RU and Old SE Reflector make a loop -- let's call it "Old Loop".

*1) Construct New SE Reflector, New SE Hand, and supporting 180-degree one-time turner. This construction salvo travels SE from the elbow, aimed at Old SE Hand (and will take a long time to get there.)

*2) Construct New Output Copier and supporting one-time circuitry. This will also be a SE salvo, but aimed at the Old Center Hand.

*3) Construct New NW RU, the New NW Hand, New Elbow, and supporting one-time circuitry. The construction salvo travels NW from Elbow Block, aimed at Old NW Hand.

4) The final glider pair in the construction recipe will produce a90-degree glider that triggers the one-time circuitry. The one-timecircuitry does four things:

4a. build the New Construction Stopper (the two 9-cell integrals) in the construction lanes, 4b. unblock the Old NW RU's 90-degree glider output, 4c. send a timing glider SE to the 180-degree one-time turner near Old SE Reflector, and 4d. replace the Elbow Block in its starting location [*haven't done this in the draft version yet, but it's fairly trivial].

5) Old NW RU can't do any more construction because of New Construction Stopper. But the next time around Old Loop, the recipe gliders will all be copied to the New Loop. After a trip to the New SE Reflector and back, they'll be ready to start construction of the next child replicator.

6) At the end of the copying cycle, the timing glider will return from the SE, and will trigger a seed that replaces the eater destroyed in step 4b, before the gliders in the Old Loop come around again. This disables the Output Copier. A branch of this signal also deletes a single block in the Output Copier that is in the way of the gliders returning from the SE part of the New Loop.

knightlife wrote:This one is still two blocks, but a little further away from the other still lifes. Interestingly the destruction glider can come from two different angles, yielding the same result:...

This looks like a good solution. It's hard to say yet which direction a destruction glider will actually come from, so it's good to have options -- and those blocks are certainly far enough from the main body that there's no problem constructing them.

I recently sorted out 10,000+ block-splitter recipes from the p2 slow salvo block-move table (see attached) so there are plenty of construction options! Most recipes are actually in the table twice, once with the block listed as the "m" (moved) block and once as the extra "b" block -- both locations are included in the text file. This duplication doesn't happen when the blocks are lined up so that only the nearer block can be deleted by a single glider.

The project I'm working on right now doesn't need any self-destruct recipes for semi-Snarks -- replicators need to keep the original version and the copy! -- but this compact one-arm construction technology suggests all kinds of uses for a self-destructing replicator unit:

-- a true (2,1) knightship (could use "freeze-dried" salvos to destroy and rebuild each end)-- a spiral-growth pattern (Calcyman mentioned this -- much easier than spaceships or replicators)-- a diamond-shaped Geminoid (much faster to run in Hashlife than the standard boustrophedonic design)-- a 2D replicator capable of exponential population growth (difficult but not impossible...!)

At some point it definitely seems worth working out a design for a minimal two-arm Geminoid using this type of construction arm, but possibly with 10hd separation instead of 9hd. It might be around 56 still lifes per replicator unit -- a Silver reflector plus two chains of three semi-Snarks each.

Two-arm constructions can be enormously more efficient, though the 56sL design would need some new problems solved -- recipes will be needed with all four gliders in every cycle, and there would be a semi-Snark signal crossing that would rule out some glider pairs. But it looks like there might be a way to code a two-arm replicator unit with under 20,000 gliders on the tape -- good competition for the one-arm version, at least.