chris_c wrote:(dvgrn: where did you get that font from?)
The conduit compiler looks like a great improvement over the ad-hoc layout I had come up with. If I recall correctly, the font is just 72-point Courier New, copied from MS Paint. Now that it's easy to substitute another font via the script, though, I'm definitely considering replacing it with a thinner sans-serif font that's a little easier to read when the whole collection is visible.
chris_c wrote:Really it shouldn't be hard for anyone to add new conduits and if N people work on the task at the same time the only thing they need to agree upon is the index number for any new additions.
I've been making a few additions to my own copy of the collection, but working along somewhat different lines -- mostly in regards to coming up with standard small labels (in Golly's make_text "mono" font) for every elementary conduit. I think that idea might work out really well with the compiler script -- e.g., if there's a name listed in a #N comment at the top of the RLE, the script could generate a label.
All of the H-to-Gs in my current stamp collection are labeled with the same labels that can be found in the
separate H-to-G collection, and they're sorted by lane number as well as output direction. I'm almost certainly going to rebuild the labels to use chris_c's Tx0 suggestion for recording the glider timing... and actually I'll probably just steal this compiler script and adapt it to re-create the H-to-G and H-to-G(n) stamp collections on the fly, as well. Further bulletins as events warrant.
I think there's a major limitation / minor irritation [delete whichever is inapplicable] with the way the script currently handles H-to-Gs. You'd have to change a lot of the index numbers if you want to add new H-to-Gs and keep them in sorted order.
Maybe that's what the separate H-to-G lookup table will be for, though, since in practice we won't care whether an H-to-G is an elementary conduit or not. If Fx77 plus h_g_01 puts a glider on the required lane, it usually won't matter that it's composite.
Speaking of which, is there a good way to keep multiple useful variants of an H-to-G near each other in the current system? For example, the old canonical form of h_g_01 has half as many still lifes, in completely different places:
Code: Select all
#C HtoG08SWpath10.rle
x = 48, y = 36, rule = LifeHistory
2$24.4B$23.5B.2B$23.9B$21.11B$21.12B$20.13B$20.14B$20.14B$20.15B$20.
17B$18.21B$12.4B2.22B$10.30B$9.4B.27B$9.4B.B.26B$9.4B3.B2A23B$9.6B.B
2A21B$9.32B$14.26B$16.B2.19B$18.19B$17.21B$16.9B.12B$15.4B.5B.12B$14.
4B2.4B3.9B.B2A$13.4B13.6B.BA.A$12.4B14.6B4.A$11.4B15.5B5.2A$10.4B17.
3B$9.4B19.2B$8.4B19.4B$7.4B19.B2AB$6.4B21.2A!
