This thread is a playground for construction designs, which are not important enough for separate thread but interesting enough to be posted (as they're somewhat challenging). This could be some breeder, or not trivial gun, or some slow salvo recipes etc.

As the first post I'll repostak-47 p232 breeder by Goldtiger997 which I think is a perfect example suiting this thread, and I would really like to see more of this kind of things.

So this script is not actually creating a tight salvo - it allows to convert single glider into a series of well separated gliders salvo.

Do we have a script that converts any tight salvo into well separated one? I remember something on this topic in SL splitters thread, that became universal salvo construction thread. Maybe we can cheat somehow and allow "most" tight salvo construction using edge shooters?

simsim314 wrote:Do we have a script that converts any tight salvo into well separated one? I remember something on this topic in SL splitters thread, that became universal salvo construction thread. Maybe we can cheat somehow and allow "most" tight salvo construction using edge shooters?

No, not that I know of. For the stable G->Weekender I placed all of the edge shooters manually. I don't know any way of making arbitrary glider salvos without relying on the clock insertion mechanism. The smallest stable clock inserter I posted is here. Trouble is that this would make the produced patterns even bigger than they would need to be.

simsim314 wrote:So this script is not actually creating a tight salvo - it allows to convert single glider into a series of well separated gliders salvo.

Yes. This solves a good percentage of the problem. We _could_ solve the rest with chris_c's script for duplicating closely-packed salvos (the rest of the code is a few posts up from the linked message). As chris_c says, this is serious overkill for all but a very few construction recipes.

But maybe that doesn't matter, if we just want a foolproof way of generating a stable glider-to-anything-constructible converter.

If so, the place to start might be to build glider-to-flotilla converters for the various two- and four-glider synchronized salvos used by the script. Probably we'll want to avoid converters with signal crossings, like the ones linked to in chris_c's last message. Then it's pretty trivial to lay out those new converters -- with an input glider each, timed to build whatever close-packed salvo is required... and then those input gliders can be trivially processed by a version of the G-to-many-G script.

It would be interesting to set up a script that knows about lots of different edge shooters, and just builds a lot of different combinations and tests them to see which ones work. Brute force might work pretty well for most cases, at least with some common-sense heuristics about what build order to try first. Would probably want an option for one-sided versus two-sided construction of salvos.

dvgrn wrote:If so, the place to start might be to build glider-to-flotilla converters for the various two- and four-glider synchronized salvos used by the script.

I have these that were made in the pre-syringe era. The inputs are Herschels. They aren't too bad but I'm sure they could be improved these days. I believe they are for recipes 4 and 4a in universal salvo script.

1. Make a script that doesn't care about complexity, but it robust and solves every salvo. This would be overkill most of the time, but will provide a final product. In this case it's pretty clear what to do as dvgrn mentioned.

2. Make a "smart" script that cares about complexity but doesn't work all the time. It would hopefully work most of the time. For the cases it doesn't work we can switch back to #1, or tweak the edge shooters.

For the smart approach we can pre-compile compatibility table between all glider pairs for every edge shooter. Then we can solve the ordering problem for a salvo as an abstract directed graph traversal problem. The case of two sides vs. single side, would be just equivalent to more edge-shooters i.e. will just add extra compatibility tables.

I was checking out how many edge shooters do we have, and I can't find more than 4, one of which has quite messy spark on both direction.

It seems like all conduit edge shooter are well suited to place in back of the salvo, while our universal slavo builders are placing the gliders in the front. Thus making the two approaches incompatible.

Which brings me to the question, in case we want to combine the two approaches: what are the chances to find alternative to the clock reaction, which will work universally from behind the salvo?

There is also an option to tweak the edge shooters with extra glider to suppress their sparks.

simsim314 wrote:It seems like all conduit edge shooter are well suited to place in back of the salvo, while our universal slavo builders are placing the gliders in the front. Thus making the two approaches incompatible...

That's pretty much true. One almost-edge-shooter that comes in handy fairly often is this H-to-G:

It's unusual in that it allows a following glider to be closer than the leading glider. But the extra sideways glider is not suppressible except by the loaf reset trick (right side of pattern) which means there are a lot of cases where it's not any use.

simsim314 wrote:There is also an option to tweak the edge shooters with extra glider to suppress their sparks.

Right. With the loaf reset, the above inserter needs two synchronized (or at least semi-synchronized) signals. There are a lot of other options once you're allowed to add an extra glider. I remember there are several ways to suppress the long-lasting spark in a Fx119, and also chris_c came up with a way to hit a passing glider with a Herschel to effectively push it over sideways by a few lanes.

simsim314 wrote:Which brings me to the question, in case we want to combine the two approaches: what are the chances to find alternative to the clock reaction, which will work universally from behind the salvo?

I'm also considering of using MWSS + glider/MWSS as an alternative back inserter.

I'd be slightly surprised if there is no such universal alternative, but I'd also be surprised if it was much cheaper than constructing and sparking a clock. Last time we tried it seemed to be pretty hard to find a reaction fast enough to catch up to a glider flotilla from behind, in a way that could handle all possible situations.

I'm not sure a search ever done to see if two (or more?) perpendicular *WSSes could collide to produce a far-enough-forward glider. That might be an alternate way to get to a simple proof of universal constructibility. The from-the-front method is definitely provably universal, but it seems to require enumerating an exhausting number of cases along a slope-2 or slope-3 line.

-- Come to think of it, a *WSS+*WSS or *WSS+glider coming from the front, might possibly allow for a proof that works for a slope-1 line, or alternatively a slope-0 line. "This reaction can always construct the rightmost glider touching such-and-such line", or something like that, just like the slope-2 or slope-3 proof but with fewer cases to enumerate and test.

simsim314 wrote:I think we should start from what we have, and make sure we can construct any valid glider pair. Then we can move to more exotic problems/solutions.

If I remember right, the only glider pair that this set of edge-shooters would have a tough time with would be one glider 14 ticks directly behind the other. Maybe there are a couple of other cases that the NW31 can't handle, but they can nearly all be constructed from one side or the other.

The problems mostly start to show up when you're building very dense wide salvos, so you're already committed to constructing gliders from one particular side. Then you can easily get into trouble when gliders are following each other closely, with the front glider on the lane closest to the edge shooters.

simsim314 wrote:interesting... can you maybe also post the slow salvo recipe in E-O notation?

It's made up of two search results and two manually placed clean-up gliders, so I don't really have the notation just like that, but I think this should be correct if the target blinker center cell is at (0, 0):

Was looking at the 7-in-a-row Cordership eater on the wiki, and it occurred to me that the 6-in-a-row Cordership would have a much simpler eater (or 6-in-a-row to X converter) these days, than the old out-of-date one shown in the article for the 7-in-a-row:

Unless I've missed or forgotten something, I think it's also true that no one has finished a glider synthesis or a gun for the 6-in-a-row yet. I would guess that almost all of the recipe could be borrowed from the 7-in-a-row V-gun, though of course the cheapest possible recipe would use fewer gliders than that.

A 6-in-a-row V-gun would be kind of interesting to have, just to see how much Life technology has improved since mid-2003. Nowadays I suppose the thing to do would be to put together a glider-to-6-in-a-row converter -- V-gun recipes are ideally suited for that kind of thing.

Anyone up for building one of those? I'd be happy to help out if someone wants to get started on a project like that. The above eater/converter can be adjusted to work down to 6-in-a-rows' minimum following distance, though I'm not sure how easy it would be to build a glider-to-6-in-a-row converter that would work down to that minimum distance; probably the V-gun approach wouldn't quite work.

I actually like it... many times it's ok to have some solution even when not optimized.

But if your intention was to make G->Loafer your output loafer is intersecting one of the input gliders stream, thus closing some input gliders, and there is no real reason for it. So I would start the improvement from directing the input streams in a way they don't intersect the output loafer.

simsim314 wrote:But if your intention was to make G->Loafer your output loafer is intersecting one of the input gliders stream, thus closing some input gliders, and there is no real reason for it. So I would start the improvement from directing the input streams in a way they don't intersect the output loafer.

Yes, it would be fairly simple, even as a manual edit, to remove the last splitter output, add another one on at the beginning right after the gun, and wrap that signal around to the south -- it could still get there on time quite easily.

Then if you do want to cut down the bounding box... my helper tools are not in a state where they'd work well for anyone but me, but since the circuitry is all stable the first round of optimization is really easy. You'll find for example that you can move every structure along the southwest edge, northeast until they almost touch the next set of structures, and the mechanism will still work just the same.

The same goes for removing the big NW-SE empty space -- move everything along the northwest edge to the southwest -- though there you have to be careful not to change any of the 180-degree timing adjustments, or to change them all by the same amount.

Goldtiger997 wrote:I'm quite annoyed at the huge space that is every where but the north-west corner. Can somebody eliminate it or explain how to eliminate it?

A sequence of 4 Snarks will not alter the colour or the mod8-timing so on the longest U-bends you could add in a couple of extra turns to make things shorter.

Alternatively (but more work) you could make a very crude 4-way fanout device that takes your input glider and delivers 4 gliders to somewhere near the required locations at the N, S, E and W at roughly the correct time. You don't need to worry about colours or mod-8 timings, anything vaguely correct will do. Once you've designed that and you know the colour/timing of the 4 gliders coming out of the fanout you can call my glider-to-widely-separated-salvo script (wherever it is) on each arm. It was a design feature of the script that the input glider can be in any phase/colour but it wasn't something that I made proper use of when building the G->Weekender converter. I guess like you, I first made all the machinery for each arm and thought "Hmmm... how am I going to join these together". For best results I imagine it is better to approach things the other way around.

Goldtiger997 wrote:It's taken me 4 days, but I now have completed a glider to 25P3H1V0.2 converter!

I like it! Similar to the glider-to-weekender converter, we can get this down under the character limit very easily, in the form of a Python or Lua script -- it probably could be under 20K, maybe under 10K.

The absolute-easiest improvement has to do with the length-8N delay "slide trombones" on all four of the input signals, and the fact that the slowest path -- clockwise around the outside -- is 150 cells or so farther away from the SW shotgun than it needs to be.

So first move everything along the SW edge northeastward by 150-or-whatever cells -- and to make up for that, make the short doubled-back section in the south corner longer by that exact same 150-plus distance. If that path remains the same length, everything will still work.

Then take that doubled-back south-corner path and reduce it to its minimum length, by moving everything NW by the same distance. In that case, all four signals get to their destinations faster, so again everything still works.

After that, use chris_c's suggestion of doubling back the longer signal paths multiple times instead of just once.

-- But before you do that, it looks like the four shotguns in the NW can easily be shrunk down to less than half their current diameter -- which frees up more space for getting the slowest signal clockwise around the outside. So really that's the place to start. There are trombone-slides in the middle of every shotgun, for example, and you can always adjust those so that _one_ of them is at its closest adjustment.

This converter is relatively small and easy to optimize, though. I might give it a try this weekend if no one beats me to it.

Finally: a much better way of getting signals around the edges of these four-shotgun designs, would be to send them via MWSSes from one corner of their bounding box. An MWSS-carried signal would get to the opposite corner of the bounding box, in about the same amount of time that it would take to send a glider straight through the middle -- but with no ugly signal crossings. (Right?)

EDIT: Each shotgun can be optimized separately, using a LifeHistory "blueprint" along these lines (had to leave off the NEmost gun so it would fit in a post):

dvgrn wrote:Each shotgun can be optimized separately, using a LifeHistory "blueprint" along these lines...

Then after a few minutes of selecting squares to see how much the central trombone-slides can move, and using shift.py to move them by that distance, it looks like this, and the gun still works the same because the path lengths are all the same:

That means we can pull in the SW shotgun's trigger glider path by 749 cells, and the NW shotgun's path by 856 cells, making those trombone slides correspondingly longer. That lets us shorten the NW-SE distance quite a bit.

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

There's a lot more that could be done, but I think that's as much time as I want to invest in this particular design. The converter is also slower to recover than necessary. Most of the syringe-based reflector circuits are fairly optimal, but there are much faster G-to-LWSS circuits available, which would work down to the minimum repeat rate of the spaceship construction.

Also it looks as if this converter will end up larger than it needs to be. The salvo in each quadrant is all built from one side. The shotguns could be much shorter if the component guns were packed in on both sides of the construction lanes.

Then again, it's twice as hard to synchronize eight input signals as four, and really the converter is just fine the way it is! Might still be worth adding a few Snarks to get rid of the remaining awkward delay loops in the southeast, and maybe do some better packing in the north half along the same lines as above. But then somewhere in there it might be best to just declare victory and stop...!