Life tag testing

[rowett]

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.

Two things going on here:

1. LifeViewer believes that only LifeHistory rules are able to be collapsed and so hasn't tried to collapse LifeBellman. What should have happened is that VIEWONLY should have been enforced. It nearly worked (the menu disappeared and the play control keys were switched off) but unfortunately due to a bug it didn't disable AUTOSTART.
2. The long list of colours in the help information is because in build 129 you get a list of all colours in the colour set (in this case because there's no specific set for LifeBellman it's using the default set, which is the Golly 256 colour set).

The good news is that all of this is fixed in build 130:

• missing custom colours now use the corresponding state colour from the rule's set (or default set if no rule set exists)
• missing colour errors now display the RGB value substituted
• improved the information display of the colour set name to display either:
  • the name of a predefined rule set if one exists (e.g. "LifeHistory", "WireWorld", etc.)
  • the word "(default)" if no rule set was found (and the Golly default colour set is used)
  • the word "(custom)" if all states used in the pattern have a custom colour defined (using the COLOR or COLOUR script commands)
  • the name of the rule set or default followed by "(custom*)" if some but not all states used in the pattern have a custom colour defined (e.g. "LifeHistory (custom*)")
    • in this case the information display shows a "*" against each custom colour in the list
• only states used in the pattern are displayed in the information display colour list
• added hotkey 'V' to reset camera view (without resetting generation)
• removed error report for STOP generation being later than LOOP generation since you can disable LOOP with pause and then continue to the STOP
• fixed a problem which allowed non-LifeHistory multistate rules to be AUTOSTART when VIEWONLY wasn't specified (in this case VIEWONLY is enforced and AUTOSTART reported as a script error)
• help and errors are not displayed in thumbnail view but are retained across thumbnail toggle
• slightly reduced notification font size
• added a new script command [[ STRICT ]] which enables strict script validation (this is off by default)

Nathaniel, as before build 130 is on the lazyslug server.

[rowett]

Can "viewonly" be the default for multistate patterns -- except possibly for LifeHistory as a special case

Yes this is the default. It just wasn't working properly in build 129.

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

Yes this works fine already. You may have a pattern you want to show but don't want people to play.

There's probably also a use case for wanting an even further locked down Viewer that doesn't allow any interaction at all (no zoom, pan, etc., i.e. just a static image viewer). If that sounds interesting let me know and I'll add it to the to do list.

For reference the current to do list is as follows:

• Waypoints
• Custom Themes
• Script error list should scroll like help
• Fix pattern reader so it reads multistate patterns with more than 26 states

[Sokwe]

Whenever I click "select all" in the code part of the viewer and copy it, it seems to add a space character to the beginning. This causes the pattern to not be read properly when pasting into Golly. As I recall, this was also a problem with the code tags early on.

[rowett]

Whenever I click "select all" in the code part of the viewer and copy it, it seems to add a space character to the beginning. This causes the pattern to not be read properly when pasting into Golly. As I recall, this was also a problem with the code tags early on.

Hi Matthias,
From my testing it looks like Firefox is adding a space before and after the code, whereas Chrome, IE and Opera do not. Please can you confirm which browser you are using?

Many thanks,
Chris

[rowett]

Hi Matthias,
From my testing it looks like Firefox is adding a space before and after the code, whereas Chrome, IE and Opera do not. Please can you confirm which browser you are using?

Hi Matthias,
Thanks for reporting the problem. No need to confirm your browser, I've figured out what's wrong.

Nathaniel,
We need to adjust part of the output of the "Viewer" BBCode from:

Code: Select all

<div>
    <code>bo$2bo$2o!</code>
</div>

to:

Code: Select all

<div><code>bo$2bo$2o!</code></div>

That should remove the extra spaces around the Firefox select all.

[rowett]

Build 131 is available on the lazyslug server:

• The code block height is only set to 2.5 lines if it is greater than 2.5 lines
• Faster start up time for each Viewer
  • Start up time is typically 67% of the start up time in previous builds
  • Start up time for a Viewer that uses the same rule as the previous Viewer on the page is reduced further to typically 25% of that in previous builds

[dvgrn]

Build 131 is available on the lazyslug server...

I tried out Build 131 locally -- haven't seen any interesting new bugs yet.

Any advice as to embedding the viewer in non-conwaylife.com web pages? I had some mysterious trouble with line breaks when I was quoting RLE in my test HTML. In particular,

Code: Select all

			<div class="content"><div class="rle">
    <div class="codebox">
        <div class="selall">Code:
            <a href="http://conwaylife.com/forums/viewtopic.php?f=2&t=1623#" onclick="selectCode(this); return false;">Select all</a>
        </div>
        <div>
<code>#C [[ AUTOSTART HEIGHT 500 LOOP 160 THEME 4 ]]<br>x = 127, y = 101, rule = B3/S23<br>
41b2obo$41bob2o2$42b5o$37b2o2bo4bo$37bo2bo2bo$38bobob2o$37b2obo5bo$40b<br>
o4bobo$40b2o2bo2bo$45b2o14$50b3ob3o$50bo5bo$50bo5bo$51bo3bo$43b2o7b3o<br>
12b2o9b3o$44bo21bo2bo11bo$41b3o23b2o8bo3bo$41bo34bobo2bo$74bo2bobo$74b<br>
o3bo$74bo$75b3o$72bo46bob2o$50b2o19bobo45b2obo$51bo19b2o$48b3o24b2o40b<br>
5o$48bo26bobo17b2o20bo4bo2b2o$19b2o3b2o44b2o5bo18bo23bo2bo2bo$19b2o2bo<br>
b3o42b2o5b2o17bobo7bo13b2obobo$23bo4bo68b2o7bo10bo5bob2o$19b4ob2o2bo<br>
76bobo8bobo4bo$19bo2bobobob2o77bo8bo2bo2b2o$22bobobobo76b2ob2o3bo3b2o$<br>
23b2obobo57b2o18bo3bo3bo$27bo59bo22bo4bo$87bobo18b4o3bo$13b2o73b2o16b<br>
2o$14bo7b2o81b3o3bo3bo$14bobo5b2o69bo11bo2bobo4bo$15b2o75bo12b2o6bo$<br>
92b3o11bo4b2o$106b2ob2o$2bo105bo2$ob3o76bo$2b2obo39b3o31bobo$2bob2o19b<br>
2o20bo32b2o$3b3obo17bo20bo$15b2o9b3o$5bo8bobo6bo4bo$9bo6bo4b3o24bo$8bo<br>
bo9bo27b3o46bo$9b2o9b2o29bo44bobo$5b2o43b2o44bobo$4bobo53b2o35bo$4bo5b<br>
2o48bo23b2o$3b2o5b2o46bobo23b2o2b2o$52b2o4b2o28bobo$51bo2bo34bo$52b2o<br>
38b3o$40b2o18bo25b2o3bo$40b2o18b3o24bo3bo3bo$16b3o34b3o7bo20b3o4bo2bob<br>
o$15b5o33bo8b2o20bo8bobo2bo$14b2o3bo34bo39bo3bo$8b2o4b5o79bo$8b2o3b4o<br>
78b3o$12b3o$12b2o$13b2o34b2o3b2o$14bobo12b2o19bo3bo17b2o$14b3o12bobo<br>
15b3o5b3o7b2o5bobo$13bob2o14bo15bo9bo7b2o7bo$13b2o4bo11b2o41b2o$15bo3b<br>
2o$14b3o3b2o39bo$13b2obobo41bobob2o$12b2o2bobo41bobobobo3b2o$12b2o4bo<br>
40b2obobobo2bobo$17bo42bo2b2ob4obobo$58bobo4bo6b2o$58b2o5bobo$66b2o2$<br>
20bobo$21b2o$21bo!</code>
        </div>
    </div>
    <canvas width="656" height="500" style="margin-left:1px;" tabindex="1"></canvas>
</div></div>
		</div>

works fine, but

Code: Select all

...
<code>#C [[ AUTOSTART HEIGHT 500 LOOP 160 THEME 4 ]]<br>
x = 127, y = 101, rule = B3/S23<br>
41b2obo$41bob2o2$42b5o$37b2o2bo4bo$37bo2bo2bo$38bobob2o$37b2obo5bo$40b...

gives an "invalid pattern" error. The only difference is the whitespace before the RLE header line. Replacing that <br> between the comments and the header line with <br /> seems to have the same bad effect.

[rowett]

I had some mysterious trouble with line breaks when I was quoting RLE in my test HTML.

Build 132 is your friend...

• RLE pattern reader now copes with blank lines between comments and header
• mouse wheel will now scroll help text

[rowett]

Any advice as to embedding the viewer in non-conwaylife.com web pages?

This is how it's integrated into the conwaylife.com webite, however it's a bit conwaylife.com specific:

• It expects there to be a <div class="rle"> element containing two elements:
  • A <code> element containing the pattern definition
  • A <canvas> element to draw on
• It dynamically sets the height of the <code> element to no more than 2.5 lines
• It hides the <canvas> element if no support is found in the browser for the Viewer
• It uses a window "load" event to trigger Viewer start
• It uses the width of the <code> element as a maximum width for the <canvas>

My intention is to use a <meta> tag to parameterise the <div> class name, <code> element name, flag to control whether to modify the <code> element height and flag to control whether to hide the <canvas> element. This way it will be much easier to integrate into a non-conwaylife.com site. It's on the to do list...

[rowett]

Build 133 is available which adds parametrisation of LifeViewer configuration to make it easier to embed in websites. Basic instructions for embedding are below.

• Include the LifeViewer Javascript plugin "lv-plugin.js". You will need to change the <script> tag to point to where you have installed it.
• Create a <meta> tag with a name of "LifeViewer" in your webpage <head> section

  Code: Select all

  <html>
      <head>
          <meta name="LifeViewer" content="viewer textarea 30 hide limit">
          <script src="js/lv-plugin.js"></script>
      </head>
  </html>

• The content is a list of two mandatory words in a specific order and then up to three optional words in any order:
  • "viewer" - the class name of the <div> that wraps the element containing the pattern definition and the <canvas> element
  • "textarea" - the name of the element containing the pattern definition (in one of the supported pattern formats, typically RLE)
  • (optional) "30" - if specified then sets the height in pixels of the element containing the pattern definition
  • (optional) "hide" - if specified then hide the <canvas> element if the browser doesn't support LifeViewer
  • (optional) "limit" - if specified then limit the width of the LifeViewer to the width of the element containing the pattern

The example below shows how you embed LifeViewer in your page with the glider pattern. In this case without limiting the LifeViewer width to the <textarea>, without limiting the <textarea> height, but still hiding the LifeViewer if the browser doesn't support it (since we specified "hide").

Code: Select all

<html>
    <head>
        <meta name="LifeViewer" content="viewer textarea hide">
        <script src="js/lv-plugin.js"></script>
    </head>
    <body>
        <div class="viewer"><textarea>bo$2bo$3o!</textarea><br><canvas width="480" height="480"></canvas></div>
    </body>
</html>

If you omit the <meta> tag then it defaults to the conwaylife.com settings:

Code: Select all

<meta name="LifeViewer" content="rle code 37 hide limit">

[dvgrn]

I guess it works to leave new-build announcements here on this mostly-invisible thread. Once Build 133 shows up on the conwaylife.com servers, maybe it makes sense to post the details as an answer to Scorbie's question on the announcement thread. We're still at Build 129 as of the morning of 19 Feburary.

Build 133 looks like great work as usual. I have a busy weekend coming up, so I'll try to get a little testing done early next week -- maybe rebuild Calcyman's stable-reflectors article as an HTML document with viewer thumbnails.

Thanks again for all the time and effort you've put into this! It's wonderful to see this viewer idea working out so well in practice -- people are slowly picking up on the new feature, and eventually I think it will get quite a bit of use.

[rowett]

I guess it works to leave new-build announcements here on this mostly-invisible thread.

I'll shift announcements to your "Pattern viewer for forum threads" topic in the "Website Discussion" forum once Nathaniel has shipped build 133 and made the adjustment to the BBCode generation I mentioned ealier (to fix the Firefox-extra-spaces-when-you-select-code-debacle).
At that point, as you suggest, I'll copy my instructions to that thread to answer Scorbie's question. But it would be great to have you test it first and let me know if my instructions are accurate!

Thanks again for all the time and effort you've put into this!

My pleasure I've much enjoyed it. Many thanks to you and Nathaniel for all the support.

[Nathaniel]

Changes uploaded to ConwayLife.com. Thanks so much Chris for your excellent work with this And Dave too for testing and making suggestions, of course

[rowett]

Hi Nathaniel,
When you get a moment would you mind adjusting the "viewer" button so it says "Viewer"?

[dvgrn]

Thanks for posting the answer to Scorbie. I tried following those instructions last night, and again this morning figuring I was just doing something silly. Apparently I'm still doing something silly. Could you maybe add to your Scorbie reply a ZIP file containing a working example -- some simple-as-possible HTML plus a copy of the viewer Javascript file in the right relative location?

See attached for my mysteriously non-working example:

sample-HTML.zip

One working sample with bug, and one non-working minimal (or I guess sub-minimal) sample

(105.53 KiB) Downloaded 6 times

I saved the previous page from this thread and got a perfectly good working chunk of HTML with embedded viewers... but it will take a while to delete unnecessary junk until it mysteriously stops working.

I've attached that sample, because there's something odd happening to viewers that are set to [[ THUMBNAIL ]]. On the saved page, they show up at half height, both in the thumbnail view and after they're expanded. I did a spot edit to add "HEIGHT 480" to one of them, and as I somehow suspected, specifically setting a viewer height fixes the problem.

[rowett]

Apparently I'm still doing something silly.

Hi Dave,
Firstly, thanks for testing this for me. Your Hello-viewer.html has the <canvas> outside the <div class="viewer">. Both the <textarea> and <canvas> must be inside the <div>.

You had:

Code: Select all

<div class="viewer">Hello World...<br><br>
    <textarea>#C [[ THUMBNAIL ... ]]
    x = 26, ...
    19bo$18...
    </textarea>
</div><canvas width="480"...>

You need to move the <canvas> inside the <div>:

Code: Select all

<div class="viewer">Hello World...<br><br>
    <textarea>#C [[ THUMBNAIL ... ]]
    x = 26, ...
    19bo$18...
    </textarea><canvas width="480"...>
</div>

With that small change it will work.

Also if you take the example code from my Build 133 announcement post above that will work also. I've updated my post in the Website Discussion forum to hopefully make this clearer.

Finally if you look at http://lazyslug.no-ip.biz/lifeview/plugin/test.html you can see multiple Viewers all in a simple page.

[rowett]

Build 134 is available and adds support for custom Themes. Note that Themes are only available for patterns that can be executed. Multi-state patterns use colour Sets to specify the colour for each state.

• You can now specify a custom Theme.
  • The COLOUR and COLOR script commands can now take a Theme element. There are five Theme elements that can be defined:
    • BACKGROUND - defines the background colour (where Life has never existed)
    • ALIVE - defines the colour when a cell first becomes alive
    • DEAD - defines the colour when a cell first dies
    • (optional) ALIVERAMP - defines the colour a cell will fade to when it has been alive for 64 generations
    • (optional) DEADRAMP - defines the colour a cell with fade to when it has been dead for 63 generations
  • As a minimum the ALIVE colour and one of BACKGROUND or DEAD must be defined
  • The 'C' hotkey will cycle through built-in Themes 0 to 9 and then Custom Theme if defined
  • The current Theme definition is displayed in the help information
• The <meta> tag "limit" word now both limits the width of the LifeViewer to that of the associated element containing the pattern definition and also sets that as the default width
• The maximum allowed width has been increased to 1024 pixels
• You can now scroll the script error list with the cursor keys, page up and page down, and the mousewheel
• Fixed an issue with the Life 1.05 and Life 1.06 decoders that would fail to read the last cell if there wasn't a trailing newline

Here are some example colour Themes:

1. Alive cells are white, dead are black

   Code: Select all

   [[ COLOR ALIVE 255 255 255
   COLOR DEAD 0 0 0 ]]

2. Alive cells are white, dead are black, cells never occupied are dark blue

   Code: Select all

   [[ COLOR ALIVE 255 255 255
   COLOR DEAD 0 0 0
   COLOR BACKGROUND 0 0 128 ]]

3. Cells never occupied are grey, cells just born are red and fade to white as they stay alive, cells just died are green and fade to black as they stay dead

   Code: Select all

   [[ COLOR BACKGROUND 96 96 96
   COLOR ALIVE 255 0 0
   COLOR ALIVERAMP 255 255 255
   COLOR DEAD 0 255 0
   COLOR DEADRAMP 0 0 0 ]]

[dvgrn]

Just ended up accidentally on the LifeWiki Help page, starting from LifeWiki:Pattern Pages. The Help page explains a lot about how to use the nonexistent Java applet.

I tried editing out the link to the Help page from "Pattern pages", and made a few other changes there. But is it possible that the viewer could be useful on the LifeWiki somehow, as a partial replacement for the Java applet?

[rowett]

But is it possible that the viewer could be useful on the LifeWiki somehow, as a partial replacement for the Java applet?

I'm fairly sure it could help however I never saw the Java applet so it's hard to comment. What functionality did it have?

In fact I've been working recently in having it load it's pattern from a file saved elsewhere on the WebSite rather than from an element on the current page, since I've seen other sites that would need this functionality. For example you might have a "patterns" folder on your WebSite containing rle or other format files.

[dvgrn]

But is it possible that the viewer could be useful on the LifeWiki somehow, as a partial replacement for the Java applet?

I'm fairly sure it could help however I never saw the Java applet so it's hard to comment. What functionality did it have?

The Java applet used to be the landing page for http://www.conwaylife.com. It allowed people to load and save named patterns, and you could click a link from an object page on the LifeWiki and load that pattern into the Java applet to display and run it online, without having to copy into Golly.

The Java applet could also create standard-looking PNG images and animated GIFs, once a pattern was loaded. These could be used in LifeWiki articles or as avatar images on the forums.

The Java applet was apparently one way that Nathaniel collected pattern files to add to the sidebars of LifeWiki object pages. It would be nice if there were a really easy way to send in candidate RLE to add to specific pages. Not that it's at all difficult at the moment -- it just requires sending an email to [email protected] with an RLE file attachment. I simply have never gotten in the habit of putting together those emails, whenever I see that a file is missing.

The way RLE submissions are currently done is described here, with a sample email text in the References section at the bottom. Notice also the checklist just above References, which still says "create it in Conwaylife" for several items.

It seems that Nathaniel's talk page also sees some activity along these lines. That seems to work also. I notice that codeholic always includes a link, either in the message text or in the comments or both, to the article that the RLE is supposed to end up in.

[That all might be kind of an aside, as far as the viewer goes -- I just realized that this has been the reason I haven't fixed more missing RLE when I saw it. I've been subconsciously a little worried about which of these upload methods is "right"...!]

One more big thing: the Java applet allowed pattern editing using the mouse, so that's an obvious difference between it and the viewer. I don't think it's necessarily very high on anyone's wish list for that functionality to come back, though: once you're doing serious editing, it seems worth firing up Golly, with its unlimited Undo system, selections, etc. It might be nice just to be able to paste in, load, and then name pattern files, so that the patterns can be retrieved later.

Nathaniel will have a much better idea what might actually be useful on the LifeWiki, though. I'm just reporting how things look from my side...!

[Nathaniel]

Not that it's at all difficult at the moment -- it just requires sending an email to [email protected] with an RLE file attachment. I simply have never gotten in the habit of putting together those emails, whenever I see that a file is missing.

Actually Dave, you (and most other mods) can upload pattern files directly at the moderator control panel - no need to e-mail me to do it:

http://www.conwaylife.com/mod.php

But yeah, it's *yet another* place to log into on this site, and admittedly isn't integrated with the rest of the site very well (send me a message/e-mail if you've forgotten your username/password).

As for LifeViewer on the wiki -- it sounds like a great idea. Give me a few days to think on it though and ponder how exactly it could be integrated best.

[Nathaniel]

Well, I've thought about it some more, and I'm still undecided about the best way to incorporate the viewer into the wiki, so I might as well ask for feedback

On the wiki, we have a lot more control (partly because I'm much more comfortable messing with the guts of MediaWiki than I am with phpBB), so I can fairly confidently say we can do more or less anything we want to with the viewer in the wiki. So one natural thing to do would be to have a {{Viewer}} template on the wiki, which works much like other MediaWiki template (i.e., takes a list of named parameters that configure how the viewer looks).

So, for example, if the user typed {{Viewer|code=bo$2bo$3o}} in the wiki source code to embed a LifeViewer for that pattern there. And then there would be other optional parameters to handle formatting the viewer (e.g., something like {{Viewer|code=bo$2bo$3o|mode=thumbnail|width=640}}).

My main question is: do we want there to be an "external" viewer that people can click to for each pattern as well? Back when we had the Java applet, there was a link (below the "Animated image" link in the right-side infobox) to the pattern in the Java applet. Should we have a link there to an external viewer with the image in it? Or maybe a viewer that opens up overlaid on top of the current wiki page?

[rowett]

My main question is: do we want there to be an "external" viewer that people can click to for each pattern as well? Back when we had the Java applet, there was a link (below the "Animated image" link in the right-side infobox) to the pattern in the Java applet. Should we have a link there to an external viewer with the image in it? Or maybe a viewer that opens up overlaid on top of the current wiki page?

I'm not really qualified to answer since the Java applet was before my time and I've not really used the Wiki. But from a technical standpoint all things are possible. I'll leave it to the more experienced to decide

[rowett]

Build 135 and then Build 136 were released on the lazyslug server!
Build 135

• added grid line display (not displayed by default)
  • will only display at zoom levels >= 4 and at angle 0
  • hotkey 'X' to toggle
  • script command "GRID" to enable on startup
  • "COLOR GRID R G B" will define grid line colour (or "COLOUR GRID R G B")
• correctly handle ":" character in rule name
• added "shapeloop-b" and "2armshapeloop-a" to the "shapeloop" colour set

Build 136

• added major grid lines to grid line display
  • script command "GRIDMAJOR <0..16>" to define interval (default = 10, no major lines = 0, all major lines = 1)
  • script command "COLOR GRIDMAJOR R G B" to define colour (or "COLOUR GRIDMAJOR R G B")
  • grid is now drawn over the bottom layer rather than over the top layer
  • grid state and colours are now displayed in the help information
• extended multi-state support to 256 states
• corrected multi-state fit zoom to display for non-LifeHistory rules

[dvgrn]

Back when we had the Java applet, there was a link (below the "Animated image" link in the right-side infobox) to the pattern in the Java applet. Should we have a link there to an external viewer with the image in it? Or maybe a viewer that opens up overlaid on top of the current wiki page?

I'm not really qualified to answer since the Java applet was before my time and I've not really used the Wiki. But from a technical standpoint all things are possible. I'll leave it to the more experienced to decide

Well, I was already used to Golly when the Java applet showed up, so I was never much tempted by it. I suspect that the people who most want the applet back are users of locked-down systems where it's not easy to install CA editing software.

Golly doesn't actually have an installer or need admin permissions on most systems, so maybe people just don't know how easy Golly is to download, or maybe their systems are really locked down to browser-only -- a Chrome OS Chromebook, for example, or some other hobbled system that won't allow decompression of downloaded ZIPs.

Anyway, my guess is that a simple CA editor would be of more interest to these people than a viewer. If so, it's probably not necessary to link to an external viewer from object pages on the LifeWiki -- you can already usually see the object, and often even an animated version of it is available. An option to open a new window overlaid on the wiki page might make some sense, or possibly an expandable thumbnail similar to the way the viewer now works in the forums. Without the code box, probably -- though maybe there could be an option to toggle a code-box view with RLE to be copied (?).

Build 136 seems to be getting close to an HTML5 equivalent of another of the Java applet's abilities -- the creation of animated GIFs representing moving patterns, with major and minor gridlines to make the object's motion clear. Adding in the waypoint editor on the current To Do list should do the trick very nicely...!

Maybe an animated GIF would still be more efficient, though, or would allow more browsers to be supported? Not sure on this. In general it could certainly be handy to have a viewer that could translate RLE directly into images ( VIEWONLY ) or animations ( AUTOSTART ). But would people start to rely on this too much instead of using simple image files, and break LifeWiki entries for people whose browsers don't support HTML5? Or do non-HTML5 browsers even matter any more?