New ideas for an old thread: with the appearance of a single-lane universal construction toolkit
, armless designs suddenly don't look like the best idea any more.
Once it's not necessary to worry about separating the two streams of gliders needed for armless construction, I think
the child replicators can safely be moved closer to the parent without any Hashlife-incompatible glider streams passing close by each other in opposite directions. By the time the two child loops are filled with gliders, the parent loop will be empty, and could even have self-destructed.
Here's a very rough initial diagram, and an attempt at a walkthrough. I'll leave out most of the switching-circuitry detail for now:
x = 287, y = 293, rule = LifeHistory
#C [[ VIEWONLY ZOOM 1.3 ]]
Start with just the green loop full of gliders, plus two elbows (near the west and east corners) and two target "hand" blocks (near the north and south corners). The replicator will build a child loop to the northwest, let's say. Then half a loop cycle later it will use the same construction recipe to build an identical loop to the southeast. I'll describe only the NW child loop construction, but the loop to the SE should be identical (except rotated 180 degrees).
A signal will be split off from the loop to trigger a *WSS-and-glider seed at the south corner of the green parent loop (red circle). The *WSS will travel to the north corner to trigger another pre-existing *WSS seed, aimed at the west corner of the white child loop (red lines). There it meets up with the glider from the original *WSS-and-glider seed, producing an elbow that will be used to slow-salvo construct the north and west corners of the child loop.
The hand block for this new elbow can be provided very easily. When construction is finished on the east corner of the white child loop, and then the south corner, a glider G(ne)
will be sent toward the east corner, where it will be turned and delayed slightly by a small constellation of glider turners, and a new glider G(nw)
will head for the north corner (yellow lines).
Meanwhile a construction recipe will be sent to the elbow at the west corner of the child loop -- and the first output glider will head for the north corner to converge with glider G(nw)
and produce a target object.
The north child-loop corner will then be constructed, followed by the west corner (using a spare out-of-the-way hand block left there, hopefully, from the *WSS+G collision.) The various one-time glider turners will be built at each corner, as needed. Also a few more protective still lifes will be added at each corner, so that when an *WSS, glider, and/or construction glider stream arrives to construct a corner that already has circuitry in it, the second construction attempt will be harmlessly absorbed.
It looks as if a couple of fishhook eaters might be enough to guard each corner, or possibly even just a single eater.
The glider stream will travel twice around the parent loop. A small amount of switching circuitry -- one-time glider turners connected to an eater seed -- will be needed to block the loop with a fishhook eater after two cycles, and do any other cleanup. There might not be much cleanup needed: the two construction outputs can be re-used unchanged to send copies of the recipe to the child loops (!).
The parent loop can be left in place, empty, with passive eater defenses to block any future attempts to rebuild a loop in that location.
It's getting too late for any more of this kind of speculation. Time for someone to point out an obvious flaw, and then I'll see if I can wave my hands and fix it...!