Pattern viewer for forum threads

[muzik]

Here's a final batch of Identify issues from rigorous further testing:

Some diagonal glide-reflective spaceships appear to have lost their mod again - all of the diagonal spaceships here no longer work, and there's also some 2-state cases as well:

Code: Select all

x = 8, y = 8, rule = R2,C4,M1,S4..4,B4..4,NM
5.2A$4.3BA$6.CA$6.CA$6.C!

Code: Select all

x = 3, y = 4, rule = B2ac/S1
2bo2$b2o$o!

Code: Select all

x = 4, y = 5, rule = B3-n4c8/S2-i34-ar6ci
2o$b2o$3bo$2bo$3bo!

Alternating rules (including B0) don't seem to process Mod anymore either.

Code: Select all

x = 4, y = 5, rule = B13/S012345678|B/S15
o2$b2o2$3bo!

Code: Select all

x = 4, y = 3, rule = B13/S012345678|B/S15
o2bo2$3bo!
[[ ZOOM 8 ]]

Code: Select all

x = 3, y = 3, rule = B3678/S23678|B3/S23
o$3o$bo!
[[ ZOOM 8 ]]

Code: Select all

x = 6, y = 4, rule = B02348/S0123
3o2bo$obo$3o$5bo!
[[ ZOOM 8 ]]

Code: Select all

x = 9, y = 1, rule = Unidim1
3o2b4o!

Code: Select all

x = 2, y = 2, rule = B2/S23|B3/S1
o$bo!

Can Identify used on this be made to say something other than "Empty Pattern"? This specific string doesn't seem to be used anymore anywhere else other than this specific case.

Code: Select all

x = 1, y = 1, rule = B3/S23
3bo2bo$3bo2bo$2b6o$10o$2b6o$2b6o$10o$2b6o$3bo2bo$3bo2bo!
[[ PASTET EVERY 12 12 PASTE 3bo2bo$3bo2bo$2b6o$10o$2b6o$2b6o$10o$2b6o$3bo2bo$3bo2bo! 0 0 ]]

Would it be possible to have spaceships in Margolus rules report their actual period? Since only every second generation is counted for Margolus Identify, these spaceships have reported periods (and displacements) of twice their actual periods, so it may be a good idea to have some way of checking odd-numbered generations to see if the actual period is lower.

Code: Select all

x = 1, y = 1, rule = Sand
o!

Code: Select all

x = 3, y = 2, rule = M0,3,10,2,5,1,6,7,12,9,8,11,4,13,14,15
2o$2bo!

Code: Select all

x = 4, y = 4, rule = M0,3,10,2,5,1,6,7,12,9,8,11,4,13,14,15
$2bo$2bo$3o$3bo!

I'd also be interested in seeing "FlipXorY" renamed to "FlipOrth" - the amount of characters would be the same, but it'd eliminate an ambiguous "or" in "FlipXorYorRot90", since with this change it'd be "FlipOrthorRot90", which reads a lot better: "flip orthogonally or rotate 90 degrees" is the only valid interpretation, whereas "FlipXorYorRot90" could be - and in my case, has been - misinterpreted as "flip X, or flip Y, or flip Rot90".

Identify does not cooperate well with this [R]History pattern (it's fine with [R]Super):

Code: Select all

x = 5, y = 5, rule = B123456/S0123456HHistory:T5
4AF$5A$5A$5A$5A!

Code: Select all

x = 5, y = 5, rule = B123456/S0123456HSuper:T5
4AF$5A$5A$5A$5A!

[R]History Identify appears to be sometimes reporting odd-period objects as having a period of double their actual period. [R]Standard and [R]Super seem unaffected.

Code: Select all

x = 2, y = 2, rule = Life
2o$2o!

Code: Select all

x = 2, y = 2, rule = LifeHistory
2o$2o!

Code: Select all

x = 2, y = 2, rule = LifeSuper
2o$2o!

Code: Select all

x = 8, y = 6, rule = Life
2bo$o3b4o$o3bo$o$3bo$b2o!

Code: Select all

x = 8, y = 6, rule = LifeHistory
2bo$o3b4o$o3bo$o$3bo$b2o!

Code: Select all

x = 8, y = 6, rule = LifeSuper
2bo$o3b4o$o3bo$o$3bo$b2o!

Would it be possible to enable the period map and period table feature for still lifes, like how the bugged [R]History example above does? Still lifes are period-1 oscillators, and I'd like a way to easily generate period map images of them like with any other oscillator.

[rowett]

This is a hilariously minor thing, but the following oscillator has a period of 1048575, which can be easily checked via Go To Gen. Identify's current period limit is 1048576, just above this period, but it doesn't detect that this is an oscillator despite it technically having a low enough period. This definitely isn't worth the time or compromises to fix, but I felt like pointing it out anyway.

1048576 is the maximum number of generations that Identify will search, and not the maximum period.

[rowett]

Some diagonal glide-reflective spaceships appear to have lost their mod again

Fixed, thanks.

Alternating rules (including B0) don't seem to process Mod anymore either.

Fixed, thanks.

Can Identify used on this be made to say something other than "Empty Pattern"? This specific string doesn't seem to be used anymore anywhere else other than this specific case.

That's because this is a specific case.

Identify does not cooperate well with this [R]History pattern

Fixed, thanks.

[R]History Identify appears to be sometimes reporting odd-period objects as having a period of double their actual period.

Fixed, thanks.

[muzik]

As of build 909, alternating rules now display all cells in period maps, rather than only cells which were on in even generations. I much prefer it this way and would like if it were to stay as such. The edges of period maps, however, appear to be subject to unwanted truncation (likely since the bounding box is only counted for even generations):

Code: Select all

x = 13, y = 5, rule = B13/S012345678|B/S15
o2$b2o9bo2$3bo!

There also appear to be some small holes and edge inconsistencies the period map that don't exist in the actual envelope of the pattern.

Code: Select all

x = 3, y = 3, rule = B3678/S23678|B3/S23
o$3o$bo!
[[ THEME Occupied AUTOFIT STEP 64 AUTOSTART STOP 320 HISTORYFIT ]]

Judging by this glider's trajectory, it would interact with this block, so it probably shouldn't be deleted by KILLGLIDERS.

Code: Select all

x = 16, y = 14, rule = B3/S23
5b2o$5b2o$2bo$obo$b2o8$14b2o$14b2o!
[[ KILLGLIDERS ]]

An inconsistency: the square grid pattern fits the entire bounded grid by default, but the hexagonal grid only focuses on alive cells.

Code: Select all

x = 1, y = 2, rule = R1,C0,S,B3,NM:T45,1
o$o!

Code: Select all

x = 1, y = 2, rule = R1,C0,S,B2,NH:T45,1
o$o!

For thumbnails like those on Catagolue, the randomize button doesn't visually change the thumbnail, but the underlying pattern definitely is changed since closing the popup and reopening it gets us the random pattern again. Should the thumbnail visually change to reflect this, shoukd the random pattern and rule be discarded, or is this intentional behaviour?: https://catagolue.hatsya.com/object/xp4 ... y5ary6aek8

This spaceship is now giving a mod again. If LifeViewer detects that a spaceship has a mod that isn't FlipX, FlipY, Rot90CWFlipX or Rot90CWFlipY, would it be possible to just have it discard that value and set the mod to the period, since no other mod is valid for spaceships in a two-dimensional rule?

Code: Select all

x = 2, y = 1, rule = MAPAABoACAAgAAAAAAAAAAAAAAAAACAAAAAgAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
2o!

The calculated strict volatility and cells map don't appear correct for this pattern:

Code: Select all

x = 36, y = 1, rule = B3i4int5ey6k7e/S1e2k3ey4irt5i
36o!

[pzq_alex]

Judging by this glider's trajectory, it would interact with this block, so it probably shouldn't be deleted by KILLGLIDERS.

Code: Select all

x = 16, y = 14, rule = B3/S23
5b2o$5b2o$2bo$obo$b2o8$14b2o$14b2o!
[[ KILLGLIDERS ]]

Actually, I want to know how KILLGLIDERS work in detail. If I recall correctly a glider can be safely deleted if there's a sufficiently wide strip of dead cells behind the glider, and nothing in front:

Code: Select all

x = 9, y = 9, rule = LifeHistory
7.2D$6.3D$5.4D$4.4D$3.4DA$2.4D2.A$.4D.3A$4D$3D!

Every red cell in the diagram and everything below it (except the glider, of course) must be off. I'm curious how LifeViewer performs this check.

[muzik]

Actually, I want to know how KILLGLIDERS work in detail. ... I'm curious how LifeViewer performs this check.

Here's an explanation, though changes have been made since to fix some edge cases so I'm not sure how accurate it is to the current algorithm: viewtopic.php?f=3&t=1622&p=131827#p131827

[rowett]

As of build 909, alternating rules now display all cells in period maps, rather than only cells which were on in even generations.

That's not quite true. But as of build 910 they do.

There also appear to be some small holes and edge inconsistencies the period map that don't exist in the actual envelope of the pattern.

See above.

For thumbnails like those on Catagolue, the randomize button doesn't visually change the thumbnail, but the underlying pattern definitely is changed since closing the popup and reopening it gets us the random pattern again. Should the thumbnail visually change to reflect this, shoukd the random pattern and rule be discarded, or is this intentional behaviour?: https://catagolue.hatsya.com/object/xp4 ... y5ary6aek8

It's an edge case that's probably not worth fixing.

This spaceship is now giving a mod again.

Fixed, thanks.

The calculated strict volatility and cells map don't appear correct for this pattern

Fixed, thanks. It was because the new memory-based period limiter allowed this pattern with a period > 65535 and the data structure to store periods was too narrow.

[muzik]

LifeViewer has two ways of rendering period maps: either with a grid (for small oscillators) or with a border and no grid (for large oscillators), with which style is used depending on the current viewer size. However, if the viewer's size changes while the map is shown, the style won't change to accommodate the new viewer size. This generally results in the version of the map with grid lines displayed appearing blurry, which I don't like at all. In most other situations, the grid lines and cells appear crystal clear with no blurring.

Here's a test pattern - I'd recommend testing this on the embedded resizable viewer at lazyslug.com, since on the desktop browsers I've tested the popup isn't resized in the same way. Try it first with the browser maximised to check that the "grid" version is used, then change the size of the browser window and use Identify again to see if you can get the version without the grid. Once you get a version of it without the grid, maximise the window. The grid does not appear. Similarly, if you try it when maximised first and then go to the non-maximised state, the grid will stay there (appearing quite blurry on my end, which is the effect I want rid of and the reason why I'm reporting this) instead of the map changing to the no-grid version.

Code: Select all

x = 65, y = 32, rule = B2-a3/S01c5i
o19bo19bo19bo$21bo19bo19bo$22bo19bo19bo$43bo19bo$64bo16$2o18b2o18b2o
18b2o$2o18b2o18b2o18b2o$2o18b2o18b2o18b2o$2o18b2o18b2o18b2o$20b2o18b2o
18b2o$20b2o18b2o18b2o$20b2o18b2o18b2o$20b2o18b2o18b2o$40b2o18b2o$40b2o
18b2o$60b2o$60b2o!

[rowett]

Judging by this glider's trajectory, it would interact with this block, so it probably shouldn't be deleted by KILLGLIDERS.

Fixed, thanks.

[muzik]

Since Identify can now detect odd-period cells for alternating rules including B0, would it be possible to enable period maps and the period table for still lifes so that we can get images and percentages of cell types? Even for non-alternating rules, having the ability to generate period map-style images would be fun to have.

Code: Select all

x = 1, y = 1, rule = B0/S
o!

On the topic of Identify and still lifes: Density would be an easy statistic to implement (and one of importance, since there's recently been renewed interest in maximal-density still lifes in B3/S23. This would probably be very easy to implement - just divide the number of cells by the size of the bounding box (and then divide by 4 for PCA rules).

Speaking of density: it's possible for density to exceed 100% in very specific cases. Here's an example that does this automatically:

Code: Select all

x = 9, y = 9, rule = B123456/S0123456HSuper:T9
F3AF3AF$9A$9A$9A$F3AF3AF$9A$9A$9A$F3AF3AF!
[[ SHOWGENSTATS PASTET 1 PASTE 9A$9A$9A$9A$9A$9A$9A$9A$F8A! 0 0 STOP 1 COLOR 0 80 80 80 ]]

The T menu's contents for bounded grids also have a visible gap at the bottom right when a bounded grid is in use. Could it be moved down to mitigate this?

[rowett]

On the topic of Identify and still lifes: Density would be an easy statistic to implement

Done.

Code: Select all

x = 21, y = 21, rule = B3/S23
2ob2obob2ob2obob2ob2o$2obob3obobob3obob2o$3bo5bobo5bo$3ob5obob5ob3o$o
2bo4bobobo4bo2bo$bobob2obobobob2obobo$2obob2obobobob2obob2o$bobo4bobob
o4bobo$o2b6obob6o2bo$3o7bo7b3o$3b7ob7o$3o7bo7b3o$o2b6obob6o2bo$bobo4bo
bobo4bobo$2obob2obobobob2obob2o$bobob2obobobob2obobo$o2bo4bobobo4bo2bo
$3ob5obob5ob3o$3bo5bobo5bo$2obob3obobob3obob2o$2ob2obob2ob2obob2ob2o!

[muzik]

Identify used on still life predecessors give multiple populations (like oscillators do) instead of just one.

Code: Select all

x = 3, y = 2, rule = B3/S23
obo$2o!

Could Density be made to display as a real number from 0 to 1 instead of a percentage, to be more consistent with Volatility and other such values?

[rowett]

Identify used on still life predecessors give multiple populations (like oscillators do) instead of just one.

Fixed, thanks.

Could Density be made to display as a real number from 0 to 1 instead of a percentage, to be more consistent with Volatility and other such values?

Yes, done.

[muzik]

Can period-2 cells be reintroduced to % Rotor in the period counts table since period-1 cells are now detected for alternating rules?

Code: Select all

x = 5, y = 1, rule = B1e/S0|B2i/S3e4e
o3bo!

[muzik]

Identify used on some still life predecessors still causes some false results for bounding box:

Code: Select all

x = 3, y = 4, rule = B3/S23
2bo2$obo$2o!

[rowett]

it's possible for density to exceed 100% in very specific cases

Fixed, thanks.

The T menu's contents for bounded grids also have a visible gap at the bottom right when a bounded grid is in use. Could it be moved down to mitigate this?

Yes, done.

[rowett]

Can period-2 cells be reintroduced to % Rotor in the period counts table since period-1 cells are now detected for alternating rules?

Yes, done.

[rowett]

Identify used on some still life predecessors still causes some false results for bounding box

Fixed, thanks.

[rowett]

This is a hilariously minor thing, but the following oscillator has a period of 1048575, which can be easily checked via Go To Gen. Identify's current period limit is 1048576, just above this period, but it doesn't detect that this is an oscillator despite it technically having a low enough period. This definitely isn't worth the time or compromises to fix, but I felt like pointing it out anyway.

Code: Select all

x = 54, y = 1, rule = B3i4int5ey6k7e/S1e2k3ey4irt5i
54o!

While I have considered suggesting raising the Identify limit to 4194304 to be on par with Go To Gen, or potentially to make it variable depending on memory like the above proposal for strict volatility limit changes, neither is a high priority at all.

Interestingly after raising the Identify generation search limit and with the new memory-based period limit for Strict Volatility this pattern can now be idenitifed with Strict Volatility. On my machine it takes 48 seconds.

[muzik]

I've been wondering a lot about alternating Identify lately. Is the fact that period-2 objects are classified as still lifes merely an unfortunate side effect of how Identify works for alternating rules? Would Identify have the ability to distinguish between objects that stay put without changing at all and those that do in fact oscillate with period 2 in this rulespace if it could, or is there a logical analytical advantage to considering objects that appear to be period-2 as still lifes? I can think of somewhat convincing reasons in both directions, although I'm personally leaning towards the former.

----

Could we have some more numbers after the decimal point in still life density for Identify? We have plenty of room for them, since only one density value has to be displayed unlike with Volatility and Temperature.

If a spaceship crashes into a plane boundary and becomes a still life, for example, Identify will still report that it's a spaceship, but Mod won't be correct, and neither will Cells or Heat. I'm not sure what the correct behaviour here would even be - should Identify report the spaceship that it once was, or the still life it has become?

Code: Select all

x = 3, y = 3, rule = B3/S23:P10
o$obo$2o!

Much of the same can be seen here. A spaceship should never have a minimum population of 0.

Code: Select all

x = 5, y = 5, rule = B2/S2H
o$2o$bo2$obobo!
[[ ZOOM 16 SQUARECELLS X -128 Y -256 STARTFROM 370 MAXGRIDSIZE 9 ]]

Periodic paste commands also do some funny things to Identify results. Previously it just expanded the bounding box beyond what it should be, but now pasted cells appear to be tracked with counterintuitive periods (for example, p8 here instead of p10). Since paste commands aren't vanilla CA behaviour I'm not sure if this is worth any attention at all.

Code: Select all

x = 6, y = 6, rule = B3/S23
3b3o$3b3o$3b3o$3o$3o$3o!
[[ PASTET EVERY 10 PASTE o! -20 -20 ]]

While Bounding Box is now correctly and consistently identified for both of these patterns, Heat and Temperature are still different despite there being no behavioural difference:

Code: Select all

x = 4, y = 4, rule = B12/SVHistory
4F$FA.F$F.AF$4F!

Code: Select all

x = 4, y = 4, rule = B2/SVHistory
4F$FA.F$F.AF$4F!

Identify doesn't detect that this is periodic at all. Taking a completely random guess, it might be constantly assuming that it's a diagonal spaceship and confirming it's not, all the while being oblivious to its overall horizontal displacement.

Code: Select all

x = 1, y = 1, rule = B3/S23
o!
[[ ZOOM 4 
PASTEDELTA 2 0 PASTET EVERY 2 PASTE o! 0 0
PASTEDELTA 2 0 PASTET EVERY 2 1 PASTE o! 1 1 ]]

Identify used on objects with TRACK specified will cause the viewer to not be centered on the object at all once identification is complete.

Code: Select all

x = 9, y = 5, rule = B3/S23
o!
[[ GRID ZOOM 4 MAXGRIDSIZE 9 PASTEDELTA 2 0 PASTET EVERY 1 PASTE o! 0 0 TRACK 2 0 ]]

Finally, I'm not sure how easy this would be to implement, but could LifeViewer be able to detect if all future paste commands can only happen out of bounds and ignore them, pausing with a "Life ended at" message if no new cells can ever come into existence through evolution or commands?

[rowett]

I've been wondering a lot about alternating Identify lately. Is the fact that period-2 objects are classified as still lifes merely an unfortunate side effect of how Identify works for alternating rules? Would Identify have the ability to distinguish between objects that stay put without changing at all and those that do in fact oscillate with period 2 in this rulespace if it could, or is there a logical analytical advantage to considering objects that appear to be period-2 as still lifes? I can think of somewhat convincing reasons in both directions, although I'm personally leaning towards the former.

My view is that alternating rules are just 2 physical transitions that create 1 logical transition on the grid. It's not valid to compare an odd with an even transition. So there is a valid argument that all periods and Mods should be displayed in logical transitions rather than physical transitions as today.

Could we have some more numbers after the decimal point in still life density for Identify? We have plenty of room for them, since only one density value has to be displayed unlike with Volatility and Temperature.

Yes I'll add another digit. This is actually why I had this as a percentage originally.

If a spaceship crashes into a plane boundary and becomes a still life, for example, Identify will still report that it's a spaceship, but Mod won't be correct, and neither will Cells or Heat. I'm not sure what the correct behaviour here would even be - should Identify report the spaceship that it once was, or the still life it has become?

I've been considering for a while treating bounded grids as one entity. It's not terribly valid, due to situations like you mention, to try and detect items within a bounded grid. It's possibly more helpful just to treat the bounded grid as a whole as an object when using Identify. Interested on opinions on this topic.

Much of the same can be seen here. A spaceship should never have a minimum population of 0.

True, this is a bug.

Periodic paste commands also do some funny things to Identify results. Previously it just expanded the bounding box beyond what it should be, but now pasted cells appear to be tracked with counterintuitive periods (for example, p8 here instead of p10). Since paste commands aren't vanilla CA behaviour I'm not sure if this is worth any attention at all.

Agreed.

While Bounding Box is now correctly and consistently identified for both of these patterns, Heat and Temperature are still different despite there being no behavioural difference

It's because Bounded Grids don't current compute births and deaths. I'll probably hide Heat and Temperature until that's fixed.

Identify doesn't detect that this is periodic at all. Taking a completely random guess, it might be constantly assuming that it's a diagonal spaceship and confirming it's not, all the while being oblivious to its overall horizontal displacement.

True. Is it possible to reproduce this kind of movement without PASTE?

[muzik]

My view is that alternating rules are just 2 physical transitions that create 1 logical transition on the grid. It's not valid to compare an odd with an even transition. So there is a valid argument that all periods and Mods should be displayed in logical transitions rather than physical transitions as today.

I can get behind this for B0 rules and alternating rules. I'm not sure if I'd agree for Margolus rules, though. This is definitely a p2 oscillator:

Code: Select all

x = 3, y = 2, rule = M0,2,8,3,1,5,6,7,4,9,10,11,12,13,14,15
bo$2bo!

Unlike with alternating rules, Margolus rules always apply the same rule everywhere - it's just the subdivision of the grid that changes. Would special-casing Margolus rules be possible so that the above can be considered p2?

While Bounding Box is now correctly and consistently identified for both of these patterns, Heat and Temperature are still different despite there being no behavioural difference

It's because Bounded Grids don't current compute births and deaths. I'll probably hide Heat and Temperature until that's fixed.

These are [R]History state 6 cells.

Identify doesn't detect that this is periodic at all. Taking a completely random guess, it might be constantly assuming that it's a diagonal spaceship and confirming it's not, all the while being oblivious to its overall horizontal displacement.

True. Is it possible to reproduce this kind of movement without PASTE?

Here's one I prepared earlier - it does, however, require the use of alternation, so I'm not sure if it's valid. Also, Identify does more or less correctly detect it (while a mod of 1 and a FlipY transform would make sense for the PASTE version, given your above argument about alternating rules I don't think the same can be said here - however there is the fact that the two rules used here are the exact same as each other, just rotated).

Code: Select all

x = 1, y = 1, rule = MAPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//////////////////////////////////////////w|MAPDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw
o!

Also, here's a non-PASTE demo of the track Identify issue:

Code: Select all

x = 3, y = 3, rule = B3/S23
o$obo$2o!
[[ TRACK -1/4 1/4 ]]

[rowett]

Could we have some more numbers after the decimal point in still life density for Identify? We have plenty of room for them, since only one density value has to be displayed unlike with Volatility and Temperature.

Done, thanks.

While Bounding Box is now correctly and consistently identified for both of these patterns, Heat and Temperature are still different despite there being no behavioural difference

Fixed, thanks.

[muzik]

A thought I've had at the back of my mind recently: with icon support on the horizon, would reimplementing the ability to view hexagonal patterns on a non-offset square grid be a good idea? It was removed back in 2019 due to there not really being any good use case for it, but since icons are fundamentally square, there's probably a good few rules out there that have their own custom set of icons designed for hexagonal grids with square-grid rendering in mind (and the offset square grid probably wouldn't work well with them since the grid squares are shifted and therefore the icons wouldn't physically match up with each other as they were designed to).

A second thought: could very basic Theme support be implemented for [R]Super rules? The only theme-specified colors you'd need are BACKGROUND (for state 0), ALIVE (for state 1) and DEAD (for state 2). None of the higher states vary by theme in [R]History, so they can be ignored for [R]Super. DEADRAMP and ALIVERAMP can also be ignored since fading isn't supported yet. Grid settings are already completely functional. The default theme for [R]Super rules would be the "LifeHistory" theme.

Code: Select all

x = 28, y = 6, rule = B3/S23History
.A3.2B2.4C3.D2.4E2.3F$2A2.B2.B.C2.C2.2D2.E4.F$.A5.B3.C2.D.D2.3E2.3F$.
A3.2B5.C.4D4.E.F2.F$.A2.B4.C2.C3.D2.E2.E.F2.F$3A.4B2.2C4.D3.2E3.2F!
[[ GRID THEME Catagolue ]]

Code: Select all

x = 28, y = 6, rule = B3/S23Super
.A3.2B2.4C3.D2.4E2.3F$2A2.B2.B.C2.C2.2D2.E4.F$.A5.B3.C2.D.D2.3E2.3F$.
A3.2B5.C.4D4.E.F2.F$.A2.B4.C2.C3.D2.E2.E.F2.F$3A.4B2.2C4.D3.2E3.2F!
[[ GRID THEME Catagolue ]]

[muzik]

Negative values are appearing in generation stats again. The expected values for each generation are as follows:

T 0: 12 Alive, 0 Births, 0 Deaths
T 1: 0 Alive, 0 Births, 12 Deaths
T 2: 0 Alive, 0 Births, 0 Deaths

Both of the following patterns display differing (and incorrect) values during T 1, with LifeHistory having -12 births.

Code: Select all

x = 6, y = 6, rule = LifeHistory
2A2.2A$AF2.FA3$AF2.FA$2A2.2A!
[[ SHOWGENSTATS ]]

Code: Select all

x = 6, y = 6, rule = LifeSuper
2A2.2A$AF2.FA3$AF2.FA$2A2.2A!
[[ SHOWGENSTATS ]]

----

If "COLOR 0" is changed via script commands, the dying trail will change color. I think the background color should change instead:
- the background is something universally considered to be state 0 across pretty much all of CA and its implementations, whereas visually fading dead cells are just a LifeViewer visual addition
- this also gives incorrect results for [R]History, where state 0 is the background and state 2 are the dead cells, so having commands that change 0 instead change state 2 and leave state 0 unchanged is wrong

Code: Select all

x = 3, y = 3, rule = B3/S23
o$obo$2o!
[[ ZOOM 8 STARTFROM 64 COLOR 0 255 255 255 ]]

Code: Select all

x = 3, y = 3, rule = B3/S23History
o$obo$2o!
[[ ZOOM 8 STARTFROM 64 COLOR 0 255 255 255 ]]

The expected behaviour would be as follows: "COLOR 0" and "COLOR BACKGROUND" would change the background color, whereas "COLOR DEAD" and "COLOR dead" would change the dying trail.