Page 4 of 15

### Re: 31c/240 caterpillar working notes

Posted: January 14th, 2014, 10:11 am
the "edgier" the better. And the active step should be as fast as possible...

### Re: 31c/240 caterpillar working notes

Posted: January 14th, 2014, 11:14 am
codeholic wrote:EDIT: Could you please take a look, if there are other tracks, that are all lined up?
Sure. Let's see, 58:102:58 works just as well as 5858 (on either side of the rephaser).

Shifting far enough to match up different exterior gliders with the kickback gliders, there's also 58:156:58. It appears that that's the only workable collision for that pair of gliders. The next offset that works is 58:218:58.

After that the cycle repeats with 58:220:58 and 58:222:58, analogous to 100 and 102. I.e., you can add 120N to any central corridor between block-pair trails, and everything will work the same (except the exterior glider suppression will happen progressively later and farther away from the block trails.)

All of these are trivial adjustments, by the way -- just shift a standard rephaser's block trails left or right to where you want them, leaving the timings of the Herschels the same, and clean up any mistimed gliders that are currently in flight. The kickback reaction will still work, and if it's a safe spacing, the exterior-glider collision will be a clean one.

57:158+118N:X and 57:102+118N:X also work. But it seems as if odd intervals would be a bad idea for Heisenburp boat-bits, so I won't investigate those further unless I hear otherwise.

56:[102|104|158|220]+120N:X all work, and 54:[104|106|160|222]+120N:X also. In general, then, the outer three block trails on each side have to have separations of

(58-d):(100+d+k+120N):X, for d=[0,2,4], k=[0,2,58,118], N=[0,1,2...], and X=[54..59].

I might have missed a possibility in there somewhere, but rephaser mechanics are pretty straightforward so I don't think so. More likely what I've missed is a clever trick allowing for a backward rake on five block trails or less...!

Just to make sure it's clear: the central block-pair trails can be spaced anywhere from 54 to 59 without affecting anything -- and the right-side spacing doesn't have to be the same as the left side's (though I think mirror-image is good, all other things being equal.)

There are lots of other spacings that produce junk off to the side, instead of a clean annihilation reaction. 58:158:58:158:58 makes nice columns of ponds, for example, and you can get eaters, blocks, LOMs, pi explosions, and so on. I don't see yet how it's possible with six trails to keep the rephaser function AND the rake function AND have a way to turn on a slow-salvo target generator, but there are still some other possible adjustments that could be made.

### Re: 31c/240 caterpillar working notes

Posted: January 14th, 2014, 11:30 am
Thank you very much for such a thorough analysis and a great explanation! This will certainly help a lot!
dvgrn wrote:57:158+118N:X and 57:102+118N:X also work. But it seems as if odd intervals would be a bad idea for Heisenburp boat-bits, so I won't investigate those further unless I hear otherwise.
You're totally right.
dvgrn wrote:I don't see yet how it's possible with six trails to keep the rephaser function AND the rake function AND have a way to turn on a slow-salvo target generator, but there are still some other possible adjustments that could be made.
I thought that it is perhaps feasible to create slow-salvo target on demand by heisenburping gliders in the spaceship stream, so probably it is not even needed to create any targets by the front pattern.

If this approach works out, it may be even cheaper to create a target anew for each spaceship, rather than pushing junk left from the previous synthesis to the new construction site.

### Re: 31c/240 caterpillar working notes

Posted: January 14th, 2014, 2:51 pm
dvgrn wrote: Now I'm wondering if it might be possible to cut the initial front-end construction down to the four outermost trails in a set of twelve. It would be a matter of getting the timing and spacing right, so that the first eight output gliders from each Herschel pair collide with each other to produce the inner eight block trails. No idea if this is possible, but it seems vaguely plausible at least, given all the degrees of freedom available.
Since the original crawler travels on a single trail of gliders and is a double-rake ... you just *might* be able to get away with laying down just this one trail "from scratch" and build the other 5 (or 11 or 1,000,000) by using theese.

But on the other hand: if you use the *WSS-and-helix style traillayers, you probably would just need *one* helix and a couple of fan-out devices (like the caterpillar does). Maybe the fan out devices of the orginal caterpillar aren't easily constructed by your current slow salvo approach, though.
dvgrn wrote: That would leave eight extra backward gliders escaping on the outside, but those could easily be caught with forerakes running on the twelve tracks, either to make absorbing junk for other gliders, or maybe even to be kicked back to build the four initial trails.
If you kicked them back, you would have to turn them *twice* I fear. But you could collide them with additional gliders from the supporting structure.
dvgrn wrote: Another part of Calcyman's suggestion was to avoid using LWSSes altogether. But I think that that still requires an unknown "glider helix" that pushes a block up 31 cells while releasing a 90-degree forward glider, all in 240 ticks or less. I'm pretty sure such things can be found, but I'm not so sure that I'd enjoy figuring out how to build such a salvo, either with a slow-salvo seed or with a series of kickbacks or whatever.
If you try to avoid LWSSes, you would have to reflect the gliders on something like your pushed-along-block example.
But even if you *did* find a version with 240 ticks or less ... that won't realy be a "slow" salvo; you'd probably firing the gliders as fast as they fit. And that would require very complicated forward rakes. (You'd have to build the gliders on many, many different trail set (tracks), because you can't realy fit them close enough on a single track.

I fear that would take quite a huge number of trails.

### Re: 31c/240 caterpillar working notes

Posted: January 14th, 2014, 3:21 pm
codeholic wrote:I thought that it is perhaps feasible to create slow-salvo target on demand by heisenburping gliders in the spaceship stream, so probably it is not even needed to create any targets by the front pattern.
Sounds promising. But are there any non-vanish Heisenburp reactions that leave all their ash a safe distance from the spaceship lane?

Along the sides of the ship, if we're only working with slow salvos from backrakes, I don't see yet how to get the loaf or boat or traffic light out of the way of the next *WSS quickly enough...?

Up at the front, though, something along those lines certainly seems possible -- once there's a glider stream to work with, I'm guessing that fanout devices could produce a couple of gliders that could do a Heisenburp-then-move-the-ash-away trick with no trouble:

Code: Select all

``````x = 19, y = 110, rule = B3/S23
5bo\$3bobo\$4b2o2\$2bo\$obo\$b2o10\$15b3o\$15bo2bo\$15bo\$15bo\$16bobo85\$15b3o\$
15bo2bo\$15bo\$15bo\$16bobo!``````
On that model, though, depending on how close together the spaceship lanes are, we're probably stuck with keeping leftover junk from each *WSS seed, and shoving it to each new lane for the next construction -- tedious, but fairly trivial, I think.

### Re: 31c/240 caterpillar working notes

Posted: January 14th, 2014, 3:33 pm
dvgrn wrote:While I'm thinking about it: wouldn't a variant of this slow-salvo method work very nicely for the original Caterpillar's little brother?
The original Caterpillar is a strange beast, moving faster than a glider but slower than a *WSS. But I think the helix construction could work basically the same way as in the 31c/240: starting from the front of the ship, backward rakes would slow-construct the innermost *WSS first, then push some leftover junk out to the next lane and construct the next stream, and so on.
Finding helices is not such a big thing. You could use my database for glider + up to thre *WSS -> glider [+ something] and combine those reactions. There are clean moves and reflections, and there are those leaving behind extra blocks or other simple still lifes. If you were **really* lucky you might even find a smaller an faster helix which just leaves some unwanted junk and thus was discarded by the original crew. You could then make good use of that "junk".
dvgrn wrote: [...]
It wouldn't take many more gliders to build each *WSS in a 6x helix than the Caterpillar uses, though no doubt pushing the junk to the next insertion point would at least double the cost. But the construction gliders would all be from backrakes, which could be packed fairly tightly -- no need for those big oblique triangles to give backrake and forerake streams enough space to meet. Wouldn't that cut the Caterpillar length down by something like an order of magnitude?
Moreover: you could use sloooooow salvos I think. As long as you keep the "construction sites" out of the way from one another you should be able to delay them as you see fit. That won't help on cutting the length of the ship, alas
dvgrn wrote: I don't understand enough detail about thowers and catchers and filter streams to guess whether the Caterpillar's little brother could get away with using fewer blinker trails.
*If* you could really use abitrary slow salvos you might be able to just use backrakes, rephasers and two filter streams (one per side) . Since the 2, 11, 17 and 45 are all relative primes to eachother (the original pi-crawler rephases the stream by 11) it should be possible to rephase the the back rake without needing a catch-and-throw logic. It might be possible to get away with just *one* 32-track. The funny part is: you then would probably need a few *more* "upships" because you have to create the filter streams somehow. (The carterpillar creates just one track with gliders from the helix-and-fan-out-part and then uses that for the rest of the ship).
It still might be worth the hassle. the body might become much smaller in cell numbers.
dvgrn wrote: At least, anything that works at 31c/240 (like the above insertion) should also work at 6*(17c/45) = 102c/270, right?
It should. More space and more time for construction. On the downside: the carterpillar helix salvo seems to be very packed ...

### Re: 31c/240 caterpillar working notes

Posted: January 14th, 2014, 4:00 pm
dvgrn wrote: Along the sides of the ship, if we're only working with slow salvos from backrakes, I don't see yet how to get the loaf or boat or traffic light out of the way of the next *WSS quickly enough...?
Why not? If I am not missing something, at least some of codeholic's LWSS seeds should work at any slow speed if you construct from the outside top inward and down.

The "next" *WSS of one given "upship stream" is build 31 cells above the current one, and 240 ticks later. That if phase n of the current ship does not collide with phase n-1 of the next one, then you could make those phases as long as need. Or *am* I missing something.
dvgrn wrote: Up at the front, though, something along those lines certainly seems possible -- once there's a glider stream to work with, I'm guessing that fanout devices could produce a couple of gliders that could do a Heisenburp-then-move-the-ash-away trick with no trouble.
There are fan out reactions in the original caterpillar which use intermediate blocks. Those can be timed as needed. So you should be able to build any slow one-glider salvo you need. (Provided the fan out salvos themselves are buildable).

### Re: 31c/240 caterpillar working notes

Posted: January 14th, 2014, 4:30 pm
dvgrn wrote:Sounds promising. But are there any non-vanish Heisenburp reactions that leave all their ash a safe distance from the spaceship lane?
Unfortunately LWSS can't, but HWSS can do it. (EDIT: The best MWSS can do is a block and glider, and the block is on the other side, so that's not exactly what we need.)

Code: Select all

``````x = 14, y = 110, rule = B3/S23
o\$b2o\$2o12\$11b3o\$10bo2bo\$13bo\$9bo3bo\$9bo3bo\$13bo\$10bobo83\$11b3o\$10bo2b
o\$13bo\$9bo3bo\$9bo3bo\$13bo\$10bobo!``````
Maybe it makes sense then to select recipes with at least one HWSS in them...

### Re: 31c/240 caterpillar working notes

Posted: January 14th, 2014, 4:47 pm
oblique wrote:Why not? If I am not missing something, at least some of codeholic's LWSS seeds should work at any slow speed if you construct from the outside top inward and down.
We were talking about creating targets for slow salvo construction on demand by colliding a glider sent from the spine into the spaceship stream, so that it doesn't harm it, but leaves some junk lying around, but not on the lane, because there is no chance to send another glider to move it from the spaceship lane before the next spaceship hits it, if we use one-rake approach.

### Re: 31c/240 caterpillar working notes

Posted: January 14th, 2014, 5:06 pm
codeholic wrote:
dvgrn wrote:Sounds promising. But are there any non-vanish Heisenburp reactions that leave all their ash a safe distance from the spaceship lane?
Unfortunately LWSS can't, but HWSS can do it.
...
Maybe it makes sense then to select recipes with at least one HWSS in them...
Ah, now it makes sense -- seems like that should work just fine to generate slow-salvo targets.

In fact, since you really only need to produce the junk once, couldn't you use up an *WSS to make the initial target? Then a backward glider and LWSS would work after all (I think). This LWSS+backward glider collision could probably produce the slow-salvo targets needed to build the LWSS lower down:

Code: Select all

``````x = 69, y = 214, rule = B3/S23
obo\$b2o\$bo89\$60bobo\$61b2o\$61bo27\$65b3o\$65bo2bo\$65bo\$65bo\$66bobo85\$65b
3o\$65bo2bo\$65bo\$65bo\$66bobo!``````
Would have to figure out how to pull the beehive back through the LWSS stream with a slow salvo without getting hit, though. Again an HWSS would probably be better:

Code: Select all

``````x = 70, y = 201, rule = B3/S23
obo\$b2o\$bo89\$60bobo\$61b2o\$61bo12\$65b3o\$65bo2bo\$65bo\$65bo3bo\$65bo3bo\$
65bo\$66bobo83\$65b3o\$65bo2bo\$65bo\$65bo3bo\$65bo3bo\$65bo\$66bobo!``````
I was originally thinking about this with HWSSes and forward gliders, which could also close the cycle and leave leftover junk to build more upship streams to send to the front -- much more expensive, though:

Code: Select all

``````x = 73, y = 102, rule = B3/S23
60b3o\$62bo\$61bo4\$70b3o\$69bo2bo\$72bo\$68bo3bo\$68bo3bo\$72bo\$69bobo17\$3o\$
2bo\$bo64\$70b3o\$69bo2bo\$72bo\$68bo3bo\$68bo3bo\$72bo\$69bobo!``````
Anyway, the main point is that we could still use just LWSSes everywhere except for the first target-junk-generating loop -- or if we want to avoid having to push targets long distances, we could use a throwaway HWSS right next to the actual recipe. No need to design HWSSes in so that they're always at the far left of a helix, necessarily... though that would certainly be more efficient!

-- Unless I'm missing something obvious again, of course.

### Re: 31c/240 caterpillar working notes

Posted: January 14th, 2014, 5:41 pm
dvgrn wrote:In fact, since you really only need to produce the junk once
Did you mean to use up one spaceship stream just for generating targets? In my opinion, it's a waste of spaceships. One can generate targets for free, it just requires more searching.

EDIT: Or maybe you meant something completely different? Then I would say, there is no "once" in the normal sense, there is only period 240.

### Re: 31c/240 caterpillar working notes

Posted: January 15th, 2014, 4:37 am
codeholic wrote:
dvgrn wrote:In fact, since you really only need to produce the junk once
Did you mean to use up one spaceship stream just for generating targets? In my opinion, it's a waste of spaceships. One can generate targets for free, it just requires more searching.
Yes, that was what I meant. I guess I just like to have plenty of backup plans.

But I definitely agree that other methods are looking much more efficient. The HWSS Heisenburp trick looks like it will work very nicely to start off the first junk column, and all it requires is that the innermost spaceship stream on both sides should be a HWSS. That shouldn't be too difficult as a search requirement.

I think I've hit a stopping point in the rephaser chaining script; I'll wait until a final decision has been made on block-trail spacing before I do any more. At the moment the script is designed to accept a list of time offsets between successive rephasers.

The list is hardcoded as "deltalist" in the version below, to test all offsets between 0 and 305. 0 is the minimum safe distance between Herschel pairs. 305 (or in general 165+240N) is the offset needed to synchronize successive rephasers, so the bottom two sets of Herschels appear exactly in phase. Probably we'll use a standard offset for the actual spaceship, either 165 (to make HashLife slightly happier) or possibly just 2, if minimizing the length of the spaceship turns out to be an interesting exercise... plus or minus a couple of ticks for rephasing and rake-making.

Having a long series of different rephaser offsets in a single column causes a very strange visual effect at some zoom levels -- kind of a bidirectional wave interference pattern. I've seen something like it before, but I don't remember where.

rakemake.py:

Code: Select all

``````import golly as g

g.setrule("Life")
g.setalgo("HashLife")

deltalist=[i for i in range(0,241+65)]

rephaser=[g.parse("""23\$327b3o\$328bo\$326b3o6\$9b3o42b3o313b3o\$10b2o41bo2bo312bo2bo\$8bo3b2o39b2o
bo312b2obo\$2b2o4bobob2o50b2o252b2o60b2o\$2b2o3b2o3b2o50b2o252b2o8b2o50b
2o\$8b2o318b2o3\$64bo315bo\$62bobo313bobo\$63b2o252bo61b2o\$316bobo\$315bo3b
o\$13b2o300bo3bo\$2o64b2o251bo62b2o\$2o64b2o248b3o63b2o\$366b2o\$365bobo\$
367bo3\$21b2o\$4b2o14b2o40b2o256b2o56b2o\$4b2o16bo39b2o256b2o56b2o8\$164b
3o\$161b2o2b4o50bobo\$161b5obobo48bo2bob2o\$160bo6b2o49bo2bob2o\$12b2o40b
2o104b3o2b6o51b2obo102b2o40b2o\$12b2o40b2o104bob2obobob2o45bo5b4o102b2o
40b2o\$167bo2bo43b2o\$162b2o2b4o44bo6b2o\$214b3obob2o3bo\$178b2o40b5o\$178b
o2bo39bo\$153b2o23b3o\$149bob2o2b2o15b2o\$148bo2bo5b2o\$148bo4b2o69b2o80b
2o\$149b3obo4bo4bo60b2o79bobo\$151bob2o4bo147bo\$111bo41b2o2bo2bo2bo\$112b
2o43bo\$81b2o28b2o44bobo\$80b2o76bo\$82bo57bo\$4b2o56b2o75bo22b2o56b2o44bo
53b2o56b2o\$4b2o56b2o75b3o20b2o56b2o44bobo51b2o56b2o\$266b2o2\$247bo\$248b
2o\$247b2o7\$170b2o40b2o\$170b2o40b2o10\$191bo\$192b2o\$191b2o3\$186bo\$186bob
o\$162b2o22b2o32b2o\$162b2o56b2o12\$170b2o40b2o\$170b2o40b2o!""",-4,-0)]

trail=g.parse("2o56b2o256b2o56b2o\$2o56b2o256b2o56b2o30\$158b2o56b2o\$158b2o56b2o!")
trails=[]
for i in range(120):
trails+=g.transform(trail,0,-31*i)
block=[0,0,0,1,1,0,1,1]

g.new("Test")
g.putcells(trails)
g.putcells(rephaser[0])

for i in range(1,241):
rephaser+=[g.evolve(rephaser[i-1],1)]
if i==101: rephaser[i] = g.join(rephaser[i],trail)

voffset, currphase=0,0

g.putcells(rephaser[currphase])
for delta in deltalist:
voffset+=84 # each rephaser leaves blocks (0,84+31N) from its initial trails
newphase=currphase-delta+65 # minimum distance -- delta=0 -- is 53 vertical cells plus 65-tick offset
g.putcells(trail, 0, voffset)
while newphase<0:
newphase, voffset = newphase+240, voffset+31
g.putcells(trail, 0, voffset)
while newphase>239:
newphase, voffset = newphase-240, voffset-31

#    (0,0) block1 at T>141,  (58,0) block2 at T>122, (158,31) block3 at T>229
# (216,31) block4 at T>210, (316,0) block5 at T>103, (374,0) block6 at T>122

g.putcells(block,316,voffset+31,1,0,0,1,"not") # trail 5
g.putcells(block,58,voffset+31,1,0,0,1,"not")  # trail 2
g.putcells(block,374,voffset+31,1,0,0,1,"not") # trail 6
g.putcells(block,0,voffset+31,1,0,0,1,"not") # trail 1
g.putcells(block,216,voffset+62,1,0,0,1,"not") # trail 4
g.putcells(block,158,voffset+62,1,0,0,1,"not") # trail 3

if newphase>103: g.putcells(block,316,voffset,1,0,0,1,"not") # trail 5
if newphase>122: g.putcells(block,58,voffset,1,0,0,1,"not")  # trail 2
if newphase>122: g.putcells(block,374,voffset,1,0,0,1,"not") # trail 6
if newphase>141: g.putcells(block,0,voffset,1,0,0,1,"not") # trail 1
if newphase>210: g.putcells(block,216,voffset+31,1,0,0,1,"not") # trail 4
if newphase>229: g.putcells(block,158,voffset+31,1,0,0,1,"not") # trail 3

g.putcells(rephaser[newphase],0,voffset)
currphase=newphase
g.fit()
g.update()
``````
Once we have the width between the block trails nailed down, I'll adjust the script so it can let a glider stream out on either side on demand, by advancing the Herschel pair on that edge by two ticks. So the next thing on the agenda is to sort out the weird mod-31 math to convert a given slow-salvo recipe into a list of offsets to feed into the script.

We can use opposite sides of the same rephaser to fire gliders for two different slow salvos on opposite sides -- whenever it happens to work out. The rephasers don't have to be synchronized, exactly, but there's an interesting optimization problem with the even/odd timing of each rephaser.

Let's adopt the convention that each rephaser/rake is assigned a number from 0 to 30, and it will fire its optional gliders on the glider lane with that number, on both the left and right sides -- [#]L and [#]R for short. Now suppose that the next glider that we have to fire in the slow salvo to the left is an odd-phase glider on the left-side Lane 1 (for example) -- and on the right we need an even-phase glider on the right-side Lane 1.

The usual limitation is that we have to wait around for the next #1 rephaser to come along -- might have to let up to 30 other rephasers go by first, if the last #1 rephaser has just gone by. But the strange extra limitation is that we then have to choose to shoot a either the 1L-odd glider or a 1R-even glider. Can't do both at once -- one of the two will have to wait around for another 30 rephasers to go by. (They aren't called "slow salvos" for nothing...)

Luckily we'll almost always be able to avoid this situation, by paying careful attention to how we create p2 intermediate targets in the two slow-salvo recipes. Any time we get back to a stable target, that adds a degree of freedom to the construction process.

EDIT: No, I was wrong about this. The rephasers aren't actually all one piece in terms of phasing. There are four sections that can be adjusted considerably forward and backward in phase without affecting the other sections. Only Herschel #s 2 and 3, and 4 and 5, require exact timing relative to each other (for any given lane width). There are limits to how far each group's phase can be adjusted -- have to avoid crashing the wrong gliders together, and not try to delete blocks before they're created, and so on -- but there are dozens or hundreds of relative timings that work.

So there's no problem creating an even-phase glider rake on the left side that is also an odd-phase glider rake on the right.

### Re: 31c/240 caterpillar working notes

Posted: January 15th, 2014, 5:40 am
dvgrn wrote:But I definitely agree that other methods are looking much more efficient. The HWSS Heisenburp trick looks like it will work very nicely to start off the first junk column, and all it requires is that the innermost spaceship stream on both sides should be a HWSS.
I've got a sneaking suspicion, that it might not work, because it seems to me, that it couples the target creation reaction with slow salvo contruction by period 240. Or am I now just paranoid?
dvgrn wrote:Having a long series of different rephaser offsets in a single column causes a very strange visual effect at some zoom levels -- kind of a bidirectional wave interference pattern. I've seen something like it before, but I don't remember where.
I think I know what you mean, it reminds me of a Shepard tone, or "hypnotic" spirals.

This YouTube video with a Shepard tone is also nice.

### Re: 31c/240 caterpillar working notes

Posted: January 15th, 2014, 9:02 am
Regarding clean-up of Herschel trails in the back it can be easily achieved by the same Heisenburp trick. One just needs to build a clean seed for a lateral backward *WSS on one side of the ship and a stopper (e. g. a block) on the other.

The seed does not have to be an edge-shooter in this case (unless I'm missing something again), so one can use the fastest seed available (I guess, that might be the MWSS recipe I posted before, just need to add some cheap junk to the seed to make it clean).

Code: Select all

``````x = 803, y = 102, rule = B3/S23
2o\$2o795b5o\$797bo4bo\$797bo\$798bo3bo\$800bo2\$54b2o56b2o98b2o56b2o98b2o
56b2o\$54b2o56b2o98b2o56b2o98b2o56b2o23\$2o\$2o675b5o\$677bo4bo\$677bo\$678b
o3bo\$680bo2\$54b2o56b2o98b2o56b2o98b2o56b2o\$54b2o56b2o98b2o56b2o98b2o
56b2o23\$2o\$2o555b5o\$557bo4bo\$557bo\$558bo3bo\$560bo2\$54b2o56b2o98b2o56b
2o98b2o56b2o\$54b2o56b2o98b2o56b2o98b2o56b2o23\$2o\$2o435b5o\$437bo4bo\$
437bo\$438bo3bo\$440bo2\$54b2o56b2o98b2o56b2o98b2o56b2o\$54b2o56b2o98b2o
56b2o98b2o56b2o!``````

### Re: 31c/240 caterpillar working notes

Posted: January 15th, 2014, 10:25 am
Another question that came into my mind is whether it's possible to shoot gliders of different colors from the same track and with the same glider-shooting reaction (is there just one?), no matter how many rephasers you use.

### Re: 31c/240 caterpillar working notes

Posted: January 15th, 2014, 10:54 am
codeholic wrote:I've got a sneaking suspicion, that it might not work, because it seems to me, that it couples the target creation reaction with slow salvo contruction by period 240. Or am I now just paranoid?
I don't think that will be a problem, because the timing of the final trigger glider is independent of the timing of the first Heisenburp glider. If that first glider is arriving N ticks too slow or too fast, adjust the timing of the rake that's producing that glider by N ticks. You'll still end up with the same block trail after the adjusted rake -- nothing else changes -- but now the glider arrives N ticks slower or faster.
codeholic wrote:Another question that came into my mind is whether it's possible to shoot gliders of different colors from the same track and with the same glider-shooting reaction (is there just one?), no matter how many rephasers you use.
Yes, there's only one glider-shooting reaction -- the Herschel's second natural glider. But glider color is definitely not a problem, because 31 and 9 are relatively prime... In any string of 31 rephasers, you have the option of converting each wing to a rake. First you can optionally shoot a glider (in your choice of phase, by adjusting the entire rephaser by 1 tick) on lane 0, then on lane 9, and so on. The full series is:

0 9 18 27 5 14 23 1 10 19 28 6 15 24 2 11 20 29 7 16 25 3 12 21 30 8 17 26 4 13 22 0

So every other glider from a given Herschel-pair climber is a different color. If a particular glider is the wrong color, you can just shut off that rake (turn it into a rephaser wing). The seventh rephaser after that one will shoot gliders of the other color, on the +1 lane; the 24th rephaser has gliders on the -1 lane. And it's no coincidence that 7+24 = 31, of course.

It's a fairly crazy way to build slow salvos, but I still think it will work... Sometime this week I'll see about making a working HWSS rake that closes the loop, starting with a Heisenburp backrake+HWSS collision and ending with some leftover junk to harass into the next *WSS build position.

### Re: 31c/240 caterpillar working notes

Posted: January 15th, 2014, 3:27 pm
codeholic wrote:We were talking about creating targets for slow salvo construction on demand by colliding a glider sent from the spine into the spaceship stream, so that it doesn't harm it, but leaves some junk lying around, but not on the lane, because there is no chance to send another glider to move it from the spaceship lane before the next spaceship hits it, if we use one-rake approach.
Well, there is a chance! If I find a fanout device, that sends two gliders in the same direction close enough to each other, preferably 2 forward gliders and one backward, like this:

Code: Select all

`````` out      in
\\     /
\\   /
\\ /
/|
/ |
/  |
/   |
out   in
``````
EDIT: Almost what I want:

Code: Select all

``````x = 16, y = 129, rule = B3/S23
13bo\$13bobo\$13b2o13\$2b3o\$bo2bo\$4bo\$o3bo\$o3bo\$4bo\$bobo14\$7bo\$6b3o\$6bob
2o\$7b3o\$7b2o65\$2b3o\$bo2bo\$4bo\$o3bo\$o3bo\$4bo\$bobo14\$7bo\$6b3o\$6bob2o\$7b
3o\$7b2o!``````

### Re: 31c/240 caterpillar working notes

Posted: January 15th, 2014, 5:25 pm
codeholic wrote:Well, there is a chance! If I find a fanout device, that sends two gliders in the same direction close enough to each other, preferably 2 forward gliders and one backward...
Yes, but what's wrong with starting with a HWSS stream, anyway? I'm sure some use can be found for it at the front of the ship -- and if it can't, I'm perfectly happy to use one of the backward-rake reactions I posted to blow it up.

Looks like the next task is to find a decent slow-salvo recipe for one of the edge-shooter HWSSes. The next task short of writing NewGlue%31 to make this job trivial, that is -- I'm getting increasingly tempted by that project.

In the meantime, the eater+blinker seed looks pretty good. The smallest eater seeds I know of for that orientation of near-edge eater are all eight slow gliders, based on a five-glider traffic-light to eater conversion. Actually there are two completely different TL+beehive to eater final steps:

Code: Select all

``````x = 104, y = 65, rule = B3/S23
64bo\$65b2o\$64b2o10\$obo\$b2o\$bo5\$7bobo\$8b2o\$8bo\$65bo\$18bo47bo6bobo\$16bob
o45b3o7b2o\$17b2o55bo2\$67bobo\$68b2o15bo\$68bo3bobo11bo\$16bo56b2o9b3o\$17b
2o54bo\$16b2o3\$92bo\$17bo75bo\$18bo72b3o\$16b3o9\$102bo\$103bo\$101b3o3\$101b
2o\$101b2o3\$47bo\$47bo\$47bo2\$43b3o3b3o2\$47bo\$47bo\$47bo!``````
Unfortunately the traffic light is dangerously close to the domino spark in the LWSS lane. But fortunately the construction timing can be adjusted in each case to let the HWSS get by -- and none of the other intermediate targets have to be as close as that traffic light:

Code: Select all

``````#C two ways of getting to an HWSS stream
x = 208, y = 129, rule = B3/S23
2bo132bo\$obo110bo19bobo\$b2o108bobo20b2o\$112b2o10\$23bo\$21bobo\$22b2o56\$
203bo\$202bobo\$202bobo\$203bo3\$203b3o2\$201bo5bo\$93b3o105bo5bo\$201bo5bo\$
91bo5bo\$91bo5bo105b3o\$91bo5bo\$88bo\$87bobo3b3o\$87bobo\$88bo3\$62bo132bo\$
60bobo110bo19bobo\$61b2o108bobo20b2o\$172b2o\$97bo109bo\$97bo109bo\$97bo
109bo5\$203bo\$202bobo\$83bo118bobo\$81bobo119bo\$82b2o2\$203b3o2\$201bo5bo\$
93b3o105bo5bo\$201bo5bo\$91bo5bo\$91bo5bo105b3o\$91bo5bo\$88bo\$87bobo3b3o\$
87bobo\$88bo7\$97bo109bo\$97bo109bo\$97bo109bo!``````
So the whole recipe should end up around a dozen gliders again, similar to the LWSS recipe -- well, maybe a few more, especially if you count the gliders that convert the HWSS+G Heisenburp debris into the initial target for the salvo. Further bulletins as events warrant.

EDIT: The other eater+blinker recipe looks competitive also. There's much more clearance for that orientation of eater -- a known recipe has two cells to spare, three for blinkers, and more than that for temporary for sparks -- but less clearance (read: zero) for the construction of the blinker:

Code: Select all

``````x = 68, y = 99, rule = LifeHistory
2.A\$A.A\$.2A49\$62.C\$62.3C\$65.C\$64.2C11\$67.C\$67.C\$67.C15\$62.C\$62.3C\$65.
C\$64.2C6\$62.A\$60.A.A\$61.2A3\$67.C\$67.C\$67.C!``````

### Re: 31c/240 caterpillar working notes

Posted: January 15th, 2014, 6:05 pm
dvgrn wrote:Yes, but what's wrong with starting with a HWSS stream, anyway?
Sorry, I've mixed up topics a little bit. I was thinking about creating trails with Heisenburps by an LWSS. Boats can be created only by backward gliders, but I would like to use forward gliders there, because it would give one more degree of freedom, if one used backward gliders instead of still lifes as a trigger for the next fanout reaction.

That's how it approximately might look like:

Code: Select all

``````x = 159, y = 93, rule = B3/S23
o2bo\$4bo\$o3bo\$b4o51\$155b3o18\$156b3o\$155bo2bo\$158bo\$158bo\$155bobo12\$
156b3o\$155bo2bo\$158bo\$158bo\$155bobo!``````
Just imagine a southwest glider instead of the input blinker and another southwest glider instead of the output block

### Re: 31c/240 caterpillar working notes

Posted: January 16th, 2014, 1:13 pm
An amazing find that can make me completely rethink the whole design of the front pattern:

Code: Select all

``````x = 62, y = 28, rule = B3/S23
59bo\$57bo3bo\$56bo\$56bo4bo\$56b5o21\$3o\$bo\$b3o!
``````

### Re: 31c/240 caterpillar working notes

Posted: January 16th, 2014, 1:59 pm
codeholic wrote:An amazing find that can make me completely rethink the whole design of the front pattern...
What! A spark from the Herschel a few ticks before the block-trail collision... just happens to make an MWSS drop a block right where it's needed. What were the odds on that?

Other serendipitous news: I have a working 31c/240 HWSS rake now. It slow-salvo constructs an HWSS starting from the block+blinker debris from a HWSS+G Heisenburp reaction. Most improbably, the blinker is dropped in the exact right location; it can be directly used as part of the HWSS seed, with no adjustments at all. So all I had to do was find a slow salvo to convert the block into the right orientation of eater.

Looks like I can close the cycle with 18 rakes. I think that's good enough for now, until NewGlue%31 comes along to do an exhaustive search for the shortest possible *WSS constructions.

EDIT: see attached. I've left enough empty trails at the top that it works to zoom in to the start of the rake and watch the entire slow construction process as the ship passes by.

Mod-31 rephaser math is somewhat painful -- there are offsets of 31 and 7 and 9 and 84 to worry about, depending on what you're moving around. But it wasn't terribly difficult to close the cycle. It's just like aligning the next glider in a slow salvo: you never add more than 30 rephasers to close any cycle of this type.

-- That's assuming you've added a rake to handle a G+*WSS collision (such as the HWSS Heisenburp) but the output is on the wrong lane and/or the timing doesn't match. To get the right lane you just have to keep adding rephasers until the glider comes out where you want it; timing you can fix just by advancing or delaying the rake.

Luckily the same exact recipe will work no matter what the block-trail spacings are -- one of the great advantages of building with pure slow salvos.

You can also build HWSSes at any distance with the same rake -- I just tried moving the HWSS stream (1000,1000), and after re-timing the HWSSes so that they all lined up with what the trigger gliders were producing at the bottom of the rake, the Heisenburp reaction automatically re-synchronized itself at the top. Very nice!

-- Now I have some ideas about making the rephaser chains much shorter. Right now the active section of the block trails is over 25,000 cells high. I'm thinking it might be possible to cut that way down... It might reduce the number of degrees of freedom for block-trail spacing, though.

### Re: 31c/240 caterpillar working notes

Posted: January 16th, 2014, 6:02 pm
It's one thing to know that it's theoretically possible, but it's amazing to see it at work! Congratulations!

I hope, you script supports parametrization of trails.

In the meanwhile I've finished all gencols searches that I think should be enough to complete the front pattern.

### Re: 31c/240 caterpillar working notes

Posted: January 16th, 2014, 6:24 pm
codeholic wrote:
codeholic wrote:We were talking about creating targets for slow salvo construction on demand by colliding a glider sent from the spine into the spaceship stream, so that it doesn't harm it, but leaves some junk lying around, but not on the lane, because there is no chance to send another glider to move it from the spaceship lane before the next spaceship hits it, if we use one-rake approach.
Well, there is a chance! If I find a fanout device, that sends two gliders in the same direction close enough to each other, preferably 2 forward gliders and one backward, like this:

Code: Select all

`````` out      in
\\     /
\\   /
\\ /
/|
/ |
/  |
/   |
out   in
``````
EDIT: Almost what I want:

Code: Select all

``````x = 16, y = 129, rule = B3/S23
13bo\$13bobo\$13b2o13\$2b3o\$bo2bo\$4bo\$o3bo\$o3bo\$4bo\$bobo14\$7bo\$6b3o\$6bob
2o\$7b3o\$7b2o65\$2b3o\$bo2bo\$4bo\$o3bo\$o3bo\$4bo\$bobo14\$7bo\$6b3o\$6bob2o\$7b
3o\$7b2o!``````
I would almost bet money, that there was a glider + 3 ss collision in my survey (somewhere) that yeilded 2 parallel gliders ... has been a while, tho

### Re: 31c/240 caterpillar working notes

Posted: January 16th, 2014, 9:17 pm
Is it possible to line up trails in two rows by three, so that the distance between trails in each of both rows would be the same and adjustable?

I fail to get distance of 54, 56 or 58 between boats.

EDIT: Maybe that's not a good idea anyway, because then clean-up gets more complicated. I think I have to the brute force approach now (hopefully there will be not so many pitfalls).

### Re: 31c/240 caterpillar working notes

Posted: January 17th, 2014, 5:00 am
What I really wish is that there were a way to parametrize distance between two trails in a pair. Would it be possible, for instance, to use kickbacked gliders to suppress outside gliders of the previous Herschel triplet? It sounds feasible to me.

There probably would be forward gliders that break away in the front of the pattern, but it might be feasible to suppress them with additional spaceships or specialized devices built by the front pattern (plain eaters probably won't work, because every next forward glider will be shifted compared to the one sent by the previous triplet).

EDIT: There will be also break-away backward gliders in the back. No good design, probably