Life tag testing

[rowett]

OK thanks.

There are currently a couple of limitiations:

1. It only calculates as you drag the selection box. If you then advance the pattern it doesn't update.
2. It limits calculation time to a few ms to prevent slow down while selecting. If it takes too long to calculate the selection population it bails and just doesn't show the population data.

EDIT: I've fixed limitation 1 above. It now displays selection population while there is a selection unless the pattern is generating.

[dvgrn]

Ran into a PASTET limitation this morning that apparently bubblegum has also reported. It showed up when I was trying to paste state-4 cells into a pattern instead of state-0 ones, to show where and when the "illegal interference" was happening.

[rowett]

Build 569 is now available on the lazyslug server

Fixes in this build:

• fix [[ PASTET ]] in COPY mode for [R]History

[rowett]

Ran into a PASTET limitation this morning that apparently bubblegum has also reported. It showed up when I was trying to paste state-4 cells into a pattern instead of state-0 ones, to show where and when the "illegal interference" was happening.

Fixed, thanks.

[rowett]

This leads to a general PASTET question.

PASTET supports 16 different PASTEMODEs of combining the source X and destination Y cells:

Code: Select all

PASTEMODE <0..15>|mode	set paste mode
 0   0000  ZERO	
 1   0001  AND	
 2   0010  0010	
 3   0011  X|COPY	
 4   0100  DIFF	
 5   0101  Y	
 6   0110  XOR	
 7   0111  OR	
 8   1000  NOR	
 9   1001  XNOR	
 10  1010  NOTY	
 11  1011  1011	
 12  1100  NOTX	
 13  1101  1101	
 14  1110  NAND	
 15  1111  ONE
 

For [R]History patterns to make these modes useful PASTET just takes the bottom bit of the X and Y cell states (to determine if the cells are alive or dead) and then applies the PASTEMODE logical operation to get the result. In this case the result will always be (0) dead or (1) alive. This is why attempting to PASTET a state 4 cell over a state 0 background ended up with state 0.

The fix implemented now treats COPY mode as a special case where PASTET pastes the clipboard cells unmodified (i.e. without reducing them to 0 or 1).

For [R]Super we will also have this issue. What's the best way to logically combine the 25 states based on PASTEMODE? My intention is to do the same as for [R]History: i.e. for COPY mode just copy the selection unmodified, otherwise reduce source and destination to just alive or dead and end up pasting just state 0 or 1.

Thoughts?

[dvgrn]

For [R]Super we will also have this issue. What's the best way to logically combine the 25 states based on PASTEMODE? My intention is to do the same as for [R]History: i.e. for COPY mode just copy the selection unmodified, otherwise reduce source and destination to just alive or dead and end up pasting just state 0 or 1.

Thoughts?

I think that works -- but that always seemed like an embarrassment of riches as far as the number of paste modes, so I haven't thought of any reason to use most of those modes yet. Theoretically Super rules could have some annoyingly complicated paste modes -- like, take a regular two-state pattern 3o$o$bo!, and paste it as a regular state-1 pattern / a marked-ON pattern / a marked-OFF pattern / a no-trail ON pattern / a state-24 hidden label / whatever.

The maximum flexibility would be to allow arbitrary maps of state-N to state-N', for all 6 HIstory states, and I guess for all 25 Super states, though in practice you'd only define the transitions you were planning to use in the paste operation. I guess there wouldn't be any need to limit this to History and Super rules, though -- a transition table could be applied to pasting any two-state or multistate pattern.

[rowett]

Theoretically Super rules could have some annoyingly complicated paste modes -- like, take a regular two-state pattern 3o$o$bo!, and paste it as a regular state-1 pattern / a marked-ON pattern / a marked-OFF pattern / a no-trail ON pattern / a state-24 hidden label / whatever.

The maximum flexibility would be to allow arbitrary maps of state-N to state-N', for all 6 HIstory states, and I guess for all 25 Super states, though in practice you'd only define the transitions you were planning to use in the paste operation. I guess there wouldn't be any need to limit this to History and Super rules, though -- a transition table could be applied to pasting any two-state or multistate pattern.

Most of this appears like it could be already solved by using the "change state" feature.

[dvgrn]

Most of this appears like it could be already solved by using the "change state" feature.

For manual editing, definitely. I was thinking about waypoint scripts, and what might theoretically be wanted beyond PASTEMODE's current interactions with PASTET. But anything like that can be done just as well by making changes in Golly or LifeViewer to the patterns-to-be-pasted, I think.

I can't even really imagine a practical use for most of the current modes allowed by PASTEMODE, and an adjustable transition table is even less necessary than that.

Separate question: is there a hotkey in LifeViewer that switches a pattern into "Super" mode, so that higher states can be added to it? I had thought based on Alt+H, Alt+J, Alt+K that you were supporting all the shortcut conventions from Golly, but Alt+G is a toggle for Kill Gliders.

[rowett]

Separate question: is there a hotkey in LifeViewer that switches a pattern into "Super" mode, so that higher states can be added to it? I had thought based on Alt+H, Alt+J, Alt+K that you were supporting all the shortcut conventions from Golly, but Alt+G is a toggle for Kill Gliders.

Yes it's on the backlog. I'll re-assign Kill Gliders to another key.

[rowett]

In the mean time I'm playing with a compressed @TREE text format. This will allow us to increase the maximum @TREE size we can store on the Rule: namespace on LifeWiki. However it won't be useful unless (at least) both LifeViewer and Golly support it.

For example:

Code: Select all

@TREE
num_states=7
num_neighbors=8
num_nodes=32
1 0 1 1 3 5 6 3
2 0 0 0 0 0 0 0
1 0 1 2 4 4 6 3
2 0 0 2 0 2 0 0
3 1 1 3 1 3 1 1
1 0 2 2 3 4 6 3
2 2 2 5 2 5 2 2
3 3 3 6 3 6 3 3
4 4 4 7 4 7 4 4
2 5 5 0 5 0 5 5
3 6 6 9 6 9 6 6
4 7 7 10 7 10 7 7
5 8 8 11 8 11 8 8
3 9 9 1 9 1 9 9
4 10 10 13 10 13 10 10
5 11 11 14 11 14 11 11
6 12 12 15 12 15 12 12
3 1 1 1 1 1 1 1
4 13 13 17 13 17 13 13
5 14 14 18 14 18 14 14
6 15 15 19 15 19 15 15
7 16 16 20 16 20 16 16
4 17 17 17 17 17 17 17
5 18 18 22 18 22 18 18
6 19 19 23 19 23 19 19
7 20 20 24 20 24 20 20
8 21 21 25 21 25 21 21
5 22 22 22 22 22 22 22
6 23 23 27 23 27 23 23
7 24 24 28 24 28 24 24
8 25 25 29 25 29 25 25
9 26 26 30 26 30 26 26

would convert into:

Code: Select all

@CTREE
(base64 characters...)

In this case the @TREE section text is 683 characters and the @CTREE equivalent text is 71 characters (10.4% of the original size).

More to follow.

[rowett]

Separate question: is there a hotkey in LifeViewer that switches a pattern into "Super" mode, so that higher states can be added to it? I had thought based on Alt+H, Alt+J, Alt+K that you were supporting all the shortcut conventions from Golly, but Alt+G is a toggle for Kill Gliders.

Please confirm if these are the correct Golly key mappings:

• Alt+G toSuper.lua
• Alt+H toHistory.lua
• Alt+J toStandard.lua

In Golly those scripts actually change the current rule and the states in the pattern.

In LifeViewer the rule and the states do not change. LifeViewer simply changes how the cells are displayed (either in 2-state Standard, 7-state History or 26-state Super mode).

This means if you have a [Rule]History pattern and press Alt-J, you can still edit with all [Rule]History states, but they're just displayed as if it was a Standard 2-state pattern (plus LifeViewer's standard history). Also during playback all [Rule]History states are processed (including state 6), but you see the pattern as a Standard 2-state pattern.

If you copy the pattern to the external clipboard then LifeViewer will create a 2-state version or a multi-state [Rule]History version of the RLE depending on whether it's currently displaying Standard or [Rule]History.

This does mean that the original pattern has to be [Rule]History since no actual state conversion happens. So if you start with a Standard 2-state pattern Alt+H and Alt+J don't do anything.

Adding [Rule]Super into the mix would work in a similar fashion. Alt-G, Alt-H and Alt-J would just define how the states are displayed, but behind the scenes all states would be there. Likewise copying to the clipboard would create the appropriate 2, 7 or 26 state version of the RLE based on the current display mode (Standard, History or Super).

Now if you want to convert the actual states in the pattern you do that using Settings->Pattern->Change Rule and adding or deleting the History or Super prefix. In this case the states are changed to match the new rule. Going from History or Super to Standard uses the odd/even rule to map the states. I'll need to add the case for going from Super to History so it correctly maps the extended states.

If you think it would be helpful and/or less confusing I could make it so Alt+H and Alt-J would actually do state conversion as needed when moving to a higher number of states (i.e. a 2-state pattern to History or Super, or a History pattern to Super).

Thoughts?

[dvgrn]

If you think it would be helpful and/or less confusing I could make it so Alt+H and Alt-J would actually do state conversion as needed when moving to a higher number of states (i.e. a 2-state pattern to History or Super, or a History pattern to Super).

It would certainly be more consistent with Golly, if pressing Alt+H or Alt+G on a two-state [Rule] pattern would then allow that pattern to be copied out as a [Rule]History or [Rule]Super pattern, respectively. The reason for using those shortcuts in LifeViewer would presumably be that you want to use the editing system to add annotations using the higher state values.

[rowett]

Build 570 is now available on the lazyslug server

Fixes in this build:

• fixed issue with drag-to-select text not working after PopUp Viewer launched

[rowett]

Build 571 is now available on the lazyslug server

Fixes in this build:

• documented rainbow mode toggle hotkey in help (Alt+W)
• fixed a tiling issue for RuleTable rules

[rowett]

Build 572 is now available on the lazyslug server

Enhancements in this build:

• hotkey Alt+G switches [R]Standard or [R]History to [R]Super
• hotkey Alt+H swtiches [R]Standard or [R]Super to [R]History
• hotkey Alt+J switches [R]History or [R]Super to [R]Standard
• kill gliders toggle is now on hotkey Ctrl+L
• [R]Super colours can now be customised with [[ COLOR <0..25> R G B|name ]]
• [R]Super paste can now paste any valid state with [[ PASTEMODE COPY ]]

Fixes in this build:

• Help->Scripts->Colours now shows correct state count for [[ COLOR ]] command

[Sokwe]

Build 572 is now available on the lazyslug server

lazyslug.com has been pretty consistently unavailable for the last few days. I was actually able to load the front page a couple hours ago, but now it's down again.

[rowett]

I've got some building work going on. Normal service will be resumed later this week.

[dvgrn]

Just noticed that on a pop-up pattern, when I hit the Edit button and scroll to the right to see the highest LifeSuper states, I can't scroll past state 24, so I can't use state 25.

On an embedded viewer with the standard forum width, there's no problem getting to state 25.

[rowett]

Just noticed that on a pop-up pattern, when I hit the Edit button and scroll to the right to see the highest LifeSuper states, I can't scroll past state 24, so I can't use state 25.

On an embedded viewer with the standard forum width, there's no problem getting to state 25.

I can't reproduce this. Please post a screenshot.

[dvgrn]

I can't reproduce this. Please post a screenshot.

Say for this pattern, in the latest Chrome on Windows 10:

Code: Select all

x = 1, y = 1, rule = LifeSuper
A!

-- I click on Show in Viewer, then click the pencil icon and drag the green bar as far to the right as it will go.

Here's what I see -- no state 25 visible:

highest-visible-state-is-24.png (64.51 KiB) Viewed 140 times

If I convert the code block to a viewer block, I can see states 0 through 13 to start out, and there's no problem getting to State 25:

Code: Select all

x = 1, y = 1, rule = LifeSuper
A!

[rowett]

Build 573 is now available on the lazyslug server

Fixes in this build:

• fix UI slider range on scaled Viewers

[rowett]

Here's what I see -- no state 25 visible

Thanks. Please try build 573.

[dvgrn]

Here's what I see -- no state 25 visible

Thanks. Please try build 573.

Still seems to be the same, but now I'm seeing something I didn't see before. This is Build 573:

highest-visible-state-is-24.png (60.78 KiB) Viewed 136 times

I still can't scroll to the right past 24 on the pop-up viewer. Also, if I don't click exactly right to start dragging the green States bar to the right, I end up drawing new state-1 cells (behind the rectangle where the screenshot says "18-24").

[rowett]

I still can't scroll to the right past 24 on the pop-up viewer. Also, if I don't click exactly right to start dragging the green States bar to the right, I end up drawing new state-1 cells (behind the rectangle where the screenshot says "18-24").

OK so that didn't work.

In Help->Info in your PopUp Viewer please let me know the following values: Display: Size, Scale, Pixel Ratio and Window Zoom. They should be at the top of the page.

[dvgrn]

In Help->Info in your PopUp Viewer please let me know the following values: Display: Size, Scale, Pixel Ratio and Window Zoom. They should be at the top of the page.

LifeViewer-params.png (34.98 KiB) Viewed 130 times