Page 3 of 97

Re: Life tag testing

Posted: February 13th, 2015, 1:57 pm
by dvgrn
rowett wrote:You can already specify a smaller HEIGHT setting. The minimum is 240. Anything below 480 hides the navigation controls. The allowed range of values for each script command is displayed in the script help.
Ooh, I hadn't noticed that. Looks good! It might be slightly puzzling to have 'M' advertised in Help as toggling the navigation menu, but it doesn't do anything if HEIGHT<480. Maybe add a note, e.g., "(unless HEIGHT<480)"?

Or, as my mockup above shows, it does seem as if there's room for all the controls at HEIGHT=240, as long as the minimum WIDTH stays at 480. Just have to give the side controls the full height, and the top and bottom controls take the space in between. Then there'd be no need for a note -- unless you move the minimum lower still. There might be a use-case for as low as HEIGHT 120, but I don't think it's nearly as important as the reduction to 240.

As things stand, maybe it makes sense to include the numeric ZOOM value in the Display section of Help, as well as the X and Y values -- again so that it's easy to preview the viewer (even if it's HEIGHT<480), adjust the display to where you want it, hit 'I', and and type the relevant information into the pattern header. I'm less concerned with ANGLE, THEME, DEPTH, and LAYERS, but maybe that's just me -- it might be handy to include at least ANGLE in the readout.
rowett wrote:While I'm on the topic I notice the current set of escapees have all been created with WIDTH 480. I presume this is because they copied Dave's initial escapee. Do you want to make that the default width?
Nope, I think it's better to default to the width of the code box, as you're doing now. I just threw in WIDTH 480 because I was posting a square soup pattern.

Re: Life tag testing

Posted: February 13th, 2015, 2:26 pm
by Nathaniel
rowett wrote:Can you get phpBB to include a specific javascript file based on the use of a specific BBCode on a page?
Unfortunately no :( It either has to always load the plugin JS, or never.

Re: Life tag testing

Posted: February 13th, 2015, 3:07 pm
by dvgrn
Nathaniel wrote:
rowett wrote:Can you get phpBB to include a specific javascript file based on the use of a specific BBCode on a page?
Unfortunately no :( It either has to always load the plugin JS, or never.
Okay, well, I'm certainly convinced that my multiple-version idea was better in theory than it is in practice. Any different kinds of viewers that might turn out to be useful -- extra-small, locked-down, whatever -- could probably be handled perfectly well with script commands, along the same lines as [[ VIEWONLY ]].

Here's another crackpot idea that I'll pretend isn't a feature request, just an innocent theoretical question. Suppose you have a small, say 150x100 viewer displayed, obviously in no-navigation-controls mode. Suppose further that the navigation-menu button is still displayed in the lower right corner, not hidden. Does the plugin have enough control over the browser to increase the viewer size on the fly, in response to a click on that button?

The idea is that most readers of the forums won't actually want to interact much with most patterns -- seeing them, and maybe running them once or twice, will usually be plenty. So a small size might be a good default. But if someone is interested enough in a pattern to click the navigation-menu button, then it might be worth devoting more screen real estate to that pattern.

This is very similar to what I tried to do with Nicolay Beluchenko's 'oscichem' articles a decade ago, with a not very savory Java/Javascript brew. What was possible then might be possible now... but I'm not holding my breath, because the phpBB layer seems to be a difficult jungle to find a path through sometimes. (?)

Re: Life tag testing

Posted: February 13th, 2015, 4:57 pm
by rowett
dvgrn wrote:It might be slightly puzzling to have 'M' advertised in Help as toggling the navigation menu, but it doesn't do anything if HEIGHT<480. Maybe add a note, e.g., "(unless HEIGHT<480)"?
In build 125 the help line for 'M' disappears if the navigation menu is not available (i.e. HEIGHT < 480).

Code: Select all

#C [[ HEIGHT 240 WIDTH 480 ZOOM 11.5 GPS 5 THEME 3 LOOP 50 AUTOSTART ]]
x = 16, y = 8, rule = B3/S23
2b3o11b$11b3o2b$o5bo9b$o5bo2bo5bo$o5bo2bo5bo$9bo5bo$2b3o11b$11b3o
dvgrn wrote:There might be a use-case for as low as HEIGHT 120, but I don't think it's nearly as important as the reduction to 240.
Let me know. I can set it to whatever makes sense, though too small and the play controls get in the way.
dvgrn wrote:As things stand, maybe it makes sense to include the numeric ZOOM value in the Display section of Help, as well as the X and Y values -- it might be handy to include at least ANGLE in the readout.
Build 125 includes both ZOOM and ANGLE. I also made the Display section the first thing on the information help page (key I) so you can see it without scrolling on a small height Viewer.

Re: Life tag testing

Posted: February 13th, 2015, 4:58 pm
by rowett
dvgrn wrote:Does the plugin have enough control over the browser to increase the viewer size on the fly, in response to a click on that button?
Yes, it's already changing the viewer size on the fly when you specify a non-default WIDTH or HEIGHT.

Re: Life tag testing

Posted: February 13th, 2015, 6:12 pm
by dvgrn
rowett wrote:
dvgrn wrote:There might be a use-case for as low as HEIGHT 120, but I don't think it's nearly as important as the reduction to 240.
Let me know. I can set it to whatever makes sense, though too small and the play controls get in the way.
...
Yes, it's already changing the viewer size on the fly when you specify a non-default WIDTH or HEIGHT.
Hmm. That doesn't quite prove that changing size in response to a mouse click will work, but from what I sort-of-know about HTML and JavaScript, it ought to work fine.

-- Okay, then, what do you think of the idea of a script command [[ SMALL ]] that starts out with the viewer at say a third of normal size, but with no visible play controls? Same as [[ VIEWONLY ]], really, except that the first click on the viewer expands it to full size.

That way in a post with lots of viewers in it, you could throw in the [[ SMALL ]] tag and basically show pattern thumbnails -- and yet it would still be easy to jump in and investigate a particular pattern in more detail if you wanted to.
rowett wrote:Build 125 includes both ZOOM and ANGLE. I also made the Display section the first thing on the information help page (key I) so you can see it without scrolling on a small height Viewer.
Wonderful! That works really well. I can't seem to find any bugs in Build 125, so I'll start writing a quick walkthrough for the official announcement. As Michael Simkin has been demonstrating, though, the Viewer is incredibly self-explanatory. Very, very nice work!

EDIT: After [view] or

Code: Select all

, my next vote for a BBCode name would be [liferle]. Less work for me that way...

Re: Life tag testing

Posted: February 14th, 2015, 3:34 am
by rowett
dvgrn wrote:Okay, then, what do you think of the idea of a script command [[ SMALL ]] that starts out with the viewer at say a third of normal size, but with no visible play controls? Same as [[ VIEWONLY ]], really, except that the first click on the viewer expands it to full size.
Build 126 adds a new script command THUMBNAIL that shrinks the viewer to a quarter of the size. When you click it expands to full size. I haven't built a facility to collapse it again to the thumbnail size. If you think that's required let me know.

Code: Select all

#C [[ AUTOSTART THEME 4 GPS 6 LAYERS 2 DEPTH 0.7 THUMBNAIL ]]
x = 27, y = 10, rule = b3/s23
2o25b$bo25b$bobo13b3o7b$2b2o3bo8bo3bo6b$6bob2o6bo4bo5b$5bo4bo6b2obo6b$
6bo3bo8bo3b2o2b$7b3o13bobob$25bob$25b2o!
dvgrn wrote:After [view] or

Code: Select all

, my next vote for a BBCode name would be [liferle]. Less work for me that way...[/quote]
I think I still prefer [viewer]. I guess the sooner we release the less tidy up there will be to do :)

Re: Life tag testing

Posted: February 14th, 2015, 9:22 am
by dvgrn
rowett wrote:Build 126 adds a new script command THUMBNAIL that shrinks the viewer to a quarter of the size. When you click it expands to full size. I haven't built a facility to collapse it again to the thumbnail size. If you think that's required let me know.
Beautiful! ... I don't think back-to-thumbnail is required, exactly, but now that you mention it, there is a certain symmetry to the idea, and the alphabet isn't entirely used up yet -- S-for-shrink seems to be unused.
rowett wrote:
dvgrn wrote:After [view] or [ viewer ], my next vote for a BBCode name would be [ liferle ]. Less work for me that way...
I think I still prefer [ viewer ]. I guess the sooner we release the less tidy up there will be to do :)
Okay, there seems to be a developing consensus here. Nathaniel, maybe you can cast the deciding vote between [view] and [ viewer ]-- or if you prefer a different tag, I think you probably get the deciding vote anyway!

Then when the appropriate button is added to the editor, I'll create a thread to officially introduce the Viewer.

It's probably time to get the .JS file back onto conwaylife.com. Every now and then I'm seeing a long "Waiting for lazyslug..." when trying to load any forum page, even one with no Viewer content. Makes sense given the all-or-nothing loading of the plugin, of course.

The only other nice-to-have items that I haven't heard a thumbs-up or thumbs-down on are suggested script commands:
    • PAUSE / DELAY {seconds} (or PAUSEBEFORE / PAUSEAFTER) -- for when the start state or the end state of a loop is worth highlighting for a few seconds:

      Code: Select all

      #C [[ AUTOSTART LOOP 16 GPS 5 THEME 0 THUMBNAIL ]]
      x = 10, y = 14, rule = B3/S23
      2bo$2bobo$2b2o4bo$7b2o$o6bobo$b2o$2o5$2b3o$2bo$3bo!
      (not the best example, because I could get a PAUSEAFTER effect here with LOOP 30 or whatever -- but sometimes the last tick of the loop will be an output Herschel or something else unstable.)
    • COLOR n RGBvalue -- for setting up a non-default theme for multistate rules in VIEWONLY mode. WireWorld for example has a traditional set of colors that are different from Viewer defaults:

      Code: Select all

      #C unary multiplier from Golly's Patterns/WireWorld
      #C [[ VIEWONLY THUMBNAIL ]]
      x = 131, y = 84, rule = WireWorld
      31.C.C.C2.C2.C2.2C2.C.C3.C3.C.C.C.C3.3C.3C.2C2.C3.3C.3C.2C$31.C.C.2C.
      C.C.C.C.C.C.C3.2C.2C.C.C.C4.C3.C2.C.C.C4.C2.C3.C.C$31.C.C.C.2C.3C.2C
      3.C4.C.C.C.C.C.C4.C3.C2.2C2.C4.C2.2C2.2C$31.C.C.C2.C.C.C.C.C2.C4.C3.C
      .C.C.C4.C3.C2.C3.C4.C2.C3.C.C$32.C2.C2.C.C.C.C.C2.C4.C3.C2.C2.3C2.C2.
      3C.C3.3C.3C.3C.C.C5$2.11C3.92C3.3C.3C3.6C$.C11.C.C92.C.C3.C3.C.C6.C$C
      6.3C.C.4C16.C5.59C7.2C2.3C.3C2.C.C6.C$C2.B2.A3.B2C2.C2.2C.C.C5.C2.A.C
      .A.C59.C5.C2.C2.C3.C3.C.C6.C$C.C.A2.BCA.C.C2.2C2.3C.C3.C.C2.B.BAC3.3C
      .7C.3C.12C.4C.2C.10C5.BC3.C.C.4C.C3.3C5.C7.C$C2.C9.2C4.C.C2.C2.C2.C2.
      A2.A3.C3.C7.C3.C12.C4.C2.C10.C3.A2.A3.3C2.C2.C6.C3.3C2.2C2.C$C2.C.C2.
      5C2.C.2C4.3C.C2.C.5C2.C5.C6.C.C.C5.A6.C.C2.C2.C4.2C.B2.C.C.C2.B2.C.C
      2.4C8.C3.C2.C2.B.C$C3.4C8.C2.C3.C.4C.C2.C.C2.C3.C2.C7.3C5.C.B2.C3.6C.
      C3.2C.A.C2.3C3.C.C4.2C.A.C8.C3.2CA2.A.C$C4.C.C.4C2.3C.C2.C.BC.C2.C2.C
      .C.C3.A.C.C8.C6.C.C.C.C.C.C2.A3.3C.4C2.C.C.C2.C.C3.C.2C.B2.7C7.BC2.C$
      C3.C3.C4.C2.C2.C3.A4.2C3.C.C.C3.B.B.C.C5.3C5.B.C.C.C.C3.C.B.C5.C3.C4.
      B2.A.C3.C6.C8.5C2.B2.C$C2.C7.C2.2C2.C10.C.2C3.2C.C.C.A2.2CA.A2.C.2C4.
      A.C.C.C.C3.B.C.C.C3.C2.3C3.A2.B.C2.3C5.3C.2C.2C5.C2.A.C$C.3C2.C2.C.C
      4.3C2.AB2CA3.C2.C.C2.2CA2.C.C.C.B.C2.AC.C.C.C.A.C.C.C3.A.C2.7C2.C.C3.
      2C2.C.C.C.C3.C3.C2.C3.C3.C2.C.C$C2.C2.C.C.C.C.C.CA.A.C5.B.3C.C.C.C.C.
      B.C.C3.C.C.B.C2.3C2.B.A.C.C3.C.A.C.C3.B2.C2.C7.C.C4.C2.C.C.C.3C.C.A3.
      C.C.C$C.C.C.C.C.C2.3C.AB2.B5.C2.A2.C.B.C3.C.C.C3.C.B2.C2.C.C.B.C.B.C.
      C3.C.B.C4.C.A.C3.7C2.C3.C.C2.3C3.C3.BA.C.C.C.C$C.C.C.C.C.C.C.C2.A.C.A
      5.2CB4.A3.C2.C.B.C3.A.A5.C4.A2.C.C.C3.C.C.C4.C.C.C12.C3.C.C3.C2.2C3.A
      .A3C2.C.C$C.C.C.C.C.C.C5.C3.3CBA4.3C5.C2.A3.C.B2.C4.C9.C2.C3.B.C.C4.C
      .C.C2.A10.3C3.3C2.C5.3C.C.C.C.C$.C2.C.C.C.C.C2.2C3.C5.A3.C2.C.C.B2.C
      5.C.C.B2.2C.C10.C.C4.A2.C4.A.B.C.C.B19.C7.C4.C.C.C$3.C2.C.C.C.C.C2.C.
      C.2C2.3C3.C2.2CA.C2.C2.C.C.C.A.C2.C9.C.C.C7.C4.B.A.C2.2C2.C2.B2CAB2C
      4.3C7.C.C2.C2.C.C$2.C3.C2.C2.C2.C.C.C3.C2.C3.3C2.C.C4.4C3.C2.C.5C5.3C
      3.4C3.C4.C.C.C.C.5CA7.C2.C4.C4.3C2.C3.C.C$2.C.C.C6.C.C.C.C2.4C.3C.C3.
      C8.C7.C2.C3.C3.C.C.C6.C2.C4.A.C.C.3C2.C2.2CBACBA2.C4.C.A4.C2.C4.C.C$
      3.3C2.2CB2.C.C.C.C.C.C.C6.C.4C7.2C6.2C4.C3.C3.C.C.3C4.C4.B2.C2.C2.3C
      10.C5.B2.C.C3.C.C.C2.C$4.C2.C3.A2.C3.C2.C4.C3.2C3.C2.C8.C10.3C2.C2.5C
      6.3C6.C3.C2.C3.2C6.C4.6C5.3C3.C$2.2C2.C.ABC5.C5.4C3.C4.C4.A2.B5.C10.C
      .C.C3.C.C8.C.C.2C2.C2.C.2C.C.C2.C5.C5.C2.C.2C2.C.C4.C$.C3.C6.6C12.4C
      4.3BC.A5.10C3.C.3C3.8C3.C2.C.C.C6.3C2.C4.C3.4C3.C.C.C6.C$.C2.3C2.C.C
      4.B.6C13.C.C2.C37.3C2.C.C6.C.C.C2.4C3.C.A.2C2.C.C.7C$2.C2.C2.C.C6.A6.
      C12.C.C41.C12.C3.C10.B.2C.2C3.C$3.2C.2C2.C5.3C6.12C3.41C14.3C18.C$2.C
      7.C.2C3.C2.C94.C$2.C8.C2.6C.B20.73C$2.C7.3C4.C2.A20.C$3.6C2.C29.C$2.C
      6.2C30.C$2.C8.106C.5C.2C$2.C38.C75.C5.C2.C$2.C107.CBA.C.C2.C2.3C.C$2.
      C106.A3.3C2.3C2.C2.C$2.C107.B2C.C.2C.C.C2.C.C$2.C117.C.2C2.C$2.C2.3C.
      C.C.3C3.3C2.C2.2C2.3C12.C2.C3.2C2.C.C2.C2.2C2.3C.3C5.2C12.C30.C$2.C3.
      C2.C.C.C6.C2.C.C.C.C.C13.C.C.C3.C.C.C.C.C.C.C.C.C4.C6.C.C.2C8.C3.2C2.
      C22.C$2.C3.C2.3C.2C5.C2.3C.2C2.2C12.3C.C3.2C2.3C.3C.2C2.2C3.C6.2C6.C
      5.C7.C22.C$2.C3.C2.C.C.C6.C2.C.C.C3.C13.C.C.C3.C3.C.C.C.C.C.C.C4.C6.C
      .C.2C8.C3.2C2.C22.C$2.C3.C2.C.C.3C4.C2.C.C.C3.3C11.C.C.3C.C3.C.C.C.C.
      2C2.3C2.C6.2C11.3C29.C$2.C123.C$2.C3.A3.A3.A3.A3.A3.C3.A3.A3.A3.A3.C
      3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C$3.C.B.C.
      B.C.B.C.B.C.B.C.C.C.B.C.B.C.B.C.B.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C
      .C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C$3.C.C.C.C.C.C.C.C.C.
      C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C
      .C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C$3.B.C.C.C.C.C.C.C.C.C.C.C.C.C.C.
      C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C
      .C.C.C.C.C.C.C.C.C.C.C.C$4.A3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.
      C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C5$.C2.3C4.3C7.C$C.C
      2.C6.C3.2C2.C.C$3C2.C6.C7.C.C$C.C2.C6.C3.2C2.C.C$C.C2.C6.C8.C3$6.C3.C
      3.C3.C3.C7.C3.C3.C3.C$2.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.
      C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C$6.C3.C3.C3.C3.C
      7.C3.C3.C3.C3$.C2.3C4.3C7.C2.3C.C3.2C2.C3.3C6.2C2.2C2.3C2.C3.C2.3C.3C
      .3C$C.C2.C6.C3.2C3.C2.C.C.C5.C.C3.C.C2.2C4.C3.C.C.C3.C.C3.C3.C.C3.C$
      3C2.C6.C8.C2.3C.3C2.C2.3C.C.C7.C3.C2.C.C4.C4.3C.C.C3.C$C.C2.C6.C3.2C
      3.C4.C2.C2.C4.C2.C.C2.2C4.C.C3.C.C3.C.C3.C.C.C.C3.C$C.C2.C6.C7.3C.3C
      2.C2.3C2.C2.3C6.2C2.3C.3C2.C3.C2.3C.3C3.C3$6.C3.C3.C3.C3.C7.C3.C3.C3.
      C7.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C$2.C3.C
      3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C
      3.C3.C3.C3.C3.C3.C3.C3.C$6.C3.C3.C3.C3.C7.C3.C3.C3.C7.C3.C3.C3.C3.C3.
      C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C3.C!
EDIT: When you expand these thumbnails, the pattern and the controls show up noticeably off-center in the Viewer window. I believe that's because I evilly put the viewer inside a BBCode list tag. I've nested a couple of list tags to make the problem more obvious.

Re: Life tag testing

Posted: February 14th, 2015, 12:48 pm
by rowett
dvgrn wrote:When you expand these thumbnails, the pattern and the controls show up noticeably off-center in the Viewer window.
It's because the Canvas element (on which the Viewer is drawn) was sized to be the width of the post area. Having indented it with the list items it's too wide to be displayed. The pattern is still centred correctly, you just can't see the right-hand part of the Viewer.

Build 127 fixes this by limiting the maximum Viewer width to the width of the Code block. If it appears slightly narrower it's because the Viewer width has to be a multiple of 8.
dvgrn wrote:I don't think back-to-thumbnail is required, exactly, but now that you mention it, there is a certain symmetry to the idea, and the alphabet isn't entirely used up yet -- S-for-shrink seems to be unused.
Added in build 127. Hotkey S now toggles between thumbnail and normal view.

Re: Life tag testing

Posted: February 14th, 2015, 12:58 pm
by rowett
dvgrn wrote:The only other nice-to-have items that I haven't heard a thumbs-up or thumbs-down on are suggested script commands:
  • PAUSE / DELAY {seconds} (or PAUSEBEFORE / PAUSEAFTER)
  • COLOR n RGBvalue -- for setting up a non-default theme for multistate rules in VIEWONLY mode.
My current to do list includes:
  1. Waypoints - when these exist you won't need PAUSE / DELAY
  2. Custom colour themes
  3. Having a list of all custom rules (LifeHistory, WireWorld, etc.) with matching colour sets
  4. Identifying which of the custom rules can be executed (i.e. reduced to a Life-like rule as with LifeHistory)
  5. Making the custom rule name appear in the help information
Dave if you could please provide me with, or point me at, the data for items 3 and 4 (custom rule names, corresponding colours sets, and which can be reduced to a two state Life-like rule) I'll add them.

Re: Life tag testing

Posted: February 15th, 2015, 3:12 am
by dvgrn
rowett wrote:Dave if you could please provide me with, or point me at, the data for items 3 and 4 (custom rule names, corresponding colours sets, and which can be reduced to a two state Life-like rule) I'll add them.
In recent versions of Golly the rule name and associated colors tend to travel together in a .rule file, so if it's okay I'll just quote the relevant pieces of those files.

For most rules, color assignments can be found as part of the rule definitions in the Rule Table Repository. There are some recently posted rules on the forums that haven't made it into the RTR yet, but that could certainly be fixed.

The three numbers after the state number in the @COLORS section are the R, G, and B values, in that order. The list below is not complete yet, by any means -- for example, there's probably a case for including some of the rules simsim314 has invented or used, e.g., Serizawa or GeminoidParticles. Meanwhile, here's a start:

Code: Select all

@RULE LifeHistory
@COLORS
1    0  255    0
2    0    0  128
3  216  255  216
4  255    0    0
5  255  255    0
6   96   96   96

@RULE WireWorld
@COLORS
0  48  48  48
1   0 128 255
2 255 255 255
3 255 128   0

@RULE WWE
@RULE WWE2
@RULE WWEJ
@RULE WWEJ2
@RULE WWEJ3
@COLORS
0    0   0   0
1  255 255 255
2  144 128 112
3  144  90  45
4  192 192 192
5  255   0   0
6  255 128   0
7  255 255   0
8    0 255   0
9    0 255 208
10   0 192 255
11   0   0 255
12 192   0 255
13 255  64 160
14 112 128 144
15   0 128   0
16   0  96 128
17 160   0  80
18  40  40  40
19 220 220 220
20 140  60   0
21   0 160   0
22 160 160 250

@RULE Novoloop
@COLORS
0 30 30 30
1 0 128 128
2 0 255 0
3 255 0 0
4 255 128 0
5 255 255 0
6 128 0 128
7 128 128 128
8 255 255 255
9 128 128 255

@RULE shapeloop
@RULE shapeloop2
@RULE shapeloop-ltd
@RULE 2armshapeloop2-a
@RULE shapeloop2a-bounded
@RULE foodshapeloop
@RULE foodshapeloop2
@COLORS
0 0 0 0
1 255 128 0
2 255 0 0
3 0 255 0
4 0 0 255
5 0 190 0
6 0 140 0
7 255 255 255
8 80 80 80
9 95 95 95
10 128 128 128
11 0 64 0
13 255 255 0
14 64 0 164
15 64 32 64
16 80 80 100
17 95 95 125
18 128 255 128
19 64 100 100
The toughest case above is the "shapeloop" rules, where many versions have been posted -- bounded, unbounded, with food particles, etc. As I've indicated above, all of these closely related rules use the same color mappings.

The WireWorldExtended rules seem to have more variety of color mappings. Above I've given a compromise set of colors for all the WWE variants. But here for example is the actual old WWE2.colors file -- this is an acceptable variant of the @COLORS syntax:

Code: Select all

color=1		0 120 250	light blue		electron head
color=2		250 250 250	white		signal electron tail
color=3		255 120 0	orange		wire
color=4		120 250 120	light green	turn left electron tail
color=5		250 250 0	yellow		extend electron tail
color=6		140 120 200	light purple	minor retract electron tail
color=7		250 120 120	light red		turn right electron tail
color=8		0 100 0		green		frozen state
color=9		0 0 128		dark blue		constructor state
color=10		120 180 120	grey green	frozen tail
color=11		160 120 120	grey red		constructor tail
color=12		0 160 0		green		turn left growth
color=13		0 160 0		green		turn right growth
color=14		0 160 0		green		frozen growth
color=15		0 160 0		green		constructor growth
color=16		0 0 0		black		moderate retract
color=17		150 100 0	green brown	construction wire
color=18		40 40 40		dark grey		aggressive retract
color=19		220 220 220	light grey		construction wire helper
color=20		140 60 0		brown		universal retract growth 1
color=21		0 160 0		green		universal retract growth 2
color=22		160 160 250	light blue		construction helper
-----------------------------------------------------

I'll continue my review tomorrow, but it seems to me that most of the rules that are installed with Golly, or catalogued in the RTR, don't particularly need special hard-wired Viewer support on the forums. There just aren't a lot of new Codd or Devore or JvN29 or Nobili32 or Hutton32 patterns being posted, that are in need of view-only thumbnails or whatever.

For the most part, new postings that could make use of multistate viewers will probably be either LifeHistory or some newly-defined rule that we don't have any prior knowledge about anyway. (I suspect there will be a lot of these over time.)

So, for anyone who wants to display a properly-colored image of their multistate pattern for their newly-invented rule, is your plan for "custom colour themes" to allow multistate themes to be defined? or does that item refer to a new customized theme along the lines of Themes 0 through 9?

EDIT: As a first-draft answer for your other question:

Quite a few rules have been created over the years that can be reduced fairly cleanly to B3/S23 Life. Unfortunately every one is different -- some have multiple colors, some have history states, some have separate history states for each color, and so on. LifeHistory has the unfair advantage of being the only such rule that is installed as part of Golly, and it's also the only such rule that people seem to have posted lots of patterns for, in the last few years anyway. So I think maybe that's the only reducible multistate rule that it makes any sense to worry about.

Re: Life tag testing

Posted: February 15th, 2015, 3:21 am
by rowett
Dave,
Firstly, thanks for the information.
dvgrn wrote:So, for anyone who wants to display a properly-colored image of their multistate pattern for their newly-invented rule, is your plan for "custom colour themes" to allow multistate themes to be defined? or does that item refer to a new customized theme along the lines of Themes 0 through 9?
Both.
For multi-state patterns my intention is to have a library of pre-defined colour sets, one per custom rule type.
Additionally to allow definition of a custom colour set probably looking much like the data you provided (i.e. COLOUR 0 255 0 0 - set colour for state 0 to red (rgb 255,0,0)).
For executable patterns my intention is to allow the definition of a custom Theme. For this you would be able to define 5 colours (as rgb values):
  1. The background colour
  2. The colour when a cell first becomes alive
  3. The colour when a cell first dies
  4. The colour to ramp to when a cell has been alive 63 generations
  5. The colour to ramp to when a cell has been dead 63 generations

Re: Life tag testing

Posted: February 15th, 2015, 5:21 pm
by Nathaniel
dvgrn wrote:Okay, there seems to be a developing consensus here. Nathaniel, maybe you can cast the deciding vote between [view] and

Code: Select all

-- or if you prefer a different tag, I think you probably get the deciding vote anyway![/quote]

Kk, let's go with [viewer] then. :)

Re: Life tag testing

Posted: February 15th, 2015, 6:18 pm
by rowett
Hi Nathaniel,
I'm happy with the current build (128) as the one to publish and host on the conwaylife.com server.

Re: Life tag testing

Posted: February 16th, 2015, 4:47 am
by rowett
dvgrn wrote: The three numbers after the state number in the @COLORS section are the R, G, and B values, in that order. The list below is not complete yet, by any means -- for example, there's probably a case for including some of the rules simsim314 has invented or used, e.g., Serizawa or GeminoidParticles. Meanwhile, here's a start:

Code: Select all

@RULE LifeHistory
@COLORS
1    0  255    0
2    0    0  128
3  216  255  216
4  255    0    0
5  255  255    0
6   96   96   96

@RULE WireWorld
@COLORS
0  48  48  48
1   0 128 255
2 255 255 255
3 255 128   0

@RULE WWE
@RULE WWE2
@RULE WWEJ
@RULE WWEJ2
@RULE WWEJ3
@COLORS
0    0   0   0
1  255 255 255
2  144 128 112
3  144  90  45
4  192 192 192
5  255   0   0
6  255 128   0
7  255 255   0
8    0 255   0
9    0 255 208
10   0 192 255
11   0   0 255
12 192   0 255
13 255  64 160
14 112 128 144
15   0 128   0
16   0  96 128
17 160   0  80
18  40  40  40
19 220 220 220
20 140  60   0
21   0 160   0
22 160 160 250

@RULE Novoloop
@COLORS
0 30 30 30
1 0 128 128
2 0 255 0
3 255 0 0
4 255 128 0
5 255 255 0
6 128 0 128
7 128 128 128
8 255 255 255
9 128 128 255

@RULE shapeloop
@RULE shapeloop2
@RULE shapeloop-ltd
@RULE 2armshapeloop2-a
@RULE shapeloop2a-bounded
@RULE foodshapeloop
@RULE foodshapeloop2
@COLORS
0 0 0 0
1 255 128 0
2 255 0 0
3 0 255 0
4 0 0 255
5 0 190 0
6 0 140 0
7 255 255 255
8 80 80 80
9 95 95 95
10 128 128 128
11 0 64 0
13 255 255 0
14 64 0 164
15 64 32 64
16 80 80 100
17 95 95 125
18 128 255 128
19 64 100 100
Build 128 contains a list of rules along with corresponding colour sets. It's currently populated from the list above. If a pattern with a rule not in the list is discovered it defaults to the LifeHistory colour set.
The current Set name, size, and list of colours are displayed in the help information.
If there is a preferred default set please let me know.

Build 128 also forces any multi-state rule into VIEWONLY mode, except for LifeHistory, where it respects the presence (or otherwise) of the VIEWONLY command.

The rule name is now correctly displayed in the help information. Note for LifeHistory in non-VIEWONLY mode this is still displayed as "Conway's Life" since this is the actual rule that is used for playback.

Build 128 also adds the [[ COLOR ]] and [[ COLOUR ]] script commands. They both work identically the only difference being one is spelt correctly. When defining a custom colour set you must specify colours for all states.

Code: Select all

#C LifeHistory sample pattern -- not-quite-working Herschel splitter
#C [[ VIEWONLY COLOR 0 64 0 0 COLOR 1 0 240 32 COLOR 2 32 32 240 COLOR 3 240 240 64 COLOR 4 240 96 240 ]]
x = 98, y = 75, rule = LifeHistory
55.2A$54.B2AB$54.3B$55.B$53.5B$53.B3D2B$53.2BD3B$53.2B3DB$53.6B$53.6B
$53.6B$53.5B$52.6B$53.6B$52.7B$52.6B$52.6B$52.6B$51.8B$52.8B$51.9B$
51.9B$51.10B$51.5B2A3B9.2A10.B$51.5B2A4B9.A8.5B$51.11B9.A.AB4.6B$51.
4BD7BA.A6.2AB.B2.6B$53.B3D4B2.2A.A7.13B$39.A13.D2B2D2B6.A8.12B$39.3A
11.5B8.2A5.14B$42.A10.5B9.2B3.16B$30.2A9.2A9.6B8.6B.15B4.3B$31.A5.3B.
5B.3B2.8B6.22B.7B$31.A.AB.4B3.20B2.22B.B2A5B$32.2AB.27B2.23BA2BA5B$
34.55B2A6B$34.62B$34.51B.6B.2B$34.46B.2B2.8B.B$17.2B13.47B7.6B.B2A$
17.3B12.43B15.B3.A.A$17.4B10.2A13B2.9B.B3.B3.10B19.2A$18.4B9.2AB.12B
2.7B11.9B$19.4B9.B.13B.9B8.11B$7.2A3.2A6.4B11.11B3.7B9.2A3.2B3D2B$6.B
2AB.B2AB6.4B10.10B4.7B10.A3.2BD4B$7.2B2.3B3.B4.4B8.11B3.9B6.3A4.B3D4B
.2B$8.3B.3B.4B3.4B6.11B5.7B7.A6.12B$2A5.7B.13B4.13B6.3B16.14B$.A5.23B
.16B4.5B14.15B$.A.AB.19B.8B.4B2A7B6.2A15.14B$2.2AB.33B2A7B6.A19.11B$
4.45B6.3A15.13B2.2B$4.33BD12B7.A14.19B$4.33B2D10B21.B.21B$5.33B2D7B
19.2A.2A22B$7.31BD10B18.A.A.B.21B$5.32BD12B15.A.A.A.A23B$5.2A3.26B3.
12B14.2A3.2A.B.19B$6.A3.20B4.B6.10B23.22B$3.3A6.15B7.2A7.7B24.21B2D$
3.A8.11B12.A9.2B2.BA22.23B2D$11.13B10.A14.A.A19.A24BD$10.15B9.2A14.2A
17.3A2.7B.14B$10.16B42.A5.7B3.7B.2B$10.17B41.2A4.7B4.5B$10.16B48.5B6.
4B$12.14B46.2AB.2B7.4B$11.4B.2B2A6B45.A.AB10.B2AB$10.4B2.2B2A6B45.A
14.2A$9.4B2.11B44.2A$8.4B4.2B3D4B$7.4B5.3BD4B$6.4B7.2B3D2B$6.3B8.7B!
Finally, build 128 ensures that only hotkey commands available in the current mode are listed in the help.

Re: Life tag testing

Posted: February 16th, 2015, 10:50 am
by rowett
With the release of build 128 the to do list now contains:
  • Waypoints
  • Custom Themes
  • Script error list should scroll like help
  • Thumbnails should not show error list or help and should remember and restore error list and help visibility when toggling between thumbnail and full size
If it's not on the to do list I'm not thinking about it... :)

Re: Life tag testing

Posted: February 16th, 2015, 12:26 pm
by dvgrn
rowett wrote:If a pattern with a rule not in the list is discovered it defaults to the LifeHistory colour set.
The current Set name, size, and list of colours are displayed in the help information.
If there is a preferred default set please let me know.
LifeHistory doesn't really have enough states to be a good standard fallback. Lots of multistate rules will have ten or more states. For a default set I'd suggest using Golly's defaults for all 256 possible states.
rowett wrote:The rule name is now correctly displayed in the help information. Note for LifeHistory in non-VIEWONLY mode this is still displayed as "Conway's Life" since this is the actual rule that is used for playback.
Seems reasonable, and seems to work as advertised.
rowett wrote:Build 128 also adds the [[ COLOR ]] and [[ COLOUR ]] script commands. They both work identically the only difference being one is spelt correctly.
Ah, I see what you've done there. You've avoided saying which one is spelled correctly... You kind of give it away with the way you spell it in the Help text for THEME, though. But then you use the Americanized spelling when you're showing error messages -- very puzzling.

Code: Select all

#C [[ THUMBNAIL COLOUR 1 255 0 0 COLOR 5 0 255 0 ]]
x = 9, y = 13, rule = UnknownRule
3.2E$3.E2.2E$2E.E3.E$E.E.3E$2.E.E$.E.E$.2E4$5.3A$6.A$6.3A!
rowett wrote:When defining a custom colour set you must specify colours for all states.
If you default to Golly's fallback colors (see above) then there's probably no need to show error messages for un-defined colors. A given pattern may not use all of a rule's colors, anyway -- in which case why require adding lots of extra COLOR commands that won't be used, as in the above sample?

Re: Life tag testing

Posted: February 16th, 2015, 1:01 pm
by rowett
dvgrn wrote:LifeHistory doesn't really have enough states to be a good standard fallback. Lots of multistate rules will have ten or more states. For a default set I'd suggest using Golly's defaults for all 256 possible states.
Will do.
dvgrn wrote:Ah, I see what you've done there. You've avoided saying which one is spelled correctly... You kind of give it away with the way you spell it in the Help text for THEME, though. But then you use the Americanized spelling when you're showing error messages -- very puzzling.
I did debate removing the word "colour" from the Theme help text to maintain ambiguity and I may still do so.
Regarding the Americanized spelling for the error messages, it uses the most recent spelling it saw before needing to display an error. In the case in your post you used COLOUR and then COLOR. So by the time it was checking if you'd missed any states COLOR was the last spelling it saw.
dvgrn wrote:
rowett wrote:When defining a custom colour set you must specify colours for all states.
If you default to Golly's fallback colors (see above) then there's probably no need to show error messages for un-defined colors. A given pattern may not use all of a rule's colors, anyway -- in which case why require adding lots of extra COLOR commands that won't be used, as in the above sample?
At the moment missing colours are defaulted to white. But I'm happy to default them to the Golly fallback set.
By the time the script is being processed I do know which states have been used in the pattern. Perhaps it would be more helpful to raise an ever if a state actually used is missing a colour definition?

Re: Life tag testing

Posted: February 16th, 2015, 2:21 pm
by rowett
Build 129:
  • The default colour set is now Golly's default for all 256 possible states
  • When creating a custom colour set (with the COLOUR or COLOR script commands) errors are only generated for missing colours for states actually used in the pattern
  • Missing custom colour states are defaulted to Golly's default
  • Help text for THEME no longer includes a possible correct spelling for colour or color

Re: Life tag testing

Posted: February 16th, 2015, 2:59 pm
by dvgrn
rowett wrote:Build 129:
  • The default colour set is now Golly's default for all 256 possible states
  • When creating a custom colour set (with the COLOUR or COLOR script commands) errors are only generated for missing colours for states actually used in the pattern
  • Missing custom colour states are defaulted to Golly's default
  • Help text for THEME no longer includes a possible correct spelling for colour or color
Now that we've dodged the color/colour wars, the philosophical question of the day is obviously this:

Does RLE really include a zero state, or does it function more like a transparent GIF -- locations left blank are assumed to be the background state?

I'm leaning toward the "transparent" answer, because other answers lead to strange places: imagine pasting a rectangular chunk of RLE onto a nonzero-state background. If RLE is really specifying state 0, then the left side of the bounding box will change to state 0, along with any zero cells in the middle of the pattern. But the right side of the bounding box will retain the background state, because the RLE convention is that you start a new line as soon as you've coded the last nonzero cell.

This is just a long way of saying that it doesn't seem necessary to display an error message for a missing state-0 color -- a silent fallback to Golly's default zero color will be exactly what is wanted 99% of the time.

In fact, I'm not sure but what those missing-color error messages will be more annoying than useful for nonzero states as well. I could see myself fixing "the colors that matter" in a JvN29 pattern, let's say -- just the stable states, basically -- but once the pattern is looking good in the viewer I might not really want to bother to define colors for all the transitory states, even if they happen to be visible as isolated dots here and there.

Not sure how to arrange it so that COLOR errors like these can be made visible if someone wants to see them, but aren't cluttering up the viewer on startup by default.

Re: Life tag testing

Posted: February 17th, 2015, 12:10 am
by Nathaniel
OK, the "viewer" tag is now live (along with its publicly-viewable button), and the [liferle] tag no longer works. The most recent build of LifeViewer (build 129 I think?) is now hosted locally on the conwaylife.com server as well.

Dave: Feel free to announce it any time now :)

Code: Select all

bo$2bo$3o

Re: Life tag testing

Posted: February 17th, 2015, 3:10 am
by rowett
dvgrn wrote:Not sure how to arrange it so that COLOR errors like these can be made visible if someone wants to see them, but aren't cluttering up the viewer on startup by default.
Sounds like the default behaviour should be to ignore missing colours. I do believe it would be helpful to allow the user to elect to see missing colours. Perhaps I could add a script command to turn on the extra validation and also enhance the error message to report the default colour used:

Code: Select all

COLOR 0 definition missing used 48 48 48
Thoughts?

Re: Life tag testing

Posted: February 17th, 2015, 3:12 am
by rowett
Nathaniel wrote:OK, the "viewer" tag is now live
Excellent, nice job :D

Re: Life tag testing

Posted: February 17th, 2015, 8:00 am
by rowett
rowett wrote:Missing custom colour states are defaulted to Golly's default
Thinking about this some more, would it make sense to default a missing colour to that of the rule's colour set? For example if the pattern uses the LifeHistory rule the default would be to use the LifeHistory colour set. You may then choose to redefine one or two state colours with the COLOR or COLOUR script command.
So perhaps this should be:
Missing custom colour states are defaulted to the rule's default, or Golly's default where no rule default exists

Re: Life tag testing

Posted: February 17th, 2015, 1:42 pm
by dvgrn
rowett wrote:I do believe it would be helpful to allow the user to elect to see missing colours. Perhaps I could add a script command to turn on the extra validation and also enhance the error message to report the default colour used:

Code: Select all

COLOR 0 definition missing used 48 48 48
Sounds like a fine idea. Once we have an extra-validation-message-readout page, there will probably be other uses for it (that I haven't thought of just yet).
rowett wrote:Missing custom colour states are defaulted to the rule's default, or Golly's default where no rule default exists.
Somehow I didn't think of that, but that sounds obviously right also.

In other news, I patched all the relevant "liferle" tags last night (I think), and posted a quick announcement about the viewer. Didn't explain everything in detail, mostly because it seems to me that the viewer help does that really well, so I just pointed to that. Also found an excuse to use the viewer in another thread. So far it's all looking really good!

Nathaniel, here's an utterly insignificant detail: all the other buttons at the top of the message editing window have the first letter capitalized, but "viewer" doesn't.

EDIT: Now that I look again, there's definitely something strange going on with the non-viewonly LifeBellman rule sample. LifeBellman has only six states, and without VIEWONLY it's supposed to get collapsed to two-state anyway (or isn't that true any more?). But we can see dozens of different Golly default colors as the viewer runs the pattern in B3/S23.

New sample, no scripting:

Code: Select all

x = 39, y = 26, rule = LifeBellman
12.2A$11.A2.A9.A$11.2A.A7.3A$12.2A7.A$21.2A$15.3A$7.A7.A$8.A2.A3.2A.A
5.15E$11.A3.A2.A5.15E$2.2A2.A.A4.2A9.15E$.A.A9.A4.A5.15E$.A21.16E$2A
9.2A.A2.2A4.16E$11.A3.A2.A5.C14E$12.A4.A6.C14E$14.3A5.3C14E$21.C3.14E
$21.C.C2.13E$22.C.C.13E$24.C.13E$24.C.13E$18.C.C.C.C.13E$17.C.C19E$
18.C.19E$20.19E$20.19E!
With AUTOSTART: EDIT: problem fixed with build 133 --

Code: Select all

x = 39, y = 26, rule = LifeBellman
12.2A$11.A2.A9.A$11.2A.A7.3A$12.2A7.A$21.2A$15.3A$7.A7.A$8.A2.A3.2A.A
5.15E$11.A3.A2.A5.15E$2.2A2.A.A4.2A9.15E$.A.A9.A4.A5.15E$.A21.16E$2A
9.2A.A2.2A4.16E$11.A3.A2.A5.C14E$12.A4.A6.C14E$14.3A5.3C14E$21.C3.14E
$21.C.C2.13E$22.C.C.13E$24.C.13E$24.C.13E$18.C.C.C.C.13E$17.C.C19E$
18.C.19E$20.19E$20.19E!
[[ AUTOSTART ]]
Thumbnail mode:

Code: Select all

x = 39, y = 26, rule = LifeBellman
12.2A$11.A2.A9.A$11.2A.A7.3A$12.2A7.A$21.2A$15.3A$7.A7.A$8.A2.A3.2A.A
5.15E$11.A3.A2.A5.15E$2.2A2.A.A4.2A9.15E$.A.A9.A4.A5.15E$.A21.16E$2A
9.2A.A2.2A4.16E$11.A3.A2.A5.C14E$12.A4.A6.C14E$14.3A5.3C14E$21.C3.14E
$21.C.C2.13E$22.C.C.13E$24.C.13E$24.C.13E$18.C.C.C.C.13E$17.C.C19E$
18.C.19E$20.19E$20.19E!
[[ THUMBNAIL AUTOSTART ]]
Now I'm thinking that it's a little odd to collapse a multistate pattern to two-state by default -- the odds are very high that that will change the pattern's behavior, more or less randomly, and display something that the user didn't intend. Can "viewonly" be the default for multistate patterns -- except possibly for LifeHistory as a special case? Maybe it would make more sense to have an OPPOSITE-OF-VIEWONLY tag instead, or also.

Is there a use case for adding VIEWONLY to a Life-like pattern that the viewer could perfectly well run with no guesswork?

Not sure what the OPPOSITE-OF-VIEWONLY tag should really be called, though -- COLLAPSE? FLATTEN? TWOSTATE? REDUCE?