simeks wrote:I'm beginning to think that soon it will not be very useful to build slow-salvo recipe databases for the most common objects. Instead, it will be easier to just do an on-demand search, using exactly the constraints of the needed recipe (such as the position of the target object, the wanted result (which could be more than one object), any pre-existing objects that must survive, an optional area where we'd like to have a new target object generated, etc.)
For really common objects I could see that working -- like blocks, blinkers, and possibly beehives and a few common constellations. But that approach seems impractical for rarer objects like eaters -- and probably anything not in the top five most common, tubs and ponds and ships and so on.
Given that we need the lookup tables for nearly all Spartan objects, it doesn't seem like it will do any harm to have tables for the common objects also. Then the same exact compiler code can do the same thing for any object to be constructed -- basically, look through recipes from cheapest to most expensive, until something is found that fits the current constraints.
Maybe do a rough pre-filtering of the list based on clearance? If a construction recipe leaves its output in the middle of its reaction envelope, four cells from the nearest edge, but an already-constructed object is only four cells away... then it doesn't matter how cheap the recipe is, there's no point in looking at it.
However, there are two parts to optimizing this kind of slow-salvo compiler. Generally we start from a target object, and want to produce an output object at (x,y) relative to the original target... plus another target object, conveniently placed. If possible the new target object should be exactly where it needs to be to start constructing the next object.
So to use, for example, one of the forward-pointing-boat recipes, we have to pick a boat recipe that is compatible with whatever objects have already been constructed -- but first we have to find a way to move a blinker to the starting position for that recipe, again without touching any already-constructed objects.
------------------------------------------
Speaking of forward-pointing boats, here are some trial results from a script (attached) that filters object recipes according to how many cells around the object are black instead of blue -- state 0 instead of state 2. I arbitrarily decided that state-0 cells immediately neighboring the object were ten times more valuable than neighbors of those neighbor cells. I ran the script on the forward-pointing-boat recipe list, and it made it easy to dig out the following recipes:
Code: Select all
#C super cheap, to back edge of reaction envelope
#C -3,2 from blinker:E-13 E-5 O-11 E-11
x = 466, y = 472, rule = LifeHistory
A$A$A17$12.3A$12.A$13.A148$166.3A$166.A$167.A148$314.2A$313.2A$315.A
148$463.3A$463.A$464.A!
Code: Select all
#C Push boat a long distance back, option to leave a blinker
#C -1,-20 from blinker:E5 E17 E11 E21 E5 [E1]
#C -13,-8 from blinker:E5 E17 E15 E3 E19 [E19]
#C -4,-17 from blinker:E5 O-5 E-9 O9 O-7 [O-7]
#C -7,-16 from blinker:E-13 E-9 E1 E-15 E-11 [E-5]
x = 772, y = 772, rule = LifeHistory
A$A$A17$21.3A$21.A$22.A148$177.3A$177.A$178.A148$324.3A$324.A$325.A
148$479.3A$479.A$480.A148$621.3A$621.A$622.A148$769.3A$769.A$770.A!
Code: Select all
#C small sideways offset
#C -7,4 from blinker:E-13 E-5 O9 E3 E9 E-7
x = 768, y = 772, rule = LifeHistory
A$A$A17$12.3A$12.A$13.A148$166.3A$166.A$167.A148$324.2A$323.2A$325.A
148$470.3A$470.A$471.A148$623.3A$623.A$624.A148$765.3A$765.A$766.A!
Code: Select all
#C bigger sideways offset
#C 16,-1 from blinker:E-13 O-11 O-3 E-21 E-5 E-1
x = 771, y = 772, rule = LifeHistory
A$A$A17$12.3A$12.A$13.A148$164.2A$163.2A$165.A148$318.2A$317.2A$319.A
148$458.3A$458.A$459.A148$616.3A$616.A$617.A148$768.3A$768.A$769.A!
Code: Select all
#C reach around from behind
#C -2,14:E-13 E-9 O5 O-1 E17 E-1
x = 771, y = 772, rule = LifeHistory
A$A$A17$12.3A$12.A$13.A148$164.3A$164.A$165.A148$322.2A$321.2A$323.A
148$469.2A$468.2A$470.A148$627.3A$627.A$628.A148$768.3A$768.A$769.A!
Code: Select all
#C narrow recipe with boat in west corner of reaction envelope
#C -1,2:E5 O-5 E11 O13 E9 O-5
x = 769, y = 772, rule = LifeHistory
A$A$A17$21.3A$21.A$22.A148$167.2A$166.2A$168.A148$324.3A$324.A$325.A
148$476.2A$475.2A$477.A148$623.3A$623.A$624.A148$767.2A$766.2A$768.A!
Obviously the script can be adapted to do a better job or sorting and classifying; this was just an easy first step.
---------------------------------
Maybe there's a case to be made for a backward lookup table for each object. For forward-pointing boats, let's say, we could make a collection of all [object@x,y] that we know about, that can be turned into a boat@0,0 with a reasonable number of slow gliders. "Reasonable number" would be bigger for rarer objects.
Then it seems like it might make sense to do an on-demand search for each new object to be constructed. I've been thinking about this for a while now: if you're constructing something fairly large, like a Demonoid-sized piece of circuitry, then at any stage of the construction you usually have a set of "optional objects" available. Each optional object is a leftover piece of junk from a previous construction, which can be shot down if it's not needed, but it isn't in the way of anything so you can leave it in place in case it becomes useful as a target.
Obviously if a later construction recipe is chosen that overlaps an optional-object location, that object stops being optional -- the compiler would go back and add a glider at some appropriate point in the compiled recipe, to shoot that object down.
Of course that brings up another big can of worms. The extra glider can be added any time after the optional object is created... but not all times are created equal. There will be a cheapest time to shoot down the object -- probably when the construction arm's elbow happens to be in the vicinity.
I think that's another problem for another month. However, it would definitely be nice to figure out a format for slow-salvo recipes that can record that kind of timing/ordering ambiguity, just as a first step toward a compiler that can make use of that information.
