ConwayLife.com

dvgrn wrote:I like the 2.5-row code block -- hope everyone else does too... So what else is on the list to be updated before this is ready for prime time?

I like it too, and as far as I'm concerned, this is good to deploy any time.

Hi Dave,

dvgrn wrote:When I try Ctrl+mousewheel outside of the Viewer, and thus change the text size to 150% or 75% or whatever, the Viewer scales appropriately and everything still seems to work very well -- except for the new zoom-around-mouse-cursor functionality, which appears to get a little bit confused by the scale change.

Well spotted! The browser scaling was actually causing problems with both the menus and the zoom in the Viewer. It was subtle since it worked fine at any browser scale (100%, 110%, 50%, etc.) until you changed the zoom level. I've fixed it in build 120 but won't be anywhere I can upload the build until Wednesday evening my time.

dvgrn wrote:So what else is on the list to be updated before this is ready for prime time?

Nothing else on my list. Next steps would be:
1. Upload and test build 120
2. Assuming testing passes then host build 120 on the ConwayLife.com site.
3. Decide on the name of the BBCode directive (currently "liferle")
4. Add a new button to the POST A REPLY editor to generate the BBCode directive (like "Quote", "Code", "List" etc.)
5. Post a message in the appropriate forum announcing the new capability and perhaps create a sticky thread for suggestion and bug reports.

Nathaniel wrote:I like it too, and as far as I'm concerned, this is good to deploy any time.

Very exciting! There has been a discontented minority on the forums for years, generally less mathematically oriented and more visually oriented, who like to see pictures of what people are talking about. But faced with a chunk of RLE gibberish, they're not terribly motivated to fire up Golly and try a copy/paste to see what it really looks like... especially if a rule file has to be installed as well.

This raises a question that last came up in the email discussion last year (29 October 2014): might it make sense for the Viewer to display (zoom, pan, rotate, etc.) patterns from multistate rules, just disabling the Play button? Or a variant of the Viewer, anyway?

-- Yes, multiple states, assignment of colors to states, and so on, would be a huge can of worms -- my apologies for bringing it up again. First draft would be to simply collapse all states >1 to state=1.

There's been fairly steady use of the LifeHistory rule on the forums lately, since it supports marked objects and labels and "safe zones" (surround stamp collections with state-6 fences, so that gliders don't get away and mess up neighboring patterns.)

With the Viewer the fences aren't so important any more, because we can put in a STOP or LOOP command to keep patterns from running farther than they're supposed to. It would still be nice to be able to see the labels in the initial pattern, though, without copying into Golly. Quite a few patterns have labels or other markings in state 2 or state 4 -- e.g., Calcyman's elementary-conduit stamp collection.

I admit, I should make a version of that pattern with better labels anyway... but in general, the extra states do convey useful information. If the option were available -- that is, if I could choose case-by-case between the current two-state viewer that can run the pattern, and a display-only viewer that would just make the different states visible -- I'd probably choose the display-only version for many of my recent LifeHistory posts. Here's a recent one from Kiho Park that would certainly make a lot more sense as a display-only multistate view:
Even without general multistate display support, LifeViewer has its special colors for fading recently-dead cells, which would make very nice LifeHistory state-2 cells -- but that's horribly specific special pleading, I suppose.

Just by the way, another new rule that's somewhat reducible to Conway's Life is Michael Simkin's LifeBellman rule, which is similarly useful for annotating search results.

Anyway, I guess people investigating non-Lifelike rules (Shapeloop, etc.) will mostly be left out of the LifeViewer fun as things stand -- whereas I think they might well use a display-only MultiStateViewer, if one were available.

------------------------

Separate question: should we do a test or two where we put Officially Way Too Many Viewers(tm) on a message thread, ones that loop large patterns at 60gps and so forth? I don't really know for sure yet if there might be people out there for whom such pages would suddenly be really slow to load, so that they wouldn't consider the viewers to be an improvement...!

I've uploaded build 120. Changes in this build are:

• Fixed zoom and menus not working properly after the browser zoom is changed
• Added a new script command [[ VIEWONLY ]] which prevents playback in the Viewer
  • The playback, generations per second and generation display controls will be hidden
  • Equivalent hotkeys will also be disabled
  • Navigation controls are still active so you can still zoom, pan and rotate
• Report an error if [[ LOOP ]] generation is earlier than [[ STOP ]] generation
  • It is valid to have both script commands for the same pattern
  • For example: [[ STOP 100 LOOP 150 ]]
  • Life will play until generation 100, stop, and then if you press play it will continue to 150 and then start again from 0
• The fit zoom hotkey was not updating the zoom control
• Fixed an issue with the Life 1.05 decoder if there was no terminating newline on the final row

Dave,
Here is your LifeHistory sample pattern in view only mode:

dvgrn wrote:This raises a question that last came up in the email discussion last year (29 October 2014): might it make sense for the Viewer to display (zoom, pan, rotate, etc.) patterns from multistate rules, just disabling the Play button? Or a variant of the Viewer, anyway?

Yes and build 120 now has a view only mode that disables play controls.

dvgrn wrote:Yes, multiple states, assignment of colors to states, and so on, would be a huge can of worms

I'm happy to have a go with multiple state rules but I need to better understand the requirements. Currently I just support LifeHistory by collapsing odd states to alive cells and even states to dead cells, which creates an executable pattern.
When the Viewer is put into view only mode I could change this behaviour (for multi-state RLE patterns) to draw each state in a different colour. Is this the requirement?
If so then we'd need:
a) A new collection of Themes defining the sets of colours for each state
and/or
b) A way of specifying colours for the states
Which reminds me at some stage I might add the ability to create your own custom Colour Theme.

dvgrn wrote:Separate question: should we do a test or two where we put Officially Way Too Many Viewers(tm) on a message thread, ones that loop large patterns at 60gps and so forth?

Good idea (and as with all good ideas you've already trademarked it )
In my testing I've only ever had about 8 Viewers on one page. In modern browsers it seems to work fine and all that happens is that the generations per second drops across all Viewers but the browser is still fairly responsive.
In old browsers (yes, Safari 5.1 and Opera 12.17, I'm looking at you) the browser itself becomes sluggish.
If it becomes a problem (i.e. we get complaints) then we could do one of:

• Only allow one Viewer at any one time to be running a pattern (the rest would be paused)
• Allow some user setting to allow users to opt out of having Viewers (which would fallback to just displaying the RLE)

There are probably other options too...

rowett wrote:I'm happy to have a go with multiple state rules but I need to better understand the requirements. Currently I just support LifeHistory by collapsing odd states to alive cells and even states to dead cells, which creates an executable pattern.
When the Viewer is put into view only mode I could change this behaviour (for multi-state RLE patterns) to draw each state in a different colour. Is this the requirement?

Yes, exactly. For any pattern where the RLE is recognizable but the rule isn't, retain the code-block copy option, but just display the pattern as a static image.

rowett wrote:If so then we'd need:
a) A new collection of Themes defining the sets of colours for each state
and/or
b) A way of specifying colours for the states
Which reminds me at some stage I might add the ability to create your own custom Colour Theme.

Any or all of those would be great. Maybe start with a few predefined theme options -- LifeHistory, YellowToRed8State, YellowToRed32State, ShamelesslyLiftedFromMCellPalette1, etc., etc. -- and then if you get around to it, add script commands to define colors and number of states for a theme called Custom...?

Might make sense to do some kind of survey of the forums and see which rules have the most patterns posted. Those would be the obvious candidates for predefined themes named the same as the rule.

Dave,
Build 121 adds basic multi-state pattern view support. In order to be displayed in this mode the pattern must have more than 2 states and the Viewer must be in [[ VIEWONLY ]] mode. Otherwise the multi-state pattern will be collapsed.

In multi-state viewing mode layers, layer depth and colour themes are disabled.

The colours at the moment are fixed and I've only defined colours for the first 7 states. See my post above with your LifeHistory pattern for an example.

rowett wrote:Build 121 adds basic multi-state pattern view support. In order to be displayed in this mode the pattern must have more than 2 states and the Viewer must be in [[ VIEWONLY ]] mode. Otherwise the multi-state pattern will be collapsed.

In multi-state viewing mode layers, layer depth and colour themes are disabled.

The colours at the moment are fixed and I've only defined colours for the first 7 states. See my post above with your LifeHistory pattern for an example.

Looks great! I think this is ready to show off to a larger audience, any time now.

Could do some more with themes and so on first if you want to. But it seems okay sometime soon to just say it's a work in progress, and see who gets the most excited about potential new features -- within reason, of course...

Here are a couple of copies of a random-sample multistate file, with and without the VIEWONLY tag. These are fairly big, and seem to take a bit longer to load. The pattern doesn't do anything meaningful when run as a regular Life pattern -- I'm just throwing random challenges at the viewer. I'm guessing this post will slow down all the AUTOSTART patterns on this page of messages -- though I don't actually see much reduction in speed. Might have to develop some new forum etiquette for using the viewer, I guess.

I'm starting to want PageUp and PageDown to scroll in larger than one-line increments -- 1/4 viewer height, maybe?

The ZOOM setting is working, but the X and Y script commands don't seem to be having any effect.

When I hit 'I' to toggle the Information view, at least the VIEWONLY version should probably report the actual rule name -- "LifeBellman" in this case. Also, is there a place where the current X and Y view setting is displayed? I'm not finding it offhand. Come to think of it, a toggle to display the current mouse cursor position would be really handy.
Here's a recent glider construction in plain-vanilla Life -- watch as it goes past T=100, when the pattern above it stops automatically. Seems totally acceptable so far. I see a slight speedup; your mileage may vary in different browsers.
EDIT: There's no way to use viewer controls to disable the LOOP 700 in this last pattern, is there? I can't decide whether I want a click on the Reset or Pause button to disable looping, similar to the way you can get past T=100 in the middle pattern, if you use the manual controls.

dvgrn wrote:I'm starting to want PageUp and PageDown to scroll in larger than one-line increments -- 1/4 viewer height, maybe?

Yes I'm not sure what to do about this. The intention of the help was that it wouldn't override any of the standard navigation controls, and cursor up and down are already used to move the pattern view. I did add "Home" and "End" so you can rapidly go to the top and bottom of the help text.
If you prefer I could kidnap cursor up and down while displaying help and have them scroll a line at a time, and then have PageUp and PageDown scroll a page (or half a page) at a time?

dvgrn wrote:The ZOOM setting is working, but the X and Y script commands don't seem to be having any effect.

Yes, sadly I broke X and Y in the last build. They are feeling better and fully recovered in build 122.

dvgrn wrote:When I hit 'I' to toggle the Information view, at least the VIEWONLY version should probably report the actual rule name -- "LifeBellman" in this case.

Yes it's on the list and leads to my own question: Is there a list of which rules can be successfully reduced to a Life-like rule (so I know which ones I can reduce to a S23/B3 style rule and execute)?

dvgrn wrote:Also, is there a place where the current X and Y view setting is displayed? I'm not finding it offhand.

No. Did you want the current script X and Y offset or the current bounding box of cells on the display?

dvgrn wrote:Come to think of it, a toggle to display the current mouse cursor position would be really handy.

Agree. I presume you want to know the cell X, Y that the mouse cursor is over?

dvgrn wrote:There's no way to use viewer controls to disable the LOOP 700 in this last pattern, is there?

No.

dvgrn wrote:I can't decide whether I want a click on the Reset or Pause button to disable looping, similar to the way you can get past T=100 in the middle pattern, if you use the manual controls.

Perhaps Pause to disable, and Reset to reinstate?
Note you can get past T=100 in the middle pattern by clicking on the Play or Pause button also.

Shamefaced confession: I had a perfect opportunity to post a soup-search discovery with a liferle tag just now. Let me know if it's going to cause trouble, and I'll undo it again quick... but at this point I'm really curious to see what people say.

rowett wrote:

dvgrn wrote:I'm starting to want PageUp and PageDown to scroll in larger than one-line increments -- 1/4 viewer height, maybe?

Yes I'm not sure what to do about this. The intention of the help was that it wouldn't override any of the standard navigation controls, and cursor up and down are already used to move the pattern view. I did add "Home" and "End" so you can rapidly go to the top and bottom of the help text.
If you prefer I could kidnap cursor up and down while displaying help and have them scroll a line at a time, and then have PageUp and PageDown scroll a page (or half a page) at a time?

Actually I like the idea of kidnapping the arrow keys, if that's possible -- can't see the pattern very well while the text is over it, so I never actually want to move the pattern around. I'm always surprised when the pattern moves instead of the text. Then probably PageUp/PageDown can do a full-page jump, same as in old builds.

rowett wrote:Is there a list of which rules can be successfully reduced to a Life-like rule (so I know which ones I can reduce to a S23/B3 style rule and execute)?

It's a short list. I'll think about it and put something together.

rowett wrote:

dvgrn wrote:Also, is there a place where the current X and Y view setting is displayed? I'm not finding it offhand.

No. Did you want the current script X and Y offset or the current bounding box of cells on the display?

Basically I want whatever numbers I would have to put into [[ ]] in the comments, to re-create the view I'm looking at (assuming a viewer of the same size.) An extra-credit trick might be to supply the exact text of the script settings -- ZOOM, X, Y, GPS, THEME, and all -- in a way that can be copied out. Probably the code box is already enough magic in that department, though.

rowett wrote:I presume you want to know the cell X, Y that the mouse cursor is over?

Yes. Not as important as the viewer-center readout, but still nice to have.

rowett wrote:

dvgrn wrote:I can't decide whether I want a click on the Reset or Pause button to disable looping, similar to the way you can get past T=100 in the middle pattern, if you use the manual controls.

Perhaps Pause to disable, and Reset to reinstate?

That certainly works for me if it works for you. Thanks!

dvgrn wrote:Shamefaced confession: I had a perfect opportunity to post a soup-search discovery with a liferle tag just now. Let me know if it's going to cause trouble, and I'll undo it again quick... but at this point I'm really curious to see what people say.

No problem from my side

dvgrn wrote:Actually I like the idea of kidnapping the arrow keys, if that's possible. Then probably PageUp/PageDown can do a full-page jump, same as in old builds.

Done in build 123. Cursor up/down = scroll one line at a time. Page up/down = scroll one page at a time. Home = to top. End = to bottom.

dvgrn wrote:Also, is there a place where the current X and Y view setting is displayed? Basically I want whatever numbers I would have to put into [[ ]] in the comments.

Done in build 123. It's on the information help page (key I).

rowett wrote:Perhaps Pause to disable, and Reset to reinstate?

Done in build 123. Pausing playback will cancel any LOOP. Resetting will restore it.

rowett wrote:Done in build 123. Cursor up/down = scroll one line at a time. Page up/down = scroll one page at a time. Home = to top. End = to bottom... [X and Y numbers are] on the information help page (key I)... Pausing playback will cancel any LOOP. Resetting will restore it.

Tested all three -- everything looks good.

Just noticed while writing this message using the "Quote" editor function, that the Viewer control shows up in the history pane -- under "Topic review: Life tag testing" -- but the Reset/Pause/Play/Display buttons don't work correctly with the default collapsed view, no matter what the browser zoom level is. If I click "Expand view" at the right, the buttons work fine.

I have remembered a few feature requests related to my new trial posting. Have mentioned some of them before... A couple of them seem fairly reasonable, at least by comparison to the last request.

1) When Autostart is turned on, there's no time to look at the initial pattern -- you only really see T=1 and later, even at a slow GPS setting. With GPS 1, there should be at least one second for the initial pattern to be displayed before the simulation starts. The initial state is often something people want to look at, so it would be nice if it were possible to add a DELAY (0-9, in seconds, maybe?) to display the pattern before starting to run it. Maybe an optional PAUSE at the end of a loop also?

2) It would be nice to be able to specify a nonzero DX and DY. This would allow a viewport to be set up that automatically moves to keep up with an interesting object, such as the LWSS-on-MWSS from the trial posting above.

3) Bring on the waypoint editor! This would probably take care of my items #1 and #2, as well -- e.g., I could start moving the viewpoint to follow the LWSS-on-MWSS only after it appears out of the soup, instead of being stuck with a pre-defined speed. A constant speed would be good for tracking a completed spaceship, but not so good for a complex spaceship synthesis (we have a lot of these to show off all of a sudden.)

dvgrn wrote:Shamefaced confession: I had a perfect opportunity to post a soup-search discovery with a liferle tag just now. Let me know if it's going to cause trouble, and I'll undo it again quick... but at this point I'm really curious to see what people say.

No problem from my side either. Just keep in mind that we'll be changing the tag from "[liferle]" to something more natural (perhaps just "[life]"? suggestions?) in the future, and your post will break when we do.

Nathaniel wrote:Just keep in mind that we'll be changing the tag from "[liferle]" to something more natural (perhaps just "[life]"? suggestions?) in the future, and your post will break when we do.

Well, yes, and maybe before there are piles of new tags showing up in lots of threads, it will make sense to not be loading the .js file from Chris' web site all the time. I will attempt to keep my enthusiasm in check (for now)... and fix anything that needs fixin' when the time comes.

[life] seems like an okay tag, but technically the Viewer can handle a lot of non-Life rules -- even a lot of non-Life-like rules, if you count VIEWONLY ones. [RLE] is not quite right either, since the Viewer supports several other pattern encodings. Is [pattern] too long a word? Or is [CA] too mysterious? Is it easy to add a Pattern-or-whatever button to go along with the others at the top of the message editor?

dvgrn wrote:Is it easy to add a Pattern-or-whatever button to go along with the others at the top of the message editor?

Yep, this is trivial from my end of things (just a checkbox I press on the backend of phpBB).

dvgrn wrote:[life] seems like an okay tag, but technically the Viewer can handle a lot of non-Life rules -- even a lot of non-Life-like rules, if you count VIEWONLY ones. [RLE] is not quite right either, since the Viewer supports several other pattern encodings. Is [pattern] too long a word? Or is [CA] too mysterious? Is it easy to add a Pattern-or-whatever button to go along with the others at the top of the message editor?

My suggestion would be

rowett wrote:Next steps would be:
1. Upload and test build 120
2. Assuming testing passes then host build 120 on the ConwayLife.com site.
3. Decide on the name of the BBCode directive (currently "liferle")
4. Add a new button to the POST A REPLY editor to generate the BBCode directive (like "Quote", "Code", "List" etc.)
5. Post a message in the appropriate forum announcing the new capability and perhaps create a sticky thread for suggestion and bug reports.

These are the release steps I proposed earlier. I foolishly omitted Dave's step:
0. Release a random build

I think the new plan should be:
1. Decide if there are any defects in the current build (123) we want fixed before unleashing the Viewer. I'll take a look this evening at Dave's report on the non-expanded quote and the menus misbehaving.
2. Host the build we want on the conwaylife.com site.
3. Decide on the BBCode directive and then go and fix any Viewers that escaped early (Dave )
4 and 5 as before.

rowett wrote:I foolishly omitted Dave's step:
0. Release a random build

Well, it's nice that you can gracefully admit your mistakes when I point them out through my foolish unilateral actions. Things are working out just about as I hoped:

gameoflifeboy wrote:Yay! Being able to run patterns in posts is almost as good as having the applet back!

So that seems to saved Nathaniel the trouble of coding an HTML5 landing-page Java applet replacement. Whew!

rowett wrote:3. Decide on the BBCode directive and then go and fix any Viewers that escaped early (Dave )

Aye, aye, Cap'n. I'll vote in favor of [view], but really any tag will be fine -- could even leave it as "liferle" and I wouldn't mind.

There are a couple of new escapees this morning. Seems to me that these are good use cases for a Viewer with a smaller minimum HEIGHT setting. 480 pixels is a lot of vertical space, and it means that even simple single-illustration posts like simsim314's don't fit on a 768-pixel-high screen without scrolling.

The posted pattern is a single column of objects, but could just as easily be a single row. Seems to me that the Viewer's controls could fit quite nicely into 480x240, with just a little tweaking at the corners:
EDIT: Might it possibly make sense to set up a separate Easter-egg BBCode tag, like [liferle] or [viewtest] or something, pointing at the latest development build on Chris' website? That way it would continue to be possible to test a new version of the Viewer -- locked-down, multistate themes, or what have you -- with a stable version deployed.

dvgrn wrote:Might it possibly make sense to set up a separate Easter-egg BBCode tag, like [liferle] or [viewtest] or something, pointing at the latest development build on Chris' website? That way it would continue to be possible to test a new version of the Viewer -- locked-down, multistate themes, or what have you -- with a stable version deployed.

There are two things that concern me about this:

• This would require the Javascript library to be loaded from Chris's server on every page load, even ones that don't have the "experimental" liferle tag on them. This isn't a huge deal, but it's nice to keep things as "in one place" as possible.
• I imagine that there would be some conflicts in the plugin (Chris, correct me if I'm wrong) if two different versions of the plugin Javascript were loaded on the same page.

Nathaniel wrote:

• This would require the Javascript library to be loaded from Chris's server on every page load, even ones that don't have the "experimental" liferle tag on them. This isn't a huge deal, but it's nice to keep things as "in one place" as possible.
• I imagine that there would be some conflicts in the plugin (Chris, correct me if I'm wrong) if two different versions of the plugin Javascript were loaded on the same page.

Ah, didn't think of that first one -- do you always load the .JS file, even if there's no viewer tag on the page that calls for it? Well, probably testing can go back to a slower pace anyway, with new builds loaded locally on conwaylife.com whenever they're needed. But possibly there might be a case in the future for two separate kinds of viewers with separate JS files -- a "locked-down" display version and the standard Viewer, or something else we haven't thought of yet. Maybe. Just making things up as I go along here.

The conflict problem I'm not so worried about -- if it's a message thread for testing like this one, it's easy enough to use only [test] tags and no [view] tags. But maybe this is all just a solution in search of a problem... I'll be curious to see, for example, if feedback comes in from anyone else about the viewer taking up too much screen real estate, for one-off cases like simsim314's this morning where really you just want to fit as much text and as many little illustrative images as possible onto one page.

I'm stuck at the hospital for half an hour after an allergy shot, using the only browser they have on one of the room's computers, which is Internet Explorer 8. So I can't see the actual viewers in the link above -- but I can report that the patterns are gracefully rendered as the old-standard code blocks instead, just like they're supposed to.

Looks like Michael Simkin is getting into the LifeViewer spirit very quickly -- that thread is turning into a good test case. Everything is going according to my evil plans (and yes, I'll fix those tags also, when the time comes.)

dvgrn wrote:The conflict problem I'm not so worried about -- if it's a message thread for testing like this one, it's easy enough to use only [test] tags and no [view] tags.

Actually, the conflict problem is the one that I'm *more* worried about. The problem is that there's no direct way to tell phpBB *which* plugin to look for with a specific tag, but rather to just load the plugin. So, if a page has a [view] tag on it (even if it has no [test] tag on it), the page will look for the LifeViewer plugin, and find two of them... and then I honestly don't know what it will do from there

dvgrn wrote:There are a couple of new escapees this morning. Seems to me that these are good use cases for a Viewer with a smaller minimum HEIGHT setting.

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.

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? It was originally but then we changed it to the width of the code box (when the code box only displayed the SELECT CODE row). Now the code box display 2.5 lines of RLE as well it doesn't look so bad with a thinner Viewer.

dvgrn wrote:Just noticed while writing this message using the "Quote" editor function, that the Viewer control shows up in the history pane -- under "Topic review: Life tag testing" -- but the Reset/Pause/Play/Display buttons don't work correctly with the default collapsed view, no matter what the browser zoom level is.

Fixed in build 124.

dvgrn wrote:When Autostart is turned on, there's no time to look at the initial pattern -- you only really see T=1 and later, even at a slow GPS setting. With GPS 1, there should be at least one second for the initial pattern to be displayed before the simulation starts.

Also fixed in build 124. Play was immediately jumping to the next generation. It now respects the gps setting.

Nathaniel wrote:

dvgrn wrote:The conflict problem I'm not so worried about -- if it's a message thread for testing like this one, it's easy enough to use only [test] tags and no [view] tags.

Actually, the conflict problem is the one that I'm *more* worried about. The problem is that there's no direct way to tell phpBB *which* plugin to look for with a specific tag, but rather to just load the plugin. So, if a page has a [view] tag on it (even if it has no [test] tag on it), the page will look for the LifeViewer plugin, and find two of them... and then I honestly don't know what it will do from there

Can you get phpBB to include a specific javascript file based on the use of a specific BBCode on a page? At the moment we always load the plugin, regardless of whether the [liferle] tag is present on the page.