Pattern viewer for forum threads

For discussion directly related to ConwayLife.com, such as requesting changes to how the forums or home page function.
User avatar
rowett
Moderator
Posts: 3776
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: Pattern viewer for forum threads

Post by rowett » April 19th, 2021, 10:59 am

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.
It's because those patterns both use a lot of memory and the mobile devices typically don't have enough.

User avatar
muzik
Posts: 5612
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Pattern viewer for forum threads

Post by muzik » April 19th, 2021, 9:17 pm

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

User avatar
muzik
Posts: 5612
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Pattern viewer for forum threads

Post by muzik » April 19th, 2021, 10:12 pm

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.

User avatar
bubblegum
Posts: 959
Joined: August 25th, 2019, 11:59 pm
Location: click here to do nothing

Re: Pattern viewer for forum threads

Post by bubblegum » April 19th, 2021, 11:25 pm

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
sonata wrote:
July 2nd, 2020, 8:33 pm
conwaylife signatures are amazing[citation needed]
anything

User avatar
rowett
Moderator
Posts: 3776
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: Pattern viewer for forum threads

Post by rowett » April 20th, 2021, 12:46 am

muzik wrote:
April 19th, 2021, 10:12 pm
This post seems to cause lifeviewer to suffer a nasty crash before 300 generations when Identify is used
Fixed. Thanks for reporting!

User avatar
muzik
Posts: 5612
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Pattern viewer for forum threads

Post by muzik » April 20th, 2021, 6:19 am

rowett wrote:
April 20th, 2021, 12:46 am
muzik wrote:
April 19th, 2021, 10:12 pm
This post seems to cause lifeviewer to suffer a nasty crash before 300 generations when Identify is used
Fixed. Thanks for reporting!
And once more thank you for your continued updates to LifeViewer!
rowett wrote:
March 30th, 2021, 4:37 pm
muzik wrote:
March 30th, 2021, 2:47 pm
And a newly discovered bug: using the select function and dragging the cursor out of the viewer window with it active doesn't cancel the selection properly, and you need to click back in the window to conclude it.
I'm quite happy with the current behaviour. It used to annoy me if I accidentally went slightly out of the window and it cancelled the selection.
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.

User avatar
muzik
Posts: 5612
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Pattern viewer for forum threads

Post by muzik » April 20th, 2021, 6:46 am

Code: Select all

x = 6, y = 7, rule = PCA_4
5.H3$H.L.D3$5.B!
Identify on this gives both a period and mod of 67292. However, running this to generation 16823 (67292/4) and rotating it accordingly gives a figure identical to the starting one. This also works for 33646 (67292/2) and 50469 (3(67292)/2), so the expected mod here would be 16823.

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?

User avatar
muzik
Posts: 5612
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Pattern viewer for forum threads

Post by muzik » April 20th, 2021, 8:22 am

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:

Code: Select all

x = 3, y = 4, rule = B3aijr4ciq7c/S2-i3-a4i5q
o$2o$b2o$2o!
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.
Image

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.

User avatar
dvgrn
Moderator
Posts: 10610
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: Pattern viewer for forum threads

Post by dvgrn » April 20th, 2021, 12:20 pm

muzik wrote:
April 20th, 2021, 8:22 am
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.
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?

User avatar
muzik
Posts: 5612
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Pattern viewer for forum threads

Post by muzik » April 20th, 2021, 12:36 pm

dvgrn wrote:
April 20th, 2021, 12:20 pm
muzik wrote:
April 20th, 2021, 8:22 am
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.
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 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?

----
muzik wrote:
April 18th, 2021, 5:02 pm
There 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
After some more in depth testing to get every single button I could think of these do seem to be the only ones.

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.

User avatar
dvgrn
Moderator
Posts: 10610
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: Pattern viewer for forum threads

Post by dvgrn » April 20th, 2021, 5:45 pm

muzik wrote:
April 20th, 2021, 12:36 pm
Does this one work?
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. (?)

User avatar
muzik
Posts: 5612
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Pattern viewer for forum threads

Post by muzik » April 20th, 2021, 5:47 pm

dvgrn wrote:
April 20th, 2021, 5:45 pm
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. (?)
I consider the resultant throttling to me a major annoyance - and its tendency to show up completely randomly certainly contributes to that factor.

User avatar
muzik
Posts: 5612
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Pattern viewer for forum threads

Post by muzik » April 21st, 2021, 2:50 pm

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:

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 ]]
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?

User avatar
muzik
Posts: 5612
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Pattern viewer for forum threads

Post by muzik » April 21st, 2021, 9:17 pm

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.

User avatar
yujh
Posts: 3066
Joined: February 27th, 2020, 11:23 pm
Location: I'm not sure where I am, so please tell me if you know
Contact:

Re: Pattern viewer for forum threads

Post by yujh » April 22nd, 2021, 6:05 am

muzik wrote:
April 21st, 2021, 9:17 pm
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.
Is 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!
Rule modifier

B34kz5e7c8/S23-a4ityz5k
b2n3-q5y6cn7s23-k4c8
B3-kq6cn8/S2-i3-a4ciyz8
B3-kq4z5e7c8/S2-ci3-a4ciq5ek6eik7

Bored of Conway's Game of Life? Try Pedestrian Life -- not pedestrian at all!

User avatar
dvgrn
Moderator
Posts: 10610
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: Pattern viewer for forum threads

Post by dvgrn » April 22nd, 2021, 6:32 am

yujh wrote:
April 22nd, 2021, 6:05 am
muzik wrote:
April 21st, 2021, 9:17 pm
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.
Is 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!
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.

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

Re: Pattern viewer for forum threads

Post by GUYTU6J » April 22nd, 2021, 7:31 am

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.

User avatar
rowett
Moderator
Posts: 3776
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: Pattern viewer for forum threads

Post by rowett » April 22nd, 2021, 12:13 pm

GUYTU6J wrote:
April 22nd, 2021, 7:31 am
What's the difference between https://lazyslug.com/lifeview/ and https://lazyslug.com/lifeviewer/? Can the former be updated?
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.

The second link is a full-size version of the plugin, also available at https://lazyslug.com/.
GUYTU6J wrote:
April 22nd, 2021, 7:31 am
Also, the INT Moore alias "Einstein" has something wrong with it.
Thanks, fixed in the next release!

User avatar
rowett
Moderator
Posts: 3776
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: Pattern viewer for forum threads

Post by rowett » April 22nd, 2021, 12:14 pm

dvgrn wrote:
April 22nd, 2021, 6:32 am
yujh wrote:
April 22nd, 2021, 6:05 am
Is 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!
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.
No it's not. So LifeViewer attempts to fetch it from the LifeWiki Rule namespace. It doesn't exist there either.

User avatar
rowett
Moderator
Posts: 3776
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: Pattern viewer for forum threads

Post by rowett » April 22nd, 2021, 12:22 pm

muzik wrote:
April 21st, 2021, 9:17 pm
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.
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.

User avatar
muzik
Posts: 5612
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Pattern viewer for forum threads

Post by muzik » April 22nd, 2021, 1:41 pm

yujh wrote:
April 22nd, 2021, 6:05 am
Is 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!
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)

User avatar
muzik
Posts: 5612
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Pattern viewer for forum threads

Post by muzik » April 22nd, 2021, 1:51 pm

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:
Image

User avatar
muzik
Posts: 5612
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Pattern viewer for forum threads

Post by muzik » April 22nd, 2021, 7:17 pm

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.

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 ]]
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:

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!
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.

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 ]]
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:

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!
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:

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 ]]
Through applying the "overlay" or "ray-casting" definitions, these six directions would be considered Orthogonal:

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 ]]
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:

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 ]]
Through interpolation or applying the "overlay" or "ray-casting" definitions, these six directions would be considered Diagonal:

Code: Select all

x = 14, y = 12, rule = B19y/SL
2$6bobo$2bo9bo$bo11bo3$bo11bo$2bo9bo$6bobo!
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).
Last edited by muzik on May 9th, 2021, 3:58 am, edited 4 times in total.

User avatar
muzik
Posts: 5612
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Pattern viewer for forum threads

Post by muzik » April 22nd, 2021, 7:44 pm

...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:

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 ]]
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)

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 ]]
(also note the slight difference in starting position with X 0 and X undefined)

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 ]]
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?

User avatar
muzik
Posts: 5612
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Pattern viewer for forum threads

Post by muzik » April 23rd, 2021, 6:18 am

Code: Select all

x = 10, y = 8, rule = none
3.G.C$2.HJDEBA$.I3J2EBA$.JMOMHG2BA$K2MPGAEBA$.L2.O3A$O$.P!
- Is the "none" rule supposed to be playable?
- 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.

Post Reply