import systrashvar = Noneyn = Nonecontinuevar = FalsecontinueProgvar = Truecellnum = 0nw = 0n = 0ne = 0e = 0se = 0s = 0sw = 0w = 0total = 0#infoprint('you are using this version of python:')print(sys.version)print()print('''this program simulates Conway's Game of Life on a torus with shift 1.It uses inputted coordinates to turn cells on and off.It asks the user what it should do next.''')print()print('this program was coded by Moosey in 2019')print('this program is version 1.0.1')print('''version history:1.0: first version. VERY buggy.1.0.1: second version. assumes true when misinterpreting responses.''')print('''bugs:coordinate 0,0 does not turn onentering y coordinate 10 appears to fail (but not x)

That at least gets you some different behavior, even though it isn't the right behavior yet.

Yeah, you need to keep track of two seperate arrays, one for the previous generation and one for the next generation, and then copy the next generation to the previous generation. (i tried and failed on this before!)

testitemqlstudop wrote:Yeah, you need to keep track of two seperate arrays, one for the previous generation and one for the next generation, and then copy the next generation to the previous generation. (i tried and failed on this before!)

That's already there in the code -- cells[] and newcells[]. That part is all coded correctly, as far as I can see.

The next problem is in the way global variables are being handled in defnesw(). Try printing the value of cellnum on the first line of defnesw(), and it will always be zero -- for some reason Python is treating it like it's a local variable (though I'm drawing a blank on why that is exactly).

Global variables are getting used for everything, though, and this is going to cause lots of other problems. Setting nw, n, ne, e, etc. inside defnesw() won't do any good at all unless you tell Python that each of those variables should be treated as a global variable -- global nw, n, ne, e, se, s, sw, w ... The code as written will set the values of eight local variables, and then throw them away.

This problem can be fixed in any number of ways that are better than over-using globals, like by passing the value of cellnum into the function, and returning the eight neighbor values from the function:*

Meanwhile, if defnesw() is fixed, a new problem will appear, which has to do with the way the universe is wrapped around. Normal toroidal Life universes connect the right side of Row N to the left side of Row N, not to the left side of Row N+1. Something in the wraparound seems to be trying to access an out-of-range cell -- like maybe cells[100], when trying to look at the northeast cell from cells[9].

There's an awful lot of code in there trying to deal with storing a 2D grid in a one-dimensional list. Probably better to pick another storage method -- two-dimensional list, dictionary, something like that. Another change, probably to be wrestled with only when the current code is working perfectly, would be to set XSIZE, YSIZE = 10, 10 at the top of the script and get rid of the large number of hard-coded assumptions about the size of the grid.

* This is a simple fix, and it works fine, but it's potentially confusing -- because "cellnum" ends up being both a global variable (outside of the defnesw() function) and a local variable (inside the function). You could change the value of cellnum inside the function, and it wouldn't affect the value of cellnum in the code that calls defnesw(). This is something that's worth Googling "Python global variables" and stepping carefully through various tutorials until you understand the concept.

That's a nice synthesis! I was able to find a reduction. Specifically I used my synthesize constellation script to find a 3 glider synthesis of the TL + blinker constellation that was used in your synthesis. Here's the resulting 6G synthesis:

That's a nice synthesis! I was able to find a reduction. Specifically I used my synthesize constellation script to find a 3 glider synthesis of the TL + blinker constellation that was used in your synthesis. Here's the resulting 6G synthesis:

Thanks a lot! I'm not experienced at glider-synthesis, so I didn't know the 3g synthesises. (All the toolkit I used is Patterns/Life/Synthesis/two-glider-collisions.rle) That reducing script is pretty cool, never heard of it before.

-- and then put together a bunch of high-period guns that repeatedly create that reaction and then clean it up. But without a clear path to mutate a later stage of the reaction directly back into the original two-sparked-houses form, that doesn't seem like a very interesting exercise.

A more specific answer might be helpful, especially a specific reaction where the pattern and spark need to be placed. Otherwise any suggested solutions are likely to end up having gliders coming in from the wrong directions, crossing spaces that aren't available for the use you have in mind.

Also an example would let people know whether small modifications might be acceptable. For example, there are no three-glider collisions that produce the spark you're asking for, but there are four different 3G recipes that make the same eight-cell predecessor of the spark's T=1 stage:

So if the spark interacts with your intended target at exactly T=0, then the above recipes are probably no good, but if the interaction happens after T=0 then one of these syntheses might be useful.

(This is a lucky false positive from Goldtiger997's synthesise-patt script, by the way. The script found a match when there isn't really a match, because the population at T=0 happens to be the same.)

Does the other pattern really have to be an exact match for what you posted? There aren't any three-glider collisions that make its T=0, but there are lots of four- or five-glider collisions that can make its T=16 stage for example. I'm sure T=16 is too late, but what about T=1 or T=2?