RCT remaining tasks

Hippo.69 · Post by **Hippo.69** » October 26th, 2023, 7:28 am

I am thinking about the overall stages of the RCT15.

Current schema was:

1) Build DBCA, prepare GPSE collision, build ECCA, jump far SE with "allarm clock", destroy remnants of the FSE GPSE starting reaction, build corder absorbers and reflectors on FSE, allarm rings what causes closing DBCA and redirectiong input to ECCA (actually first redirected glider is turned back (traveling 3 parsecs) to destroy the reflectors). what is activated long after GPSE collision. ECCA clears the collision spot, sends corderships from the spot to clean all 3 directions, and cleans remnants of GPSE's starting reaction (FSW) and makes FSW corder absorbers.

2) Than build sleeping pattern for the universal construction task ...

3) Than reposition arm FNW and destroy remnants of FNW GPSE starting reaction and build corderabsorbers here with last of them sending signal back to destroy the ECCA and woke the sleeping pattern after it.

What about doing 3) before 2)?
jump far NW with "allarm clock", destroy remnants of FNW GPSE starting reaction and build corderabsorbers here. Than allarm rings what causes arm getting back, and we can construct the (sleeping pattern)? for the univarsal constructor task and then self destroy the ECCA and invoke the seed.

Actually in this schema, we can build the target pattern as we would build it using ECCA ignoring the RCT15 environment. Just build it far away to be able to destroy ECCA in time not to colide with the pattern. (We do not need to calculate the huge delay among the pattern construction and pattern activation (determined by RCT15 in the previous version).

Advantage of this process would be the bits of RCT15 would be constant upto time when the ECCA have to build the pattern,
than if the construction returns the arm block to the "pattern independent" fixed position, we can use the same bits to destroy the ECCA.
We could specify the pattern to be built is activated by the glider in "pattern independent line".

In that case changing the target pattern would just mean changing "bit" substring encodding the ECCA program.

Unfortunately this schema could in general ignite the pattern before the corderships reach their destinations and as the pattern could expand faster then the corderships travel, that would defintely be problem.

But this schema definitely allows destroying ECCA by itself (partially by direct glideres, partially by seeds of destruction), far before the corderships reach their destinations. We can use the last corderabsorber on either FNW or rather FSW to send back glider to activate the built pattern.
(But the timing would be difficult to guess so we are back to building sleeping pattern for the universal construcion target pattern.)

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

OK what would be pro for allarm clock repositioning the arm block?
We could destroy part of the ECCA by ECCA itself what could help even when it restricts the ECCA functionality (just green color). Doing it before the work on FNW is done would inrease the FNW costs. Is it worth it?

In both cases the RCT15 programming would mean using fixed prefix and fixed suffix and the middle bits are exactly the program for ECCA.
So in both cases we could make easy convertor of ECCA bits program to RCT15 demo's. (Expecting standardised pattern ignition).

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

Another idea ... Could the selfdestruction of ECCA be ignited by last bits comming closer and closer? It is far before the corderships reach their destinations.... and we do not need a special signal for it ... (but the signal could be cheaper ...)

Post by **dvgrn** » October 26th, 2023, 10:56 am

Hippo.69 wrote: ↑
October 26th, 2023, 7:28 am
Another idea ... Could the selfdestruction of ECCA be ignited by last bits comming closer and closer? It is far before the corderships reach their destinations.... and we do not need a special signal for it ... (but the signal could be cheaper ...)

"Last bits coming closer and closer" sounds like the time just before the "singularity", when the GPSEs are all about to crash into each other. I'm not finding it immediately, but I remember at one point posting some solution for the crash at the epicentre, that released an extra glider. A signal like that didn't turn out to be needed for anything, so nobody used that idea.

-- But that can't be what you mean, because the ECCA and the cleanup Corderships haven't even been built yet at the singularity point, so the ECCA definitely doesn't need a self-destruct signal then.

So... we could certainly design a little chunk of circuitry that notices when the last two bits come in, closer together than any previous pair of adjacent bits -- and cause a self-destruct explosion that does the ECCA cleanup.

I can't immediately think of a way to build such a mechanism that seems likely to be cheap enough to build, that it could compete with the current method of having the ECCA explicitly build an OTT / splitter / whatever to shoot itself down, when all of its other work is done. That doesn't mean that there isn't a clever solution along those lines, just that I'm not clever enough to think of it.

I guess a more likely approach is not to build any specific trigger mechanism for closely spaced input signals, but instead to figure out what the allowable repeat time is for the ECCA, see if the last two signals from the pseudo-BSRD can be arranged to be shorter than that repeat time ... and then just see exactly what it is that fails, and arrange self-destruct machinery to catch that failure.

Then the last act of the ECCA might just be to build an OTT to shoot down its own elbow, or something like that. It might work, I guess... But it's going to save a very small number of bits, at best. Or am I just misunderstanding the whole idea?

AlbertArmStain · Post by **AlbertArmStain** » October 26th, 2023, 11:47 am

dvgrn wrote: ↑
October 26th, 2023, 10:56 am
. . . When the GPSEs are all about to crash into each other. I'm not finding it immediately, but I remember at one point posting some solution for the crash at the epicentre, that released an extra glider. A signal like that didn't turn out to be needed for anything, so nobody used that idea.

Does epicenter signal or “episignal” go all the way down to the south east, self destruct the snarks, releasing a glider that self destructs the ECCA?

I’m pretty sure the current RCT already implements this, unless I’m mistaken for something else.

Hippo.69 · Post by **Hippo.69** » October 26th, 2023, 3:20 pm

AlbertArmStain wrote: ↑
October 26th, 2023, 11:47 am

dvgrn wrote: ↑
October 26th, 2023, 10:56 am
. . . When the GPSEs are all about to crash into each other. I'm not finding it immediately, but I remember at one point posting some solution for the crash at the epicentre, that released an extra glider. A signal like that didn't turn out to be needed for anything, so nobody used that idea.
Does epicenter signal or “episignal” go all the way down to the south east, self destruct the snarks, releasing a glider that self destructs the ECCA?

I’m pretty sure the current RCT already implements this, unless I’m mistaken for something else.

The snarks are destroyed by first bit redirected to ECCA ... it is just turned before reaching the ECCA.
I have expected the epicenter bits (reflected from FSE reflectors) could be close enough that reset mechanism would be slower than the spacing among them and they are naturaly at the end of the recipe so there is definiely no more need for the ECCA ... but that was just an idea... but anyways I should check what the last bits would do to the ECCA ...

OK their distance is 24*256 ticks ... let me try... The +4 cycle is fast enough to accept the last bits, similarly the '2' signals could closely follow.
But if the 24*256 interval comes just during reset the ECCA explodes. The reset signal enters to the first codon reaction ...

Actually reset just started ... only the first (4) codon was reset codons (2), (1), (fake), (phase) and (fire) are still to be reset.
this is why resets with longer gaps would probably explode as well. .... let me check how big distance the reset requires so when the last fire could occur ... if we want to prevent the explosion ... (by going to (4) reset cycle).

distance 90*256 after reset is the last collision (this actually without explosion).

last glider time disances of current recipe are 90*256, 45*256, 24*256. (bits '1221')
24 explodes, 45 reset signal does not colide with the codon(s), 90 colides to stabilised pattern. We probably can increase the glider distance by something like multiple of 3*256 without changing the function of the pattern ... so we can select a best fitting collision if we decide to go this way....