Pattern viewer for forum threads

[rowett]

I've noticed a small inconsistency: if we set the UI background to white, the disabled script indicators directly to the right of the zoom bar have a white shadow, but disabled buttons on the bottom have shadows colored identically to themselves.

Fixed, thanks.

[muzik]

In most cases, the color of the shadow behind text is UIBACKGROUND. However, there appears to be a small handful of cases where the text is hardcoded to be black, such as help texts and graph axis labels:

Code: Select all

x = 19, y = 16, rule = B3/S23
17bo$17bo2$17bo$16bobo$2bo6bo$b2o6b2o5b3o$3o6b3o$b2o6b2o$2bo6bo6b3o2$
16bobo$17bo2$17bo$17bo!
[[ COLOR UIFOREGROUND Aqua COLOR UIBACKGROUND White COLOR HELP Pink COLOR GRAPHBG White COLOR GRAPHAXIS PaleGreen ]]

Error-related texts are another such example:

Code: Select all

x = 19, y = 16, rule = B3/S23
17bo$17bo2$17bo$16bobo$2bo6bo$b2o6b2o5b3o$3o6b3o$b2o6b2o$2bo6bo6b3o2$
16bobo$17bo2$17bo$17bo!
[[ COLOR UIFOREGROUND Aqua COLOR UIBACKGROUND White COLOR HELP Pink COLOR GRAPHBG White COLOR GRAPHAXIS PaleGreen COLOR ERROR Yellow COLOR UILOCKED Aquamarine VIEWONLY STARTFROM 5 ]]

The colors of texts that pop up, of all three kinds (pulsating "Click to control" and similar prompts, upper texts like "Play" and lower texts like "Life ended at"), also appear to have a hardcoded shadow:

Code: Select all

x = 8, y = 3, rule = B3/S23
obo$bo4b2o$bo4b2o!
[[ THEME Day COLOR TEXT Pink COLOR UIFOREGROUND Salmon COLOR UIBACKGROUND White COLOR UISELECT Yellow ]]

[rowett]

In most cases, the color of the shadow behind text is UIBACKGROUND. However, there appears to be a small handful of cases where the text is hardcoded to be black

These cases now use the UIBACKGROUND colour for shadows.

[muzik]

Looks like it's time for the horrifying debug theme (upgraded to account for "HELP" and "SELECTED") to make a return. Here's some of the remaining things without customizable colors:

- The text, as well as the shadow of said text, in the frame times box appear to be hardcoded and do not appear to respect any settings. I remember the background also being seemingly hardcoded, however this has since changed. It could either be made to use the UI foreground color or text color.
- The frame times box also has a color-changing bar behind it to indicate the FPS. I'm not sure how this would be made customizable.
- When identifying oscillators, a drop shadow is displayed behind each cell type in the table and map Identify menus. This appears to be permanently black - making it use UIBACKGROUND instead would be more fitting since all other shadows use it.
- For popup viewers, the close button at the bottom right in Settings still remains hardcoded. It could be made to use the "Error" color just like the speed bar recently was.

Code: Select all

x = 40, y = 50, rule = B3aeikr4cekrtwy5ckq6cei7/S2cen3-jr4cei5eikq6-a7c8
16bo$15b3o$14b5o$13b7o$12b9o$11b2o2b3o2b2o$10b3o3bo3b3o$9b2o5bo4b3o$8b
5o8b4o$7b4o11b4o$6b4o15b2o$5b2obo16b3o$4b2ob2o7bo7bo2b2o$3b2obo8b3o9b
3o$2b3o9b5o10b2o$b3o9b7o8bob2o$2obo8b9o9b3o$2bobo6b5o2bob2o4bo4b3o$2o
8b5o4b4o9b3o$2bo6b5o7b3o8b4o$8b5o6bobob2o7bob3o$9b5o8b4o9b3o$10b5o8b4o
8b4o$11b5o7b5o6b6o$12b3o8b4o6bob4o$13bo8b4o9b3o$23b2o7bo2b2o$32b4o$32b
3o$32b2o$30b3o$29b3o$27bob2o$28b2o$24b5o$23b5o$22b5o$22b4o$22b3o$21b3o
$18bo2b2o$19b3o$6bo12b2o$9b4o4b3o$8b3o6b2o$9b4ob4o$10b7o$11b5o$12b3o$
13bo!
[[ SHOWTIMING EXTENDEDTIMING
COLOR BACKGROUND Purple
COLOR DEAD Purple
COLOR DEADRAMP Purple
COLOR ALIVE Pink
COLOR ALIVERAMP Pink
COLOR MARK1 Pink
COLOR MARK2 Pink
COLOR MARKOFF Purple
COLOR KILL Purple
COLOR GRID Pink
COLOR GRIDMAJOR Pink
COLOR BOUNDARY Pink
COLOR BOUNDED Pink
COLOR SELECT Pink
COLOR PASTE Pink
COLOR ADVANCE Pink
COLOR SELECTED Pink
COLOR GRAPHBG Pink
COLOR GRAPHAXIS Pink
COLOR GRAPHALIVE Pink
COLOR GRAPHBIRTH Pink
COLOR GRAPHDEATH Pink
COLOR UIFOREGROUND Pink
COLOR UIBACKGROUND Pink
COLOR UIHIGHLIGHT Pink
COLOR UISELECT Pink
COLOR UILOCKED Pink
COLOR UIBORDER Pink
COLOR TEXT Pink
COLOR ERROR Pink
COLOR HELP Pink
COLOR STARS Pink
MAXGRIDSIZE 9 ]]

Also, a random, inconsequential sighting: while the viewer is loading, the T button appears considerably more opaque than any of the other buttons. I'm not sure why.

[rowett]

The text, as well as the shadow of said text, in the frame times box appear to be hardcoded and do not appear to respect any settings

Fixed.

The frame times box also has a color-changing bar behind it to indicate the FPS. I'm not sure how this would be made customizable.

I don't want this to be customizable.

When identifying oscillators, a drop shadow is displayed behind each cell type in the table and map Identify menus. This appears to be permanently black

Fixed.

For popup viewers, the close button at the bottom right in Settings still remains hardcoded.

Yes, by design.

Also, a random, inconsequential sighting: while the viewer is loading, the T button appears considerably more opaque than any of the other buttons. I'm not sure why.

Fixed, thanks.

[muzik]

For popup viewers, the close button at the bottom right in Settings still remains hardcoded.

Yes, by design.

I'm curious now - would it be possible to make the popup window's upper elements (white top bar thing, title text and close button) have colors changeable by scripts, or is it outwith what would be possible with commands? In such a case, the setting for the close button could simultaneously change the color of the in-viewer X and the upper X.

[muzik]

Since the period map's background color and grid color remain constant at all times, rather than changing depending on the pattern like cell period colors do, would it be possible to make these customizable via script commands?

[rowett]

Would it be possible to make the popup window's upper elements (white top bar thing, title text and close button) have colors changeable by scripts

Yes it's possible but I'm not interested in having those customizable.

[rowett]

Since the period map's background color and grid color remain constant at all times, rather than changing depending on the pattern like cell period colors do, would it be possible to make these customizable via script commands?

All the period map colours are fixed.

[muzik]

Since the period map's background color and grid color remain constant at all times, rather than changing depending on the pattern like cell period colors do, would it be possible to make these customizable via script commands?

All the period map colours are fixed.

From what I can see, they use the colors that the background and grid use by default. It may be possible to make them use whatever background and grid colors are specified at the time, like what was done for the grid button, but I'm not sure.

[rowett]

From what I can see, they use the colors that the background and grid use by default. It may be possible to make them use whatever background and grid colors are specified at the time, like what was done for the grid button, but I'm not sure.

You missed the point. The colours for the period map are fixed and I have no plans to make them customizable.

[muzik]

When the viewer is loading and the T menu is specified to be open, due to the fact that the "currently moused over coordinates" box below it is hidden when the viewer is in the process of loading, it appears to levitate since it's absence results in a gap.

Code: Select all

x = 6, y = 6, rule = B3/S23
2b2o$3bo$o3b2o$2o3bo$2bo$2b2o!
[[ SHOWGENSTATS COLOR UIBACKGROUND White ]]

Could elements of the T menu be hidden until loading is complete for consistency with it?

[rowett]

Could elements of the T menu be hidden until loading is complete for consistency with it?

Yes, done.

[muzik]

Could the same be done for the info bar?

Code: Select all

x = 6, y = 6, rule = B3/S23
2b2o$3bo$o3b2o$2o3bo$2bo$2b2o!
[[ SHOWINFOBAR COLOR UIBACKGROUND White ]]

I'd also like to see some text displayed in the "cell the mouse is currently over" bar if the mouse hasn't entered the viewer yet. Currently it just remains completely blank if the T menu is open by default, making what it's there for ambiguous. Something like "No cell highlighted" would resolve this.

Code: Select all

x = 6, y = 6, rule = B3/S23
2b2o$3bo$o3b2o$2o3bo$2bo$2b2o!
[[ SHOWGENSTATS COLOR UIBACKGROUND White ]]

[muzik]

The following four patterns return different values for Mod. From my limited understanding of PCA I'd think that 1 and 3 get it right and the remaining ones are wrong, but I may be wrong on this one.

Code: Select all

x = 1, y = 1, rule = PCA_4
B!

Code: Select all

x = 2, y = 2, rule = PCA_4
2B$2B!

Code: Select all

x = 3, y = 3, rule = PCA_4
3B$3B$3B!

Code: Select all

x = 4, y = 4, rule = PCA_4
4B$4B$4B$4B!

Identify now appears to return identical values for period and mod for these patterns, even though the mod should be a quarter of the period since they rotate each generation.

Likewise, this does not produce a mod of 16823:

Code: Select all

x = 6, y = 7, rule = PCA_4
5.H3$H.L.D3$5.B!

Identify on this gives both a period and mod of 67292. However, running this to generation 16823 (67292/4) and rotating it accordingly gives a figure identical to the starting one. This also works for 33646 (67292/2) and 50469 (3(67292)/2), so the expected mod here would be 16823.

And another example:

I'm not sure if lifeviewer is calculating mods for PCA patterns correctly anymore. This should have a mod a quarter of its period but does not:

Code: Select all

 x = 4, y = 3, rule = PCA_4
A.B$3.B$2.F!

[rowett]

The following four patterns return different values for Mod.

Fixed, thanks!

[muzik]

When commands are set up as to paste something at every n generations plus a given offset, that pattern will also be pasted at T=0 (when the pattern loads), despite the fact that T=0 doesn't itself satisfy the equation. In the following example, cells are to be pasted every 152n, 152n+38, 152n+76 and 152n+114 generations, and they are, but those cells are also pasted at T=0 despite 0 not being a valid value of 152n+38, 152n+76 or 152n+114 for integer n; only the bottommost cell should be pasted.

Code: Select all

x = 19, y = 18, rule = B3/S23
8bo8$o15bo3$14b3o$13b2o3bo$10b2ob3o2bo$10b2o3bo2bo$10bo2bo2b2o$8bo2bo
2b2o$12b4o!
[[
PASTET EVERY 152 38 PASTE o! 0 8
PASTET EVERY 152 76 PASTE o! 8 0
PASTET EVERY 152 114 PASTE o! 16 8
PASTET EVERY 152 PASTE o! 8 16
]]

Is this intended? I can see this behaviour becoming rather disruptive for cases where such regions would be required to be left blank at T=0 as to not disrupt expected evolution.

[hotdogPi]

152n = 0 when n = 0.

[muzik]

152n = 0 when n = 0.

Precisely - this is why the bottommost cell should remain on in such cases. The other three cells should not, as a constant (either 38, 76 or 114) sim added each time, and so when n=0, the cell should only be pasted at generations 38, 76 and 114, respectively.

[rowett]

When commands are set up as to paste something at every n generations plus a given offset, that pattern will also be pasted at T=0 (when the pattern loads)

No it won't. The pattern RLE has those three cells set.

[muzik]

No it won't. The pattern RLE has those three cells set.

I genuinely cannot believe I overlooked this as a possibility before reporting this. For me to make such a mistake is downright embarrassing. Here's confirmation that it does, in fact, work:

Code: Select all

#CXRLE Pos=10,11
x = 9, y = 7, rule = B3/S23
4b3o$3b2o3bo$2ob3o2bo$2o3bo2bo$o2bo2b2o$bo2b2o$2b4o!
[[
PASTET EVERY 152 38 PASTE o! 0 8
PASTET EVERY 152 76 PASTE o! 8 0
PASTET EVERY 152 114 PASTE o! 16 8
PASTET EVERY 152 PASTE o! 8 16
]]

----

This mistake aside, I've stumbled into what I believe to be a proper bug: for PCA patterns, strange things happen after around 520k generations (seemingly 525849). If the graph is open, the population will suddenly drop to zero after a given point. For example, try to identify this oscillator:

Code: Select all

x = 20, y = 14, rule = 2PCA4,0,2,4,3,8,10,6,14,1,9,5,7,12,11,13,15
6$5.B.B.B.B$4.D.D.D.D.D!
[[ GRAPH ]]

There are other strange effects that arise from this bug: if we run the pattern past this point manually, pause it after said point is surpassed, use the undo button to return to the previous state before Play was pressed, and then attempt to play the pattern again, the pattern will not evolve nor will the generation counter increment, even though Time will continue to increase.

Code: Select all

x = 20, y = 14, rule = 2PCA4,0,2,4,3,8,10,6,14,1,9,5,7,12,11,13,15
6$5.B.B.B.B$4.D.D.D.D.D!
[[ STARTFROM 520000 GRAPH STEP 64 SHOWGENSTATS ]]

This may be related to the issue where T will not increment past 1 (or -1) for a new pattern, unlike all other rulespaces:

Code: Select all

x = 1, y = 1, rule = PCA_4
!

Code: Select all

x = 1, y = 1, rule = Life
!

[rowett]

I've stumbled into what I believe to be a proper bug: for PCA patterns, strange things happen after around 520k generations (seemingly 525849). If the graph is open, the population will suddenly drop to zero after a given point.

The Population Graph only captures data for the first 524,288 generations.

[muzik]

There are other strange effects that arise from this bug: if we run the pattern past this point manually, pause it after said point is surpassed, use the undo button to return to the previous state before Play was pressed, and then attempt to play the pattern again, the pattern will not evolve nor will the generation counter increment, even though Time will continue to increase.

It appears this is actually unrelated to the graph and PCA:

Code: Select all

x = 1, y = 3, rule = B3/S23
o$o$o!
[[ STARTFROM 8000 STEP 64 ]]

If this pattern is run for a few thousand more generations manually, then the Undo button is used, the exact same effect can be seen.

[rowett]

if we run the pattern past this point manually, pause it after said point is surpassed, use the undo button to return to the previous state before Play was pressed, and then attempt to play the pattern again, the pattern will not evolve nor will the generation counter increment, even though Time will continue to increase

Fixed, thanks!

This may be related to the issue where T will not increment past 1 (or -1) for a new pattern, unlike all other rulespaces

Unrelated but also fixed.

[muzik]

The Population Graph only captures data for the first 524,288 generations.

Would it be possible to stop the graph from expanding beyond this limit? Having it suddenly drop to 0 is rather unexpected, and it continuing to expand results in valid data eventually being pushed back into an unreadable state. Having the graph stop expanding after hitting the limit would make it clearer that there is a defined, intended limit.