It's because those patterns both use a lot of memory and the mobile devices typically don't have enough.muzik wrote: ↑April 19th, 2021, 7:09 am- There's a pretty serious lag that can be experienced when switching from one LifeViewer window to another on LTL rules. Open the first viewer code box, press play, wait for about 80 generations and then click Show in Viewer on the second: (not sure if this lag is device specific)

It takes about three seconds for the old window to close and the new one to show up on my end.

In addition, the reset button especially on the bottom viewer takes longer than expected to rewind the pattern to generation 0.

Closing one of these viewer windows and then clicking Show in Viewer yet again causes the viewer to take longer than it should to show up.

## Pattern viewer for forum threads

### Re: Pattern viewer for forum threads

LifeViewer https://lazyslug.com/lifeviewer

### Re: Pattern viewer for forum threads

Can "Fast Identify" (CtrlF6) and the advance functions (functionSpace) be given in-viewer buttons?

Help wanted: How can we accurately notate any 1D replicator?

### Re: Pattern viewer for forum threads

This post seems to cause lifeviewer to suffer a nasty crash before 300 generations when Identify is used specifically from before 300 generations:

viewtopic.php?f=11&t=5093#p127616

Running it for 1000 generations and then using Identify works fine.

viewtopic.php?f=11&t=5093#p127616

Running it for 1000 generations and then using Identify works fine.

Help wanted: How can we accurately notate any 1D replicator?

### Re: Pattern viewer for forum threads

Speaking of Identify, it appears that Ctrl+F6 sets the identify mode to fast permanently (AKA until the viewer is closed).

Each day is a hidden opportunity, a frozen waterfall that's waiting to be realised, and one that I'll probably be ignoring

anythingsonata wrote:July 2nd, 2020, 8:33 pmconwaylife signatures are amazing[citation needed]

### Re: Pattern viewer for forum threads

Fixed. Thanks for reporting!

LifeViewer https://lazyslug.com/lifeviewer

### Re: Pattern viewer for forum threads

And once more thank you for your continued updates to LifeViewer!

Perhaps this could be made an option of some sort much like smart draw? By default it would use the current behaviour, but if turned off selections would be cancelled in such cases.

Help wanted: How can we accurately notate any 1D replicator?

### Re: Pattern viewer for forum threads

Code: Select all

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

While doing this, I also noticed the Select All function seems to count dead history states as well (inconsistently - it might only happen after the initial pattern is rotated), which is inconsistent with almost all other rule families. (Verifying this claim I noticed that historical cells are ignored in [R]History but not in [R]Super, not sure if intended but definitely not consistent.)

For testing things like this in future, perhaps an in-viewer "run up to generation and then pause" function (analogous to the PAUSE script function) could be added?

Help wanted: How can we accurately notate any 1D replicator?

### Re: Pattern viewer for forum threads

I may have finally stumbled upon a way to activate the random occurrences of Slo Mo Blue Box syndrome with the popup viewer. While the results are nowhere near consistent, with a bit of luck and the appropiate hardware (dvgrn might be able to reproduce this) it should take less than a minute for it to happen.

1. Open up a viewer popup window:
2. Using two digits, continually tap on the viewer window, then somewhere on the page that isn't the viewer window. After a truly undeterminable but hopefully reasonable amount of taps have been made (usually less than two hundred) the blue icy box should end up surrounding the viewer. Feel free to scroll through the page and get creative with whatever pattern of taps you desire if it takes too long.

Of course, since this isn't very consistent at all, finding the root cause of this and eliminating it for good seems like a quite daunting task, but the fact that I can basically guarantee it happens at all with a setup like this should be something. Perhaps more helpful to this case is the fact that appearances of the Slow Mo Blue Box are always accompanied by the "Click to control" text.

1. Open up a viewer popup window:

Code: Select all

```
x = 3, y = 4, rule = B3aijr4ciq7c/S2-i3-a4i5q
o$2o$b2o$2o!
```

Of course, since this isn't very consistent at all, finding the root cause of this and eliminating it for good seems like a quite daunting task, but the fact that I can basically guarantee it happens at all with a setup like this should be something. Perhaps more helpful to this case is the fact that appearances of the Slow Mo Blue Box are always accompanied by the "Click to control" text.

Help wanted: How can we accurately notate any 1D replicator?

### Re: Pattern viewer for forum threads

Unfortunately, I've followed these instructions for somewhere between five and ten minutes on an iPad, without seeing the unwanted icy blue selection box appear.

I have seen some other slightly strange behavior, though. When I use the two-finger "pinch" action on this forum thread page in the browser (outside of the LifeViewer frame, I can eventually get a very zoomed-in view of the page. When I zoom out again (again with two fingers) sometimes the LifeViewer pane ends up a radically different size -- mostly very small. Sometimes it eventually snaps back to standard size again, but usually it's stuck at its small size.

Is there any hope of getting the "pinch" and "stretch" two-finger actions to work in LifeViewer, along with the zoom bar at the top?

### Re: Pattern viewer for forum threads

I believe I may have found a much more reliable method of getting it to show up (although I'm not sure if it's the same event and that fixing this will fix the other one) - click the show in viewer link, and then click the area where the viewer shows up straight after, just before it shows up, for what may be an almost guaranteed, instant blue box.

For me there's about a third of a second delay between clicking the link and the viewer window actually showing up, so this should be enough time to trigger it. Hopefully this doesn't rely on the device being sufficiently low end and laggy to pull off.

(speculation:) I now believe that this bug happens because the web page assumes that the "cursor" is at that point. Moving the cursor over an existing viewer window is probably handled specially so the viewer actually works, but in that split second before the viewer appears, tapping moves the cursor to the viewer region just before it shows up, and then the viewer ends up being highlighted due to the cursor being there but not handled as expected. Quick tapping could also potentially be a point of confusion and cause the effect as well, and from my understanding of how sync and save works the cursor is moved out of the viewer and back again, but again improperly.

Does this one work?

----

After some more in depth testing to get every single button I could think of these do seem to be the only ones.muzik wrote: ↑April 18th, 2021, 5:02 pmThere are a couple of other buttons and sliders that appear to have no associated keybinds. I'm not sure if all of these should get them though, so these are your decision. There are still some buttons yet to be tested.

- Random fill density

- Clipboard library

- Clipboard library buttons

- Settings buttons

- Help sections

- Themes

- Back/close buttons e.g. for settings

On the topic of buttons, I've noticed the reset button is always white, even though there are cases where it doesn't do anything, and would be expected to be gray much like the step back button.

Alt GridLines also appears to be permanently set to on for hexagonal rules.

And on the topic of gray buttons - could the reverse playback, 2-state fill and clear [R]History/Super cells be made to be always present and grayed out for rules they don't apply to, rather than just not appearing at all, as to be more consistent with other buttons?

Last edited by muzik on April 22nd, 2021, 1:56 pm, edited 1 time in total.

Help wanted: How can we accurately notate any 1D replicator?

### Re: Pattern viewer for forum threads

Yup, I can get the icy blue ring to appear around LifeViewer with that trick.

I'm not sure this even counts as a bug any more, though, since you have to work so hard to make it appear, and LifeViewer still seems perfectly functional even after it has appeared. (?)

### Re: Pattern viewer for forum threads

I consider the resultant throttling to me a major annoyance - and its tendency to show up completely randomly certainly contributes to that factor.

Help wanted: How can we accurately notate any 1D replicator?

### Re: Pattern viewer for forum threads

When moving forward purely by using the step forward button, natural deaths or all cells show the message as expected, but those resulting from KILLGLIDERS do not:

The play button causes it to show up for both, although one generation later for the latter, which is very likely the cause of this.

EDIT: I've also noticed that the values in the T menu don't account for it properly either, so perhaps due to there being a nonzero amount of births it assumes the pattern can't have died out?

Code: Select all

```
x = 31, y = 32, rule = B3/S23
2o$2o$o27$29b2o$29b2o$29bo!
[[ KILLGLIDERS ]]
```

Code: Select all

```
x = 31, y = 32, rule = B3/S23
2o$2o$o12$12bo$10bobo$11b2o13$29b2o$29b2o$29bo!
[[ KILLGLIDERS ]]
```

EDIT: I've also noticed that the values in the T menu don't account for it properly either, so perhaps due to there being a nonzero amount of births it assumes the pattern can't have died out?

Help wanted: How can we accurately notate any 1D replicator?

### Re: Pattern viewer for forum threads

The Select All button does not appear to work in invalid rules even though manual selection does:

https://catagolue.hatsya.com/object/xp4 ... 4s12d0-1-1

Also, closing the popup viewer here and reopening it causes it to appear empty for about a second, but this is probably a mobile memory issue.

https://catagolue.hatsya.com/object/xp4 ... 4s12d0-1-1

Also, closing the popup viewer here and reopening it causes it to appear empty for about a second, but this is probably a mobile memory issue.

Help wanted: How can we accurately notate any 1D replicator?

### Re: Pattern viewer for forum threads

Is this rule supported by lifeviewer?muzik wrote: ↑April 21st, 2021, 9:17 pmThe Select All button does not appear to work in invalid rules even though manual selection does:

https://catagolue.hatsya.com/object/xp4 ... 4s12d0-1-1

Also, closing the popup viewer here and reopening it causes it to appear empty for about a second, but this is probably a mobile memory issue.

Code: Select all

```
x = 6, y = 8, rule = B34/S12d0-1-1
.B$.BA$2.A$2BA3$5.B$3.3B!
```

B34kz5e7c8/S23-a4ityz5k!!!

b2n3-q5y6cn7s23-k4c8

B3-kq6cn8/S2-i3-a4ciyz8

wiki

Bored. Will do LaundryPizza03.

b2n3-q5y6cn7s23-k4c8

B3-kq6cn8/S2-i3-a4ciyz8

wiki

Bored. Will do LaundryPizza03.

### Re: Pattern viewer for forum threads

Apparently not, since it isn't providing a "Show in viewer" link. What does the "d0-1-1" mean? I don't recognize it, and Golly doesn't support it either.yujh wrote: ↑April 22nd, 2021, 6:05 amIs this rule supported by lifeviewer?muzik wrote: ↑April 21st, 2021, 9:17 pmThe Select All button does not appear to work in invalid rules even though manual selection does:

https://catagolue.hatsya.com/object/xp4 ... 4s12d0-1-1

Also, closing the popup viewer here and reopening it causes it to appear empty for about a second, but this is probably a mobile memory issue.Code: Select all

`x = 6, y = 8, rule = B34/S12d0-1-1 .B$.BA$2.A$2BA3$5.B$3.3B!`

- GUYTU6J
**Posts:**1372**Joined:**August 5th, 2016, 10:27 am**Location:**拆哪！I repeat, CHINA! (a.k.a. 种花家)-
**Contact:**

### Re: Pattern viewer for forum threads

What's the difference between https://lazyslug.com/lifeview/ and https://lazyslug.com/lifeviewer/? Can the former be updated?

Also, the INT Moore alias "Einstein" has something wrong with it.

Also, the INT Moore alias "Einstein" has something wrong with it.

Lifequote:

Stop Japan from dumping nuclear waste!

I'm afraid there's arrival but no departure.In the drama The Peony Pavilion, Tang Xianzu wrote: 原来姹紫嫣红开遍，似这般都付与断井颓垣。

(Here multiflorate splendour blooms forlorn

Midst broken fountains, mouldering walls.)

Stop Japan from dumping nuclear waste!

### Re: Pattern viewer for forum threads

The first link is the original project I did many years ago to learn Javascript. I announced it on the forums and met dvgrn who suggested it could evolve into a plugin that could be used on the forum which you see now. I haven't touched it for many years and it won't be udpated.GUYTU6J wrote: ↑April 22nd, 2021, 7:31 amWhat's the difference between https://lazyslug.com/lifeview/ and https://lazyslug.com/lifeviewer/? Can the former be updated?

The second link is a full-size version of the plugin, also available at https://lazyslug.com/.

Thanks, fixed in the next release!

LifeViewer https://lazyslug.com/lifeviewer

### Re: Pattern viewer for forum threads

No it's not. So LifeViewer attempts to fetch it from the LifeWiki Rule namespace. It doesn't exist there either.dvgrn wrote: ↑April 22nd, 2021, 6:32 amApparently not, since it isn't providing a "Show in viewer" link. What does the "d0-1-1" mean? I don't recognize it, and Golly doesn't support it either.yujh wrote: ↑April 22nd, 2021, 6:05 amIs this rule supported by lifeviewer?Code: Select all

`x = 6, y = 8, rule = B34/S12d0-1-1 .B$.BA$2.A$2BA3$5.B$3.3B!`

LifeViewer https://lazyslug.com/lifeviewer

### Re: Pattern viewer for forum threads

It's because the pattern contains a rule that is not built in. The delay is LifeViewer attempting to download the rule definition from the LifeWiki Rule namespace.

LifeViewer https://lazyslug.com/lifeviewer

### Re: Pattern viewer for forum threads

The rule is supposed to be an Extended Generations rule, a family which isn't natively supported (although the fact that the rulestring isn't correct converted isn't exactly helping matters: https://gitlab.com/apgoucher/catagolue/-/issues/13)yujh wrote: ↑April 22nd, 2021, 6:05 amIs this rule supported by lifeviewer?Code: Select all

`x = 6, y = 8, rule = B34/S12d0-1-1 .B$.BA$2.A$2BA3$5.B$3.3B!`

Help wanted: How can we accurately notate any 1D replicator?

### Re: Pattern viewer for forum threads

Here's another example of a long-standing bug that affects the viewer. This is another case which I can't seem to get to happen consistently, but the most important part is that it does indeed seem to affect desktop platforms as well. Discussion over in the discord reveals that there are others who have encountered this same bug.

Specifically, this is the issue where clicking on a button in the viewer can occasionally not cause the button press to be registered until clicking on somewhere in the viewer again. If that click happens on the same button, it will register as the button having been pressed twice.

A bug which may have the exact same cause as this occurs when using the Select function, where releasing the mouse/tap will cause the selection box to stay as expected, but none of the relevant buttons for manipulating the selection will show up. This should probably happen eventually if you use the select tool and just drag and release it for a minute or two (would encourage others here to try this and post their results to confirm this).

Here's a screenshot of the bug in action - nothing was touching the screen when it was taken:

Specifically, this is the issue where clicking on a button in the viewer can occasionally not cause the button press to be registered until clicking on somewhere in the viewer again. If that click happens on the same button, it will register as the button having been pressed twice.

A bug which may have the exact same cause as this occurs when using the Select function, where releasing the mouse/tap will cause the selection box to stay as expected, but none of the relevant buttons for manipulating the selection will show up. This should probably happen eventually if you use the select tool and just drag and release it for a minute or two (would encourage others here to try this and post their results to confirm this).

Here's a screenshot of the bug in action - nothing was touching the screen when it was taken:

Help wanted: How can we accurately notate any 1D replicator?

### Re: Pattern viewer for forum threads

While rotations and mod calculation and such for hex and triangular grids are nowhere near priority at this point, implementing direction calculation for Identify should be a pretty simple task.

Here's a relatively in-depth examination of how directions can be defined for said grids (which should also double as an effective explanation for anyone who wants to understand how directions are defined and can be identified for hexagonal and triangular grids), as well as example spaceships travelling in said directions, and their displacements on a square grid, such that those can be used for calculating the directions in these cases:

----

Hexagonal Grids

Unlike the square grid which has four orthogonal and four diagonal directions, the hexagonal grid has six orthogonal and six diagonal directions.

----

Orthogonal

We define the orthogonal direction through an analogy with the square grid. Starting from the center of a hexagon, an infinite ray drawn in one of these directions will always intersect the edges of the grid at their very centers, and will never intersect a vertex.
For sufficiently non-chaotic ships such as the one shown in the below example, their direction can be found to be orthogonal by examining the history trail - a gentle 120-degree zigzag with two different directions indicates an orthogonal ship.

By the prior definition, the following six directions would be considered Orthogonal:

On a square grid, these are reported as (1,0), (1,1), (0,-1), (-1,0), (-1,-1) and (0,1).

----

Diagonal

While it can be clearly seen that the diagonal direction would by definition be exactly halfway between two given orthogonal directions, we can again define the diagonal direction through the same method as was used previously: an infinite ray traced from the center of a cell out to infinity in one of these directions will always intersect the two opposite vertices of every cell it visits.
For sufficiently non-chaotic ships such as the one shown below, their direction can be found to be diagonal by examining the history trail - a more dramatic boundary with three different directions and "period" of 4 indicates a diagonal ship.

The following six directions would, via the definition provided at the top, be considered Diagonal:

On a square grid, these are reported as (1,-1), (2,1), (1,2), (-1,1), (-2,-1) and (-1,-2).

----

Hexagonal Conclusion

As a result, for hexagonal grids, using square grid coordinates, for any integer n:

- spaceships travelling with a displacement of (n,0), (n,n), (0,-n), (-n,0), (-n,-n) or (0,n) should be reported as travelling orthogonally,

- spaceships travelling with a displacement of (n,-n), (2n,n), (n,2n), (-n,n), (-2n,-n) or (-n,-2n) should be reported as travelling diagonally

- and spaceships travelling in a direction that does not fit any of these criteria should be considered as travelling oblique.

Triangular Grids

For triangular rules, we can also define directions. As LifeViewer displays hexagonal and triangular grids in positions where they form a geometrical dual compound when superimposed, it is advisable to define triangular grid directions by what the hexagonal grid directions correspond to were they superimposed on the triangular grid. Conveniently, the definitions this approach yields also appear to match up with the ray-casting definitions defined earlier.

As the behaviour of handling triangular rules on a square grid is considerably different from hexagonal, the square-grid displacements and what they correspond to on the triangular grid will also differ.

Again, the triangular grid has six each of orthogonal and diagonal directions.

----

Orthogonal

Through the ray-casting approach, this would be the Orthogonal direction:
Through applying the "overlay" or "ray-casting" definitions, these six directions would be considered Orthogonal:
On a square grid, these displacements correspond to (1,-1), (2,0), (1,1), (-1,1), (-2,0) and (-1,-1).

----

Diagonal

Barring extrapolation/interpolation from the orthogonal directions, the raycasting definition shows this to be our diagonal direction:
Through interpolation or applying the "overlay" or "ray-casting" definitions, these six directions would be considered Diagonal:
On a square grid, these displacements (for these period 2 ships specifically - I know of no period 1 spaceships that travel in this direction, and doubt they can exist) correspond to (0,-2), (3,-1), (3,1), (0,2), (-3,1) and (-3,-1).

----

Triangular Conclusion

As a result, for hexagonal grids, using square grid coordinates, for any integer n:

- spaceships travelling with a displacement of (n,-n), (2n,0), (n,n), (-n,n), (-2n,0) or (-n,-n) should be reported as travelling orthogonally,

- spaceships travelling with a displacement of (0,-2n), (3n,-n), (3n,n), (0,2n), (-3n,n) or (-3n,-n) should be reported as travelling diagonally

- and spaceships travelling in a direction that does not fit any of these criteria should be considered as travelling oblique.

----

The displacement shown at the top of Identify still currently uses the square grid format, which of course doesn't make any sense in cases such as these. However, I'd say it should be kept until further support for hexagonal and triangular grids is supported, at which point basically all coordinate values that users can see may be hexagon/triangle-specific (perhaps something like this).

Here's a relatively in-depth examination of how directions can be defined for said grids (which should also double as an effective explanation for anyone who wants to understand how directions are defined and can be identified for hexagonal and triangular grids), as well as example spaceships travelling in said directions, and their displacements on a square grid, such that those can be used for calculating the directions in these cases:

----

Hexagonal Grids

Unlike the square grid which has four orthogonal and four diagonal directions, the hexagonal grid has six orthogonal and six diagonal directions.

----

Orthogonal

We define the orthogonal direction through an analogy with the square grid. Starting from the center of a hexagon, an infinite ray drawn in one of these directions will always intersect the edges of the grid at their very centers, and will never intersect a vertex.

Code: Select all

```
x = 1, y = 1, rule = B/S
o!
[[ VIEWONLY X 15 ZOOM 16 GRID GRIDMAJOR 0 THEME 6 COLOR ARROW 0 192 0 ARROW 0 0 32 0 10 ]]
```

Code: Select all

```
x = 1, y = 1, rule = B/SH
o!
[[ VIEWONLY X 15 ZOOM 16 GRID GRIDMAJOR 0 THEME 6 COLOR ARROW 0 192 0 ARROW 0 0 32 0 10 ]]
```

By the prior definition, the following six directions would be considered Orthogonal:

Code: Select all

```
x = 25, y = 25, rule = B2/S3H
3bo5bo$b2o8b2o$bo3bo3bo3bo$o2bo8bo2bo$5b2o3b2o$2bobo8bobo$4bo9bo3$obo
16bobo$4bo13bo$bo2bo14bo2bo$bobo17bobo$2bo2bo14bo2bo$6bo13bo$3bobo16bo
bo3$10bo9bo$9bobo8bobo$13b2o3b2o$9bo2bo8bo2bo$11bo3bo3bo3bo$12b2o8b2o$
15bo5bo!
```

----

Diagonal

While it can be clearly seen that the diagonal direction would by definition be exactly halfway between two given orthogonal directions, we can again define the diagonal direction through the same method as was used previously: an infinite ray traced from the center of a cell out to infinity in one of these directions will always intersect the two opposite vertices of every cell it visits.

Code: Select all

```
x = 1, y = 1, rule = B/S
o!
[[ VIEWONLY X 15 Y -15 ZOOM 16 GRID GRIDMAJOR 0 THEME 6 COLOR ARROW 0 192 0 ARROW 0 0 32 -32 10 ]]
```

Code: Select all

```
x = 1, y = 1, rule = B/SH
o!
[[ VIEWONLY X 15 Y -10 ZOOM 16 GRID GRIDMAJOR 0 THEME 6 COLOR ARROW 0 192 0 ARROW 0 0 20 -20 10 ]]
```

The following six directions would, via the definition provided at the top, be considered Diagonal:

Code: Select all

```
x = 34, y = 36, rule = B2/S2H
4$9bo$9b2o$10bo2$9bobobo2$3b2o2bo9bo2b2o$4b2o14b2o$7bo11bo2$7bo13bo4$
9bo13bo2$11bo11bo$9b2o14b2o$9b2o2bo9bo2b2o2$17bobobo2$20bo$20b2o$21bo!
```

----

Hexagonal Conclusion

As a result, for hexagonal grids, using square grid coordinates, for any integer n:

- spaceships travelling with a displacement of (n,0), (n,n), (0,-n), (-n,0), (-n,-n) or (0,n) should be reported as travelling orthogonally,

- spaceships travelling with a displacement of (n,-n), (2n,n), (n,2n), (-n,n), (-2n,-n) or (-n,-2n) should be reported as travelling diagonally

- and spaceships travelling in a direction that does not fit any of these criteria should be considered as travelling oblique.

Triangular Grids

For triangular rules, we can also define directions. As LifeViewer displays hexagonal and triangular grids in positions where they form a geometrical dual compound when superimposed, it is advisable to define triangular grid directions by what the hexagonal grid directions correspond to were they superimposed on the triangular grid. Conveniently, the definitions this approach yields also appear to match up with the ray-casting definitions defined earlier.

As the behaviour of handling triangular rules on a square grid is considerably different from hexagonal, the square-grid displacements and what they correspond to on the triangular grid will also differ.

Again, the triangular grid has six each of orthogonal and diagonal directions.

----

Orthogonal

Through the ray-casting approach, this would be the Orthogonal direction:

Code: Select all

```
x = 1, y = 1, rule = B/S
o!
[[ VIEWONLY X 15 ZOOM 16 GRID GRIDMAJOR 0 THEME 6 COLOR ARROW 0 192 0 ARROW 0 0 32 0 10 ]]
```

Code: Select all

```
x = 1, y = 1, rule = B/SL
o!
[[ VIEWONLY X 15 ZOOM 16 GRID GRIDMAJOR 0 THEME 6 COLOR ARROW 0 192 0 ARROW 0 0 32 0 10 ]]
```

Code: Select all

```
x = 12, y = 9, rule = 369/25/3LV
$6.B$3.2A.B.2A$.2B.2B.2B.2B$.A.B5.B.A$.A.B5.B.A$.2B.2B.2B.2B$3.2A.B.2A
$6.B!
[[ THEME Blues ]]
```

----

Diagonal

Barring extrapolation/interpolation from the orthogonal directions, the raycasting definition shows this to be our diagonal direction:

Code: Select all

```
x = 1, y = 1, rule = B/S
o!
[[ VIEWONLY X 15 Y -15 ZOOM 16 GRID GRIDMAJOR 0 THEME 6 COLOR ARROW 0 192 0 ARROW 0 0 32 -32 10 ]]
```

Code: Select all

```
x = 1, y = 1, rule = B/SL
o!
[[ VIEWONLY X 10 Y -5 ZOOM 16 GRID GRIDMAJOR 0 THEME 6 COLOR ARROW 0 192 0 ARROW -0.25 -0.25 24.5 -8.5 10 ]]
```

Code: Select all

```
x = 14, y = 12, rule = B19y/SL
2$6bobo$2bo9bo$bo11bo3$bo11bo$2bo9bo$6bobo!
```

----

Triangular Conclusion

As a result, for hexagonal grids, using square grid coordinates, for any integer n:

- spaceships travelling with a displacement of (n,-n), (2n,0), (n,n), (-n,n), (-2n,0) or (-n,-n) should be reported as travelling orthogonally,

- spaceships travelling with a displacement of (0,-2n), (3n,-n), (3n,n), (0,2n), (-3n,n) or (-3n,-n) should be reported as travelling diagonally

- and spaceships travelling in a direction that does not fit any of these criteria should be considered as travelling oblique.

----

The displacement shown at the top of Identify still currently uses the square grid format, which of course doesn't make any sense in cases such as these. However, I'd say it should be kept until further support for hexagonal and triangular grids is supported, at which point basically all coordinate values that users can see may be hexagon/triangle-specific (perhaps something like this).

Last edited by muzik on May 9th, 2021, 3:58 am, edited 4 times in total.

Help wanted: How can we accurately notate any 1D replicator?

### Re: Pattern viewer for forum threads

...and while setting up a visual example for the above post I seem to have come across a bug where hexagonal patterns are loaded at completely unexpected position:

It appears that X, if defined at all, sets the focus to be 128 away from the origin, then adding the X definition: (EDIT: further testing with Y seems to imply a bug arising from the visual transform to hexagons)
(also note the slight difference in starting position with X 0 and X undefined)

This does not affect triangular grids:
Could VIEWONLY be made to make all buttons gray rather than displaying "VIEWONLY", as to be consistent with NOSTEPBACK? And could VIEWONLY also be made to not disable the T menu, as to allow the number of cells to be seen?

Code: Select all

```
x = 1, y = 1, rule = B/S
o!
[[ VIEWONLY X 15 ZOOM 16 GRID GRIDMAJOR 0 THEME 6 COLOR ARROW 0 192 0 ARROW 0 0 32 0 10 ]]
```

Code: Select all

```
x = 1, y = 1, rule = B/SH
o!
[[ VIEWONLY X 15 ZOOM 16 GRID GRIDMAJOR 0 THEME 6 COLOR ARROW 0 192 0 ARROW 0 0 32 0 10 ]]
```

Code: Select all

```
x = 1, y = 1, rule = B/S
o!
```

Code: Select all

```
x = 1, y = 1, rule = B/S
o!
[[ X 15 ]]
```

Code: Select all

```
x = 1, y = 1, rule = B/S
o!
[[ X 0 ]]
```

Code: Select all

```
x = 1, y = 1, rule = B/SH
o!
```

Code: Select all

```
x = 1, y = 1, rule = B/SH
o!
[[ X 15 ]]
```

Code: Select all

```
x = 1, y = 1, rule = B/SH
o!
[[ X 0 ]]
```

This does not affect triangular grids:

Code: Select all

```
x = 1, y = 1, rule = B/SL
o!
```

Code: Select all

```
x = 1, y = 1, rule = B/SL
o!
[[ X 15 ]]
```

Code: Select all

```
x = 1, y = 1, rule = B/SL
o!
[[ X 0 ]]
```

Help wanted: How can we accurately notate any 1D replicator?

### Re: Pattern viewer for forum threads

Code: Select all

```
x = 10, y = 8, rule = none
3.G.C$2.HJDEBA$.I3J2EBA$.JMOMHG2BA$K2MPGAEBA$.L2.O3A$O$.P!
```

- Is drawing supposed to be disabled for it? I see no reason why it should be since select support is still allowed and permits changes to the pattern.

- When the select option is used, there's an empty space where the "2-state fill" button should be, which is inconsistent with how it's absent for 2-state rules. This inconsistency should probably be fixed - I'd prefer for it to be present but grayed out for both the none and 2-state cases.

Help wanted: How can we accurately notate any 1D replicator?