Page 3 of 13

Re: Hacking apgsearch

Posted: January 25th, 2016, 10:29 pm
by drc
Just uploaded a haul of B3S23-q, hope it worked!

Edit: woo hoo!

Re: Hacking apgsearch

Posted: January 27th, 2016, 7:56 pm
by A for awesome
A small bugfix and update:
apgsearch-2016-1-21-v0.54+0.21i.py.zip
(157.2 KiB) Downloaded 360 times
It fixes a bug that caused the auxiliary rules to be misgenerated sometimes and the rule to be randomly set to B3/S23 sometimes. Anyone currently using v0.20i is strongly encouraged to update to v0.21i because the bug severely limits v0.20i's capabilities. It also adds two small p4 ships to the common_names dict.

Re: Hacking apgsearch

Posted: January 27th, 2016, 9:37 pm
by drc
I keep getting the error:

Code: Select all

---------------------------
Golly warning:
---------------------------
Error reading APG_CoalesceObjects_B2-aS12.rule on line 87: ba,bb,bc,2 - too few entries
---------------------------
OK   
---------------------------
When I use a new rule with both 0.2i and 0.21i. What is happening? An example of a used rule:

Code: Select all

@RULE B2-aS12
@TABLE
n_states:2
neighborhood:Moore
symmetries:rotate4reflect

0,1,0,1,0,0,0,0,0,1
0,1,0,0,1,0,0,0,0,1
0,1,0,0,0,1,0,0,0,1
0,0,1,0,1,0,0,0,0,1
0,0,1,0,0,1,0,0,0,1
0,0,1,0,0,0,1,0,0,1
1,0,0,0,0,0,0,0,0,0
1,1,1,1,0,0,0,0,0,0
1,1,1,0,1,0,0,0,0,0
1,1,1,0,0,1,0,0,0,0
1,1,1,0,0,0,1,0,0,0
1,1,1,0,0,0,0,1,0,0
1,1,1,0,0,0,0,0,1,0
1,1,0,1,0,1,0,0,0,0
1,1,0,1,0,0,1,0,0,0
1,1,0,0,1,0,1,0,0,0
1,0,1,0,1,0,1,0,0,0
1,1,1,1,1,0,0,0,0,0
1,1,1,1,0,1,0,0,0,0
1,1,1,1,0,0,1,0,0,0
1,1,1,0,1,1,0,0,0,0
1,1,1,0,1,0,1,0,0,0
1,1,1,0,1,0,0,1,0,0
1,1,1,0,1,0,0,0,1,0
1,1,1,0,0,1,1,0,0,0
1,1,1,0,0,1,0,1,0,0
1,1,1,0,0,1,0,0,1,0
1,1,1,0,0,0,1,1,0,0
1,1,0,1,0,1,0,1,0,0
1,0,1,0,1,0,1,0,1,0
1,0,0,0,1,1,1,1,1,0
1,0,0,1,0,1,1,1,1,0
1,0,0,1,1,0,1,1,1,0
1,0,0,1,1,1,0,1,1,0
1,0,0,1,1,1,1,0,1,0
1,0,0,1,1,1,1,1,0,0
1,0,1,0,1,0,1,1,1,0
1,0,1,0,1,1,0,1,1,0
1,0,1,1,0,1,0,1,1,0
1,1,0,1,0,1,0,1,1,0
1,0,0,1,1,1,1,1,1,0
1,0,1,0,1,1,1,1,1,0
1,0,1,1,0,1,1,1,1,0
1,0,1,1,1,0,1,1,1,0
1,1,0,1,0,1,1,1,1,0
1,1,0,1,1,1,0,1,1,0
1,0,1,1,1,1,1,1,1,0
1,1,0,1,1,1,1,1,1,0
1,1,1,1,1,1,1,1,1,0
@COLORS
0 0 0 0
1 255 255 255

Re: Hacking apgsearch

Posted: January 27th, 2016, 10:40 pm
by A for awesome
drc wrote:I keep getting the error:

Code: Select all

---------------------------
Golly warning:
---------------------------
Error reading APG_CoalesceObjects_B2-aS12.rule on line 87: ba,bb,bc,2 - too few entries
---------------------------
OK   
---------------------------
When I use a new rule with both 0.2i and 0.21i. What is happening? An example of a used rule:

Code: Select all

@RULE B2-aS12
@TABLE
n_states:2
neighborhood:Moore
symmetries:rotate4reflect

0,1,0,1,0,0,0,0,0,1
0,1,0,0,1,0,0,0,0,1
0,1,0,0,0,1,0,0,0,1
0,0,1,0,1,0,0,0,0,1
0,0,1,0,0,1,0,0,0,1
0,0,1,0,0,0,1,0,0,1
1,0,0,0,0,0,0,0,0,0
1,1,1,1,0,0,0,0,0,0
1,1,1,0,1,0,0,0,0,0
1,1,1,0,0,1,0,0,0,0
1,1,1,0,0,0,1,0,0,0
1,1,1,0,0,0,0,1,0,0
1,1,1,0,0,0,0,0,1,0
1,1,0,1,0,1,0,0,0,0
1,1,0,1,0,0,1,0,0,0
1,1,0,0,1,0,1,0,0,0
1,0,1,0,1,0,1,0,0,0
1,1,1,1,1,0,0,0,0,0
1,1,1,1,0,1,0,0,0,0
1,1,1,1,0,0,1,0,0,0
1,1,1,0,1,1,0,0,0,0
1,1,1,0,1,0,1,0,0,0
1,1,1,0,1,0,0,1,0,0
1,1,1,0,1,0,0,0,1,0
1,1,1,0,0,1,1,0,0,0
1,1,1,0,0,1,0,1,0,0
1,1,1,0,0,1,0,0,1,0
1,1,1,0,0,0,1,1,0,0
1,1,0,1,0,1,0,1,0,0
1,0,1,0,1,0,1,0,1,0
1,0,0,0,1,1,1,1,1,0
1,0,0,1,0,1,1,1,1,0
1,0,0,1,1,0,1,1,1,0
1,0,0,1,1,1,0,1,1,0
1,0,0,1,1,1,1,0,1,0
1,0,0,1,1,1,1,1,0,0
1,0,1,0,1,0,1,1,1,0
1,0,1,0,1,1,0,1,1,0
1,0,1,1,0,1,0,1,1,0
1,1,0,1,0,1,0,1,1,0
1,0,0,1,1,1,1,1,1,0
1,0,1,0,1,1,1,1,1,0
1,0,1,1,0,1,1,1,1,0
1,0,1,1,1,0,1,1,1,0
1,1,0,1,0,1,1,1,1,0
1,1,0,1,1,1,0,1,1,0
1,0,1,1,1,1,1,1,1,0
1,1,0,1,1,1,1,1,1,0
1,1,1,1,1,1,1,1,1,0
@COLORS
0 0 0 0
1 255 255 255
It's the @COLORS section; I will fix this in the next update, but for now, just put an amended version of the rule without the @COLORS section in Golly's rules folder (keeping the version including the colors in your rules folder). This takes advantage of the fact that Golly and apgsearch look up rules in the opposite order from each other, so Golly sees the colors and apgsearch doesn't.

Re: Hacking apgsearch

Posted: February 6th, 2016, 1:22 pm
by A for awesome
I just noticed, in the Rule Request Thread, this:
dvgrn wrote:the correct "n" instead of the old Life32 "v".
I guess v0.2Ni has been outputting the rules in the wrong format all along. Here's the patched script:
apgsearch-2016-2-06-v0.54+0.21i-update.py.zip
(157.23 KiB) Downloaded 382 times
You are, again, strongly recommended to update. I also updated the Hensel-test.py script in the main v0.2Ni post to reflect the change.

Re: Hacking apgsearch

Posted: February 9th, 2016, 1:30 am
by Bullet51
Possibly a bug: When searching in rule B2-a/S0146, apgsearch-isotropic-v0.2 reports something like xq1_q1qz08, which is actually xp6_q1qz08. I have totally no idea about it.

Re: Hacking apgsearch

Posted: March 9th, 2016, 7:47 am
by Apple Bottom
Not so much a bug as a problem: searching certain rules will cause 0.54+0.21i to rapidly consume all available memory and cause the machine it's running on to thrash.

Image

Example rule: B2-aei3-a/S2-i34-i (rule files generated by isotropic-rule.py):

Code: Select all

@RULE B2-aei3-a_S2-i34-i

*** File autogenerated by saverule. ***


This is a two state, isotropic, non-totalistic rule on the Moore neighbourhood.
The notation used to define the rule was originally proposed by Alan Hensel.
See http://www.ibiblio.org/lifepatterns/neighbors2.html for details


@TABLE


n_states:2
neighborhood:Moore
symmetries:rotate4reflect

var a={0,1}
var b={0,1}
var c={0,1}
var d={0,1}
var e={0,1}
var f={0,1}
var g={0,1}
var h={0,1}

# Birth
0,1,0,0,1,0,0,0,0,1
0,0,1,0,1,0,0,0,0,1
0,0,1,0,0,0,1,0,0,1
0,1,1,0,1,0,0,0,0,1
0,1,1,0,0,1,0,0,0,1
0,1,1,0,0,0,1,0,0,1
0,1,1,0,0,0,0,1,0,1
0,1,1,0,0,0,0,0,1,1
0,1,0,1,0,1,0,0,0,1
0,1,0,1,0,0,1,0,0,1
0,1,0,0,1,0,1,0,0,1
0,0,1,0,1,0,1,0,0,1

# Survival
1,1,1,0,0,0,0,0,0,1
1,1,0,1,0,0,0,0,0,1
1,1,0,0,1,0,0,0,0,1
1,0,1,0,1,0,0,0,0,1
1,0,1,0,0,0,1,0,0,1
1,1,1,1,0,0,0,0,0,1
1,1,1,0,1,0,0,0,0,1
1,1,1,0,0,1,0,0,0,1
1,1,1,0,0,0,1,0,0,1
1,1,1,0,0,0,0,1,0,1
1,1,1,0,0,0,0,0,1,1
1,1,0,1,0,1,0,0,0,1
1,1,0,1,0,0,1,0,0,1
1,1,0,0,1,0,1,0,0,1
1,0,1,0,1,0,1,0,0,1
1,1,1,1,1,0,0,0,0,1
1,1,1,1,0,1,0,0,0,1
1,1,1,1,0,0,1,0,0,1
1,1,1,0,1,0,1,0,0,1
1,1,1,0,1,0,0,1,0,1
1,1,1,0,1,0,0,0,1,1
1,1,1,0,0,1,1,0,0,1
1,1,1,0,0,1,0,1,0,1
1,1,1,0,0,1,0,0,1,1
1,1,1,0,0,0,1,1,0,1
1,1,0,1,0,1,0,1,0,1
1,0,1,0,1,0,1,0,1,1

# Death
1,a,b,c,d,e,f,g,h,0


@COLORS

I'd make a mostly uneducated guess that this is due to extremely high-period oscillators. If so, I'd suggest capping the maximum number of generations the script'll do when investigating an object before giving up saying "ah ain't got no clue 'bout this here 'un".

Re: Hacking apgsearch

Posted: March 9th, 2016, 9:52 am
by A for awesome
Apple Bottom wrote:Not so much a bug as a problem: searching certain rules will cause 0.54+0.21i to rapidly consume all available memory and cause the machine it's running on to thrash.

Code: Select all

image
Example rule: B2-aei3-a/S2-i34-i (rule files generated by isotropic-rule.py):

Code: Select all

rule
I'd make a mostly uneducated guess that this is due to extremely high-period oscillators.
Generally (and I've encountered this a lot), it has to do with the time it takes soups to come to stabilization. For this rule, that time tends to run over 100000 gens. The RuleLoader algorithm naturally runs these patterns slower and takes more memory to do so (thanks to the hashing, which is useless for running soups to stabilization). I've found that 0.54+0.21i chokes up once soups start regularly taking in excess of 20000 gens to stabilize. I see no way to solve this problem, other than to write 0.54+0.21i up into a standalone c++ implementation (which I don't really know how to do) and use a non-hashing algorithm or wait for Golly 3.0 to come out.

Re: Hacking apgsearch

Posted: March 9th, 2016, 1:09 pm
by Apple Bottom
A for awesome wrote:Generally (and I've encountered this a lot), it has to do with the time it takes soups to come to stabilization. For this rule, that time tends to run over 100000 gens. The RuleLoader algorithm naturally runs these patterns slower and takes more memory to do so (thanks to the hashing, which is useless for running soups to stabilization). I've found that 0.54+0.21i chokes up once soups start regularly taking in excess of 20000 gens to stabilize. I see no way to solve this problem, other than to write 0.54+0.21i up into a standalone c++ implementation (which I don't really know how to do) and use a non-hashing algorithm or wait for Golly 3.0 to come out.
OK, fair enough. The problem's easy to diagnose and fix, so it shouldn't be a problem in practice.

Still, I'm wondering. Why run the pattern until stabilization no matter how generations it takes, instead of stopping after (say) 20,000? Rules like these aren't really suitable for soup-searching anyway, so perhaps the script could just pop up a message to this effect (possibly allowing the user to continue anyway, if they so choose).

Thanks for looking into this, BTW!

Re: Hacking apgsearch

Posted: March 9th, 2016, 2:50 pm
by fluffykitty
What happens if you set the hash memory to 0?

Re: Hacking apgsearch

Posted: March 9th, 2016, 5:13 pm
by A for awesome
Apple Bottom wrote:Still, I'm wondering. Why run the pattern until stabilization no matter how generations it takes, instead of stopping after (say) 20,000? Rules like these aren't really suitable for soup-searching anyway, so perhaps the script could just pop up a message to this effect (possibly allowing the user to continue anyway, if they so choose).
This seems like it might be a very good idea for non-totalistic rules. I will probably implement some variation of this feature if I ever get around to making 0.22i.

P.S. I should probably state as a disclaimer that the explanation given in my previous post was just an educated guess (read "wild speculation") about the source of the bug. My experience with 0.Ni and with Golly in general seems to suggest it, but it's not a 100% certainty.
fluffykitty wrote:What happens if you set the hash memory to 0?
I am mildly embarrassed to say that I don't actually know how to do that. It probably would still run slower than the equivalent outer-totalistic search (due to inherent inefficiencies in the RuleLoader algorithm compared to QuickLife).

Re: Hacking apgsearch

Posted: March 9th, 2016, 5:38 pm
by Apple Bottom
fluffykitty wrote:What happens if you set the hash memory to 0?
You mean the memory limit for HashLife in Golly's preferences? I'm not sure what that would accomplish, since setting it to 0 would actually remove the limit (set to 500 MB now).

In any case I noticed something interesting: when you leave Golly and apgsearch 0.54+0.21i running undisturbed, memory usage only fluctuates by about 300 MB, barely a blip on the radar. However, if you interact with the view, say by zooming or panning, it sometimes suddenly starts consuming memory at a rate of 700 MB/second.

I haven't figured out exactly what's triggering this yet, but it appears that it's due to rapid UI interaction. If you don't do anything, patterns will happily evolve for tens of millions of generations.

I'm fairly sure right now that this IS a bug somewhere (in Golly, Golly's scripting subsystem, or apgsearch). Presumably it doesn't usually manifest because patterns stabilize too fast in "normal", soup-searchable rules for the user to be able to trigger it.

'course, given that, it's still just a curiosity.

EDIT: here's another bug. Soup-searching a related rule, B2ck3-a/S2-aei34-i, produces the following error (sometimes quickly, sometimes after a while):

Image

"period" is likely zero there.

Re: Hacking apgsearch

Posted: March 21st, 2016, 5:20 pm
by Apple Bottom
There's a small issue with chaotic-growth patterns; these are reported as z_* instead of zz_*, e.g. z_QUADRATIC instead of zz_QUADRATIC, as seen here.

The culprit's powerlyse(), which returns the wrong descriptions.

Re: Hacking apgsearch

Posted: March 22nd, 2016, 3:32 pm
by A for awesome
Apple Bottom wrote:There's a small issue with chaotic-growth patterns; these are reported as z_* instead of zz_*, e.g. z_QUADRATIC instead of zz_QUADRATIC, as seen here.

The culprit's powerlyse(), which returns the wrong descriptions.
http://conwaylife.com/forums/viewtopic. ... &start=281

Re: Hacking apgsearch

Posted: March 22nd, 2016, 8:24 pm
by gameoflifeboy
Apple Bottom wrote:There's a small issue with chaotic-growth patterns; these are reported as z_* instead of zz_*, e.g. z_QUADRATIC instead of zz_QUADRATIC, as seen here.
This should be fixed in v(0.54+0.22i).

Another thing that should be added is the ability to separate pairs of gliders that only run in non-Life-like rules. See here: http://catagolue.appspot.com/object/xq4 ... b3-kq4js23

Re: Hacking apgsearch

Posted: March 23rd, 2016, 4:12 pm
by A for awesome
gameoflifeboy wrote:Another thing that should be added is the ability to separate pairs of gliders that only run in non-Life-like rules. See here: http://catagolue.appspot.com/object/xq4 ... b3-kq4js23
I'm actually working on a version of pseudo-bangbang that separates moving objects. I will probably include it in the next version, which would also get rid of things like this.

Re: Hacking apgsearch

Posted: April 8th, 2016, 3:09 am
by dom
Hi guys, I am currently testing my custom 3-state life-like rules with birth-forcers implemented. Is there a way to adapt apgsearch for oscillators and spaceships in this rule (eelife3, I did not use state 4 or 5 or 6)?

The raw rule before undergoing table generation:

Code: Select all

switch (c) 
{
case 0:
if (state1 neighbors==8)
return 2;
else if ((state1 neighbors + state6 neighbors ==3 )||(state2 neighbors + state4 neighbors >=1))
return 1;
else 
return 0;
case 1 :
if (state1 neighbors==8)
return 2;
else if (
!(
( ( state1 neighbors + state6 neighbors ) | 1 ) 
==3)
||
(state3 neighbors + state4 neighbors>=1 )  
)
return 0;
else
return 1;
case 2:
if ( ( ( state1 neighbors + state2 neighbors) | 1 )==3 )
return 2;
else 

return 0;
case 3: return 3;
case 4: return 4;
case 5: return 5;
case 6: return 6;
default:
        return 0 ; // should throw an error here
   }
The rule table :

Code: Select all

@RULE eelife3
# General Behavior:
#
# 0 is empty
# 1 is on
# 2 is birthforcer

# Specific Behavior
# 0 changes to 2 when state2 neighbors ==8
	otherwise changes to 1 when (state1 neighbors==3) || (state2 neighbors>=1)
		otherwise 0 stays 0
# 0 or 1 changes to 2 when state1 neighbors == 8
# 1 changes to 0 when (state1 neighbors) != 2, 3 
# 2 changes to 0 when (state1 neighbors + state2 neighbors) !=2,3
#     changes to 1 when state1 neighbors ==3 
# otherwise 1,2 stays 1,2
#  

@TABLE
# rules: 52
#
# Golly rule-table format.
# Each rule: C,N,NE,E,SE,S,SW,W,NW,C'
# N.B. Where the same variable appears multiple times in a transition,
# it takes the same value each time.
#
# Default for transitions not listed: no change
#
n_states:4
neighborhood:Moore
symmetries:rotate8
var a={0,1,2,3}
var b={0,1,2,3}
var c={0,1,2,3}
var d={0,1,2,3}
var e={0,1,2,3}
var f={0,1,2,3}
var g={0,1,2,3}
var h={0,3}
var i={0,3}
var j={0,3}
var k={0,3}
var l={0,3}
var m={0,1}
var n={0,2,3}
var o={0,2,3}
var p={0,2,3}
var q={0,2,3}
var r={0,2,3}
var s={0,2,3}
var t={0,2,3}
var u={1,2}
var v={0,3}
var w={0,3}
var x={1,2}
var y={1,2}
var z={1,2}
0,a,b,c,d,e,f,g,2,1
0,h,i,j,k,l,1,1,1,1
0,h,i,j,k,1,l,1,1,1
0,h,i,j,k,1,1,l,1,1
0,h,i,j,1,k,l,1,1,1
0,h,i,j,1,k,1,l,1,1
0,h,i,j,1,1,k,l,1,1
0,h,i,1,j,k,1,l,1,1
m,1,1,1,1,1,1,1,1,2
1,n,o,p,q,r,s,t,a,0
1,a,b,c,d,e,f,g,3,0
1,0,0,0,0,0,1,3,1,0
1,0,0,0,0,0,3,1,1,0
1,0,0,0,0,1,0,1,3,0
1,0,0,0,0,1,0,3,1,0
1,0,0,0,0,1,1,0,3,0
u,n,a,b,c,1,1,1,1,0
1,0,0,0,0,1,3,0,1,0
1,0,0,0,0,3,0,1,1,0
1,0,0,0,0,3,1,0,1,0
u,n,a,b,1,o,1,1,1,0
u,n,a,b,1,1,o,1,1,0
u,n,o,p,1,1,1,q,1,0
u,n,o,1,p,q,1,1,1,0
u,n,o,1,p,1,q,1,1,0
u,n,o,1,p,1,1,q,1,0
u,n,o,1,1,p,q,1,1,0
u,n,o,1,1,p,1,q,1,0
u,n,1,o,1,p,1,q,1,0
2,h,i,j,k,l,v,w,a,0
2,a,b,c,d,u,x,y,z,0
2,0,0,0,0,1,1,2,1,0
2,0,0,0,0,1,2,1,1,0
2,h,a,b,u,i,x,y,z,0
2,0,0,0,1,0,1,2,1,0
2,0,0,0,1,0,2,1,1,0
2,h,a,b,u,x,i,y,z,0
2,0,0,0,1,1,0,2,1,0
2,h,i,j,u,x,y,k,z,0
2,0,0,0,1,1,2,0,1,0
2,h,i,u,j,k,x,y,z,0
2,0,0,1,0,0,1,2,1,0
2,0,0,1,0,0,2,1,1,0
2,h,i,u,j,x,k,y,z,0
2,0,0,1,0,1,0,2,1,0
2,h,i,u,j,x,y,k,z,0
2,0,0,1,0,1,2,0,1,0
2,h,i,u,x,j,k,y,z,0
2,0,0,1,1,0,0,2,1,0
2,h,i,u,x,j,y,k,z,0
2,0,0,1,1,0,2,0,1,0
2,h,u,i,x,j,y,k,z,0


Re: Hacking apgsearch

Posted: April 14th, 2016, 5:42 pm
by drc
This is getting really annoying:

Image

Alright thanks!

Re: Hacking apgsearch

Posted: April 14th, 2016, 5:51 pm
by A for awesome
drc wrote:This is getting really annoying:

Code: Select all

image
Okay, I'm working on it! Give me time.

Re: Hacking apgsearch

Posted: April 14th, 2016, 6:08 pm
by drc
Alright thanks!

Also, this is commonly clasiffied as pathological:

Code: Select all

x = 6, y = 3, rule = B34k_S23
3b2o$o3b2o$2obo!
I'm guessing it separates the block and glider.

Re: Hacking apgsearch

Posted: April 15th, 2016, 11:06 am
by A for awesome
drc wrote:Also, this is commonly clasiffied as pathological:

Code: Select all

rle
I'm guessing it separates the block and glider.
Yes, that's what happens. That will be fixed in the next version as well.

Re: Hacking apgsearch

Posted: May 27th, 2016, 2:11 pm
by muzik
Uploading some unneccesarily microscopic B2in3_S123a hauls. Is there a way to increase the searching speed for this (I'm searching the heck out of b3s12, my other favourite rule, at the same time)?

Re: Hacking apgsearch

Posted: June 21st, 2016, 7:05 pm
by A for awesome
As it is taking much longer than expected for me to develop a new version (which will probably NOT be numbered 0.54+0.22i due to significant differences from the previous version; I am also considering making a C++ version), I've decided to post the one dirty bug fix for 0.21i that I do know how to do (Warning: untested code ahead; read whole post before using, and use at your own risk):
Within the Soup.census() function, change the two lines reading

Code: Select all

        # Remove any gliders:
        if (glidersexist):
to read

Code: Select all

        # Remove any gliders:
        if (glidersexist and stepsize < 8):
and later in the same function change the lines reading

Code: Select all

        # Remove Ts, if they exist:
        if self.rg.t:
to read

Code: Select all

        # Remove Ts, if they exist:
        if self.rg.t and stepsize < 8:
.
This should cause much fewer pathological objects in rules with glider tagalongs and possible T tagalongs if any aside from the double T exist in any rule. However, this will also result in the misidentification of all close glider and T pairs whenever an error-correcting phase is triggered. This won't be a problem once there is an accurate way to separate close spaceship pairs, but for the moment I would recommend copying your version of 0.21i, then implementing this fix and only using the fixed version for rules that have a problem with glider or T tagalongs.

Re: Hacking apgsearch

Posted: June 22nd, 2016, 10:42 pm
by drc

Re: Hacking apgsearch

Posted: June 23rd, 2016, 8:59 am
by A for awesome
drc wrote:With the new hack, this showed up:
http://catagolue.appspot.com/object/xq4_163xac4/b36ns23
Yes. That's why I said to only use it in rules where glider tagalongs (or T tagalongs) cause too many pathological objects, not for rules with unidentifiable objects arising for any other reason (like replicators). Ultimately, this problem can be solved, but it will take quite a bit of time (and frankly, I'd almost prefer just to rewrite the whole thing).