Life tag testing

[rowett]

Dave,
Did you get a chance to look at the recent LifeViewer builds since the pattern decoder rewrite? From my testing it's looking OK and I'm fairly keen to get it out "into the wild" since it contains a bunch of useful new functionality.

[dvgrn]

Dave,
Did you get a chance to look at the recent LifeViewer builds since the pattern decoder rewrite? From my testing it's looking OK and I'm fairly keen to get it out "into the wild" since it contains a bunch of useful new functionality.

I can't claim to have done any kind of decent run-through, unfortunately -- was traveling for a week, and now have a software rollout to finish up late tonight.

It will probably be a few more days before I can really think about LifeViewer bug-hunting. But I'm not necessarily indispensable to the testing effort, of course!

[rowett]

It will probably be a few more days before I can really think about LifeViewer bug-hunting. But I'm not necessarily indispensable to the testing effort, of course!

No problem. Always worth having you cast your expert eye over a build before we inflict it on the wider community. Joint culpability and all that...
Of course, the longer you take, the more features I'll add to be tested.

Good luck with the software rollout!

[rowett]

Next build should be posted tomorrow and includes Generations support for both Moore (totalistic and isotropic non-totalistic) and Hex (totalistic) neighbourhoods with or without bounded grids.

[dvgrn]

Next build should be posted tomorrow and includes Generations support for both Moore (totalistic and isotropic non-totalistic) and Hex (totalistic) neighbourhoods with or without bounded grids.

Awesome! I'm putting a big collection of test pages together for all (or at least some) of the newly supported rule types, so hopefully Build 180 can get tested and rolled out fairly quickly.

[rowett]

Build 180 is now available on the lazyslug server

Enhancements in this build:

• support for Generations rules - test
  • added a new theme (11) which is the default for Generations rules (red -> yellow)
  • Generations rules will also work with isotropic non-totalistic definitions
• help information now includes pattern name and originator if specified in the RLE (#N and #O)
• generation display (T) now shows decimal places for millions

Fixes in this build:

• RLE decoder was ignoring last line if ! was missing

Known issues in this build:

• population count is not always correct with bounded grids that wrap
• population count is not correct for one generation when switching stats from off to on for Generations rules
• area size in help information is not always correct for bounded grids that wrap
• autoFit with Hex display is not quite right

Note that Generations rules can also be used with Hex neighbourhood (e.g. B23456/S2456/8H - see last test) and bounded grids.

[dvgrn]

Build 180 is now available on the lazyslug server

Enhancements in this build:

• support for Generations rules - test

The first pattern in that "test" link behaves slightly strangely when you run it past generation 7. Yellow cells remain indefinitely but the clock continues to run. Hit 'b' to stop the clock and run backwards one tick, and the yellow cells disappear (until you get back to generation 7).

[rowett]

The first pattern in that "test" link behaves slightly strangely when you run it past generation 7. Yellow cells remain indefinitely but the clock continues to run. Hit 'b' to stop the clock and run backwards one tick, and the yellow cells disappear (until you get back to generation 7).

Yes it's because there are no "alive" (red) cells left and LifeViewer stops processing the grid once that happens (to save CPU cycles and be green). I'm happy to keep processing until the decaying (yellow) cells have all died if that's better.

[rowett]

The first pattern in that "test" link behaves slightly strangely when you run it past generation 7. Yellow cells remain indefinitely but the clock continues to run. Hit 'b' to stop the clock and run backwards one tick, and the yellow cells disappear (until you get back to generation 7).

Yes it's because there are no "alive" (red) cells left and LifeViewer stops processing the grid once that happens (to save CPU cycles and be green). I'm happy to keep processing until the decaying (yellow) cells have all died if that's better.

This has been fixed, rerun the first test and all will be well.

[rowett]

Build 181 is now available on the lazyslug server

Enhancements in this build:

• the bottom line of the LifeViewer window now displays a reason when a pattern can not execute (including VIEWONLY mode)
• improved performance of Generations rule execution by 30%

Fixes in this build:

• bounded grids are not valid with Hex neighbourhoods - test
• patterns can not be larger than bounded grids - test
• [R]History is not valid with Generations rules - test

Dave, the enhancement above was actually suggested by you just over a year ago. Seemed like it had sat on backlog row for long enough...

[dvgrn]

Build 181 is now available on the lazyslug server

Okay, I'm up to twenty-five sample forum pages collected now -- will add more eventually, as I think of new categories. To test a new LifeViewer build, I only have to replace lv-plugin.js in one place now. Things are getting better all the time --

Now, I haven't had time to actually look at all those sample pages, but I couldn't resist checking out what Generations and hexagonal rules are going to look like. Very impressive! I'm looking forward to getting a build rolled out soon (and yes, I know I'm the roadblock at the moment.)

The only problem I've run into so far is that Build 181 reports a "0" as an illegal character for a Generations rule. But then it goes ahead and interprets the rule and simulates it correctly. See the 0/2/3 thread for example.

[rowett]

Build 182 is now available on the lazyslug server

Enhancements in this build:

• added Generations aliases

Fixes in this build:

• The only problem I've run into so far is that Build 181 reports a "0" as an illegal character for a Generations rule. But then it goes ahead and interprets the rule and simulates it correctly. See the 0/2/3 thread for example.

• bottom line error messages were not being cleared in the standalone viewer

[dvgrn]

Build 182 is now available on the lazyslug server...

Looks good -- that fixes everything I've found so far.

@Nathaniel, I'll gradually run through some other tests in the next few days, especially with bounded grids. But I think you can probably do your magic and go live with Build 182, as soon as you notice this note...!

[rowett]

182 is live!

Thanks Nathaniel

[rowett]

When a page loads in the forum LifeViewer scans it for [ code ] and [ viewer ] blocks and does appropriate things.

I was thinking the other day that a similar process could be used to detect words from the Life Lexicon in posts and replace them with links to a pop-up Lexicon viewer.

Thoughts?

Chris

[rowett]

Build 183 is now available on the lazyslug server

Enhancements in this build:

• [[ TITLE ]] script command string (which sets the popup window title) can contain variables:
  • #B - the LifeViewer build number
  • #N - the pattern name (if defined)
  • #O - the pattern originator (if defined)
  • #R - the pattern rule name
  • ## - the # symbol
• performance improvements for next generation calculation and colour update calculation

Fixes in this build:

• state display was incorrect for Generations rules
• Generations decay states were not counted in bounding box
• Generations rule patterns with scripts were marked as VIEWONLY
• angle UI slider should not display in Hex display mode

[rowett]

Build 184 is now available on the lazyslug server

Enhancements in this build:

• new script command [[ SQUAREDISPLAY ]] to force square display (for unknown rules that are autodetected as Hex)
• further performance improvements to the next generation calculation
• increased maximum STEP to 50 (allowing smaller patterns to play at 3000 generations per second)
• increased step back generations to 2500
• improved the "Auto", "Fit" and "Help" buttons

Fixes in this build:

• left column of bounded grid box was sometimes not being drawn correctly

[rowett]

Build 185 is now available on the lazyslug server

Enhancements in this build:

• aliases in the help information are now grouped by rule family
• added GlideLife to the alias list
• improved rule error checking, pattern state validation and error messages
• performance improvements for the next generation calculation with population statistics
• [[ TITLE ]] string can now also contain #T which is the program title (LifeViewer)
  • [[ TITLE "#T #B" ]] would set the popup window title to "LifeViewer 185"

Fixes in this build:

• two of the Generations aliases were incorrect

[dvgrn]

Just tried to set up waypoints to track a moving spaceship, and ran into two difficulties that I don't remember.

Code: Select all

x = 58, y = 126, rule = B2i34c/S2-i3
6bo$5b2o$2o4bo$2o2$51bo$51b2o$51bo4b2o$56b2o2$10bo$9b2o$2o8bo$2o2$47bo
$47b2o$47bo8b2o$56b2o2$14bo$13b2o$2o12bo$2o2$43bo$43b2o$43bo12b2o$56b
2o2$18bo$17b2o$2o16bo$2o2$39bo$39b2o$39bo16b2o$56b2o2$22bo$21b2o$2o20b
o$2o2$35bo$35b2o$35bo20b2o$56b2o2$26bo$25b2o$2o24bo18bo$2o42b2o$45bo$
31bo9b2o$31b2o8b2o$12bo18bo24b2o$12b2o42b2o$12bo$15b2o13bo$15b2o12b2o$
2o28bo18bo$2o46b2o$49bo$27bo13b2o$27b2o12b2o$8bo18bo28b2o$8b2o46b2o$8b
o$15b2o17bo15bo2bo$15b2o16b2o13bobo$2o32bo13bo3bobo$2o47bo2b2o$52bo$4b
o2bo15bo17b2o$7bobo13b2o16b2o$3bobo3bo13bo32b2o$4b2o2bo26bo2bo17b2o$5b
o27bobo$15b2o16bo3bobo12b2o$15b2o17bo2b2o7b2o4bobo$2o35bo8b2o6bo$2o17b
o2bo30bobo$22bobo$4b2o12bobo3bo16b2o$3bobo4b2o7b2o2bo17b2o$3bo6b2o8bo
26bo8b2o$2bobo32b2o8bo8b2o$31b2o4bobo$15b2o14b2o6bo8b2o$15b2o21bobo6b
4o$2o8bo35bo3bo$2o8bo8b2o25bo2bo$18bobo4b2o20b3o$8b2o8bo6b2o5bo8b2o$7b
4o6bobo12bo8b2o$7bo3bo44b2o$8bo2bo21b2o21b2o$8b3o21b4o$15b2o8bo5bo3bo$
15b2o8bo5bo2bo$2o30b3o$2o21b2o$22b4o$22bo3bo14b2o$23bo2bo14b2o6b2o$23b
3o30b2o$56b2o2$15b2o$7b2o6b2o25bo$2o40bo$2o53bobo$43b2o$42b4o10bo$15bo
25bo3bo$15bo25bo2bo8b3o$obo39b3o8bo2b2o$13b2o39b3o$bo10b4o39bo$12bo3bo
$2b3o8bo2bo$2o2bo8b3o$b3o$2bo!
#C [[ AUTOSTART X 0 Y 0 ]]
#C [[ COLOR ALIVE 0 255 0 ]]
#C [[ COLOR DEAD 0 0 0 ]]
#C [[ COLOR DEADRAMP 0 0 0 ]]
#C [[ COLOR HISTORY 0 0 0 ]]
#C [[ T 200 X 0 Y -100 ]]
#C [[ LOOP 200 ]]

At first I tried to use THEME 6 to avoid the problem with History cells suddenly disappearing at the end of the LOOP, but I couldn't get the theme to be applied when the pattern first opened, so there is always a flash of discontinuity -- see below.

Also the waypoint interpolation appears to be interestingly wobbly, where I expected to be able to set it up to be plain old linear. The spaceship seems to speed up and slow down, especially if I set up a longer loop. At LOOP 2000 the viewport drops far behind and then races far ahead:

Code: Select all

x = 58, y = 126, rule = B2i34c/S2-i3
6bo$5b2o$2o4bo$2o2$51bo$51b2o$51bo4b2o$56b2o2$10bo$9b2o$2o8bo$2o2$47bo
$47b2o$47bo8b2o$56b2o2$14bo$13b2o$2o12bo$2o2$43bo$43b2o$43bo12b2o$56b
2o2$18bo$17b2o$2o16bo$2o2$39bo$39b2o$39bo16b2o$56b2o2$22bo$21b2o$2o20b
o$2o2$35bo$35b2o$35bo20b2o$56b2o2$26bo$25b2o$2o24bo18bo$2o42b2o$45bo$
31bo9b2o$31b2o8b2o$12bo18bo24b2o$12b2o42b2o$12bo$15b2o13bo$15b2o12b2o$
2o28bo18bo$2o46b2o$49bo$27bo13b2o$27b2o12b2o$8bo18bo28b2o$8b2o46b2o$8b
o$15b2o17bo15bo2bo$15b2o16b2o13bobo$2o32bo13bo3bobo$2o47bo2b2o$52bo$4b
o2bo15bo17b2o$7bobo13b2o16b2o$3bobo3bo13bo32b2o$4b2o2bo26bo2bo17b2o$5b
o27bobo$15b2o16bo3bobo12b2o$15b2o17bo2b2o7b2o4bobo$2o35bo8b2o6bo$2o17b
o2bo30bobo$22bobo$4b2o12bobo3bo16b2o$3bobo4b2o7b2o2bo17b2o$3bo6b2o8bo
26bo8b2o$2bobo32b2o8bo8b2o$31b2o4bobo$15b2o14b2o6bo8b2o$15b2o21bobo6b
4o$2o8bo35bo3bo$2o8bo8b2o25bo2bo$18bobo4b2o20b3o$8b2o8bo6b2o5bo8b2o$7b
4o6bobo12bo8b2o$7bo3bo44b2o$8bo2bo21b2o21b2o$8b3o21b4o$15b2o8bo5bo3bo$
15b2o8bo5bo2bo$2o30b3o$2o21b2o$22b4o$22bo3bo14b2o$23bo2bo14b2o6b2o$23b
3o30b2o$56b2o2$15b2o$7b2o6b2o25bo$2o40bo$2o53bobo$43b2o$42b4o10bo$15bo
25bo3bo$15bo25bo2bo8b3o$obo39b3o8bo2b2o$13b2o39b3o$bo10b4o39bo$12bo3bo
$2b3o8bo2bo$2o2bo8b3o$b3o$2bo!
#C [[ THEME 6 AUTOSTART X 0 Y 0 ]]
#C [[ PAUSE 2 ]]
#C [[ T 2000 X 0 Y -1000 ]]
#C [[ LOOP 2000 ]]

I'm guessing some previous feature request of mine Is probably to blame for this...?

[rowett]

Just tried to set up waypoints to track a moving spaceship, and ran into two difficulties that I don't remember.

At first I tried to use THEME 6 to avoid the problem with History cells suddenly disappearing at the end of the LOOP, but I couldn't get the theme to be applied when the pattern first opened, so there is always a flash of discontinuity -- see below.

This is a bug and has been fixed in the next build. Basically the reset code was always setting the default theme, rather than the theme defined in the first waypoint.

Also the waypoint interpolation appears to be interestingly wobbly, where I expected to be able to set it up to be plain old linear. The spaceship seems to speed up and slow down, especially if I set up a longer loop. At LOOP 2000 the viewport drops far behind and then races far ahead:
I'm guessing some previous feature request of mine Is probably to blame for this...?

Not sure who's to blame... the implementation is currently using Bezier rather than linear interpolation which is causing the wobbles. If I change it to linear it's working as desired. Perhaps I'll need to add new keywords so you can specify which mode you want (maybe per waypoint and per item, i.e. [[ LINEAR X ]] [[ BEZIER ZOOM ]] etc.).

[rowett]

Dave,
In the next build you can specify whether you want the camera to move using LINEAR or BEZIER interpolation. You specify it for each of X, Y and ZOOM individually, and this is per waypoint.
The default is currently BEZIER. Would it make more sense if the default was LINEAR?
Waypoints that don't have motion mode defined continue with the current mode.

For your example above you'd currently need to add [[ LINEAR X LINEAR Y ]] to your [[ T 2000 ]] waypoint definition.

[rowett]

Build 186 is now available on the lazyslug server

Enhancements in this build:

• new script commands [[ LINEAR ALL|X|Y|ZOOM ]] and [[ BEZIER ALL|X|Y|ZOOM ]] that sets the camera movement mode for X, Y, ZOOM or ALL elements at once
  • the mode is set at each waypoint
  • waypoints that do not define camera mode use last defined mode
  • the default is that bezier motion is used for camera movement

Fixes in this build:

• points of interest would get lost if display mode switched between Hex and Square
• when waypoints are defined the reset state should use the first waypoint theme

See here for a test case using the new LINEAR script command and the fix for the THEME being reset incorrectly when playback loops.

[rowett]

Dave,
Do you know (roughly) what proportion of Golly custom rules that the community creates are 2 state, Moore or Hex neighbourhood? For those that are it would be nice if Golly could output the [[ MAP ]] in a pattern comment with the pattern since then they'd be able to be viewed in LifeViewer automatically when posted to the forum.

[dvgrn]

Dave,
Do you know (roughly) what proportion of Golly custom rules that the community creates are 2 state, Moore or Hex neighbourhood? For those that are it would be nice if Golly could output the [[ MAP ]] in a pattern comment with the pattern since then they'd be able to be viewed in LifeViewer automatically when posted to the forum.

I don't really know. Recently the proportion has gone down a bit, I think, because of recent interest in loop rules and rule mashups. And occasional custom XHistory rules, which LifeViewer could really handle reasonably well, but it would be hard for Golly to figure out from the rule table that it was "really" just Rule X.

It seems to me that the simplest next step along these lines is to keep encouraging Tom Rokicki to add support for Hensel-format rule strings for isotropic rules. That would mean that arbitrary rule renamings such as 'salad' would occur a lot less often, anyway.

Are there categories where we could fairly easily supply a script to translate a rule table into a [[ MAP ]] line for LifeViewer? Maybe that would be another small step in the right direction? Adding comment lines to Golly patterns is a good idea as long as it doesn't break other parsing code that doesn't expect them to suddenly show up... Andrew's instinct about this kind of thing is usually to keep things the same unless there's a really strong use case for changing them.

[rowett]

Are there categories where we could fairly easily supply a script to translate a rule table into a [[ MAP ]] line for LifeViewer?

Yes I also thought about this too but I can't see people bothering to use it which is why I figured if Golly produced it automatically then no effort would be required on the user.

I did think about adding limited rule table support into LifeViewer but it's unpleasant in the forum since the rule definitions are either in separate posts or not posted. Plus at some stage I suspect Andrew will release Molly - the LifeViewer integration is done but disabled until he's ready.

Alternatively if the golly gang are open to contributions I may download the Golly source and see how hard it will be to add the isotropic code. The implementation in LifeViewer was fairly trivial.