Golly is cell level editor. In GOL many times we have "logical components" (like reflectos, duplicators, blockic seeds etc.). So we need more tools to allow "Smart Editing". By Smart Editing I mean tools that allow move reflectors, duplicators, place reflectors from gliders, and even manage Hershels from inside golly using input-output interfaces style.

This thread is made to make collection (and collect more request) for logical editors scripts for Golly.

----

For starters, I've wrote a small script that allows moving reflectors while maintaining their function (recognizing them, iterating, keeping on the correct lane).

Looks good! A good goal to look at might be the idea of making a circuit editor that would actually be helpful at tightening up the guns in the new p160 dart gun.

An edge shooter isn't technically a reflector, but it needs exactly the same kind of phasing adjustment if it's moved diagonally. If a component as large as an individual edge shooter can be recognized, then dragging it a few steps closer to a neighbor should be easy enough. The trick is that really close placements tend to require welding or other customization.

Once a weld has been put in place,

A) the edge shooter isn't an exact match for the standard model any more, and
B) the edge shooter and its neighbor should really be considered as one unit for future moves. Or if they're broken apart, the welds should be removed (but maybe remembered in case they get shoved back to minimum distance again later?)

That starts getting pretty tricky. Maybe the first step is to include a library json-or-whatever to which new reflector patterns can be added, and see if a workable GUI can be designed to shove around things as big as guns or edge shooters.

We want to leave the "output" glider at place, and adjust the gun relative to it. So we need few scripts:

1. Click on a glider and the gun will appear automatically at some "safe distance". Right click and the gun "flips" to shoot the same glider form other side (or shows the next available gun). Click another glider, and once again gun is added in even further "safe" distance etc.

2. Take a gun, and move it along a diagonal, while adding and erasing gliders if they recognized as his output, while moving it, you can press "space" and check out the output after say 1000 generations (or gun period *5). This way you can "micro adjust" your gun pretty quickly. Also we should allow more accurate movement by typing the move step (or arrow keys to move it one cell diagonally).

---

Regarding the performance search issue: One way to optimize the search is to have "hash table" around the area of the click. Having say 5x5 square hashed, will reduce the search options very quickly.

Obviously json is important addition. Having 160 period with 100 cells gun, and 8 orientations - becomes somewhere around 12M of data. We can define the gun itself in the script, just need to save json first time the script executes. Next time the script will initialize much faster.

---

Do you think we need more functionality?

EDIT I was thinking about it again. We don't need smart pattern recognition functionality. It's great that we have one, but what we need is "metadata" per cell. We want to know for each cell (or to maximum cells), to which pattern it belongs. i.e. what is the pattern, where it's placed, how it's oriented, what its input and output, what its current internal state etc. We also want the document to hold array of patterns instead of array of cells. When you start from array of gliders, the only thing that needs recognition is the glider. For guns that you place according to the gliders, you can store it all in the metadata. Once you finish, you save the metadata, and once you want to continue working you load the metadata. In general one can "code" any metadata inside the cells of the pattern itself, just place them at distance 2 from each other, but I don't like this idea too much (still we can store something like path to json inside the pattern).

This can also allow working with different prepared patterns, this array of patterns can be part of json. I don't think we need to store the p160 in our constant array of recognizable objects. What we need is to store array of recognizable object inside the json of the current document, and initialize it inside metadata constructor.

simsim314 wrote:EDIT I was thinking about it again. We don't need smart pattern recognition functionality. It's great that we have one, but what we need is "metadata" per cell. We want to know for each cell (or to maximum cells), to which pattern it belongs. i.e. what is the pattern, where it's placed, how it's oriented, what its input and output, what its current internal state etc.

That seems right. We only need to store one orientation and phase of each object, plus the fact that it's periodic, emits gliders/spaceships/whatever, or is capable of performing a conversion of input object A into output object B.

Possibly this kind of pattern definition could shrink some large patterns down to where they could be included in Golly's pattern collection. As the link above says, I've always wondered how big a complete high-level description of the Caterpillar would be.

Anyway, yes, the really handy thing would be an editor that groups cells into objects, and small objects into constellations and larger objects, and so on. It could allow editing operations on the highest-level objects only, with an option to ungroup a chosen object into a collection of lower-level objects. Not sure what the GUI would look like for this grouping/ungrouping idea, but the pattern could be displayed in a multistate rule in Golly -- it doesn't have to be instantly runnable, just has to be convertible into a Life pattern on demand. Edits would be saved only as metadata, not (necessarily) as bit patterns.

Hmm this is interesting - because I was concerned more with logical representation, and you with hierarchy.

Let me explain what is more or less the difference: take the replicator for example. It has some "serial" input output components, but it's not "very" hierarchical. It's of course built out of N herschel conduits and reflectors etc, but you can approach it as series of input->Transormer->output way. You don't need deeply nested hierarchy.

On the other hand you can see that replicator input signal is very versatile and yet has some very distinct "logical meaning". So the "versatility" will come not from hierarchy, but from complex input encoding sequences. So what's actually need logical representation is the glider sequence, that encodes another sequence for slow salvo, which encodes SL building order. This is all part of "smart input" encoding, and less about object hierarchy.

Obviously this is specific property of the replicator, for the universal computer (or take the pi calculator), the hierarchical representation is much more relevant - but still I think this is point we should pay attention to.

---

Anyway I definitely like the idea of switching rules, and representing data in special rule, although the metadata approach could make a lot of micromanagement itself as well, so you will not need anything special shown in golly except the basic pattern itself - unless you just want to colorize the logical entities for the data representation.

I was thinking about how a GUI for logical herschel conduit construction would look like - the problem that there is a lot of conduits, so just displaying not ordered list of conduits is a bad idea. So GUI is definitely an issue, and golly is not really helping out - we need to add side menu of our own, although golly has place for such things in pattern/script menu.

I was also considering to compile Golly myself, to tweak it a bit (for starters to add more events like shift up or mouse up) but I guess it's kinda dead end, asking people to download my version of golly, is a bad direction, and starting to tweak golly sound like story without ending.

simsim314 wrote:Hmm this is interesting - because I was concerned more with logical representation, and you with hierarchy.

Let me explain what is more or less the difference: take the replicator for example. It has some "serial" input output components, but it's not "very" hierarchical. It's of course built out of N herschel conduits and reflectors etc, but you can approach it as series of input->Trans[f]ormer->output way. You don't need deeply nested hierarchy.

The linear replicator seems like kind of a special case, though. First, the circuitry has been cut down to a bare minimum so there isn't much of a circuit hierarchy. And second, everything is placed very carefully to match a custom construction recipe, so there's really no editing that could usefully be done.

Let's take a different example, where a circuit editor would actually be quite handy: the dart gun currently in progress. One of the standard edge-shooter guns for this project looks like this:

Or you could even put a twist in the loop, and then there are various movable pairs of reflectors that can be adjusted. Actually that trick does look as if it can save half a dozen rows in the p160 dart gun... I'm not sure how to make an intuitive GUI that can flip over a reflector and add two more flanking Snarks, though, so probably that would have to start out as a different gun variant:

Maybe it would work to have a mechanism to "unlock" some sub-objects while leaving others locked. If you unlock just Snark3, it won't be movable -- but if you unlock Snark2 and Snark3 and turn off the period-160 constraint, you can move either Snark2 or Snark3 diagonally and the other Snark will come along automatically.

If you don't turn off the period-160 constraint, then ideally the two Snarks could still be moved, but they'd snap to just every 40th position on the diagonal. Or if you unlock Snark1, Snark2, and Snark3 but keep the period-160 constraint, then it ought to be possible to move Snark2 vertically, with the other two moving diagonally to compensate (!).

A complete gun is one or two steps up in the hierarchy. It's probably more interesting to think about representing it successfully with metadata, than to actually edit the full gun pattern and work down through that many levels:

<wild weld tangent>I really love the idea of a library of known welds, where as you're dragging a Snark (let's say) closer to another Snark, an appropriate weld automatically appears, and disappears again when you drag it further away. If no workable weld is known, the object would presumably snap to the closest position that doesn't need a weld.

An automatic search for weld solutions would be impressive, but a terrible headache -- objects not only have to be stable in proximity to each other, but the original function of each must not be damaged... A more likely impressive feature would be a way to turn off the proximity alarm, drag the object into the right position, draw a weld in by hand, and have it automatically added to the database of known solutions.

-- Sorry, all of the weld speculations are pretty unlikely in the short term, I suppose. Might be something to think about once the basic circuit editor is working and the metadata format is worked out.</wild weld tangent>

simsim314 wrote:Anyway I definitely like the idea of switching rules, and representing data in special rule, although the metadata approach could make a lot of micromanagement itself as well, so you will not need anything special shown in golly except the basic pattern itself - unless you just want to colorize the logical entities for the data representation.

Colorization is the main thing, I think -- we could easily have a different color for each of dozens of separate components. Or there could be patches of background color showing where one component leaves off and another begins. Background colors could be altered to show that an item has been selected or changed status, while still leaving the select tool available to make a second selection. The rule table itself could be empty, so that nothing at all would happen if you ran the pattern.

simsim314 wrote:I was thinking about how a GUI for logical herschel conduit construction would look like - the problem that there is a lot of conduits, so just displaying not ordered list of conduits is a bad idea. So GUI is definitely an issue, and golly is not really helping out - we need to add side menu of our own, although golly has place for such things in pattern/script menu.

I was also considering to compile Golly myself, to tweak it a bit (for starters to add more events like shift up or mouse up) but I guess it's kinda dead end, asking people to download my version of golly, is a bad direction, and starting to tweak golly sound like story without ending.

I've been seriously considering putting some time into creating a simple programmable toolbar in Golly, where you can choose a bitmap and assign a script to any of an adjustable number of buttons -- maybe just in the blank part of the existing toolbar? I wouldn't say no to a floating toolbar, but wouldn't want it enough to deal with the code for docking and undocking it.

The really nice trick would be to allow programmable access to the toolbar buttons, so that some buttons would be visible only when a script is running. Seems as if that would make it a lot easier to write really good editing and search tools.

My experience with the Golly project has been that whenever I really wanted to contribute code for some minor new functionality, Andrew has been really nice about fixing any obvious silly mistakes I might have made, and rolling the changes into the next official release. Seems to me if there are obvious holes in Golly's abilities that you'd like to try patching, then that isn't necessarily a dead end at all.

The code is divided nicely into classes. And made no assumption for the pattern library - so it can easily be adjusted to any gun building task. I took few "shortcuts" (obviously) - one of the is the assumption that the input patetrns ouput glider center, is at (0, 0). It's easy to adjust - just need to be known. Another shortcut is that for now I've no input, or two output option (although the data structure supports it)- the script was optimized for p160 gun building in few places. Obviously it's pretty easy to improve it, the code is maintainable, and very systematic.

To use:

Start from glider synth, click on gliders to get gun, move guns freely (they iterate internally automatically), hit space to see the near future, hit arrow keys to adjust guns with small step, hit c to look at each gun with separate color. Hit 'h' for help. Enjoy.

Last edited by simsim314 on December 19th, 2014, 8:14 pm, edited 3 times in total.

This is interesting point you're making. I was thinking about it as "logical builder" but actually, we have "hierarchical" builder. While the gun editing phase, is just one of many phases in the "same" hierarchy building process.

I understood the point of colorizing pretty quickly playing with my script . Used some rule with 69 states, and nice colors for the first states.

Python is surprisingly ill supported to all that concern a little bit more advanced serialization.

I'll see if there is something simple I can tweak in golly. Golly is huge projects anyway...I guess I much more prefer to invest my time in LifeAPI.

I'm coming to conclusion that we not only need a nice GUI for logical editors - but some sort of high programming language, or an API for designing large patterns.

Also in high level design, many times one wants to make simple searches - like what is the minimal distance from where the design will work, or what is the best SL reflector to place somewhere, or what is the optimal order of placement. Those things don't need to be done by hand, we need some set of tools (GUI/Programming), that will do the work in user friendly manner.

Say for the enginless caterpillar, I've *WSS edge shooters recipes, and *WSS recipes, and slow salvo recipes. But I still need to work really hard to combine them all together, into one coherent design.

And obviously some works is needed, but I think we need some sort of standard tool/library, that will do many of the things automatically, or even half automatically - we're doing too much things by hand.

I'm not familiar with robocat (and couldn't find anything that seems relevant on google). Do you have a link?

Anyway taking some parts and playing with them, the basic data structure design was already made in gun script. Basically the guns are adjusted according to the output glider.

But it seems to me it's not the only thing that we need. We need not only adjustment, and placement - but also small search utilities, and high level input-output language/data structure.

Think of universal constructor it has four stages:

1. List of SLs.
2. Recipes to construct each SL and order of construction. This should be done by some search utility.
3. Recipes for arm movements. The recipe list should be cost input for the search utility.
4. Recipes from glider stream to glider pairs. This should be done with some "auto translation" - output to X becomes input to Y. And you just concatenate inputs.

Now for the caterpillars is very similar:

1. List of *WSS recipes to produce.
2. Recipes to produce each *WSS with edge shooters.
3. Recipes to place the "basic interaction" stream, to generate edge shooters with slow salvo.
4. For each glider in slow salvo recipe - place SL, and concatenate the SLs.

- It seems to me we're solving a lot of similiar problem writing almost the same script over and over again.

@HartmutHolzwart - thx for the link. I saw the code a little bit, and it seems there are few general classes there, that can be put into some sort of library, but many of them are caterpillar oriented.

Anyway this is c++ implementation. I don't think that for high level designer we need c++, actually python+golly seems to be a better option for such things, and it also allows nicer user experience overall.

But you bring up an interesting question: maybe someone who designed high level complex designes (dvgrn, calcyman, chris_s, biggiemac, codeholic(?)), can post here their generation scripts, to analyze them.

Still it feels they're missing something. All of them are very implementation oriented, and it's hard to see how to make general usage function library for them. Especially many small searches that were done in preparation are omitted from the final scripts.

EDIT Maybe someone has an idea for data structure / library of functions / GUI design that are needed as "tool set" of logical editors. I've more or less the concept of single level data structure with auto-adjustable for timing input-output (you can see it in the glider gun script). But this is just a very small part of what is really needed for high level design. Except of the hierarchical concept of input-output devices built one on top of the other, maybe some people have more ideas.

EDIT2 I think to see what kind of tools are needed for high level enginless, and try to write the script as generic as possible, hopefully providing a general purpose tool set.