Goldtiger997 wrote: ↑November 19th, 2021, 8:36 am
Using my script I was able to complete the remaining shotguns without too much hassle. Here they are assembled with the rest of the pattern to create a breeder...
Very nice, thanks! It's good to have a working model.
This pattern actually makes a very nice test case for a "circuit tightener-upper" script that it probably makes sense to write at this point. Now that we have [Rule]Super supported in Golly, it should be possible to build a generalized helper script that works something like this:
1) Expect the user to switch a pattern into [Rule]Super, use toChangeState.lua to mark the parts of the pattern that need to be adjusted using some particular state, let's say State 25 -- and maybe make a selection of the "test" area (a section of the pattern that does not include the adjusted part, but that will break if that part is adjusted wrong).
If it works better, maybe a separate helper script could automatically find and mark the circuitry (whatever is stable, or periodic and doesn't move) inside a rectangular selection.
-- But it may turn out that we want the signals in that area marked in the same color anyway -- not sure yet. Like, it would be good to be able to click-and-drag things like this:
Code: Select all
x = 44, y = 56, rule = LifeHistory
6.3BA$7.ABAB$8.2A2B$9.4B$10.4B$11.4B$12.4B$13.4B$14.4B$15.4B$16.4B$
17.3BA13.A$18.ABAB10.3A$19.2A2B8.A$20.4B7.2A$21.4B3.5B$22.4B2.3B$23.
9B7.2A.2A$24.8B8.A.2A$25.10B3.B.A$25.4BA6B.B3A$25.2B2AB2A5BAB2.2A$25.
2B3A7B4A2.A$23.2AB.7B3.2B.A.2A$22.A.AB.7B2.B3A2.A$22.A5.4B4.A5.A$21.
2A5.4B5.5A$27.4B8.A$26.4B$25.4B$24.4B$9.A13.4B$9.3A10.A3B$12.A8.BABA$
11.2A7.2B2A$11.5B3.4B$13.3B2.4B$2A.2A7.9B$2A.A8.2BA5B$3.A.B3.4BABA3B$
3.3AB.4BA3BA2B$.2A2.BA5BA3BA2B$A2.4A5BA3BA2B$2A.A.2B3.3BABAB.B2A$.A2.
3AB2.4BA2B.BA.A$.A5.A4.4B5.A$2.5A5.4B5.2A$4.A8.4B$14.4B$15.4B$16.4B$
17.4B$18.4B$19.3BA$20.ABA$21.2A!
Seems like it would probably work better if the script knew that those signals were allowed to move along with the circuitry, especially the signals that are in the middle of interacting.
2) When the script runs, it will ask for a length of time T to run to test the adjustment. A default value of 1000 or whatever will probably be fine in most cases.
3) The script will analyze the marked area and see how signals move out of it. It might be spitting out gliders, *WSSes, loafers, fireships -- who knows? For the tightener-upper script to do its work, all outputs should be in the same direction, to give one degree of freedom.
The idea would be for the script to figure out what the direction of movement is, and let a user click and drag the marked region in that direction as long as the adjustment doesn't cause any changes to the selected area at T=1000. For the kind of adjustments I'm thinking of, it would probably be fine to pre-calculate every possible adjustment, and quickly XOR in whichever one the mouse is pointing at at a given moment. The most common effect would be that you could "snap" to the closest-in adjustment that still works.
Automatic welding, to allow slightly tighter positioning... will be left to be accomplished by a much more ambitious script designer than me.
I guess when the script exits, the adjustment will be presumed to have been made, so the state-25 markings can be automatically removed at that point.