Diagonal flipping fast (approaching c/4) loopship

[MathAndCode]

I had an idea for a self-constructing spaceship with speed approaching c/4 diagonal that creates its targets for the glider stream with glider-XWSS collisions. (More XWSSes could be used in construction, but because extensive research has already been done into unidirectional glider streams, this is unlikely.) This means that there would be at least two parts active at any one time, one to shoot the gliders and one to shoot the XWSSes. Once the newest section of circuitry is completed, it would shoot XWSSes, the part that just shot XWSSes would shoot gliders, and the part that just shot gliders would no longer be needed for construction. Here is a discussion that I had about this before I created this topic:

• https://conwaylife.com/forums/viewtopic ... 76#p103628
• https://conwaylife.com/forums/viewtopic ... 76#p103632
• https://conwaylife.com/forums/viewtopic ... 76#p103636
• https://conwaylife.com/forums/viewtopic ... 76#p103650
• https://conwaylife.com/forums/viewtopic ... 76#p103651
• https://conwaylife.com/forums/viewtopic ... 76#p103667
• https://conwaylife.com/forums/viewtopic ... 76#p103676
• https://conwaylife.com/forums/viewtopic ... 50#p103680

For those who don't want to have to look through all of those posts in order to understand the idea, here's a summary of the takeaways:
After each piece of circuitry is finished constructing, it can be (mostly) reused for things like storing and splitting the glider stream. It will eventually be deleted but not until it's much farther back. In order to approach c/4 diagonal, the spaceships will need to send more time going to the target location, which means that the pieces of circuitry will get farther away from each other. This will increase the amount of time that it will take for the construction tape to go through whichever loop it's being stored in, so inorder to prevent delays between when the newest section of circuitry is constructed and when a copy of the tape arrives, there will probably need to be multiple copies of the tape. Also, it might be better to have separate tapes on each side instead of tapes going back and forth between the two sides, as that will probably make timing easier when adjusting the spaceship.

[MathAndCode]

Dealing with multiple simultaneous copies of a construction recipe still sounds like an unnecessary hassle to me. On the other hand, self-constructing circuitry has taken a big detour for ten years after the Gemini spaceship came out, and honestly that's probably mostly my fault. The Gemini constructed itself with nice efficient "slow glider pairs" colliding at 90 degrees. Everything after that has been basically unidirectional, either slow salvos or single-channel streams.

So I might be badly biased about what is "simple" and what is not, just based on what I'm used to.

I think that I see your point: One copy of the tape will need to go past any given point in the glider loop per the amount of time between the beginning of a new construction, corrected in anticipation of Doppler shift, so if we have gliders bouncing back and forth between reflectors in the circuitry behind the constructing edge, then we will need to deal with the problem of making sure that we don't inject the glider tape into the new loop if there's already a copy in there. There might be some injector that's already capable of that (assuming that the two gliders have a fixed relative timing, which will be the case here as long as all of the glider loops have the same size), but if not, we could have some sort of switch that would turn the splitter into an eater. This could be done with an XWSS from the section constructed either just before or just after the current section, but it would probably be better to use the first glider to make a round trip through the new loop because that wouldn't introduce any new timing difficulties. One could also use some method where the glider loop spans more than one diagonal separation, but that will not so much get rid of the problem as replace it with three other problems (although it would increase the number of possibilities for minimal separation).

[dvgrn]

There might be some injector that's already capable of that (assuming that the two gliders have a fixed relative timing, which will be the case here as long as all of the glider loops have the same size), but if not, we could have some sort of switch that would turn the splitter into an eater.

There are certainly exact-timing OR gates available, but if you rebuild them so that they're not painfully expensive to construct with gliders, then they get kind of bulky. And adjusting the loop timing so that the two inputs come into the OR gate at exactly the right time, would take even more circuitry. The one-time switching method probably makes a lot more sense.

There's a structure in the loopship that adds an eater to a splitter to turn it into a plain reflector. The best way to find it is to switch the loopship over to LifeHistory (currently Alt+H in Golly) and watch at a high step size what happens at each corner. Maybe use Alt+K to switch everything from state 1 to state 3 before you start, so you can see the still lifes that used to be there, after they've been used up (they'll turn red).

The signal that handles all the switching and the self-destruct mechanism actually travels two times around the loop by the time it's done, following the recipe but on different lanes. It's really very easy to set this kind of thing up. It's just a matter of scattering a few extra still lifes around the edges, maybe from this toolkit. Compared to the rest of the mechanisms you're contemplating here, the cost of these one-time turners and splitters and switches is pretty much negligible.

[MathAndCode]

There might be some injector that's already capable of that (assuming that the two gliders have a fixed relative timing, which will be the case here as long as all of the glider loops have the same size), but if not, we could have some sort of switch that would turn the splitter into an eater.

There are certainly exact-timing OR gates available, but if you rebuild them so that they're not painfully expensive to construct with gliders, then they get kind of bulky. And adjusting the loop timing so that the two inputs come into the OR gate at exactly the right time, would take even more circuitry. The one-time switching method probably makes a lot more sense.

I don't think that that will be a problem. If the length of the loop doesn't change and the lengths of the two loops have the same, then the two gliders will always have the same relative timing. Specifically, the two gliders would end up in the same place if not for each other.

There's a structure in the loopship that adds an eater to a splitter to turn it into a plain reflector. The best way to find it is to switch the loopship over to LifeHistory (currently Alt+H in Golly) and watch at a high step size what happens at each corner. Maybe use Alt+K to switch everything from state 1 to state 3 before you start, so you can see the still lifes that used to be there, after they've been used up (they'll turn red).

The idea of turning a splitter into a reflector by adding an eater is trivial. There might be other possible modifications, like removing a catalyst that turns what would otherwise be a spark that dies out into a glider if the splitter has one. The difficult part will likely be figuring out how to trigger it, and if we use the first glider to make a round trip, we need to make sure that future gliders being reflected by the same mechanism don't mess anything up.

The signal that handles all the switching and the self-destruct mechanism actually travels two times around the loop by the time it's done, following the recipe but on different lanes. It's really very easy to set this kind of thing up. It's just a matter of scattering a few extra still lifes around the edges, maybe from this toolkit. Compared to the rest of the mechanisms you're contemplating here, the cost of these one-time turners and splitters and switches is pretty much negligible.

Alright; it's good to know that we can worry about one less thing for a while, assuming that I'm correctly interpreting that the part that is very easy includes how to ensure that the destruction salvo actually destroys the reflector and doesn't just get reflected.