Pattern viewer for forum threads

[rowett]

Is the Advance Outside button also supposed to be copying the selection to the clipboard?

Yes at the moment it's using one of the internal clipboards. I may change that in the future.

[muzik]

Haven't tested this on other hardware, but it seems like for some thumbnail-style viewers on the wiki, the grid lines don't fully reach the edge, which can lead to the shape of cells being slightly incorrect on the right hand side:

IMG_7309.jpeg (266.2 KiB) Viewed 9076 times

There's been some recent discussion of oscillator types in the unproven conjectures thread pertaining to generalized phoenices and such, which makes the concept of an easy tool for generating frequency maps even more appealing - would it be possible to implement this, even for just low periods?

[lemon41625]

Code: Select all

x = 0, y = 0, rule = R2,C2,S24-36,B20-31,NW1232124642369632464212321
b4o$o4bo$o4bo$o4bo!

This ship should work as below but doesn't.

Code: Select all

x = 0, y = 0, rule = R2,C2,S24-36,B20-31,NG
b4o$o4bo$o4bo$o4bo!

[confocaloid]

That's because in the weighted neighbourhood string, you are using one digit per cell weight, so the digit '9' gets interpreted as a negative weight (-1) rather than as a positive weight (9). This isn't specific to LifeViewer.

The spaceship seems to work (both in Golly and in LifeViewer) if you use two digits per cell weight (i.e. insert '0' before every digit):

Code: Select all

x = 6, y = 4, rule = R2,C0,S24-36,B20-31,NW01020302010204060402030609060302040604020102030201
b4o$o4bo$o4bo$o4bo!

Code: Select all

x = 0, y = 0, rule = R2,C2,S24-36,B20-31,NW1232124642369632464212321
b4o$o4bo$o4bo$o4bo!

This ship should work as below but doesn't.

Code: Select all

x = 0, y = 0, rule = R2,C2,S24-36,B20-31,NG
b4o$o4bo$o4bo$o4bo!

[rowett]

This ship should work as below but doesn't.

Code: Select all

x = 0, y = 0, rule = R2,C2,S24-36,B20-31,NG
b4o$o4bo$o4bo$o4bo!

Here is the documentation for LifeViewer and Golly.

[PHPBB12345]

Here is HTML entities related bug, test pattern:

Code: Select all

#C [[ "&<>&amp;&lt;&gt;&amp;lt;&amp;gt;" ]]
x=0,y=0,rule=B3/S23
o!

Expected:

Expected.png (16.7 KiB) Viewed 8900 times

Actual in LifeViewer build 1148:

Actual in LifeViewer 1148.png (15.54 KiB) Viewed 8900 times

[unname4798]

Here is HTML entities related bug, test pattern:

Code: Select all

#C [[ "&<>&amp;&lt;&gt;&amp;lt;&amp;gt;" ]]
x=0,y=0,rule=B3/S23
o!

Expected:
Expected.png
Actual in LifeViewer build 1148:
Actual in LifeViewer 1148.png

That is not a bug.

[squareroot12621]

It is a bug—the &amp;lt; and &amp;gt; shouldn't be doubly converted into < and >.
(In fact, they shouldn't be converted at all.)

[rowett]

It is a bug—the &amp;lt; and &amp;gt; shouldn't be doubly converted into < and >.
(In fact, they shouldn't be converted at all.)

It's more complex than that. Here on the forums the string:
"&<>&amp;&lt;&gt;&amp;lt;&amp;gt;"
is converted by the forum software into:
"&amp;&lt;&gt;&amp;amp;&amp;lt;&amp;gt;&amp;amp;lt;&amp;amp;gt;"

Whereas the same string on the LifeViewer home page is not changed.

So the current algo that deals with HTML entities is producing different results for the forum vs LifeViewer home page.

Based on that I'm proposing recursively substituting HTML entities until they're all gone. I don't really see a valid reason why you'd want LifeViewer to display a raw one anyway.

[PHPBB12345]

More HTML entities related bugs found in View.prototype.copyToClipboard, View.prototype.saveCurrentRLE, View.prototype.loadText, updateMe and dropHandler

[muzik]

If both of the rules that a B0/D8 rule uses to iterate each generation are the exact same, could it be run as that rule instead like is the case for B0/S8? This should permit the following to be identified:

Code: Select all

x = 4, y = 2, rule = B01245/S0125
2o$b3o!

identically to this:

Code: Select all

x = 4, y = 2, rule = B3678/S34678
2o$b3o!

Also, why does this zoom out to show all the history cells every time it is paused? I don't see any HISTORYFIT here. Is this intentional to assist with pattern editing?

Code: Select all

x = 68, y = 9, rule = 23/34/128
4.sW.sT3.sK.sH3.rW.rT3.rK.rH3.qW.qT3.qK.qH3.pW.pT3.pK.pH3.W.T3.K.H$3.
sXtAsUsTsU.sLsMsIsHsI.rXsArUrTrU.rLrMrIrHrI.qXrAqUqTqU.qLqMqIqHqI.pXqA
pUpTpU.pLpMpIpHpI.XpAUTU.LMIHI.3A$2.tBtD2tA2sVsNsP2sM2sJsBsD2sA2rVrNrP
2rM2rJrBrD2rA2qVqNqP2qM2qJqBqD2qA2pVpNpP2pM2pJpBpD2pA2VNP2M2JBD2A$2.tC
.2tDsUsXsOsT2sPsIsLsCsH2sDrUrXrOrT2rPrIrLrCrH2rDqUqXqOqT2qPqIqLqCqH2qD
pUpXpOpT2pPpIpLpCpH2pDUXOT2PILCH2D2A$4.tFtDtBsXsVsTsRsPsNsLsJsHsFsDsB
rXrVrTrRrPrNrLrJrHrFrDrBqXqVqTqRqPqNqLqJqHqFqDqBpXpVpTpRpPpNpLpJpHpFpD
pBXVTRPNLJHFDBA$3.tCtFsUtB2sVsOsRsIsN2sJsCsFrUsB2rVrOrRrIrN2rJrCrFqUrB
2qVqOqRqIqN2qJqCqFpUqB2pVpOpRpIpN2pJpCpFUpB2VORIN2JCFABA$.2tG2tDsTsV
2sS2sPsHsJ2sG2sDrTrV2rS2rPrHrJ2rG2rDqTqV2qS2qPqHqJ2qG2qDpTpV2pS2pPpHpJ
2pG2pDTV2S2PHJ2G2D2A$tFtGtCtBtC.sRsSsOsNsO.sFsGsCsBsC.rRrSrOrNrO.rFrG
rCrBrC.qRqSqOqNqO.qFqGqCqBqC.pRpSpOpNpO.pFpGpCpBpC.RSONO.FGCBC$.tE.tB
3.sQ.sN3.sE.sB3.rQ.rN3.rE.rB3.qQ.qN3.qE.qB3.pQ.pN3.pE.pB3.Q.N3.E.B!
[[ AUTOSTART AUTOFIT ]]

[muzik]

Auto Identify appears to be carrying over to other viewers, similarly to how the FPS counter does. Is this expected?

Code: Select all

x = 1, y = 1, rule = B/S0
o!
[[ AUTOIDENTIFY ]]

Code: Select all

x = 1, y = 1, rule = B12345678/S012345678
o!

[rowett]

Auto Identify appears to be carrying over to other viewers, similarly to how the FPS counter does. Is this expected?

Fixed in build 1152. Thanks for reporting!

[PHPBB12345]

Suggestion: add 12 paste modes

Code: Select all

case ViewConstants.pasteModeZero:
	result = 0;
	break;
case ViewConstants.pasteModeCopy:
	result = source;
	break;
case ViewConstants.pasteModeDest:
	result = dest;
	break;
case ViewConstants.pasteModeSourceOver:
	if (this.engine.isPCA) {
		result = source | dest;
	} else {
		result = source == 0 ? dest : source;
	}
	break;
case ViewConstants.pasteModeDestOver:
	if (this.engine.isPCA) {
		result = source | dest;
	} else {
		result = dest == 0 ? source : dest;
	}
	break;
case ViewConstants.pasteModeSourceIn:
	if (this.engine.isPCA) {
		result = source & dest;
	} else {
		result = dest == 0 ? 0 : source;
	}
	break;
case ViewConstants.pasteModeDestIn:
	if (this.engine.isPCA) {
		result = source & dest;
	} else {
		result = source == 0 ? 0 : dest;
	}
	break;
case ViewConstants.pasteModeSourceOut:
	if (this.engine.isPCA) {
		result = source & (numStates - source);
	} else {
		result = dest == 0 ? source : 0;
	}
	break;
case ViewConstants.pasteModeDestOut:
	if (this.engine.isPCA) {
		result = dest & (numStates - source);
	} else {
		result = source == 0 ? dest : 0;
	}
	break;
case ViewConstants.pasteModeSourceAtop:
	if (this.engine.isPCA) {
		result = dest;
	} else {
		result = dest == 0 ? 0 : source == 0 ? dest : source;
	}
	break;
case ViewConstants.pasteModeDestAtop:
	if (this.engine.isPCA) {
		result = source;
	} else {
		result = source == 0 ? 0 : dest == 0 ? source : dest;
	}
	break;
case ViewConstants.pasteModeXor:
	result = source ^ dest;
	if (this.engine.isPCA && source != 0 && dest != 0) {
		result = 0;
	}
	break;

[rowett]

Code: Select all

#C [[ ICONS ]]
x = 2, y = 2, rule = WangTiler11
A$2F!

Code: Select all

#C [[ ICONS AUTOSTART GPS 8 ]]
x = 74, y = 47, rule = AnimatedPixelArt
pJuOpJuOpJuOpJuOpJuOpJuOpJuO6.pJBpJBpJBpJBpJBpJBpJB6.pJBpJBpJBpJBpJBpJ
BpJB6.pJBpJBpJBpJBpJBpJBpJB$uPuQuPuQuPuQuPuQuPuQuPuQuPuQ6.uPuQuPuQuPuQ
uPuQuPuQuPuQuPuQ6.uPBuPBuPBuPBuPBuPBuPB6.14B$pJuOKtLKtLKtLKtLKtLpJuO
6.pJBK.K.K.K.K.pJB6.pJBK.K.K.K.K.pJB6.pJBK.K.K.K.K.pJB$uPuQ10tLuPuQ6.
uPuQ10tLuPuQ6.uPBtL.tL.tL.tL.tL.uPB6.2B10.2B$pJuOKtLOtVpXvGOtVKtLpJuO
6.pJBK.O.pXCO.K.pJB6.pJBK.O.pXCO.K.pJB6.pJBK.O.pXCO.K.pJB$uPuQ2tLtTtU
vEuUtTtU2tLuPuQ6.uPuQ2tLtTtUvEuUtTtU2tLuPuQ6.uPBtL.tT.vECtT.tL.uPB6.
2B4.2C4.2B$pJuOKtLpTvGpTuUOtLKtLpJuO6.pJBK.pTCpTCO.K.pJB6.pJBK.pTCpTC
O.K.pJB6.pJBK.pTCpTCO.K.pJB$uPuQ2tLuUvF2uUtTtU2tLuPuQ6.uPuQ2tLuUvF2uU
tTtU2tLuPuQ6.uPBtL.uUCuUCtT.tL.uPB6.2B2.4C4.2B$pJuOKtLOtVpXvGOtVKtLpJ
uO6.pJBK.O.pXCO.K.pJB6.pJBK.O.pXCO.K.pJB6.pJBK.O.pXCO.K.pJB$uPuQ2tLtT
tUvEvFtTtU2tLuPuQ6.uPuQ2tLtTtUvEvFtTtU2tLuPuQ6.uPBtL.tT.vECtT.tL.uPB
6.2B4.2C4.2B$pJuOKtLOtLpTuUKtVKtLpJuO6.pJBK.O.pTCK.K.pJB6.pJBK.O.pTCK
.K.pJB6.pJBK.O.pTCK.K.pJB$uPuQ4tL2uUtTtU2tLuPuQ6.uPuQ4tL2uUtTtU2tLuPuQ
6.uPBtL.tL.uUCtT.tL.uPB6.2B4.2C4.2B$pJuOKtLpXvGpXvGpXvGKtLpJuO6.pJBK.
pXCpXCpXCK.pJB6.pJBK.pXCpXCpXCK.pJB6.pJBK.pXCpXCpXCK.pJB$uPuQ2tLvEuUvE
uUvEvF2tLuPuQ6.uPuQ2tLvEuUvEuUvEvF2tLuPuQ6.uPBtL.vECvECvECtL.uPB6.2B
2.6C2.2B$pJuOKtLKtLKtLKtLKtLpJuO6.pJBK.K.K.K.K.pJB6.pJBK.K.K.K.K.pJB
6.pJBK.K.K.K.K.pJB$uPuQ10tLuPuQ6.uPuQ10tLuPuQ6.uPBtL.tL.tL.tL.tL.uPB
6.2B10.2B$pJuOpJuOpJuOpJuOpJuOpJuOpJuO6.pJBpJBpJBpJBpJBpJBpJB6.pJBpJB
pJBpJBpJBpJBpJB6.pJBpJBpJBpJBpJBpJBpJB$uPuQuPuQuPuQuPuQuPuQuPuQuPuQ6.
uPuQuPuQuPuQuPuQuPuQuPuQuPuQ6.uPBuPBuPBuPBuPBuPBuPB6.14B4$60.KtLKtLWtX
WtXWtXKtLKtL$60.4tL6tX4tL$60.KtLWtXKtLKtLKtLWtXKtL$60.2tL2tX6tL2tX2tL
$60.KtLWtXKtLKtLKtLWtXKtL$60.2tL2tX6tL2tX2tL$27.KtLKtLWtXWtXWtXWtXWtX
WtXKtLKtL13.KtLWtXKtLKtLKtLWtXKtL$27.4tL12tX4tL13.2tL2tX6tL2tX2tL$27.
KtLWtXWtXpTuXpTuXpWuUpWuUWtXWtXKtL13.KtLKtLWtXWtXWtXKtLKtL$27.2tL4tX
8uU4tX2tL13.tM3tL6tX4tL$6.KtLKtLpIuJNtPKtL11.WtXWtXKtOWtXWtXWtXWtXNtL
WtXWtX13.LtMKtLKtLWtXKtLKtLKtL$6.3tLtVuMuJ4tL11.4tXtLtO8tXtOtL4tX13.tL
3tM2tL2tX6tL$6.KtPKtLqEvGKtLNtL11.WtXKtOWtXWtXsVyAsVyAWtXWtXNtLWtX13.
VtWWtXWtXWtXWtXWtXVtW$6.4tLvAvBtOtV2tL11.2tXtLtO4tXxWxXxWxX4tXtOtL2tX
13.4tW6tX4tW$6.pIuJqEvGKtLqEvGpIuJ11.WtXKtLWtXsVyAsVyAsVyAsVyAWtXKtLW
tX13.KtLKtLKtLWtXKtLKtLLtM$6.2uJvAvB2tLvAvB2uJ11.2tX2tO2tXxW2xXyAxXyA
xWxX2tX2tO2tX13.6tL2tX2tL2tMtLtM$6.NtLKtLqEvGKtLKtP11.WtXKtLWtXsVyAsV
yAsVyAsVyAWtXKtLWtX13.KtLKtLKtLWtXKtLKtLKtL$6.2tLtOtVvAvB4tL11.2tX2tO
2tXxW2xXyAxXyAxWxX2tX2tO2tX13.6tL2tX4tLtMtL$6.KtLNtPpIuJKtLKtL11.WtXN
tLWtXWtXsVyAsVyAWtXWtXKtOWtX13.KtLKtLKtLWtXKtLKtLKtL$6.4tLuMuJtLtV2tL
11.2tXtOtL4tXxWxXxWxX4tXtLtO2tX13.6tL2tX6tL$27.WtXWtXNtLWtXWtXWtXWtXK
tOWtXWtX13.KtLKtLWtXKtLWtXKtLKtL$27.4tXtOtL8tXtLtO4tX13.4tL2tX2tL2tX
4tL$27.KtLWtXWtXpWuUpWuUpTuXpTuXWtXWtXKtL13.KtLWtXKtLKtLKtLWtXKtL$27.
2tL4tX8uU4tX2tL13.2tL2tW2tM2tL2tM2tW2tL$27.KtLKtLWtXWtXWtXWtXWtXWtXKtL
KtL13.VtWLtMKtLKtLKtLLtMVtW$27.4tL12tX4tL13.2tWtL2tM3tLtM2tLtM2tW!

[muzik]

I assume support for the default Golly icons for Moore, von Neumann, hexagonal and emulated triangular rules is also planned?

[b-engine]

I assume support for the default Golly icons for Moore, von Neumann, hexagonal and emulated triangular rules is also planned?

No. LifeViewer renders the cells in the respective lattice grid of the CA. Adding default icons are unnecessary.

[rowett]

I assume support for the default Golly icons for Moore, von Neumann, hexagonal and emulated triangular rules is also planned?

The current plan is to only support Icons on RuleLoader rules since in this case the icons can be used to represent useful extra information.

[muzik]

Emulated triangular rules don't appear to be using the triangular icon set assigned to them by Golly. They don't appear to be defined in the rule tree so I;m not sure how Golly figures out that they should be assigned these icons, but LifeViewer should follow I'd assume.

Code: Select all

x = 3, y = 2, rule = TriLife-B4S456
BCA$.2C!

Alternatively, 2-state emulated triangular rules could be automatically converted to the LifeViewer triangular rule system (see here for how it could be done).

Also I think that a default icon set for PCA rules would be useful to make it much more clear what states represent what directions, like is shown in the research papers Brian based his ruletables on.

[rowett]

Emulated triangular rules don't appear to be using the triangular icon set assigned to them by Golly. They don't appear to be defined in the rule tree so I'm not sure how Golly figures out that they should be assigned these icons, but LifeViewer should follow I'd assume.

I'm not interested in legacy non-square rules on a square grid. If someone wants to convert the rules to something that LifeViewer natively supports that's great.

Also I think that a default icon set for PCA rules would be useful to make it much more clear what states represent what directions, like is shown in the research papers Brian based his ruletables on.

I've added some PCA icons.

Code: Select all

#C [[ ICONS ]]
x = 5, y = 5, rule = 2PCA4,0,4,8,3,1,10,6,11,2,9,5,13,12,14,7,15:T9,9
3.A$HOCO$.IOF$.OLOB$.D!

[muzik]

Could the PCA icons be made to use the "just died" colour for unoccupied triangles, as to not create holes in regions where cells existed before:

Code: Select all

x = 14, y = 7, rule = 2PCA4,0,4,8,3,1,10,6,7,2,9,5,11,12,13,14,15
B$B$B10.3B$B10.3B$B10.3B$B$B!
[[ ICONS ZOOM 32 X -30 STARTFROM 32 ]]

...as well as made to follow the active theme (so that north = state 1 colour, east = state 2, south = state 4, west = state 8, and empty = just died colour)?

Code: Select all

x = 13, y = 13, rule = 2PCA4,0,2,4,12,8,5,9,7,1,6,10,11,3,13,14,15
4.A3.B3.C4$D3.E3.F3.G4$H3.I3.J3.K4$L3.M3.N3.O!
[[ ICONS THEME Book ]]

Also, having the icons displayed in the draw menu's palette at the top right somehow would also be useful.

[muzik]

Code: Select all

x = 1, y = 1, rule = R2,C2,S0-5,B1,3,5,N@0003e0
o!
[[ AUTOFIT ]]

This appears to be running upside-down now, which is also the case for desktop Golly but not on mobile. Was there a recent fix that revealed that all such previous asymmetric neighbourhoods were being handled upside-down incorrectly?

----

Would it be possible to make period maps for hexagonal grid oscillators use offset squares? Having highly symmetric stuff get distorted in the map is something I find irritating.

Code: Select all

x = 15, y = 23, rule = B2o3-o4-m56/S2m3o4-o56H
b2o$o3bo$b4o$2bobo$3b2o14$10b2o$10bobo$10b4o$10bo3bo$12b2o!

Code: Select all

x = 14, y = 3, rule = B2o4-p56/S2p34-o56H
ob4ob4obo$14o$bob4ob4obo!

Code: Select all

x = 5, y = 5, rule = R1,C2,S2-3,6-9,11-15,B5,10-11,14-15,NW410104041H
3bo$ob3o$3o$bobo$b3o!

Code: Select all

x = 7, y = 12, rule = R2,C2,S3,20-36,B13,21,26,33,43,NW0001000000010a0a0100000a000a0000010a0a010000000100H
o$2o$2o$4bo$2bo$3bobo2$3bo$2b2ob2o$2b4o$3b2o$4bo!

Code: Select all

x = 25, y = 25, rule = B2o46/S2o46H
b3o$o4bo$7o$obo2bobo$bob3obo2$5bo6$7b3o$8b2o$8b3o$7b6o$8b5o$2o7bo2bo7b
2o$o21bo$4obo12bob4o$2bobo15bobo$bobobo14bobobo$2bob2o15b2obo$3bobobo
12bobobo$5b3o13b3o!

[rowett]

This appears to be running upside-down now, which is also the case for desktop Golly but not on mobile. Was there a recent fix that revealed that all such previous asymmetric neighbourhoods were being handled upside-down incorrectly?

Yes it was fixed in LifeViewer build 1132 and Golly 4.3.

[muzik]

Cells appear to be visually offset from the grid when icons are enabled compared to when they're not.

Code: Select all

x = 20, y = 20, rule = 2PCA4,0,4,8,3,1,10,6,7,2,9,5,11,12,13,14,15:T20+5,20
20O$O18.O$O18.O$O18.O$O18.O$O18.O$O18.O$O18.O$O18.O$O18.O$O18.O$O18.O
$O18.O$O18.O$O18.O$O18.O$O18.O$O18.O$O18.O$20O!
[[ ICONS GRID THEME Caterer ]]

I also find that icons appear blurry, even at integer zoom levels, which is not the case in Golly.

Code: Select all

x = 5, y = 6, rule = Langtons-Ant
2.2A$.A.H$A3.A$A3.A$.F.A$.2A!
[[ ICONS ZOOM 32 ]]

Gaps also appear in cells when at non-integer zoom levels. Try zooming in and out here for a weird flickery experience:

Code: Select all

x = 16, y = 16, rule = Langtons-Ant
16A$16A$16A$16A$16A$16A$16A$16A$16A$16A$16A$16A$16A$16A$16A$16A!
[[ ICONS ]]

Will it be possible to define icons for any rule via script commands, or will they be restricted to rule tables? In addition, will script commands be ab,w to change the colours associated with existing icons?

[rowett]

Would it be possible to make period maps for hexagonal grid oscillators use offset squares? Having highly symmetric stuff get distorted in the map is something I find irritating.

Done. Note that bounded grids will display as square but I'm not planning to fix this since bounded grids are problematic for non-square neighbourhoods anyway.