Life tag testing

[rowett]

Even if I am the only user, I do kind of like the POI idea.

Yes I'm still considering it. I may end up building both. Unlike commercial software I get the luxury of doing this because I enjoy it My LifeViewer backlog has exploded since the Wiki integration (which is good) but it's kind of put my non-isotropic Golly investigations on the back burner.

Fair warning: the next build is going to invert the X and Y values so I'll give the Wiki a heads up before it's released since they'll need to modify the TRACK templates.

[rowett]

The new behaviour is as follows:

• When LOOP and Waypoints defined:
  • Pause simply pauses and play continues
  • First Reset resets to T=0 and disables both LOOP and Waypoint mode
  • Second Reset does a full reset (Waypoints and LOOP re-enabled)
• When just LOOP defined:
  • Pause pauses and disables LOOP (so you can then manually play beyond the LOOP point)
  • First Reset resets to T=0 and leaves LOOP disabled
  • Second Reset does a full reset (LOOP re-enabled)
• When just Waypoints defined:
  • Pause simply pauses and play continues
  • First Reset resets to T=0 and disables Waypoint mode
  • Second Reset does a full reset (Waypoints re-enabled)

For consistency I've modified the behaviour slightly of the items marked above in red. This is now defined as:

• When just LOOP defined:
  • Pause simply pauses and play continues
  • First Reset resets to T=0 and disables LOOP
  • Second Reset does a full reset (LOOP re-enabled)

Pause no longer disables LOOP. This brings consistency between Waypoint playback and non-Waypoint playback. If you want to disable LOOP just Reset once. Also the "w" hotkey now toggles LOOP when no Waypoints are defined (and toggles Waypoint playback when Waypoints are defined as it always did).

I've also added visual indicators on the UI so you can see whether AUTOSTART, LOOP, TRACK (Waypoint mode) and STOP are enabled.

[rowett]

Added HISTORYFIT which sets the AUTOFIT mode.

• If HISTORYFIT is not specified then bounding box encloses live cells (and Generations decaying cells).
• If HISTORYFIT is specified then bounding box includes where cells have died.
• If LifeHistory pattern then bounding box includes State 2 through State 6 cells.
• HISTORYFIT just defines the mode, you still need to switch AUTOFIT on.

Nicely stabilizes the camera on oscillators no later than T=period.

[rowett]

Dave,
When AUTOFIT is not enabled do you think there is value in the first Reset not also resetting the camera i.e. is there ever a need to reset T to 0 without resetting the camera position?

[dvgrn]

Dave,
Do you think there is value in the first Reset not also resetting the camera i.e. is there ever a need to reset T to 0 without resetting the camera position?

Interesting question. Golly has a Preferences option "Reset/undo will restore view" -- which I always immediately uncheck when I'm setting up Golly on a new computer.

So you'd think I would like the option of not resetting the camera. But I guess what's needed for a viewer is probably a little different from what's needed for an editor. Seems as if at least for the case I'm thinking about now -- a viewer following a spaceship -- if you don't reset the view, you end up looking at a small piece of very empty space.

It often happens that I want to reset a complicated circuit pattern back to T=0, make a change to the particular area I was looking at before the reset, and then run the pattern again to make sure the circuit still works (or works better now)... so it's important to not move the camera on a reset in that case. But I don't think that kind of thing will be an issue until you get around to converting LifeViewer to LifeViewerEditor...!

[rowett]

LifeViewerEditor...!

You'll possibly be interested to know that "implement pattern editor" is the longest serving item on the LifeViewer backlog!

[rowett]

Build 196 is now available on the lazyslug server

Enhancements in this build:

• for consistency coordinates in scripts have been negated
  • you'll need to edit any Waypoint or TRACK definitions of existing patterns e.g. [[ TRACK 4 1 1 ]] becomes [[ TRACK 4 -1 -1 ]] and [[ X 1000 Y -50 ]] becomes [[ X -1000 Y 50 ]]
• numeric values in scripts can now be specified as fractions [[ DEPTH 2/3 ]] [[ X -13/6 ]]
  • division by zero is treated as zero
• new UI indicators to show whether any of the following are defined (grey: no, coloured: yes) and enabled (highlighted):
  • AUTOSTART "START"
  • LOOP "LOOP"
  • STOP "STOP"
  • Waypoints, TRACK or TRACKBOX "TRACK"
• new script command [[ HISTORYFIT ]] that changes AUTOFIT behaviour so it uses cells that have died as well as live cells to set the camera position - test
  • shift and hotkey "h" will toggle HISTORYFIT mode
  • HISTORYFIT just defines the AUTOFIT mode, you still need to switch AUTOFIT on
  • added AUTOFIT status to help information
• new script command [[ TRACKBOX N E S W ]] which makes the camera track the bounding box starting at the initial T=0 pattern position by applying N, E, S and W as speeds in cells/generation to the North, East, South and West edges - test
  • the current N, E, S and W speeds are shown in the help information and this can be used to set TRACKBOX for patterns where the speeds are unknown
  • you can not use TRACKBOX together with TRACK or Waypoints
• hotkey "w" will now toggle any combination of LOOP, Waypoints, TRACK and TRACKBOX that are defined
• shift and hotkey "r" resets all viewers (including the current one)
• Pause no longer disables LOOP when no waypoints are specified
• don't show "Life ended at generation" notification if LOOP defined and enabled - test
• reduced the font size of the generation statistics, rule, elapsed time and mouse coordinates

Fixes in this build:

• close button is now larger in general and correct width on the Wiki
• fixed an edge case where grid could grow too late based on the increase in maximum STEP size

[dvgrn]

Build 196 is now available on the lazyslug server

Enhancements in this build:

• for consistency coordinates in scripts have been negated
  • you'll need to edit any Waypoint or TRACK definitions of existing patterns e.g. [[ TRACK 4 1 1 ]] becomes [[ TRACK 4 -1 -1 ]] and [[ X 1000 Y -50 ]] becomes [[ X -1000 Y 50 ]]

Sounds good. I'll work on that when it's time for the next rollout.

For the record, a couple of evenings ago I went back and tried building a new waypoint animation from scratch. The coordinates did seem kind of backwards, but I didn't have to care because I was always just copying X, Y and ZOOM values out of the Information page. I kind of wanted to be able to match up X and Y with the mouse coordinates that are displayed in the lower left corner, but those don't seem to line up at all -- they're Golly coordinates, measured from the upper left-hand corner, where the View coordinates have the (X,Y) origin at the center of the pattern.

As long as it will still be possible to copy X, Y, ZOOM information easily from somewhere, I think this is a worthwhile adjustment. For making waypoint animations, it would be nice to be able to toggle a single X, Y, ZOOM readout line somewhere on the regular viewer screen (just because you can't make adjustments when the full Information overlay is visible). We can already see ZOOM, and mouse-coordinate versions of X and Y are already visible too... might it make sense to have the waypoint system run off of Golly coordinates?

I only had trouble with two things for this build's test viewers:
1) Hitting the Reset button on a TRACKBOX animation doesn't reset the view.
2) TRACK and TRACKBOX seem to lock down the Step and GPS settings as well as everything else. It'd be nice to be able to run the simulation faster or slower than the script writer (in his/her infinite wisdom) decided on. Maybe the zoom could even be adjustable as well, while I'm wishing for horses.

One way to think of a TRACK or TRACKBOX system is, the script writer is telling the viewer that there's something in the picture that moves at a certain speed, or grows in a certain way. Doesn't mean that users won't want to zoom in on one part or another of the pattern, or zoom out to see the big picture -- but at least for TRACK, on average they'll want the viewport to move at the specified speed, because otherwise they'll be looking at empty space after a while.

[rowett]

Build 197 is now available on the lazyslug server

Enhancements in this build:

• TRACKBOX mode no longer disables STEP and GPS controls - test
• shift and hotkey "i" now toggles display of the information bar which shows the camera X, Y, ANGLE and the TRACKBOX speeds
• new script command [[ SHOWINFOBAR ]] which turns the information bar on at pattern load - test
• first Reset now also resets camera

Fixes in this build:

• ensure navigation menu appears above population statistics
• Angle, Layers and Depth hotkeys were not disabled when corresponding UI controls were disabled

The updated hotkey map is here.

[rowett]

I only had trouble with two things for this build's test viewers:
1) Hitting the Reset button on a TRACKBOX animation doesn't reset the view.

Fixed.

2) TRACK and TRACKBOX seem to lock down the Step and GPS settings as well as everything else. It'd be nice to be able to run the simulation faster or slower than the script writer (in his/her infinite wisdom) decided on. Maybe the zoom could even be adjustable as well, while I'm wishing for horses.

Fixed STEP and GPS for TRACKBOX. Will investigate for TRACK (which is trickier since it uses the locked-down Waypoint system under the covers).

You want ZOOM too?!? I'll order some horses...

[rowett]

I've been thinking. I know that's not a terribly encouraging start but bear with me.

Currently I've implemented TRACK as special cases of the Waypoint system. This was easy to do since the Waypoint system is already there but came with all the baggage of the Waypoint system itself, specifically that the Waypoint system is, by definition, a control freak.

I was going to implement TRACKBOX in the same way but discovered it was easier to do as a mode of the AutoFit system, like HISTORYFIT.

I'm now thinking that TRACK should also be a mode of AutoFit. My new proposal is as follows:

• AutoFit has five modes of operation:
  1. AUTOFIT
     • Glides the camera towards the current generation bounding box
     • Good for arbitrary patterns
  2. HISTORYFIT
     • Glides the camera towards the bounding box defined by the current generation and any cells that used to be alive
     • Good for oscillators
  3. TRACK X Y
     • You define X and Y velocities in cells/generation (different than the current TRACK implementation)
     • Glides the camera towards the bounding box defined by the initial pattern bounding box offset by T*X, T*Y
     • Good for fixed size spaceships
     • Shorthand for TRACKBOX Y X Y X
  4. TRACKBOX N E S W
     • You define N, E, S and W velocities in cells/generation (as current implementation)
     • Glides the camera towards the bounding box defined by the initial pattern bounding box whose edges are offset by T*N, T*E, T*S and T*W
     • Good for growing spaceships
  5. TRACKLOOP N X Y
     • You define N (period) and X and Y velocities in cells/generation (different than the current TRACK implementation)
     • Works as TRACK X Y above but also LOOPs every N generations
     • N will be multiplied by GRIDMAJOR setting if non-zero
     • Good for fixed size spaceships in the Wiki since LOOP means they never hit the grid edge
     • Shorthand for TRACK X Y LOOP N*M or TRACKBOX Y X Y X LOOP N*M (where M is GRIDMAJOR setting, M=1 if zero)

How would it work?

• If any of these are defined in the script then AutoFit will be switched on when the pattern loads
• AutoFit can be toggled by clicking the "Auto" button top left of the UI or with Shift and hotkey "F"
• If AutoFit defined then first Reset will disable, second Reset will enable

Why do I think this is better?

• It's consistent
• It avoids the control-freakery of the Waypoint system
• It clearly distinguishes between wanting the camera to simply follow a pattern (AutoFit modes) and deciding to create an animation (Waypoints)

Outstanding questions:

• There's an argument for consistency that TRACK parameters should be TRACK Y X (rather than TRACK X Y) to be more consistent with (TRACKBOX N E S W)
• TRACK N X Y (the current implementation) used to define X and Y in terms of cells moved in N generations. I've changed this in the proposal above for TRACK and TRACKLOOP so that X and Y are cells/generation to be consistent with TRACKBOX
• TRACKLOOP N X Y could automatically convert to TRACK X Y if Launched from THUMBLAUNCH

Thoughts?

[dvgrn]

I've been thinking. I know that's not a terribly encouraging start but bear with me.
...
Thoughts?

Now you want me to think too? That's just asking to double your trouble.

I agree that it's good to think of TRACK and TRACKBOX, and now TRACKLOOP, as autofit variations. The waypoint system was just what previous viewers happened to have, to simulate a smooth autofit.

I'm having trouble with the idea of switching to TRACK Y X, just because LifeViewer generally reports coordinates (mouse, infobar, view, etc.) as (X, Y). The only way you're going to get consistency would be to switch to TRACKBOX E S W N, or possibly E W N S. I think either of those would be fine, as long as the infobar reports its numbers in that order.

Are all of these AutoFit variations intended to be possible targets for waypoint animations? I'm not really clear about why a string of TRACK or TRACKBOX waypoints would be any improvement over the usual X Y ZOOM specifications, but they might be useful sometimes for tracking a series of signals.

I guess the infobar gives TRACKBOX information relative to the original view, so to make it really easy to collect those numbers, it would be necessary to be able to reset the infobar to calculate relative to the current view. Quite possibly that would be a lot more trouble than it's worth. Waypoints using (centerX, centerY, zoom) convey the same information as the four cells-per-tick fractions, and are probably easier to collect.

I haven't thought about ZOOM interpolation in waypoint animations for recent builds, which is probably a good thing. For the Infinite Conduit animation, the viewer must have done what I expected it to do. Would a T1 X1 Y1 ZOOM1 ... T2 X2 Y2 ZOOM2 waypoint animation do the same thing as a T1 TRACKBOX n1 e1 s1 w1 ... T2, um, STOPTRACKBOXING?

(It seems a little weird that you would already know X2 Y2 ZOOM2 at T2, and could easily tell the waypoint system something contradictory if you went back to a T2 X Y ZOOM specification. Again, I'm not really asking for TRACK and TRACKBOX to be integrated with the waypoint system -- just wondering if they will be.)

[rowett]

I agree that it's good to think of TRACK and TRACKBOX, and now TRACKLOOP, as autofit variations. The waypoint system was just what previous viewers happened to have, to simulate a smooth autofit.

Yes except now I see the new AutoFit modes as the way to smoothly follow a simple pattern and, by contrast, the Waypoint system as more than that: It's what you use when you want to present a complex pattern.

Actually you started all this madness back in January 2013 when I innocently posted my first article to the forum about LifeView[er]. You wrote:

LifeView[er]'s appearance is particularly well-timed for me. Oddly enough, just in the last few days I've been trying to help out with a multimedia presentation that includes Conway's Life, and have been thinking a lot about smooth zooming and other visual effects. Really I'd love to be able to load a particular pattern, then write a little script to tell the camera exactly how to follow the action. I'm visualizing pop-up text to explain whatever needs to be explained, but of course the sequence could be converted to video with text added later... Any hope for this kind of functionality in a future release?

Abandon hope all ye who enter here.

I'm having trouble with the idea of switching to TRACK Y X, just because LifeViewer generally reports coordinates (mouse, infobar, view, etc.) as (X, Y). The only way you're going to get consistency would be to switch to TRACKBOX E S W N, or possibly E W N S. I think either of those would be fine, as long as the infobar reports its numbers in that order.

Agreed - I'll switch TRACKBOX to E S W N and the infobar too.

Are all of these AutoFit variations intended to be possible targets for waypoint animations?

No. Just the original AUTOFIT. Not AutoFit Zero, Diet AutoFit or new Cherry-tastes-like-detergent AutoFit.

I'm not really asking for TRACK and TRACKBOX to be integrated with the waypoint system -- just wondering if they will be.)

No they won't.

And while I think of it we're getting dangerously near to build 200...

[rowett]

I've slightly changed my thinking. HISTORYFIT is a toggle that can be used with AUTOFIT, TRACK, TRACKLOOP or TRACKBOX.

[dvgrn]

I've slightly changed my thinking. HISTORYFIT is a toggle that can be used with AUTOFIT, TRACK, TRACKLOOP or TRACKBOX.

When is it useful to pay attention to history cells with any of the TRACK options? Seems like those are all situations where either we're pretending that history doesn't exist, or in the case of TRACKBOX we're not fitting on an ongoing basis anyway.

Unless it will be possible to start TRACKBOXing after T=0 -- but that didn't seem to be in the plans. The idea is that it will make a difference for [R]History patterns, only...? That could certainly come in handy somehow.

[rowett]

When is it useful to pay attention to history cells with any of the TRACK options? Seems like those are all situations where either we're pretending that history doesn't exist, or in the case of TRACKBOX we're not fitting on an ongoing basis anyway.

It's no different to wanting HISTORYFIT with standard AUTOFIT. We use it when we want to see where the pattern started as well as where it is now. TRACK and TRACKBOX are just different ways of smoothly showing where the pattern is now.
Try the test in the build notes below and toggle HISTORYFIT on the various modes to see how it works (shift and hotkey "h").

[rowett]

Build 198 is now available on the lazyslug server

Enhancements in this build:

• new AutoFit engine that has different ways of tracking patterns with the camera - test
  1. AUTOFIT
     • glides the camera towards the current generation bounding box
     • good for arbitrary patterns
     • not recommended for low GPS playback
  2. TRACK X Y
     • you define X and Y velocities in cells/generation (can be specified as fractions)
     • glides the camera towards the bounding box defined by the initial pattern bounding box offset by T*X, T*Y (where T is the current generation)
     • good for tracking fixed size spaceships including low GPS playback
  3. TRACKBOX E S W N
     • you define the East, South, West and North velocities in cells/generation
     • glides the camera towards the bounding box defined by the initial pattern bounding box whose edges are offset by T*E, T*S, T*W and T*N
     • good for tracking growing spaceships including low GPS playback
  4. TRACKLOOP P X Y
     • you define P (the period) and X and Y velocities in cells/generation
     • shorthand for LOOP P TRACK X Y but also works well with GRIDMAJOR
     • good for tracking fixed size spaceships since the LOOP means the pattern never hits the grid edge
     • not good for Themes that show history
  5. HISTORYFIT modifies any of the four above modes to include cells that have died into the bounding boxes
     • good for showing where a pattern has ever been
     • shift and hotkey "h" to toggle
• AutoFit only locks the pan and zoom controls when Playing and unlocks all the controls when playback Paused
• if AutoFit defined then first Reset disables it, and second Reset enables
• toggle AutoFit with shift and hotkey "f" or the "Auto" button at the top left
• hotkey "w" now only toggles Waypoints and Loop if defined

Fixes in this build:

• improved the layout on the information bar

Note this build is not ready for the Wiki yet - still some tuning to be done.

[dvgrn]

Try the test in the build notes below and toggle HISTORYFIT on the various modes to see how it works (shift and hotkey "h").

Yup, it works as I was imagining it. When I turn it on with TRACK or TRACKLOOP, it does kind of strange things, which probably just means that I wouldn't actually use the HistoryFit toggle with those options -- except maybe for cases that I haven't thought of yet. I don't see that there's any harm having the option available.

In the Copperhead test cases, Theme 6 is the default, so you can't see the History cells. When I switch to the next theme with the 'c' hotkey, the change in setting only lasts to the next automatic reset... can this be added to my list of wishful horses, along with STEP and GPS?

Those two options seem to be in working order for TRACK and TRACKBOX, but they still get reset on every TRACKLOOP cycle. It will probably be most annoying when the default speed is too fast and somebody tries to slow it down.

There are some interesting effects with STEP combined with TRACK. I think my favorite is when you bump up the Copperhead TRACK test viewer to GPS 60, and then gradually move the STEP slider to the right.

For TRACK and TRACKBOX you can also get some suboptimal behavior with low GPS and high STEP settings -- the zoom to the next STEP location gets increasingly jerky, though at least the pattern stays inside the view. Not sure if there's going to be an easy way to handle all of these possible combinations, though; seems like high STEP settings are going to be a challenge in general.

[rowett]

In the Copperhead test cases, Theme 6 is the default, so you can't see the History cells. When I switch to the next theme with the 'c' hotkey, the change in setting only lasts to the next automatic reset... can this be added to my list of wishful horses, along with STEP and GPS?

I've changed the automatic LOOP (caused by TRACKLOOP) to only reset the camera X, Y, ZOOM and ANGLE.
I've also changed the first Reset to do the same. Second Reset restores all settings.
I've also improved handling during high STEP values.

Try this build. You'll need to refresh your browser.

Any better?

[dvgrn]

I've changed the automatic LOOP (caused by TRACKLOOP) to only reset the camera X, Y, ZOOM and ANGLE.
I've also changed the first Reset to do the same. Second Reset restores all settings.
I've also improved handling during high STEP values.

Try this build. You'll need to refresh your browser.

Any better?

Much better! Can you get TRACKLOOP to behave as nicely as TRACK now does at high step values? TRACK's only problem is that it suddenly tells you that "Life ended at generation N" after you play around with speeding up the copperhead for a while... which I think is Working As Designed.

TRACKLOOP, on the other hand, gets very twitchy at high STEP levels, like STEP 49 let's say, apparently because it keeps resetting before the copperhead has a chance to display more than two of its phases -- thanks to mod-49 weirdness. A longer calculated loop time would fix the problem sometimes, but for very high-period objects you might still not see all the phases before reset (or hitting the edge of the grid).

Is it possible to reset automatically but then run the right number of steps to get to 0 mod 49 (or whatever), to show the correct phase? Or is that just too painful to contemplate?

[rowett]

TRACK's only problem is that it suddenly tells you that "Life ended at generation N" after you play around with speeding up the copperhead for a while... which I think is Working As Designed.

It has, of course, hit the grid boundary and been DELETERANGEd at that point.

TRACKLOOP, on the other hand, gets very twitchy at high STEP levels, like STEP 49 let's say, apparently because it keeps resetting before the copperhead has a chance to display more than two of its phases -- thanks to mod-49 weirdness.

We're always going to get some weirdness due to STEP and the pattern period, P:

• In the worst case if ((STEP mod P) == 0) then we only ever see one phase
• if ((STEP mod P) == P-1) we'll see the pattern animation in reverse
• if ((STEP mod P) == 1) we'll see the normal pattern animation

I've fixed the TRACKLOOP twitching. Reset and STEP were not playing well together. I'll upload the new build later today.

[dvgrn]

Oops, I seem to have accidentally reminded Nathaniel to update the build on the Wiki a little sooner than expected. My unwarranted apologies...

I noticed while fixing the Loafer page that the zoom level comes out very strangely small if there's no THUMBSIZE setting, as in this version of the page. I don't quite understand why it's that small, because it's only marginally smaller than the Copperhead, and nothing like that happens on that page if I take out the THUMBSIZE setting.

EDIT: Looks like it's still Build 188 on the forums. I think it makes sense to wait for build 200+ before updating (?). If it gets updated some evening of this upcoming long holiday weekend... holiday for me anyway... then it will be a little easier for me to track down all the waypoint animations and fix the coordinates.

Meanwhile, I'll work upward from the bottom the pages that link to LV:Viewer, and hopefully will meet up with someone working down from the top. Seems as if the last entry has a similar THUMBSIZE setting issue: if it's at THUMBSIZE 2, it shows up at about the right size -- just falls off the bottom of the viewer sometimes because of the starting phase of the pattern -- but at THUMBSIZE 3 the pattern ends up a little bit small, though not as bad as the loafer.

[rowett]

I noticed while fixing the Loafer page that the zoom level comes out very strangely small if there's no THUMBSIZE setting, as in this version of the page. I don't quite understand why it's that small, because it's only marginally smaller than the Copperhead, and nothing like that happens on that page if I take out the THUMBSIZE setting.

Yes it's a bug which is fixed in the next build, I'll upload in about 4 hours and ask Nathaniel to put it on the Wiki. I wasn't quite ready for the Wiki release and the build currently on the Wiki is an unfinished build 199

Looks like it's still Build 188 on the forums. I think it makes sense to wait for build 200+ before updating (?). If it gets updated some evening of this upcoming long holiday weekend... holiday for me anyway... then it will be a little easier for me to track down all the waypoint animations and fix the coordinates.

Happy for the next build to go on the forum whenever it suits you!

I'm on vacation from Saturday for a week so won't easily be able to push new builds out via the lazyslug website (I guess I could always email someone a fixed lv-plugin.js file in an emergency). On the positive side it should give me more time to attack the backlog.

[rowett]

Build 199 is now available on the lazyslug server

Enhancements in this build:

• when playback loops only the camera position, zoom and angle are reset
• further layout improvements to the information bar

Fixes in this build:

• Reset and STEP now work better together

[rowett]

Build 200 is now available on the lazyslug server

Fixes in this build:

• fixed an issue with Fit Zoom in THUMBNAIL mode - test
• fixed an issue with Waypoints and AutoFit in THUMBNAIL mode - test

This build should fix the recent ZOOM issue on the Wiki - please upload to the Wiki!

Note: you no longer need to specify HEIGHT or ZOOM for the Wiki thumbnails.