This page contains a list of issues within LifeViewer which are not considered to be a high enough priority to fix immediately, with test cases where they apply.
Please report any new bugs to this forum topic. This page is for unresolved issues that have already been reported.
Issues which are not fixable are documented at LifeViewer/Known bugs/Not fixable. Checking there is recommended before reporting bugs in the event that said issue is already listed there.
Twisted edges of Klein bottles and cross-surfaces might not be being processed correctly in PCA rules.
In the following pattern, a single PCA cell crosses the twisted edge of a Klein bottle. In a normal unbounded plane, the cell, being in the "west" state, would become a "south" cell in the next generation. In this example, since it crosses a twisted boundary, it'd be expected that it would be flipped vertically (or, equivalently, rotated 180 degrees), and would become a "north" cell as a result. However, in this demonstration, it still becomes a "south" cell.
x = 5, y = 2, rule = 2PCA4,0,2,4,12,8,5,9,7,1,6,10,11,3,13,14,15:K5,5*
b$4.A!
#C [[ THUMBSIZE 2 THEME 6 GRID GRIDMAJOR 0 SUPPRESS THUMBLAUNCH ]]
[[ THEME Book ]]
In many cases, script commands will persist after resuming playback if Identify is used while script-related sequences are underway.[1]
Even-odd Klein bottle bounded grids for triangular rules are forbidden, and only even-even sizes are allowed, despite the fact that these permit undefined behaviour (triangles of the same rotation are placed adjacent to each other when they should not be).
It'd be expected that only even-odd or odd-even bounded grids would be permitted for Klein bottles in triangular rules, depending on which axis the twist is on.
Likewise, cross-surfaces should be restricted to odd-odd for triangular rules instead of even-even.
The same logic likely applies to Margolus rules.
x = 3, y = 2, rule = B1/SL:K26*,26
$obo!
#C [[ THUMBSIZE 2 THEME 6 GRID GRIDMAJOR 0 SUPPRESS THUMBLAUNCH ]]
[[ THEME Book ]]
In the general-range algorithm, selections behave oddly at the very edge of the unbounded grid.
For range 1 in the general range algorithm, the three cells at the edge are effectively treated as one. Any selection in a cell one or two away from the edge will snap to the very edge, and any selection containing any of those cells plus cells four or more cells away will select all three of those cells.
Since the three cells at the very edge cannot be modified at all, it'd be preferable if selections simply could not be made at the three cells at the edge for this algorithm. The fact that selections can be made here at all can result in unwanted deletion of cells when flipping or rotating selections containing them.
For Margolus rule bounded grids, attempting to begin drawing by clicking in the topmost row or leftmost column inside of the boundaries will do nothing. However, if this click is held while the cursor is moved further to the right or downwards and them moved back into one of these extreme rows/columns, or the click does not begin in said row or column and is dragged into it, only then will drawing be permitted.
x = 10, y = 10, rule = M0,4,8,12,4,12,12,13,8,12,12,14,12,13,14,15:T10,10
9o$9o$9o$9o$9o$9o$9o$9o$9o!
#C [[ THUMBSIZE 2 THEME 6 GRID GRIDMAJOR 0 SUPPRESS THUMBLAUNCH ]]
[[ THEME Book ]]
Dying cells in the range-1 algorithm are handled differently from the same cells in the general-range algorithm, being counted towards the pattern bounding box in the former but not the latter.
Margolus patterns on bounded grids will delete the top row and leftmost column of the pattern when loaded, unlike in other rulespaces.
Other issues can arise from this, particularly if the top-left cell should be alive but is not. For example, a "New Pattern" message will not be displayed despite no alive cells being present, the population counter will report that one live cell is present, and using "Select All" creates a selection at the bottom right corner of the bounded grid.
Fixes for Margolus pattern positioning on bounded grids are on the backlog.[3]
Triangular patterns loaded on bounded grids also result in cell deletion.
For either of the following two patterns, drawing a cell at the very top left of the bounded grid, using Save Pattern and then reloading the pattern will result in everything being shifted down and to the right.
When saving a Margolus pattern using Save Pattern at an odd generation, reopening that pattern will cause it to have completely different behaviour than the original pattern.
This could be fixed by including an extra cell of empty space on both axes before the pattern iff saved on an odd generation to compensate for the shifting grid subdivisions.
x = 3, y = 3, rule = M0,2,8,3,1,5,6,7,4,9,10,11,12,13,14,15
bo$2bo$2o!
#C [[ THUMBSIZE 2 THEME 6 GRID GRIDMAJOR 0 SUPPRESS THUMBLAUNCH ]]
[[ THEME Book ]]
Setting GRIDMAJOR to 0 and setting GRID and GRIDMAJOR to the same color produce visually identical results, but LifeViewer handles these differently.
For the GRID = GRIDMAJOR case, Settings > Display > Major GridLines remains toggleable.
For the GRIDMAJOR 0 case, the color that major grid lines would use is still displayed in Help > Info > Gridlines, despite these grid lines being completely inaccessible.
For the GRID = GRIDMAJOR case, the color is displayed identically for both, which could be considered inconsistent with how GRID = GRIDMAJOR cases are handled in Help > Themes.
The grid lines used to partition the grid in Margolus rules are not consistent in representing the partitioned regions.
It would be expected that either GRIDMAJOR would represent the "active" partitioning, or GRID would, but not interchangeably depending on the input pattern. The former would be preferable.
GRID used
GRIDMAJOR used
x = 1, y = 1, rule = M0,2,8,3,1,5,6,7,4,9,10,11,12,13,14,15
o!
#C [[ THUMBSIZE 2 THEME 6 GRID GRIDMAJOR 0 SUPPRESS THUMBLAUNCH ]]
#C [[ COLOR GRIDMAJOR Black GRIDMAJOR 2 THUMBNAIL THUMBSIZE 4 WIDTH 600 HEIGHT 600 ]]