I've found some other issues with tile loading that may be linked to the one from earlier you weren't able to reproduce:
Firstly, for the following patterns, create a selection starting from the dot and the center and drag it towards one of the upper corners of the board. It's possible to reach the horizontal edges, but a ceiling will be hit which the selection cannot expand past vertically. If a selection is started beyond this ceiling, this effect goes away until the viewer is restarted.
Code: Select all
x = 2, y = 2, rule = B1357/S02468
2o$2o!
[[ MAXGRIDSIZE 9 DELETERANGE 1 ZOOM -1 ]]
Code: Select all
x = 2, y = 2, rule = R1,C2,S0,2,4,6,8,B1,3,5,7,NM
2o$2o!
[[ MAXGRIDSIZE 9 DELETERANGE 1 ZOOM -1 ]]
Code: Select all
x = 2, y = 2, rule = rlrep
2o$2o!
[[ MAXGRIDSIZE 9 DELETERANGE 1 ZOOM -1 ]]
@RULE rlrep
@TABLE
n_states:2
neighborhood:Moore
symmetries:permute
0,0,0,0,0,0,0,0,1,1
0,0,0,0,0,0,1,1,1,1
0,0,0,0,1,1,1,1,1,1
0,0,1,1,1,1,1,1,1,1
1,1,0,0,0,0,0,0,0,0
1,1,1,1,0,0,0,0,0,0
1,1,1,1,1,1,0,0,0,0
1,1,1,1,1,1,1,1,0,0
Secondly, for the above patterns, evolutionary differences can be seen. The first pattern makes use of the entire grid and acts periodically, to the point where you can even use Identify on it and get a good result. The second pattern, despite the rule and initial pattern being "the same", collides with the same "floor" and "ceiling" from the selection issue, and quickly becomes asymmetric and highly chaotic. It only expands past these boundaries around 800 generations in. The third pattern, like the first, does not hit those invisible boundaries. However, when cells are killed at the edge of the grid, it happens in a less symmetric fashion than the first pattern, meaning that it cannot be identified as an oscillator. It'd be expected that the second and third patterns would behave identically to the first when running them, to the point where identification is possible.
Finally, there seem to be some minor issues with Undo at considerable distances. In the following pattern, try drawing something small and regular such as a 2x2 block centered at the intersection of the two major grid lines. If we then immediately press the Undo button, only three of the four cells will be cleared, and the first one created by drawing persists. If, instead of immediately pressing Undo, we step forward one generation, then either step back to T=0 or use the undo button, three out of the four cells will remain, with only the first drawn cell being absent from its initial position. In fact, this first cell seems to have been shifted down considerably for some reason (it can be easily located via Select All).
Code: Select all
x = 1, y = 1, rule = B1357/S1357
!
[[ MAXGRIDSIZE 9 GRID X -250 Y -250 ]]
----
Off of the topic of unloaded chunks but still on the topic of boundaries: for this pattern, if we click inside of the bounded grid to draw, and then drag the cursor outside of the bounded grid, cells will be drawn at the farthest possible point which is inside of the bounded grid, as expected. However, while still holding down the mouse button, if we drag the cursor so that it's outside of the "unbounded boundary" of gray cells (i.e. where one of the coordinates seem in the bottom left is further from the origin than -256) then drawing will stop happening until the cursor goes back into the "black" regions.
Code: Select all
x = 1, y = 1, rule = B/S012345678:P480
!
[[ MAXGRIDSIZE 9 GRID ZOOM 8 X -240 Y -240 ]]
I'd also like to point out that if we click inside of the black region that's outside of the bounded grid but still within bounds, cells are immediately drawn at the edge of the bounded grid. I think that cells should only be drawn if the click begins within the bounded grid, much like how you can only create a selection if the click begins inside the bounded grid (but you can still drag the cursor out while the click is being held).
