Pattern viewer for forum threads

[rowett]

There might be issues with the ruletable conversion command.

It doesn't support B0 rules. I'll have it ignore them.

[muzik]

Will the new algorithm be on by default for 5-state to 8-state Moore @TABLEs once it gets out of the development stage? If so, I'd recommend having the viewer appear immediately and implement a special loading message for the cases where it takes a while to load up.

Done, thanks.

Sadly, this new loading screen appears to take far, far longer to get to the pattern than the prior approach, at least on my end. I don't know if it should be reverted, or if the renderer is to blame somehow, or something else entirely.

[rowett]

Sadly, this new loading screen appears to take far, far longer to get to the pattern than the prior approach, at least on my end. I don't know if it should be reverted, or if the renderer is to blame somehow, or something else entirely.

Please post an example pattern. On my end the initializing time is similar to the non-loading-screen version.

[rowett]

Sadly, this new loading screen appears to take far, far longer to get to the pattern than the prior approach, at least on my end. I don't know if it should be reverted, or if the renderer is to blame somehow, or something else entirely.

Let me know if this makes a difference.

On my machine initializing incrementally takes 14.6 seconds. Doing it in one block takes 12.8 seconds. So the incremental version is only 14% slower.

Code: Select all

#C [[ FASTLOOKUP ]]
#C [[ SHOWTIMING STEP 64 ]]
x = 99, y = 369, rule = Rainbow-RuleTable
46.3G14$41.2A5.2A$41.2A5.2A2$45.2A$45.2A5$63.2A.2A$62.A5.A$62.A6.A2.
2A$62.3A3.A3.2A$67.A7$63.3G69$17.C$16.C.2C$20.C.C$20.C.C$3C12.C7.C$2.
C11.2C6.C43.2C$C14.C6.C43.C.2C$.C15.C47.C4.C$18.3C44.2C2.2C$18.C50.C$
65.C.C$54.2C8.C2.C$53.3C9.2C3$48.2C.2C$48.2C.3C$50.C2.C$51.2C.C$52.C.
C$52.2C5$6.3G5$75.3G22$57.G$57.G$57.G$64.3D$11.2F50.D3.D$14.D15.3G29.
D5.D13.3G$13.2D48.D3.D$14.D49.3D$11.2F13$68.3G16$14.2E4.2E$14.2E4.2E$
17.2E$13.2E.E2.E2.2E$13.2E2.2E3.2E13$16.G$16.G$16.G46$56.2G$56.2G$56.
2G$56.2G3$55.2G$54.G2.G$54.G2.G$54.G2.G$53.6G$53.6G$53.6G$53.6G$53.6G
$54.G2.G$54.4G$54.4G$54.4G$55.2G12$55.2G$55.2G$55.2G$55.2G4$73.2G.G.G
.2G14.3B$74.3G.3G$75.G.G.G$75.G3.G$73.G7.G$73.4G.4G$73.2G5.2G$73.9G$
64.4G7.5G$64.4G7.5G$77.G15$54.2G$54.2G$54.2G$54.2G13$63.4G$61.G.4G.G
8.4G$61.G.G2.G.G6.G.4G.G$61.3G2.3G6.G.G2.G.G$62.6G7.3G2.3G$63.4G9.6G$
77.4G8$78.G$77.G.G$80.G$76.G.2G$76.G2$52.2G$48.3G.4G$49.G.G3.G$49.2G
4.2G$48.2G4.3G$50.G3.3G$48.2G4.3G$49.2G4.2G$49.G.G3.G$48.3G.4G$52.2G
8.4G$62.4G10.4G$76.4G!


@RULE Rainbow-RuleTable

@TABLE
n_states:8
neighborhood:Moore
symmetries:rotate4reflect
var l=1
var h=2
var t=3
var u=4
var c=5
var w=6
var m=7
var a={0,1,2,3,4,5,6,7}
var b=a
var d=a
var e=a
var f=a
var g=a
var i=a
var j=a
var k=a
#life
0,l,l,l,0,0,0,0,0,l
0,l,l,0,l,0,0,0,0,l
0,l,l,0,0,l,0,0,0,l
0,l,l,0,0,0,l,0,0,l
0,l,l,0,0,0,0,l,0,l
0,l,l,0,0,0,0,0,l,l
0,l,0,l,0,l,0,0,0,l
0,l,0,l,0,0,l,0,0,l
0,l,0,0,l,0,l,0,0,l
0,0,l,0,l,0,l,0,0,l
l,l,l,0,0,0,0,0,0,l
l,l,0,l,0,0,0,0,0,l
l,l,0,0,l,0,0,0,0,l
l,l,0,0,0,l,0,0,0,l
l,0,l,0,l,0,0,0,0,l
l,0,l,0,0,l,0,0,0,l
l,0,l,0,0,0,l,0,0,l
l,l,l,l,0,0,0,0,0,l
l,l,l,0,l,0,0,0,0,l
l,l,l,0,0,l,0,0,0,l
l,l,l,0,0,0,l,0,0,l
l,l,l,0,0,0,0,l,0,l
l,l,l,0,0,0,0,0,l,l
l,l,0,l,0,l,0,0,0,l
l,l,0,l,0,0,l,0,0,l
l,l,0,0,l,0,l,0,0,l
l,0,l,0,l,0,l,0,0,l
#highlife
0,h,h,h,0,0,0,0,0,h
0,h,h,0,h,0,0,0,0,h
0,h,h,0,0,h,0,0,0,h
0,h,h,0,0,0,h,0,0,h
0,h,h,0,0,0,0,h,0,h
0,h,h,0,0,0,0,0,h,h
0,h,0,h,0,h,0,0,0,h
0,h,0,h,0,0,h,0,0,h
0,h,0,0,h,0,h,0,0,h
0,0,h,0,h,0,h,0,0,h
0,0,0,h,h,h,h,h,h,h
0,0,h,0,h,h,h,h,h,h
0,0,h,h,0,h,h,h,h,h
0,0,h,h,h,0,h,h,h,h
0,h,0,h,0,h,h,h,h,h
0,h,0,h,h,h,0,h,h,h
h,h,h,0,0,0,0,0,0,h
h,h,0,h,0,0,0,0,0,h
h,h,0,0,h,0,0,0,0,h
h,h,0,0,0,h,0,0,0,h
h,0,h,0,h,0,0,0,0,h
h,0,h,0,0,h,0,0,0,h
h,0,h,0,0,0,h,0,0,h
h,h,h,h,0,0,0,0,0,h
h,h,h,0,h,0,0,0,0,h
h,h,h,0,0,h,0,0,0,h
h,h,h,0,0,0,h,0,0,h
h,h,h,0,0,0,0,h,0,h
h,h,h,0,0,0,0,0,h,h
h,h,0,h,0,h,0,0,0,h
h,h,0,h,0,0,h,0,0,h
h,h,0,0,h,0,h,0,0,h
h,0,h,0,h,0,h,0,0,h
#tlife
0,t,t,t,0,0,0,0,0,t
0,t,t,0,t,0,0,0,0,t
0,t,t,0,0,t,0,0,0,t
0,t,t,0,0,0,t,0,0,t
0,t,t,0,0,0,0,t,0,t
0,t,t,0,0,0,0,0,t,t
0,t,0,t,0,t,0,0,0,t
0,t,0,t,0,0,t,0,0,t
0,t,0,0,t,0,t,0,0,t
0,0,t,0,t,0,t,0,0,t
t,t,t,0,0,0,0,0,0,t
t,t,0,t,0,0,0,0,0,t
t,t,0,0,t,0,0,0,0,t
t,0,t,0,t,0,0,0,0,t
t,0,t,0,0,t,0,0,0,t
t,0,t,0,0,0,t,0,0,t
t,t,t,t,0,0,0,0,0,t
t,t,t,0,t,0,0,0,0,t
t,t,t,0,0,t,0,0,0,t
t,t,t,0,0,0,t,0,0,t
t,t,t,0,0,0,0,t,0,t
t,t,t,0,0,0,0,0,t,t
t,t,0,t,0,t,0,0,0,t
t,t,0,t,0,0,t,0,0,t
t,t,0,0,t,0,t,0,0,t
t,0,t,0,t,0,t,0,0,t
t,t,t,t,0,0,t,0,0,t
#thighlife
0,u,u,u,0,0,0,0,0,u
0,u,u,0,u,0,0,0,0,u
0,u,u,0,0,u,0,0,0,u
0,u,u,0,0,0,u,0,0,u
0,u,u,0,0,0,0,u,0,u
0,u,u,0,0,0,0,0,u,u
0,u,0,u,0,u,0,0,0,u
0,u,0,u,0,0,u,0,0,u
0,u,0,0,u,0,u,0,0,u
0,0,u,0,u,0,u,0,0,u
0,0,0,u,u,u,u,u,u,u
0,0,u,0,u,u,u,u,u,u
0,0,u,u,0,u,u,u,u,u
0,0,u,u,u,0,u,u,u,u
0,u,0,u,0,u,u,u,u,u
0,u,0,u,u,u,0,u,u,u
u,u,u,0,0,0,0,0,0,u
u,u,0,u,0,0,0,0,0,u
u,u,0,0,u,0,0,0,0,u
u,0,u,0,u,0,0,0,0,u
u,0,u,0,0,u,0,0,0,u
u,0,u,0,0,0,u,0,0,u
u,u,u,u,0,0,0,0,0,u
u,u,u,0,u,0,0,0,0,u
u,u,u,0,0,u,0,0,0,u
u,u,u,0,0,0,u,0,0,u
u,u,u,0,0,0,0,u,0,u
u,u,u,0,0,0,0,0,u,u
u,u,0,u,0,u,0,0,0,u
u,u,0,u,0,0,u,0,0,u
u,u,0,0,u,0,u,0,0,u
u,0,u,0,u,0,u,0,0,u
u,u,u,u,0,0,u,0,0,u
#B2ce3ai/S23
0,c,0,c,0,0,0,0,0,c
0,0,c,0,c,0,0,0,0,c
0,c,c,c,0,0,0,0,0,c
0,0,c,c,c,0,0,0,0,c
c,c,c,0,0,0,0,0,0,c
c,c,0,c,0,0,0,0,0,c
c,c,0,0,c,0,0,0,0,c
c,c,0,0,0,c,0,0,0,c
c,0,c,0,c,0,0,0,0,c
c,0,c,0,0,c,0,0,0,c
c,0,c,0,0,0,c,0,0,c
c,c,c,c,0,0,0,0,0,c
c,c,c,0,c,0,0,0,0,c
c,c,c,0,0,c,0,0,0,c
c,c,c,0,0,0,c,0,0,c
c,c,c,0,0,0,0,c,0,c
c,c,c,0,0,0,0,0,c,c
c,c,0,c,0,c,0,0,0,c
c,c,0,c,0,0,c,0,0,c
c,c,0,0,c,0,c,0,0,c
c,0,c,0,c,0,c,0,0,c
#B2in3/S123a
0,w,0,0,0,w,0,0,0,w
0,0,w,0,0,0,w,0,0,w
0,w,w,w,0,0,0,0,0,w
0,w,w,0,w,0,0,0,0,w
0,w,w,0,0,w,0,0,0,w
0,w,w,0,0,0,w,0,0,w
0,w,w,0,0,0,0,w,0,w
0,w,w,0,0,0,0,0,w,w
0,w,0,w,0,w,0,0,0,w
0,w,0,w,0,0,w,0,0,w
0,w,0,0,w,0,w,0,0,w
0,0,w,0,w,0,w,0,0,w
w,w,0,0,0,0,0,0,0,w
w,0,w,0,0,0,0,0,0,w
w,w,w,0,0,0,0,0,0,w
w,w,0,w,0,0,0,0,0,w
w,w,0,0,w,0,0,0,0,w
w,w,0,0,0,w,0,0,0,w
w,0,w,0,w,0,0,0,0,w
w,0,w,0,0,w,0,0,0,w
w,0,w,0,0,0,w,0,0,w
w,w,w,w,0,0,0,0,0,w
#move
0,m,m,m,0,0,0,0,0,m
0,m,m,0,m,0,0,0,0,m
0,m,m,0,0,m,0,0,0,m
0,m,m,0,0,0,m,0,0,m
0,m,m,0,0,0,0,m,0,m
0,m,m,0,0,0,0,0,m,m
0,m,0,m,0,m,0,0,0,m
0,m,0,m,0,0,m,0,0,m
0,m,0,0,m,0,m,0,0,m
0,0,m,0,m,0,m,0,0,m
0,0,0,m,m,m,m,m,m,m
0,0,m,0,m,m,m,m,m,m
0,0,m,m,0,m,m,m,m,m
0,0,m,m,m,0,m,m,m,m
0,m,0,m,0,m,m,m,m,m
0,m,0,m,m,m,0,m,m,m
0,m,m,m,m,m,m,m,m,m
m,m,m,0,0,0,0,0,0,m
m,m,0,m,0,0,0,0,0,m
m,m,0,0,m,0,0,0,0,m
m,m,0,0,0,m,0,0,0,m
m,0,m,0,m,0,0,0,0,m
m,0,m,0,0,m,0,0,0,m
m,0,m,0,0,0,m,0,0,m
m,m,m,m,m,0,0,0,0,m
m,m,m,m,0,m,0,0,0,m
m,m,m,m,0,0,m,0,0,m
m,m,m,0,m,m,0,0,0,m
m,m,m,0,m,0,m,0,0,m
m,m,m,0,m,0,0,m,0,m
m,m,m,0,m,0,0,0,m,m
m,m,m,0,0,m,m,0,0,m
m,m,m,0,0,m,0,m,0,m
m,m,m,0,0,m,0,0,m,m
m,m,m,0,0,0,m,m,0,m
m,m,0,m,0,m,0,m,0,m
m,0,m,0,m,0,m,0,m,m
m,0,0,0,m,m,m,m,m,m
m,0,0,m,0,m,m,m,m,m
m,0,0,m,m,0,m,m,m,m
m,0,0,m,m,m,0,m,m,m
m,0,0,m,m,m,m,0,m,m
m,0,0,m,m,m,m,m,0,m
m,0,m,0,m,0,m,m,m,m
m,0,m,0,m,m,0,m,m,m
m,0,m,m,0,m,0,m,m,m
m,m,0,m,0,m,0,m,m,m
#death
a,b,d,e,f,g,i,j,k,0

@COLORS

0 0 0 0
1 0 255 0
2 255 255 0
3 0 0 255
4 63 255 255
5 255 0 0
6 255 0 127
7 255 255 255

[rowett]

Fast Lookup now supports @TABLE hexagonal neighbourhood rules.

Original:

Code: Select all

#C [[ STEP 64 ]]
x = 11, y = 11, rule = HexLoops:T300
6B$B2AG.AB$BA4BGB$BAB3.B.B$BAB4.BAB$BAB5.BGB$.BAB4.B.B$2.BAB3.BAB$3.B
A4BDB$4.B4AEB$5.6B!

Fast Lookup:

Code: Select all

#C [[ STEP 64 FASTLOOKUP ]]
x = 11, y = 11, rule = HexLoops:T300
6B$B2AG.AB$BA4BGB$BAB3.B.B$BAB4.BAB$BAB5.BGB$.BAB4.B.B$2.BAB3.BAB$3.B
A4BDB$4.B4AEB$5.6B!

[rowett]

The new Fast Lookup algo which accelerates a large subset of @TABLE and @TREE rules appears to be working well. I'll give it a few more days to see if any reports of bad behaviour arrive. After which I'll enable it in LifeViewer by default.

Specifically it accelerates:

• Moore neighbourhood @TABLE or @TREE rules with up to 8 states
• von Neumann neighbourhood @TABLE or @TREE rules with up to 32 states
• Hexagonal neighbourhood @TABLE rules with up to 8 states

Anything not supported by Fast Lookup will continue to work with the existing @TABLE and @TREE algos.

I ran a survey of the LifeWik Rule namespace. As of the time of posting there are 1510 valid rules.

Rules by algo:

• @TREE 869 (57%)
• @TABLE 641 (43%)

Rules by neighbourhood:

• Moore 1203 (80%)
• von Neumann 260 (17%)
• Hexagonal 34 (2%)
• One Dimensional 13 (1%)

Rules supported by Fast Lookup by neighbourhood:

• Moore 904 / 1203 (75%)
• von Neumann 229 / 260 (88%)
• Hexagonal 28 / 34 (82%)

I haven't added support for One Dimensional neighbourhood rule since they make up only 1% of the repository and being 1D likely wouldn't benefit from performance improvements.

[muzik]

Could Plane bounded grids with odd sizes be permitted for triangular rules and Margolus rules? To my knowledge, the odd restriction is so that bounded grids with connected edges connect up properly without unwanted behaviour. Since planes don't have any connections whatsoever, this restriction is unnecessary.

Code: Select all

x = 2, y = 2, rule = R1,C2,S,B1,NL:P29,29
o$bo!

Also, could the bounded grid restrictions for general-range rules be made a bit less strict than Golly's? Patterns like the following used to work just fine in LifeViewer but can no longer be run:

Code: Select all

x = 1, y = 1, rule = R1,C2,S2-3,B3:T20,1
o!

The velocity for this spaceship is too long and therefore the unsimplified speed cannot be displayed in full:

Code: Select all

x = 50, y = 79, rule = B2in3-cekn4eikz5ry6ci/S2aek3-ace4it5-jqy6i7c
4o$obob2o4bo$obobo$b3o59$46b3o$45bo2bo$45bo3bo$49bo$47b2o$45b2o8$44bo$
44bob3o$44bo2bo$44b3o!

Build 993 in /previous appears to be misnamed and is listed in the wrong position.

[rowett]

Could Plane bounded grids with odd sizes be permitted for triangular rules and Margolus rules?

No. It's related to pattern placement.

Also, could the bounded grid restrictions for general-range rules be made a bit less strict than Golly's? Patterns like the following used to work just fine in LifeViewer but can no longer be run

No. The algo doesn't support it and the fact that some worked fine was luck. Plus it's not a good idea to make things that would not be interoperable between the tools where possible.

The velocity for this spaceship is too long and therefore the unsimplified speed cannot be displayed in full

The unsimplified speed is also shown in full at the top.

Build 993 in /previous appears to be misnamed and is listed in the wrong position.

Corrected, thanks.

[muzik]

Something appears to have broken about PASTE commands in build 2^10, since the second and third demos in this section have all eight viewers displaying "New pattern", the four vertical cases don't paste any cells at all unlike the previous build, and things like Select All don't result in all cells being selected even though they render: https://conwaylife.com/wiki/LifeViewer/ ... rn_editing

Also, is there a way to force LifeViewer to run patterns that would otherwise be invalid? I want to experiment with odd bounded grid sizes for triangular and Margolus rules to test a few hypotheses I have regarding edge connections.

[rowett]

Something appears to have broken about PASTE commands in build 2^10

It was unrelated to PASTE but fixed in build 2^10+1, thanks.

Also, is there a way to force LifeViewer to run patterns that would otherwise be invalid?

No. That would be a LifeViewer Pro feature and it's really really expensive.

[rowett]

Fast Lookup is now on by default for supported @TABLE and @TREE rules.

The [[ FASTLOOKUP ]] script command has been deprecated and will now be silently ignored.

Initializing the algorithm will take a few seconds for @TABLE rules with 5 to 8 states. The initialization takes place in the background and LifeViewer is fully functional while it is happening. Once initialized the algo will be automatically switched on. You can be running the pattern while this happens.

[rowett]

Identify now displays the generations at which the minimum and maximum population and minimum and maximum bounding box were found for Oscillators and Spaceships.

Open the pattern below and select Settings->Pattern->Identify (hotkey F6). Once finished select Help->Info->Identify and see the T Min/Max entries.

Example spaceship:

Code: Select all

x = 6, y = 4, rule = B3/S23
2b3o$b5o$2ob3o$b2o!

Example output from Help->Info->Identify:

Code: Select all

Type		Spaceship
Cells		11 | 15 | 13
  T Min/Max	11 @ T9 | 15 @ T10
Bounding	6 x 5 = 30
  T Min/Max	6 x 4 = 24 @ T10 | 6 x 5 = 30 @ T9
Direction	Orthogonal
Period		4
Mod		2 (FlipY)
Slope		0
Speed		c/2 | 2c/4
Heat		12 | 18 | 15
Generation	8 and 12

[squareroot12621]

A minor thing: Could the Tn's be reduced modulo Mod, and the bounding boxes be rotated and/or flipped according to the flip/rotation direction?
For example, with your MWSS example:

Code: Select all

Type		Spaceship
Cells		11 | 15 | 13
  T Min/Max	11 @ T1 | 15 @ T0
Bounding	6 x 5 = 30
  T Min/Max	6 x 4 = 24 @ T0 | 6 x 5 = 30 @ T1
Direction	Orthogonal
Period		4
Mod		2 (FlipY)
Slope		0
Speed		c/2 | 2c/4
Heat		12 | 18 | 15
Generation	8 and 12

[muzik]

Selections behave oddly at the edges of grids in the general range algorithm:

Code: Select all

x = 2, y = 2, rule = B/S01234V
2o$2o!
[[ GRID MAXGRIDSIZE 9 X -256 ]]

Code: Select all

x = 2, y = 2, rule = R1,C2,S0-4,B,NN
2o$2o!
[[ GRID MAXGRIDSIZE 9 X -256 ]]

I'm wondering if it'd be possible to forbid the selection rectangle from extending into the three spaces at the edge (for range 1, or however many spaces for higher ranges) in the first place, since none of that region can be modified at all. It also raises possible issues: if you make a selection that includes those three spaces, random fill it, then flip it, you end up losing a bunch of cells. Making that region not selectable would get rid of that issue as well.

[muzik]

There's probably some residual fixes needing done to the hexagonal grid regarding coordinates, drawing and selecting cells and label positions. Try panning with the following pattern:

Code: Select all

x = 1, y = 1, rule = B/S0123HT
o!
[[ GRID LABEL 2 0 32 "word" ]]

Compare:

Code: Select all

x = 1, y = 1, rule = B/S0123LE
o!
[[ GRID LABEL 2 0 32 "word" ]]

Code: Select all

x = 1, y = 1, rule = B/S01234V
o!
[[ GRID LABEL 2 0 32 "word" ]]

Is there any way to trigger this effect intentionally? Parallax labels (kind of like what happens with layers and the star effect) sounds like a fun mechanic for,scripting.

[PHPBB12345]

Suggestion: LifeViewer supports [R]Investigator and [R]Func

[confocaloid]

^^ there is a Python script to generate a ruletable for [R]Investigator v3 where [R] is a two-state isotropic cellular automaton with Moore neighbourhood. I already created several rule tables using this script (here). A few example patterns link, link, link, link,

[PHPBB12345]

Here is implementation of [R]Investigator:

Code: Select all

var deathforcer = (1 << 2) | (1 << 3) | (1 << 6) | (1 << 7) | (1 << 14) | (1 << 16);
var birthforcer = (1 << 8) | (1 << 9) | (1 << 12) | (1 << 13) | (1 << 14);
var requirestate1 = (1 << 15) | (1 << 16);
var treatifdead = (1 << 1) | (1 << 2) | (1 << 4) | (1 << 6) | (1 << 8) | (1 << 10) | (1 << 12) | (1 << 15) |  (1 << 16) | (1 << 17) | (1 << 19);
var treatifalive = treatifdead ^ ((1 << 17) | (1 << 18) | (1 << 19) | (1 << 20));
var nextstate = [2, 3, 4, 5, 7, 6, 8, 9, 11, 10, 13, 12, 14, 15, 16, 17, 18, 20, 19];

function updatefunc (nw, n, ne, w, c, e, sw, s, se) {
	if (c >= 2) return nextstate[c - 2];

	var flags = (1 << nw) | (1 << n) | (1 << ne) | (1 << w) | (1 << e) | (1 << sw) | (1 << s) | (1 << se);

	if (flags & (c ? deathforcer : birthforcer)) return 1 - c;
	if (!c && (flags & requirestate1) && !(flags & 2)) return 0;

	var treat = c ? treatifalive : treatifdead;
	return lookuptable[
		(((treat >> nw) & 1) << 8) |
		(((treat >> n) & 1) << 7) |
		(((treat >> ne) & 1) << 6) |
		(((treat >> w) & 1) << 5) |
		(c << 4) |
		(((treat >> e) & 1) << 3) |
		(((treat >> sw) & 1) << 2) |
		(((treat >> s) & 1) << 1) |
		((treat >> se) & 1)];
}

[rowett]

Here is implementation of [R]Investigator

Thanks, I'll take a look.

[muzik]

Aside from performance, how can I be sure that the new fast lookup algorithm is currently active?

[rowett]

Aside from performance, how can I be sure that the new fast lookup algorithm is currently active?

Help->Info->Pattern->Type

[muzik]

This is probably another one of those ultra minor visual bugs, but if we Select All and change the zoom level for this, it reveals that the selection rectangle appears to over-reach in the two negative directions causing it to overlap the boundary, while failing to reach the boundary in the two positive directions:

Code: Select all

x = 7, y = 7, rule = W0:P7
o6$6bo!

Rotating the camera exactly 90 or 270 degrees produces slightly different effects, and 180 degrees gives much the same.

Even more subtle is the following thing: if we start a selection at the bottom left right against the edge of the grid, and drag that selection to the top right such that it remains one cell thick, the amount that the selection intersects the out of bounds cells appears to change as we increase the width. This might be some sort of precision loss issue. I'm not sure. It definitely doesn't seem worth investing much time into.

Code: Select all

x = 2, y = 2, rule = W0
2o$2o!
[[ MAXGRIDSIZE 9 X -256 ANGLE 61.28372 ]]

[muzik]

This pattern is identified as being FlipY in [R]History but FlipYOrRot180 in [R]Super, despite being functionally identical:

Code: Select all

x = 3, y = 2, rule = B3/S23History
2AF$A.F!

Code: Select all

x = 3, y = 2, rule = B3/S23Super
2AF$A.F!

Something to point out: if the T menu is open, it overlaps the Identify output table to an extent. This isn't a massive problem since it only overlaps part of one of the titles, but might become more significant if more results for objects are computed and displayed in future.

[GUYTU6J]

There is a bug with lifeviewer when displaying this kind of pattern in a torus...

If I recall correctly, this scriptless tall torus pattern used to be zoomed out and wholly in view upon initial launch (after fixing the old bug of course). But now it zooms in around origin. Has there recently been any change to how torus patterns are displayed by default?

For comparison, I see no apparent difference between how this scriptless wide torus pattern is rendered in my memory and in current effect. Same for this huge torus pattern. I would prefer a zoomed-out full view of bounded patterns for it giving an obvious idea about the size of bounded grid.

[squareroot12621]

Autofit doesn't seem to work for spaceships moving significantly faster than c.

1. Open the quoted code block.
2. Select the part of the spaceship that has been replaced by a soup.
3. Fill the area with cells. (This can be done by clearing the area and then inverting its cells.)
4. Enable Autofit.
5. Run the pattern.
6. Observe the position of the bug.
7. The expected position should be in the middle of the viewer. However, it appears near the top.

Feed a bug soup to turn it:

Code: Select all

x = 138, y = 124, rule = R100,C0,M1,S5612..9776,B5612..7585,NN
34b16o38b16o$31b30o16b30o$28b82o$26b86o$25b88o$23b92o$22b94o$20b98o$
19b100o$18b102o$17b104o$16b106o$15b108o$14b110o$13b112o$12b114o$11b
116o$11b116o$10b118o$9b120o$8b122o$8b122o$7b124o$7b124o$6b93o2bo2bo2b
7obob15o$5b93obo5b9ob3ob14o$5b93obo3bo2b4o2bo2b2o2b14o$4b93obobo2b2o7b
2o2bob16o$4b93o3bo3b6o3b2obo2b15o$3b94o2b3o4b2ob2ob4ob18o$3b94o4b4o2bo
5b3o2bob15o$3b95ob2obo10b2obob17o$2b95o2bob2o2bo2bobob3obo3b16o$2b96o
2b4ob2o2bo4bo3bob16o$2b97obo3b3obobo4b21o$b99obo2b2o3bo2bo4b2ob17o$b
97o2bob2ob3o4b2o2bobob17o$b97o2b4o2b5o4bob20o$b96obob2o2b2obobob2o2b2o
b19o$98obob4o2b4o2b2ob22o$98o2b8o2b4o3b2ob18o$97ob4o2bo2bo2bobobo2bo2b
18o$66o6b26o2b2o2bob2o2bo4b2o2b19o$61o16b21obo3bo2b4o8bob18o$58o22b17o
2bo3b3obo2bobo4bob19o$55o28b14ob4ob6ob4obo2bob18o$53o32b13obo2bo3b2ob
2obo6b19o$52o34b11ob2ob4o3bo2bo2bobo2b19o$50o38b10obo2b3obob2o3b2ob22o
$49o40b8ob3ob5ob2o3b2ob2o2b18o$49o40b8ob3obobo3bo2bobob3o2b18o$b48o40b
8ob3o2b4obobo2b2obob19o$b47o42b7o3b4o2b2o6b2o4b17o$b47o42b9ob4o5bob2o
2b2ob19o$b46o44b9ob2ob3ob2obo2b3ob19o$b46o44b6ob3o4bobob2o2b4o2b18o$2b
45o44b6ob3ob4o2bobob3o2b19o$2b45o44b6o6bo6b3o2b2ob18o$2b45o44b6obo2b2o
2b2o2bob2o4b2ob16o$3b43o46b6o2b2o3bo3bo2bo2b2o2b16o$3b43o46b5o4bobo5bo
b2o2b2ob17o$3b43o46b6o4bobo5b2ob2o3bob15o$4b42o46b5obo2bob3o4bo3b4o2b
14o$4b42o46b7obob2ob3o2bo4b19o$5b41o46b5o2bo3bobo7bo4b15o$5b41o46b12o
4b3o2b4o2b14o$5b41o46b5ob3o5b4o3b3o4b13o$6b40o46b5o2b2o4bo2bobobob3obo
b12o$6b40o46b5ob7o2b2o4b3obob13o$6b40o46b5o5b2o2bo2bo6bo3b12o$7b39o46b
8o2b3o4bob2o2b2o2b12o$7b39o46b6ob2o2b4o2b4ob2o2b13o$7b39o46b5ob2obobob
2o3bob6ob12o$8b38o46b7obo2b2ob4ob2ob4ob11o$8b38o46b6obob8ob5obobob10o$
9b37o46b5ob3o5b2obob2ob2o4b9o$9b37o46b6ob3ob4o3bo2b16o$9b37o46b5obo2b
2o2b3obo2bo2bob12o$10b36o46b5o4bo2bo4bo3b2ob2ob9o$10b36o46b6o4b3obo2b
3o2bo3bob8o$10b36o46b5ob2o2b2o7b2ob4o2b8o$11b35o46b6ob2ob3o2bob2ob4obo
b8o$11b35o46b35o$11b35o46b35o$12b34o46b34o$12b34o46b34o$12b34o46b34o$
12b34o46b34o$13b33o46b33o$13b33o46b33o$13b33o46b33o$13b33o46b33o$14b
32o46b32o$14b32o46b32o$14b32o46b32o$14b32o46b32o$15b31o46b31o$15b31o
46b31o$15b31o46b31o$16b30o46b30o$16b30o46b30o$16b30o46b30o$17b29o46b
29o$17b29o46b29o$17b29o46b29o$18b29o44b29o$18b33o36b33o$19b37o26b37o$
19b100o$20b98o$21b96o$21b96o$22b94o$23b92o$24b90o$26b86o$28b82o$30b78o
$33b72o$37b64o$41b56o$46b46o$52b34o$58b22o!

This might be because the code takes an average of the last few generations' centers and puts the camera at that spot. This fix might work (though it probably won't):

1. Apply the camera-smoothing function normally.
2. If the camera consistently lags behind the center of the pattern (the last 10 times, it was over 7% of the screen away), add the average "lag" to the camera position.