Seems oriented part is built, remains to start the main clock, clean up and remove the OGGCA and the snarks ... and concentrate on transition function encoding forced modifications to the gene.
Hmmm, respacing the gene could take a while ... I should probably add separators to the timedelta files denoting possible places for changes.
In OGGCA portions the gap increase means we should crowl against the simkin gliders ... the non OGGCA portions are much more easier.
The OGGCA destroyals are critical considering the count of escaping gliders, another critical section would be OGGCA program interrupted by created speboe on the input path ... the allocation using splitters with seeds rather by synchronized ships is easier, as it creates less constraints.
Let us see which portions of the DNA would be affected.
First task would probably be graphical representation of requirements caused by the transition function (to be added to gen.mc).
Hmm the main clock seed expected build from NW rather from SE ... there will be slight change in it (and its salvo).
... 3 synchronization problems at the same time ... when to send OGGCA destroyal, when snark destroyal and when clock start ...
So OGGCA cleanup for case without blinker on right recomputed (just reduction of debries before the destroyal) ...
Hmmm, I have to stop OGGCA while allocating NNWW and NW, unfortunately the used ott boats are in the way of OGGCA stopping, so the boats should be moved further and another glider lane used for the allocation (after OGGCA stop passes around).
0E0P constructions
Re: 0E0P constructions
Seems construction is finished, clocks are synchronized.
The only problem remains ... the transition function (and state transitions).
Checking the maximal signal 7 passing through neighbors DNA ...
there is no problem at signal crossing to SW, there is collision of 4th glider on path to NW with NW DNA
... spacing in DNA should be slightly altered there. There are no colisions on the paths to SE or NE neighbors.
So I have to generate graphical map of transition function requirements, and modify SimkinECCA.py to preserve comments from the source code to the result ... to allow easier localisation of problems ... (and solutions).
Actually the ONWWW probably requires some changes ... current realisation seems cuts from the 1024 ticks too small portion to allow 7 gliders to be present ... yes 509 consecutive glider positions can hold at most 6 gliders (in sc90 stream). There are 7 forbidden ticks before the portion opening and 63 forbidden ticks after its closing … giving us 954 of 1024 glider positions to be split to in/out portions. 589/365 looks like a reasonable split.
... it was proposal with variable long boat 180 ott position to decide the closing time (mod 1024) ... we need at least 541 consecutive glider positions so at least 4 FD shift, but let us plan the spacing first (we probably prefere gaps of size about 96 corresponding to 9 FD shift ...) and do the change at the end.
Seems a lot of the transition function is currently coded by DNA part waiting for 0hd glider to destroy the snark at the end of the oriented construction. There definitely cannot be gliders added to the DNA. So the transition function reading window should be shifted somewhere else.
Hmmm, I have not published snark conversion by -8hd glider to -13hd glider ... I could use this (and conversion by -13hd glider to nothing) instead of conversion to 0hd glider and 0hd to nothing. This would allow me to continue sending gliders ... .
If we make figure eight at correct lane behind the second snark (before building the snark?), we can use it as eater of %8 well timed gliders and destroy it cleanly by last glider ... this would allow us to encode transition function at this critical portion.
Codding in DNA portion before the second snark destroyal would not be that problematic, we can add almost arbitrary delay to OGGCA destroyal, (the OSSSE could me modified latter as well) we can let escape more gliders if required. (We can plan 7 OGGCA gliders per 0/7 state and use 7 single OGGCA glider anihilations in used portion) to code state 7 and 2*2+3 glider anihilations before the used portion to encode state 0 (using -> pond -> ship->)
The transition function encodding uses almost 1/4 of the DNA length (the distance between portions encoding 7777 and 0004), there are 15 portions encoding transitions from 07 to 0123456 and 511 portions encodding from 0123456 to 07, ideally we want to make these 511 portions to encode selectably (0/7).
We can delay the transition function DNA position by 1/8 DNA length by switching order of block boat on central clock output. Adding K gliders absorber after last semisnark after countdown clock would delay transition function by K/32 DNA length, but that would require repslmaking the most complicated build block. We can change the state of first semisnark after the main clock and change block before the boat to a 2 glider absorber what would shift transition function DNA by another 1/8 DNA length ... this would put it to the start of the shell build, what is probably the most flexible solution. Yep seems it would be "just" after ignition of the second fuse of the doublestretching crab. There is definitely a lot of flexibility there.
Seems it is solvable but there is still a lot of work to do.
OK, I have pslmaked main clock gun neighbourhood and ONWWW part with longboat shifted. I will replace corresponding portions of the recipe ... .
Meanwhile I made the graphic representation of the transition function requirements, I have added comments to gen.txt (timedeltas) with positions in the DNA in octa and I have changed the simkinECCA.py to include comments in output. I have recompiled all the sources ... and now there is some problem in shell construction (wrong synchronization around SSSE interuption of EEEE construction) ... I will be looking for the differences ...
There is a small complication in "looking for differences" as the compilation is "nondeterministic" ... there are often alternative recipes of the same length and there are hidden factors deciding which variant it choses ... so not all changes causes the problem ...
Seems when I was finishing the kernel openning changes to the shell, I have forgot manual splitting of a compiled file ... and I worked with the old version ... not corresponding to the source code ... It would be better to newly resync the SSSE interuption then returning to the old source code.
OK seems I have finaly made source codes compatible with cell building both shell and oriented contents. I have not resynchronized the central clock.
(Last problem was the better OGGCA algorithm laying boat at given position was not compatible with the proximity of the Simkin gun so the older recipe hed to be used. Other issues were essentially synchronization changes caused by more efficient parity emission choices. ... it was probably good training as changing spacing would cause to solve the synchronization problems again.)
So now its time to implement the small changes in the oriented pattern and resynchronize ... if the transition portion would be encoded in shell build portion, the changes to oriented portion would remain ... upto clock synchronization. It would be probably wise to increase distance between current shell build and the oriented build and let shell build expand to the emptied space ... during transition function encoding changes.
Hmm the selfdependencies ... Natural prolonging gap between shell build and kernel opening of the oriented build requires to close the shell input later ... but if there will be no GEN gliders between shell build and oriented build, there will be no problem if the kernel would be opened earlier.
So what would be shortened when shell build would be prolonged is not wait for kernel openning, but the distance between kernel openning and oriented gliders going through. There will be still risk in OEEEE corssing the input lane ...
The only problem remains ... the transition function (and state transitions).
Checking the maximal signal 7 passing through neighbors DNA ...
there is no problem at signal crossing to SW, there is collision of 4th glider on path to NW with NW DNA
... spacing in DNA should be slightly altered there. There are no colisions on the paths to SE or NE neighbors.So I have to generate graphical map of transition function requirements, and modify SimkinECCA.py to preserve comments from the source code to the result ... to allow easier localisation of problems ... (and solutions).
Actually the ONWWW probably requires some changes ... current realisation seems cuts from the 1024 ticks too small portion to allow 7 gliders to be present ... yes 509 consecutive glider positions can hold at most 6 gliders (in sc90 stream). There are 7 forbidden ticks before the portion opening and 63 forbidden ticks after its closing … giving us 954 of 1024 glider positions to be split to in/out portions. 589/365 looks like a reasonable split.
... it was proposal with variable long boat 180 ott position to decide the closing time (mod 1024) ... we need at least 541 consecutive glider positions so at least 4 FD shift, but let us plan the spacing first (we probably prefere gaps of size about 96 corresponding to 9 FD shift ...) and do the change at the end.
Seems a lot of the transition function is currently coded by DNA part waiting for 0hd glider to destroy the snark at the end of the oriented construction. There definitely cannot be gliders added to the DNA. So the transition function reading window should be shifted somewhere else.
Hmmm, I have not published snark conversion by -8hd glider to -13hd glider ... I could use this (and conversion by -13hd glider to nothing) instead of conversion to 0hd glider and 0hd to nothing. This would allow me to continue sending gliders ... .
If we make figure eight at correct lane behind the second snark (before building the snark?), we can use it as eater of %8 well timed gliders and destroy it cleanly by last glider ... this would allow us to encode transition function at this critical portion.
Codding in DNA portion before the second snark destroyal would not be that problematic, we can add almost arbitrary delay to OGGCA destroyal, (the OSSSE could me modified latter as well) we can let escape more gliders if required. (We can plan 7 OGGCA gliders per 0/7 state and use 7 single OGGCA glider anihilations in used portion) to code state 7 and 2*2+3 glider anihilations before the used portion to encode state 0 (using -> pond -> ship->)
The transition function encodding uses almost 1/4 of the DNA length (the distance between portions encoding 7777 and 0004), there are 15 portions encoding transitions from 07 to 0123456 and 511 portions encodding from 0123456 to 07, ideally we want to make these 511 portions to encode selectably (0/7).
We can delay the transition function DNA position by 1/8 DNA length by switching order of block boat on central clock output. Adding K gliders absorber after last semisnark after countdown clock would delay transition function by K/32 DNA length, but that would require repslmaking the most complicated build block. We can change the state of first semisnark after the main clock and change block before the boat to a 2 glider absorber what would shift transition function DNA by another 1/8 DNA length ... this would put it to the start of the shell build, what is probably the most flexible solution. Yep seems it would be "just" after ignition of the second fuse of the doublestretching crab. There is definitely a lot of flexibility there.
Seems it is solvable but there is still a lot of work to do.
OK, I have pslmaked main clock gun neighbourhood and ONWWW part with longboat shifted. I will replace corresponding portions of the recipe ... .
Meanwhile I made the graphic representation of the transition function requirements, I have added comments to gen.txt (timedeltas) with positions in the DNA in octa and I have changed the simkinECCA.py to include comments in output. I have recompiled all the sources ... and now there is some problem in shell construction (wrong synchronization around SSSE interuption of EEEE construction) ... I will be looking for the differences ...
There is a small complication in "looking for differences" as the compilation is "nondeterministic" ... there are often alternative recipes of the same length and there are hidden factors deciding which variant it choses ... so not all changes causes the problem ...
Seems when I was finishing the kernel openning changes to the shell, I have forgot manual splitting of a compiled file ... and I worked with the old version ... not corresponding to the source code ... It would be better to newly resync the SSSE interuption then returning to the old source code.
OK seems I have finaly made source codes compatible with cell building both shell and oriented contents. I have not resynchronized the central clock.
(Last problem was the better OGGCA algorithm laying boat at given position was not compatible with the proximity of the Simkin gun so the older recipe hed to be used. Other issues were essentially synchronization changes caused by more efficient parity emission choices. ... it was probably good training as changing spacing would cause to solve the synchronization problems again.)
So now its time to implement the small changes in the oriented pattern and resynchronize ... if the transition portion would be encoded in shell build portion, the changes to oriented portion would remain ... upto clock synchronization. It would be probably wise to increase distance between current shell build and the oriented build and let shell build expand to the emptied space ... during transition function encoding changes.
Hmm the selfdependencies ... Natural prolonging gap between shell build and kernel opening of the oriented build requires to close the shell input later ... but if there will be no GEN gliders between shell build and oriented build, there will be no problem if the kernel would be opened earlier.
So what would be shortened when shell build would be prolonged is not wait for kernel openning, but the distance between kernel openning and oriented gliders going through. There will be still risk in OEEEE corssing the input lane ...
Re: 0E0P constructions
It is probably time to think about efficient build of this ^ (xy swap possible) (typically we have time to build it, but why not to use fast recipe), it could be nice to replace wX for big enough X by figure eight construction so transition function encodding would be trivial in affected gaps. The shell construction till 4q has a lot of gaps witing for synchronization events and we can postpone a lot of build "for free".Hippo.69 wrote: June 12th, 2026, 9:25 pmCode: Select all
x = 192, y = 65, rule = LifeHistory14 10$10.DyN58.DyN58.DyN$10.yN2D57.yN2D57.yN2D$10.2D2yN56.2D2yN56.2D2yN$ 11.4yN56.4yN56.4yN$12.4yN56.4yN56.4yN$13.4yN56.4yN56.4yN$14.4yN56.4yN 56.4yN$15.4yN56.4yN56.4yN$16.4yN56.4yN56.4yN$17.4yN56.4yN56.4yN$18.4yN 56.4yN56.4yN$19.4yN56.4yN56.4yN$20.4yN56.4yN56.4yN$21.4yN56.4yN56.4yN $22.4yN56.4yN56.4yN$23.4yN56.4yN56.4yN$24.4yN56.4yN56.4yN$25.4yN56.4yN 56.4yN$26.4yN56.4yN56.4yN$27.4yN56.4yN56.4yN$28.4yN56.4yN56.4yN$29.4yN 56.4yN56.4yN$30.4yN56.4yN56.4yN$31.4yN56.4yN56.4yN$32.4yN56.4yN56.4yN $33.4yN8.2yN46.4yN56.4yN$34.4yN6.3yN47.4yN56.4yN$35.4yN4.6yN46.4yN56. 4yN$36.4yN3.6yN47.4yN56.4yN$37.5yN.7yN47.4yN56.4yN$38.13yN47.8yN.yN 50.4yN.pBE$39.5yND6yN48.5yND4yN50.2yN2.2EN$39.4yNDyND4yN51.2yN3D3yN 52.pBEP2E$41.yND3yND3yN51.yN3DyND4yN50.3EPTE$42.yND3yND2yN52.yND3yND 4yN50.NETE.E$43.yND3yND2yN51.2yND3yND3yN52.E.ETEN$44.yND3yNDyN51.3yND yN3DyN54.ETP3E$45.yNDyND2yN49.6yN3D2yN55.2EPEpB$46.yND3yN48.8yNDyN57. N2E$47.2yN50.10yN58.EpB$99.9yN$99.9yN$100.7yN$101.5yN$102.2yN!
here are bespokes for figure8 in this orientation:
Code: Select all
x = 82, y = 23, rule = B3/S23
8b2o61bo$8b2o60bobo$71bo2$5b2o5b2o$4bo2bo4b2o$5b2o54b2o$60bo2bo$61b2o
5b2o$68b2o$bo$obo$o2bo$b2o65b2o$68b2o2$79b3o$79bo$80bo2$21b2o$21bobo$
21bo!