LifeViewer/Known bugs
Revision as of 12:20, 7 September 2023 by Rowett (talk | contribs) (→Rendering: AutoFit is smoothing the camera glide)
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.
Playback
- 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.
| (click above to open LifeViewer) |
- The current generation shown in the generation statistics menu is inconsistent between non-reversible and reversible rulespaces if a custom starting generation has been specified via #CXRLE Gen.
- It'd be expected that either both cases would follow CXRLE Gen (as to be consistent with the T button itself as well as the "Life ended at" text), both would ignore it, or both the relative and absolute generations would be displayed in the generation statistics menu (this option is preferable since it'd allow for the unabbreviated relative generation to be obtained, as well as the absolute generation to be seen which would assist greatly with timed scripts).
| NI Moore | Margolus |
|---|---|
(click above to open LifeViewer) |
(click above to open LifeViewer) |
- In many cases, script commands will persist after resuming playback if Identify is used while script-related sequences are underway.[1]
Pattern editing
- Selections can often appear offset from their actual location when using bounded grids.
- This generally arises due to the bounding box specified in the RLE (x = width, y = height) differing from the actual bounding box of the pattern encoded by the RLE.
- This is more than a visual issue, as certain selections cannot be created in certain positions, and cannot be correctly manipulated either.
- This issue is on the backlog to fix.[2]
| (click above to open LifeViewer) |
- 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 st all can result in unwanted deletion of cells when flipping or rotating selections containing them.
| Standard | General |
|---|---|
(click above to open LifeViewer) |
(click above to open LifeViewer) |
- Changes made to a pattern via selections can become impossible to undo after the Reset button is used.
- On the following pattern, using the Select tool, select one of the shapes and then use the "Clear Selection" button to remove it, then get rid of the selection by clicking somewhere else. After this, press the reset button, and the Undo button will become locked, rendering the change irreversible.
| (click above to open LifeViewer) |
Identify
- 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.
- This also affects AutoFit during playback.
- A fix for this is planned.[3]
| range-1 | general-range |
|---|---|
(click above to open LifeViewer) |
(click above to open LifeViewer) |
- Some impossible Mod outputs can be provided on bounded grids, such as this period-2000 mod-100 torus.
| (click above to open LifeViewer) |
Pattern loading
- 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.[4]
| Margolus | outer-totalistic |
|---|---|
(click above to open LifeViewer) |
(click above to open LifeViewer) |
- 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.
| range-1 | general-range |
|---|---|
(click above to open LifeViewer) |
(click above to open LifeViewer) |
Rendering
- 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 |
|---|---|
(click above to open LifeViewer) |
(click above to open LifeViewer) |
Platform-exclusive issues
iOS
Pattern editing
- Copying patterns to the external clipboard does not appear to actually work.