Life tag testing

[rowett]

Build 191 is now available on the lazyslug server

Enhancements in this build:

• standalone Viewer now works with LifeWiki
• [[ THUMBLAUNCH ]] script command now enables [[ THUMBNAIL ]] mode - no need to use both

Fixes in this build:

• standalone Viewer should ignore WIDTH and HEIGHT validation since they are not used
• first Reset no longer enables LOOP if defined

[rowett]

Build 192 is now available on the lazyslug server

Fixes in this build:

• title bar styling on standalone viewer was incorrect/missing when used in LifeWiki
• rle patterns beginning with "o" were being treated as Cells format and failing to decode - test
• patterns with Waypoints defined and no theme were defaulting to the wrong theme - test
• patterns with Waypoints defined were ignoring initial ZOOM - test

[rowett]

Build 193 is now available on the lazyslug server

Enhancements in this build:

• improved the styling of the standalone viewer title bar (including mouse cursor)
• [[ TITLE ]] string is more accurately clipped to the title bar - test
• new script command [[ NOREPORT ]] that disables the "Life ended at generation" message - test

[dvgrn]

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

Build 192 is currently uploaded to the LifeWiki, and I was trying to get the LifeViewer_config tag settings to work correctly with the Copperhead.

It seems as if the general LifeViewer_config:spaceship tags are getting applied right now, but there's a problem with applying the tags from pattern-specific LifeViewer_config:{pname} config pages.

But separately from that, try out the Reset button in the current Copperhead infobox. Click to expand the viewer, then try to get the Reset button to turn the Loop behavior off so you can zoom in and out while running the copperhead. The Loop timer in the lower left is always on, and depending on which kind of reset has just been done, you can sometimes get control for a moment... but once the viewer has gotten through one full loop cycle, the viewpoint jumps back to its reset location.

With some number of clicks of the Reset button, I'd like to be able to turn off all automatic looping and waypoint-following behavior.

EDIT: Also just added some wild speculations about [[ AUTOTRACK N ]] functionality over at the LifeWiki tiki bar. Just looking for a good way to track spaceships smoothly without having to figure out specific waypoints.

I had a hard time getting a short LOOP to look quite right, for tracking a loafer -- seemed as if it should have been possible to do T 7 LINEAR X X 1 LOOP 7 (or LOOP 6, I guess?) But it seems much cleaner with a longer loop like T 700 LINEAR X X 100 LOOP 700.

LOOP 6:

Code: Select all

x = 9, y = 10
4bobo$2o2bobo$2o3bobo$2o$2bo5bo2$5b2obo$5b2o$5bo2bo$6b2o!
#C [[ THEME 6 GRID GRIDMAJOR 0 THUMBNAIL AUTOSTART GPS 5 HEIGHT 800 WIDTH 483 ]]
#C [[ ZOOM 32 T 7 LINEAR X X 1 LOOP 6 ]]

LOOP 7:

Code: Select all

x = 9, y = 10
4bobo$2o2bobo$2o3bobo$2o$2bo5bo2$5b2obo$5b2o$5bo2bo$6b2o!
#C [[ THEME 6 GRID GRIDMAJOR 0 THUMBNAIL AUTOSTART GPS 5 HEIGHT 800 WIDTH 483 ]]
#C [[ ZOOM 32 T 7 LINEAR X X 1 LOOP 7 ]]

LOOP 8:

Code: Select all

x = 9, y = 10
4bobo$2o2bobo$2o3bobo$2o$2bo5bo2$5b2obo$5b2o$5bo2bo$6b2o!
#C [[ THEME 6 GRID GRIDMAJOR 0 THUMBNAIL AUTOSTART GPS 5 HEIGHT 800 WIDTH 483 ]]
#C [[ ZOOM 32 T 7 LINEAR X X 1 LOOP 8 ]]

[rowett]

... try out the Reset button in the current Copperhead infobox...

With some number of clicks of the Reset button, I'd like to be able to turn off all automatic looping and waypoint-following behavior.

I've just fixed this. 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)

So in summary the first Reset always leaves you with manual control, the second Reset restores to whatever was defined by the script commands.

You can see this in action here.

[Nathaniel]

It seems as if the general LifeViewer_config:spaceship tags are getting applied right now, but there's a problem with applying the tags from pattern-specific LifeViewer_config:{pname} config pages.

This is just because we hadn't applied the LifeViewer updates to Template:Spaceship yet, only Template:Oscillator. Everything's up-to-date now and should be working fine.

[rowett]

I had a hard time getting a short LOOP to look quite right, for tracking a loafer -- seemed as if it should have been possible to do T 7 LINEAR X X 1 LOOP 7 (or LOOP 6, I guess?) But it seems much cleaner with a longer loop like T 700 LINEAR X X 100 LOOP 700.

I've just figured out why. I've now just got to figure out how to fix it...

EDIT: I think I've just fixed it in Build 194.
You can now use T 7 LINEAR X X 1 LOOP 7 for the loafer and in the general case for a period n spaceship use T n LINEAR X 1 LOOP n.

Also if you want major gridlines at interval m then use T n*m LINEAR X m LOOP n*m.

[rowett]

Build 194 is now available on the lazyslug server

Fixes in this build:

• fixed Reset behaviour with any combination of LOOP and Waypoints so that first Reset always gives manual control and second Reset is full reset - test
• Waypoint playback at < 60 GPS was not spending enough time at T=0 - test

[dvgrn]

Build 194 is now available on the lazyslug server
...
[*]fixed Reset behaviour with any combination of LOOP and Waypoints so that first Reset always gives manual control and second Reset is full reset - test

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)

I don't think this is quite right yet. On the test page, when you reset the Just LOOP viewer (without hitting Pause first!) AUTOSTART gets turned off, but the pop-up text doesn't say anything about turning off LOOP. You can adjust the GPS manually, but when the viewer gets to 99 it resets, and all the tags get re-applied at T=0.

I think those are two separate bugs. I'd like to be able to apply a different GPS or theme manually, and not have it reset when the loop restarts. And I want to be able to turn off the loop with one Reset click, as well as with the Pause button.

Does it make sense to also announce in the pop-up text what the Reset operation is doing to the Autostart setting? Or is that too much text? Seems like it might help people understand how to use Reset more quickly.

Waypoint playback at < 60 GPS was not spending enough time at T=0 - test[/list]

This looks good. There's still an unavoidable flicker at the reset point, and a very slight slowdown compared to full-speed simulation. So I don't think the minimum-length loop should be used for spaceships on the LifeWiki -- but if we stick with a standard 100x multiple for distance, time, and loop, I think that should work really well now.

[rowett]

I don't think this is quite right yet. On the test page, when you reset the Just LOOP viewer (without hitting Pause first!) AUTOSTART gets turned off, but the pop-up text doesn't say anything about turning off LOOP. You can adjust the GPS manually, but when the viewer gets to 99 it resets, and all the tags get re-applied at T=0.

Fixed the LOOP without hitting Pause first case. All should be well now.

Also don't forget that:

1. during Waypoint playback hotkey "w" can be used to turn Waypoint mode on and off
2. hotkey "v" can be used to reset (just) the camera (useful after a First Reset if you pan away from the pattern)

Does it make sense to also announce in the pop-up text what the Reset operation is doing to the Autostart setting? Or is that too much text? Seems like it might help people understand how to use Reset more quickly.

Yes, done.

There's still an unavoidable flicker at the reset point.

Flicker now avoided.

[rowett]

Build 195 is now available on the lazyslug server

Enhancements in this build:

• new script command [[ TRACK N X Y ]] that makes tracking spaceships with the camera easier - test
  • N is the spaceship period and X and Y are the offset in cells that the spaceship reaches at the period generation
  • TRACK may not be used with other waypoint commands
• Reset notification now also shows whether AutoStart was switched On or Off

Fixes in this build:

• fixed Reset behaviour with LOOP and no Pause test
• fixed flicker while looping - test

[dvgrn]

Build 195 is now available on the lazyslug server

The fixes all look good! The flickerlessness is good enough now that it's not necessary to run multiple cycles before looping back, any more -- though I think a standard of something like 10x is still a good idea, just to show that the spaceship really _is_ a spaceship. Otherwise it's really easy to make April Fool's spaceships:

Code: Select all

#C Finally, a (2,1) knightship, period 6!
#C (implemented in the old pre-TRACK way for now)
x = 13, y = 19, rule = b3/s23
11bob$6b2o2bo2b$6bob2o3b$5bo5b2o$bobo2bo6b$o12b$o3bo2b3ob2o$o3bo4bo3b$
5bob2o4b$bo3bob2o4b$2ob3o7b$4b2obo5b$2o2b3o6b$2obo9b$3b2o4b2o2b$b3o9b$
2bo2b3ob2o2b$3b2o2b2o4b$4b3o!
#C [[ THEME 6 GRID GRIDMAJOR 0 AUTOSTART GPS 6 THUMBNAIL ]]
#C [[ ZOOM 20 T 6 LINEAR ALL Y -2 X 1 LOOP 7 ]]

Not that April Fool's spaceships will ever be a really big problem, or anything... but there's still something slightly flicker-y about that fast progress bar in the lower left corner, that seems better to me if it only fills up after several spaceship cycles.

Enhancements in this build:

• new script command [[ TRACK N X Y ]] that makes tracking spaceships with the camera easier -

The only hiccup that I can see is that the Pause/Step button doesn't interact with TRACK very well. The Pause button doesn't turn LOOP off the way it does normally, and hitting the Step button after a pause just goes to the next frame -- for slow frame rates you almost don't notice that the Step button is working at all, and you have to click a lot of times to get to the next tick.

The GPS and THEME, and presumably other settings, still reset to their original values at the end of a loop. I guess this is by design, since sometimes those settings are needed to make an animation run "right". But this spaceship-tracking is a case where it's not necessary to override that user input. If someone sets up a spaceship animation that's too fast for me, and I want to watch every frame, I can turn the speed down to GPS 1, but I can only watch one spaceship cycle that way before it will speed up again.

Creeping Featurism Request #37: might it be worthwhile to allow an (optional?) startup waypoint, distinct from a T=0 waypoint, that some tags can be associated with? The viewer would only re-apply those tags on a double reset, not after a mere LOOP, which would leave those parameters a little more under user control.

[rowett]

The flickerlessness is good enough now that it's not necessary to run multiple cycles before looping back, any more -- though I think a standard of something like 10x is still a good idea, just to show that the spaceship really _is_ a spaceship. Otherwise it's really easy to make April Fool's spaceships.

I enjoyed the April Fool spaceship Quick note if you want to use the old method the T and LOOP targets should now be the same generation (since a fix in a recent build).
I'll probably change the TRACK command so it applies a multiple.

The only hiccup that I can see is that the Pause/Step button doesn't interact with TRACK very well.

For reference TRACK is just Waypoint mode.

The Pause button doesn't turn LOOP off the way it does normally

True, because in Waypoint mode we're saying "pause the animation at this point" and the most likely course of action is that I want to continue the animation.

... and hitting the Step button after a pause just goes to the next frame -- for slow frame rates you almost don't notice that the Step button is working at all, and you have to click a lot of times to get to the next tick.

In Waypoint mode step moves forward in time, not generation. This allows you to manually glide through a waypoint animation. I tend to hold down the SPACE bar rather than click. If I want to step forward generations I just turn Waypoints off with hotkey "w" and then SPACE (or Step button) steps generations (not time).

More later... just getting on a flight.

[dvgrn]

The Pause button doesn't turn LOOP off the way it does normally

True, because in Waypoint mode we're saying "pause the animation at this point" and the most likely course of action is that I want to continue the animation.

Thanks for the explanation. I think the 'w' hotkey was the reminder I was looking for -- a quick way to escape from the tyranny of the waypoint system. There isn't any onscreen equivalent, correct?

Just to keep a record of another test case: in another thread I tried the following:

Code: Select all

x = 64, y = 34, rule = LifeHistory
34.A$34.ABA$34.2A11$54.A.A$55.2A$20.A34.A$19.A.A$15.CD2.C.CD22.2D2.D.
2D4.A.A$14.C.AD2.CD22.D2.D2.2D5.2A$14.AD.C27.D.D10.A$15.AC29.D14.3A$
23.D37.A$20.2D.D38.A$20.D$20.3D$34.3A$34.A$35.A4$.A$.2A$A.A!
#C [[ PAUSE 2 THEME 6 AUTOSTART STOP 47 ]]

I can see how THEME 6 would cause trouble with a LifeHistory pattern... but some odd things happen to the colors without the THEME 6 setting also. Haven't checked to see if this is still an issue in Build 195 yet -- I'm about to start a seven-hour road trip.

[rowett]

Thanks for the explanation. I think the 'w' hotkey was the reminder I was looking for -- a quick way to escape from the tyranny of the waypoint system.

In fact if you Pause during Waypoint playback and then zoom and pan the pattern when you then Play the first thing that happens is the Waypoint system will glide from where you navigated back to where it left off.

There isn't any onscreen equivalent, correct?

No, there's no onscreen equivalent to the "w" hotkey. One UI design goal was to keep the screen as uncluttered as possible from controls. The only visual clue you have that Waypoint mode or LOOP is active is the progress bar on the generation display control bottom left.

The two options I'm debating on this topic are:

1. Should I make TRACK a special simple case of Waypoint animation that behaves like LOOP-only mode i.e. as soon as you Pause it disables Waypoint playback and LOOP, which would also mean Step would work generation by generation. The fact TRACK uses Waypoint mode under the covers in an implementation decision which we can hide from the user.
2. Should I add a script command so when you launch the standalone viewer via THUMBLAUNCH it doesn't inherit the TRACK command. So you could be watching a Copperhead animation, think to yourself you'd like to explore more, click on the Thumbnail and then get the standalone viewer without the TRACK in manual mode (but with other settings, THEME, ZOOM etc.).

I think I prefer the first option because it's more intuitive to the user. Thoughts?

[rowett]

I'm also considering making the Step and Step Back controls always work on generation (even in Waypoint mode). In addition when in Waypoint mode and playback Paused a new slider control would appear just north of the Step buttons that would allow you to move forward and back in time. The furher you slide the control the faster it goes.

[dvgrn]

The two options I'm debating on this topic are:

1. Should I make TRACK a special simple case of Waypoint animation that behaves like LOOP-only mode i.e. as soon as you Pause it disables Waypoint playback and LOOP, which would also mean Step would work generation by generation. The fact TRACK uses Waypoint mode under the covers in an implementation decision which we can hide from the user.
2. Should I add a script command so when you launch the standalone viewer via THUMBLAUNCH it doesn't inherit the TRACK command. So you could be watching a Copperhead animation, think to yourself you'd like to explore more, click on the Thumbnail and then get the standalone viewer without the TRACK in manual mode (but with other settings, THEME, ZOOM etc.).

I think I prefer the first option because it's more intuitive to the user. Thoughts?

The first option seems to have been what I was intuitively expecting, so it certainly makes some sense to me to go that route.

Really when you want a closer look -- but not for something small and simple like a Copperhead, more for something big that's still a spaceship, like pretty much anything in Golly's Patterns/Life/Spaceships collection -- it doesn't seem like you'd necessarily want to disable TRACK when you go to the larger size. It will be really nice to not always have to be chasing what you're looking at, as it's running off the screen.

... Hmm, for growing spaceships, would it be possible to set a change-in-zoom as well as a change-in-X and change-in-Y, so that by default the whole spaceship remains on the screen? That would be vaguely useful in some cases -- though definitely very far from a necessity. And it would require a version of TRACK that kept going instead of LOOPing, of course.

[rowett]

I think I prefer the first option because it's more intuitive to the user. Thoughts?

The first option seems to have been what I was intuitively expecting, so it certainly makes some sense to me to go that route.

Agreed I'll go with option 1.

... Hmm, for growing spaceships, would it be possible to set a change-in-zoom as well as a change-in-X and change-in-Y, so that by default the whole spaceship remains on the screen? That would be vaguely useful in some cases -- though definitely very far from a necessity. And it would require a version of TRACK that kept going instead of LOOPing, of course.

Please could you point me at some growing spaceship examples? TDD need to start with a test case

[dvgrn]

Please could you point me at some growing spaceship examples? TDD need to start with a test case

I've pretty much decided that this was a lousy feature request, because growing spaceships are relatively rare and in a lot of cases not terribly interesting. And actually it would be nice to be able to set up non-looping smooth-zooms for a lot of other patterns, including ones that grow in several directions at once.

But let's start with this random sample, anyway:

Code: Select all

#C growing spaceship based on tubstretcher --
#C c/4 at the front, c/12 at the back.
#C Jason Summers, 30 June 1999
x = 161, y = 176, rule = B3/S23
116b3o2$120b2o$122bo10b3o$116b4obo11bo$116b5o2$133bo2bo$116bobo14bob2o
$116bobo14bo2bo$117bo15bobo5b2o$116bobo14b3o5b2o$117b2o$117bo3$113bobo
15b3o$104bob3o4bobo13b2ob2o$102b2obo4bo5bo11bobob2o15b2o$104b2o4bo2bo
2bo11b2o19b2o$110bo2bo2bo11b2o$109bo4bo$105bo2bo16b2o$106b2o17b2o$87b
3o49b3o$86bo3bo47bo3bo$86bo3bo27bo19bo3bo$86bo3bo13bo12bobo18bo3bo$
104bo12bobo$87b2ob2o12bo13bo20b2ob2o$88bo2bo48bo2bo$89bobo14bo34bobo$
90b2o13bobo34b2o$87bo3bo14bo32bo3bo$86bobobobo45bobobobo$87bo51bo5$
133bo$133bo7bo$133bo5b3o9b2o$132b2o3bobo11b2o$138bo2bo$92b2o43bo2b2o$
92b2o3$83bo$82b3o74b2o$81b2o2bo73b2o$80b2o2b2o$81b2o17b2o$82b5o13b2o$
86b2o$84bo2bo53b2o3b2o$85b2o12b2o38b4o3bobo$99b2o37bo2bo2bo3bo$132bo5b
o4bo3b2o$120bo10b3o5bo3bo$108b2o9b3o7b6o9bo$83b3o22b2o8bo13b2o$83bobo
33b2ob2o5bob2o$83bo36b3ob2o4b2o$83bo2bo20b2o13b4o$83bo3bo19b2o$86b2o$
83b2o3bo$65b3o15b3obo28b2o$64bo14b2o6bo28b2o$63bo4b2o9b3o$62bo3bo10bob
3o11bo$62bo2bo4bo4b2o15bob2o19b2o$37b2o15bo7bo3bo3bo4b2o14bo6bo7bo8b2o
$25b3o9bobo13b3o7b2obob3o19b4o4bo6b3o$25bo2b3o6bo9bo18bo23b2o2bo3bo$
26bobo16b2obo4b3o11b4o18b2o5b2o7b3o$31bo4b2o2bo3b2o2bo5b2ob2o10b2o11bo
b2o3bo16b2ob2o$29bo6b2o2bob2o2bo9bo25bo25bo$31bob2obo3b5o39b2o55bo$40b
2o41b3o55bobo$32bo2b6o29bo12bobo55b2o$33b7o30bo12bobo$35b3o16bo15bo13b
o21bo$53bobo49bobo$38bo15bo17bo33bo$37bobo31bobo$38bobo12b2o17bo32b2o$
39bobo10bobo49bobo$40bobo$41bobo8b3obobo45b3obobo$42bobo11b3o49b3o$43b
obo10b2o50b2o$44bobo$45bobo48b5o7bo$46bobo45b2o5b2o4bobo$47bobo44bo7bo
4bo9b2o$48bobo43b2o7bo3bo2bo6b2o$49bobo44b2o6bo3b3o$50bobo5b2o39bo$40b
obo8bobo4b2o39bo4bo$26bobo7bo2bo2bo9bobo45b2obo$25b2ob2o5bobob2obo10bo
bo$26bob2o6bo17bobo$30bo11b3o10bobo67b2o$29bo13b2o11bobo66b2o$29bo12b
2o7b2o4bobo$51b2o5bobo5b2o$59bobo4b2o47bo3bo$60bobo50bo2bob3o$23b3o35b
obo52bobobo$22bo3bo35bobo22bo26bo10bo$21bo4bo36bobo20b3o24b2o10bobo$
20bo3bo39bobo18b2ob2o14b2o8bobo3bo4b2o$20bo2bob3o31b2o4bobo18b3o9b2o4b
2o8bobo$20bo7bo30b2o5bobo5b2o11bo10b2o5b2o$22bo3bobo38bobo4b2o11bobo$
22bo3bob2o38bobo16b4o8bob2o$24b3ob2o3b3o33bobo18bo7b2obo$38bo31bobo28b
2o$37bobo31bobo12b2ob2o8bo$38bo33bobo10bo5bo$67b2o4bobo10bo3bo$24b2o
41b2o5bobo5b2o3bo$24b2o49bobo4b2o$23bo52bobo$77bobo$21b3o54bobo$3bo17b
3o55bobo$2b3o17b2o56bobo$b2ob2o23b2o44b2o4bobo$2o3bo7b5ob2o11b3o40b2o
5bobo$bobobobo5bo5b2o8bob2o2bo47bobo$2b2obo2bo4b2o5bo8bob4o30bo7bo10bo
bo$5b2obo7bobo45b3o5bobo10bobo$6b2o9b2ob2o41b2ob4o2bo2bo10bobo$19bo44b
3o2bo17bobo$28b2o35bo2b2o2bo15bobo$26b3o40b2obobo14bobo$25b3o45bo16bob
o9bo$24bobo64bobo7bo$23bo2bo65bobo6b3o$24bo2bo19b3o43bobo$24bo22bobo
44bobo12bo$28bo17bo3bo44bobo11bobo$28bo17bo3bo45bobo10b2o$25b3o18bo19b
2o2bo26bobo$8b2o36bo4b2o13b2ob2obo25bobo$8b2o36bo6bo45bobo$47bo5bo15b
3o20b2o6bobo$47b2o20bobo19bobo7bobo$49bo3bo39bo8bobo$40bobo7bobo12b2o
36bo$26bobo7bo2bo2bo22b3o$25b2ob2o5bobob2obo24bo$16b2o8bob2o6bo10b3o$
16b2o12bo11b3obo3bo$29bo13b2o2bo2bo$29bo12b2o5b2o3$61bo2bo$63b4o$24b2o
34bo$24b2o35b2o2b2o$48b2o$48b2o11b2o$60b2o$61b2o2bo5$56b2o$56b2o!
#C [[ AUTOFIT ]]

Other old classics include Paul Schick's c/2 and 6c/13 blinker ship --

Code: Select all

x = 22, y = 19, rule = B3/S23
12b2o$8b4ob2o$8b6o$9b4o$18b2o$17b4o$17b2ob2o$10bo2bo5b2o$bo8bo3bo$2o7b
o4b2o$bo8bo3bo$10bo2bo5b2o$17b2ob2o$17b4o$18b2o$9b4o$8b6o$8b4ob2o$12b
2o!
#C [[ AUTOFIT ]]

and David Bell's c/2 and 3c/10 pi ship:

Code: Select all

x = 117, y = 93, rule = B3/S23
25b4o$24b6o$23b2ob4o17b6o$24b2o21bo5bo$47bo$15bo32bo4bo$13bo3bo32b2o$
12bo19b2o$12bo4bo8b2o3b3o$12b5o8bo2b3o3b2o$25bobo7b2o5b2o$26bo3bo5b2o
4bobo$4o27bo4bo6bobo$o3bo9bo20bo8bo68b2o$o11b2o98b2ob2o$bo2bo2b2o5b3o
96b4o$6b3o6b3o96b2o$bo2bo2b2o5b3o11bo$o11b2o$o3bo9bo$4o18bobo39b3o$36b
2o26bobo$35b2ob3o19bo3b2o$13b2o21b5o17bo3bo$12b2ob2o20b3o6bo10bo$13b4o
27bo3bo8bo4bo$14b2o27bo13b5o$43bo4bo$43b5o3$31b4o$31bo3bo10bo$31bo7b2o
4bobo$32bo2bo2b4o3bo2b2o8b2o16b2o$37b2o3bo5bob2o6b2o16b2o$32bo2bo2b4o
3bo2b2o$31bo7b2o4bobo$31bo3bo10bo$31b4o3$44b5o$44bo4bo$44bo31bo$45bo3b
o25b2o$74bo$45bo3bo25b2o$44bo31bo$44bo4bo$44b5o3$31b4o$31bo3bo10bo$31b
o7b2o4bobo$32bo2bo2b4o3bo2b2o$37b2o3bo5bob2o6b2o16b2o$32bo2bo2b4o3bo2b
2o8b2o16b2o$31bo7b2o4bobo$31bo3bo10bo$31b4o3$43b5o$43bo4bo$14b2o27bo
13b5o$13b4o27bo3bo8bo4bo$12b2ob2o20b3o6bo10bo$13b2o21b5o17bo3bo$35b2ob
3o19bo3b2o$36b2o26bobo$4o18bobo39b3o$o3bo9bo$o11b2o$bo2bo2b2o5b3o11bo$
6b3o6b3o96b2o$bo2bo2b2o5b3o96b4o$o11b2o98b2ob2o$o3bo9bo20bo8bo68b2o$4o
27bo4bo6bobo$26bo3bo5b2o4bobo$25bobo7b2o5b2o$12b5o8bo2b3o3b2o$12bo4bo
8b2o3b3o$12bo19b2o$13bo3bo32b2o$15bo32bo4bo$47bo$24b2o21bo5bo$23b2ob4o
17b6o$24b6o$25b4o!
#C [[ AUTOFIT ]]

-- all of which are somewhat nauseating to follow with AUTOFIT.

The most general case would probably need a separate configurable speed for the N, S, E, and W edges of a bounding box, and the LifeViewer would continuously AUTOFIT the bounding box, whatever size it is calculated to be. That would allow smooth-zooms of strange things like elbow ladders:

Code: Select all

x = 463, y = 206, rule = B3/S23
141b2o160b2o$141bo162bo$159b2o143bobo$128b2o29bo145b2o7bo$128bo184b2o$
173b2o137b2o$173bo139b2o$300b2o37b3o$300bobo38bo$139b2o3b2o101b2o53bo
38bo$142bo104bo52b3o10b2o25bo$139bo5bo10b2o3b2o82bobo64b2o$95b2o43b2ob
2o12b5o70b2o11b2o66b2o9bo15bo$95bo31b3o11bobo14b3o70bo2b2o78bo7b2o17bo
$126bo3bo11bo16bo70b6o64b3o20b2o16bo8bo$82b2o41bo5bo10bo27b2obob2o38b
2o15b4o47bo18bo36b3o8b2o62b2o$82bo42bo5bo68bo13bo2bo36b3o26b2o15bobo
112bo$128bo41bo5bo23b2o11b2o2bo35bo4bo41b2o63b2o48bobo11bo$126bo3bo83b
o2bo34bo5bo106bo50b2o10b2o$127b3o41b2ob2o39bo9bo6b4o17bo109bobo61b3obo
$128bo44bo52b2o2b6o18b2o97b2o8b2o61b2o$82bo55bobo19bo54bo9b2o4bo2b2o
69b2o45bo2bo51b2o18b2o17b3o$82bo13bo41b2o21b2o51bo2bo14b2o20b2o48bobo
44b2o2bo53bo18bo15bo4bo$81bobo11b3o27b3o11bo3b3o14b2o51b2o2bo35bo50bo
47bo2bo50b2o2bo33bo5bo$80b2ob2o9b5o26b3o14bo3bo67bo2bo34bo5bo8bo35b2o
6bobo15b4o20bo16b2o35bo2bo17bo20bo$79bo5bo7b2o3b2o24bo3bo12bo5bo67b2o
36bo4bo8b2o42b2o16b2obo36bo2b2o34bobo16b2o18b2o$82bo11b5o33bobo6b2obob
2o106b3o55bo19bo20bo14b6o34b2o16b2o7bobo$79b2o3b2o8bo3bo24b2o3b2o3b2o
39b3o153b2o20bo2bo14b4o53b3obo3b2o10b2o$95bobo35bo20b2o3b2o12bo3bo173b
2o2bo52b2o18b2o6bo12bo$96bo59b3o122b4o45b2o20bo2bo52bobo18bo14bo5bo10b
o$155bo3bo12bo5bo59bo6b2o18bo15bo2b2o46bo20b2o39bo12bo2bo33bo4bo11b2o$
156bobo13b2o3b2o59b2o5bobo17b2o15bo2b2o31bo10b2obo37b4o20b2o10b2o2bo
35b3o$98bo58bo72bo16bo34bo2bo32b2o9b4o35b6o11bo23bo$96b2ob2o45b2o82b2o
15b2o34b2o84bo2b2o11b2o20b2o$146bo223b2o51b2o$95bo5bo45b3o4b2o127b2o
74bo64bo$149bo5bo126bo2bo73b2o55b2o4bo3b2o$95b2obob2o24b2o24b3o127bo2b
2o5bo100b2o20bobo4bob2ob2o$77b2obob2o42bo9b4o12bo110bo17bo2b2o6b2o69b
2o18bo7b2ob2o14bo4bo7b2obo$77bo5bo47b2o7bo33b2o88bo16b4o78bobo17b2o6bo
2bo15b2o2b2o$78bo3bo48bo3b2o3bo24b2o7bo6bo80b3o83bo16bo25bo2bo$79b3o
53bo3bo15bo6bobo2bob2o8b3o166b2o15b2o25b2o$153b2o6b2o2bo4bo7bo69bo$
154b2o10bo11b2o69b2o141b2o$142b2o23bo80b2o110bo30bo2bo$100b2o40bo19bo
198b2o28bo2bo15bo$100bo28b2o9bobo17b3o13bo183b2o29b2ob2o14b2o$97bo3b3o
27bo8b2o17bo14b2ob2o109bobo102b2o$59b2o34bobo5bo17b2o9bo26b2o127b2o$
59bo20b2o14b2o23bo10bo40bo5bo42b2obo3bob2o56bo52bo5bo63bobo$80bo8b2o
41bo89bo2bo3bo2bo108b3o3b3o62b2o$46b2o37b2o2b2o2b2o36bo41b2obob2o43b3o
3b3o108b2obo3bob2o23b2o37bo$46bo38bobo2bo2bo35b2o5bo78bo23bo135b2o$86b
3o47bobo76b3o19b3o134bo$60bo26b2o47b2o40bo39bo17bo$60bo114bo2bo38b2o
17b2o$59bobo116bo$58b2ob2o83bo27b2o$57bo5bo82bobo5b2o3b2o13bo$43bo5bo
10bo85b2o8b3o15bobo$43bo5bo7b2o3b2o30bo60bo3bo15b2o62b2o92bo23bo$44bo
3bo45b2o60bobo61bo5bo13b2o44bo46b3o19b3o$45b3o34b2o11b2o27b2o31bo61b3o
3b3o11bo47bo48bo17bo$81b3o3bo7b3o7b2o17bo50b2o3b2o36b2obo3bob2o56b3o
47b2o17b2o42bo$78bob2o4b4o5b2o8bo53b2o14bo5bo217bo$71b2o5bo2bo4bo4bo2b
2o63bo111bo125b3o$71bo6bob2o5bo3bo2bo65b3o13bo3bo91b2o$81b3o3b2obo71bo
14b3o78b2o3bo7b2o110bo$82b2o23b2o134bo14b3obob2o118b2o$106bo2bo133b2o
13b3o4bo117b2o21bo$109bo151bo3bo10bo130b2o$59b2obob2o43bo15bo10b2o90bo
33b3o3b2o7b2o127b2o$59bo5bo40b2obo13b2o11bobo15bo73b2o38b2o6b2o110bo$
60bo3bo42bo16b2o10bo17b2o71bobo32b3o3bo120b2o$61b3o197bo3bo85b2o20bo
14b2o$24b2o129bo102b3o4bo86b2o15b2o2bo$24bo16b2o3b2o33bo25b2o45bobo
101b3obob2o71bo7bo5bo9bo6bo5bo$55bo24bobo24bo19bo25bo2bo101b2o3bo73bo
2bobo2bo15b2o4b2o2bobo$11b2o29bo3bo9bo11b2o9bo3b2o8bo9bo21bobo24bo2bo
12bo108bo59b3o3b3o22b2o3bo$11bo31b3o8b3o11bo10bo3b2o5b4o10b2o20b2o39b
2o3b2o3b2o98b2o90b3o$43b3o33bo3b2o4b4o10b2o50bo11bobo$64b2o14bobo6bo2b
o47bo13b2o17bo3bo191b3o$64bo16bo7b4o45b3o33b3o191b2o3bo$65b3o22b4o7b2o
34bo36b3o190b2o2bobo$22b2o3b2o38bo25bo7bobo6bo26b2o170bo58bo5bo$25bo
18b2o57bo5bo200bo58b2o2bo32bo$22bo5bo15bo9bo48b2o4b3o50b2o9bo134b3o62b
o21bo10bo2bo$23b2ob2o21b3ob2o2b2o57bo41b2o2b2o2b2o4b3o220b2o9bo2b2o$
10b3o11bobo22b4o4bo58bobo39bobo2bo2bo4bo3bo46bo7bo63bo$9bo3bo11bo27b2o
61b2o41b3o11bo48bo2bobo2bo64b2o$8bo5bo10bo134b2o8bo5bo45b3o3b3o63b2o
45bo5bo$8bo5bo155bo5bo163b3o3b3o$11bo58bo100bo3bo164bob2ob2obo$9bo3bo
57bo100b3o124bo42b2ob2o$10b3o56b3o61b5o131b2o7b2o20b2o40b2ob2o41b3o3b
3o$11bo120bob3obo130bob2o3b2obo19b2o41b2ob2o41bo2bobo2bo$21bobo35bobo
71bo3bo131bo3bobo3bo107bo3bobo3bo$21b2o36bo3bo70b3o132b2o2bobo2b2o107b
4o3b4o$8b3o11bo3b3o14bo19bo71bo134b3o3b3o109bo7bo$8b3o14bo3bo11b4o14bo
4bo4b2o50b2o106bo41bo5bo165b2o$7bo3bo12bo5bo9bobob2o17bo5bo51bo60b2o
45b2o211b2o$24b2obob2o4b2o2bo2bob3o12bo3bo31bo70b2o7b2o5bo261bo$6b2o3b
2o3b2o17bo4bobob2o13bobo31b2o40b2o23bo5bobo6bo$16bo24b4o49b2o11bo10bob
o14bo24b3o3bo9b3o$43bo28bo33bo10bo2bo42bo14bo$71b2o33b3o7b2o44b2o113bo
$114b2o3bo8b2o147b2o$72bo43b2o10bo203bo7bo$23bo5b2o40bobo43bo2bo212bo
6b2o$24b2o3bo31bobo6bo2bo44bobo61b3o146b3o$23b2o5b3o29b2o5bo2bo38bo69b
o3bo$32bo29bo47b3o67bo5bo130bo$9b2o21bobo8b2o27bo36b5o66b2obob2o131b2o
$9bo8b2o13b2o7b3o26b2o89b2obob2o148b2o69bo$14b2obo2bob2o15bob2o12bo24b
o307b2o$14bo4bo2bo16bo2bo12b2o22bo82bo5bo$18bo20bob2o13b2o21b3o240bo$
17bo24b3o11b3o27bo17bo58b2ob2o155b2o$43b2o11b2o28bobo13b3o60bo156b2o$
55b2o8b2o19b2o13bo7b5o$55bo9bobo33b2o7b3o$67bo43bo55bo$67b2o97bobo$
165bo3bo8b2o3b2o$76bobo14bobo69b5o11bo$77b2o14b2o4bo64b2o3b2o7bo5bo$
77bo16bo3b3o64b5o9b2ob2o$28bo69b3o65b3o11bobo227b3o$28b4o135bo13bo230b
o$12bo16b4o63b2o3b2o78bo229bo$11bobo5b2o8bo2bo5b2o56bo4bo253bo$9b2o3bo
14b4o5bo26bo290bo$4b2o3b2o3bo4bobob2o3b4o31b2o289b3o$4bo4b2o3bo5b2o3bo
2bo35b2o11bo$11bobo10bo51bo103b2o158bo$12bo8bo2bo15b2o34b3o6b2o93bo
160b2o$40bobo42bo254b2o$41b3o123b2o$42b2o9bo45b2o66bo$25b3o3bo7b2o13b
2o43bo245bo$27bo4bo6b3o11b2o291b2o$2o24bo3b3o312b2o$bo$bobo8b2o26b2o$
2b2o8bo5bo21bo9bo$9b2o6b5ob2o24bo$8b3o5bo2b2o4bo23b3o$9b2o5b2o8bo29bo$
12b2o4bo7bo29bobo$12bo13bo29b2o$25bo8b2o26bo$23b2o9bobo23b2o$36bo24b2o
14bo$36b2o37b3o300bo$74bo304bo$74b2o301b3o$32bo354b3o$32bobo328bo25bo$
32b2o330b2o22bo$363b2o3$69b2o3b2o292bo$47bo21bobobobo293b2o$46bo23b5o
293b2o$46b3o22b3o$53bo18bo$53bobo$53b2o2$58b2o$58bo2$72b2o$72bo$386bo$
386bo2bo$386bo2b2o$22b2o$22bo$32bo$30b2o$31b2o11$17bo$16bo$16b3o$23bo$
23bobo$23b2o6$12b2o$12bo!
#C [[ AUTOFIT ]]

There would still be difficulties with some patterns, like ones with bounding boxes that grow logarithmically. But I think most of those are big and awkward enough that reasonable people wouldn't ask LifeViewer to simulate them -- at least not beyond the point where a linear smooth-zoom would be a reasonable approximation.

[rowett]

The most general case would probably need a separate configurable speed for the N, S, E, and W edges of a bounding box, and the LifeViewer would continuously AUTOFIT the bounding box, whatever size it is calculated to be. That would allow smooth-zooms of strange things like elbow ladders.

Were you envisioning N, S, E and W being defined as cells per generation where:

• -c <= N, S E or W <= c
• N >= S and E <= W
• non-growing patterns would have N=S and E=W

The other thing to bear in mind is that the LifeViewer grid is a maximum of 8192x8192 cells. This is not an issue for the TRACK command because it LOOPs. If you're not looping then at some stage your pattern will hit the grid boundary. One example is the 3c/7 post on the conwaylife.com home page and your blog. Since this doesn't use LOOP it actually hits the upper grid boundary at T=9393. Luckily the pattern is only running at 4 GPS so this takes just over 39 minutes to happen. You could buy more time by using the YOFFSET command to start the pattern at the bottom of the grid and a large DELETERANGE so it left no evidence after the hit.

[dvgrn]

Were you envisioning N, S, E and W being defined as cells per generation where:

• -c <= N, S E or W <= c
• N >= S and E <= W
• non-growing patterns would have N=S and E=W

This description makes me try to think about two different things at once. The inequalities make sense for points along the X and Y axes, but the definition would be a starting N, S, E, and W, plus a deltaN, deltaS, deltaE, and deltaW which would all usually be between -1 and 1.

I see that there are some things to worry about as regards "N >= S and E <= W", if you're trying to avoid having the N and S or E and W boundaries coincide (and possibly cause division by zero errors). I was kind of thinking that the current closest zoom level would put a cap on that kind of thing, and that the boundaries could be swapped if the N one got farther south than the S one (or whatever).

Huh. "E <= W". What kind of coordinate system has the X coordinate increasing to the west, anyway? Have been meaning to ask about that. For the April Fool's knightship I originally wrote

#C [[ T 6 X -1 Y 2 LINEAR ALL ]] (simplified)

because by T=6 I wanted the camera to move by (-1, 2), left 1 and down 2, to keep up with the "knightship" motion. But to make it work I had to edit that to

#C [[ T 6 X 1 Y -2 LINEAR ALL ]]

and I didn't really know why -- just kind of shrugged and moved on, figuring I was just confused and it would all be clear if I thought about it more. But today I'm still confused.

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

Here's an alternate proposal that allows a lot more interesting cases to be covered -- including the pi ship one that doesn't stick out beyond the LWSSes on the right at all for a while, and then it does.

• Define a Point of Interest (POI) as POI X1 Y1 T1 X2 Y2 T2, where the point is considered to move linearly from (X1, Y1)@T1 to (X2, Y2)@T2
• Points of interest always have to be inside the view, so if the current view doesn't include the POI's current location, adjust the appropriate boundary so that the point is (at least barely) visible.
• Add more POIs, at least one for each moving boundary -- and if a boundary shouldn't move at first, then start with T1>0... and if a boundary should start moving faster after a while, define a second POI that moves faster than the first POI at that boundary.
• If AUTOFIT is turned on, then consider the corners of the current active pattern's bounding box to be POIs also.
• [Tangential thought: might it be possible to have an AUTOFIT version that includes LifeHistory 'blue cells', or the LifeViewer equivalent?]
• If all POIs are inside the viewport, or if there are no active POIs, then there's nothing to do and the zoom level can remain the same.
• If one POI moves outside of the viewport, the default is to move the camera and keep the zoom level the same... but if that would move another POI outside of the viewport, then the zoom level has to change.

The appearance and disappearance of POIs could affect the viewport in all kinds of interesting ways -- could allow an alternate way of tracking multiple signals simultaneously through a circuit without having to calculate common center locations or zoom levels.

The other thing to bear in mind is that the LifeViewer grid is a maximum of 8192x8192 cells. This is not an issue for the TRACK command because it LOOPs. If you're not looping then at some stage your pattern will hit the grid boundary.

Thinking about it, it's usually fine to stop or loop at some point, which can be chosen safely below the limits of the viewer. Growing patterns tend to get boringly predictable well before 8192x8192, and really you might as well start them over. Just wouldn't want them to start over too early, before the pattern was established.

[rowett]

Were you envisioning N, S, E and W being defined as cells per generation where:

• -c <= N, S E or W <= c
• N >= S and E <= W
• non-growing patterns would have N=S and E=W

This description makes me try to think about two different things at once. The inequalities make sense for points along the X and Y axes, but the definition would be a starting N, S, E, and W, plus a deltaN, deltaS, deltaE, and deltaW which would all usually be between -1 and 1.

Yes sorry I wasn't clear. My expectation was that N, S, E and W would be deltas from the pattern starting bounding box, so there would be no need to specify an initial N, S, E and W. Also I got E and W the wrong way round. Jet lag.

I see that there are some things to worry about as regards "N >= S and E <= W", if you're trying to avoid having the N and S or E and W boundaries coincide (and possibly cause division by zero errors). I was kind of thinking that the current closest zoom level would put a cap on that kind of thing, and that the boundaries could be swapped if the N one got farther south than the S one (or whatever).

The reason for this (correctly written as "N >= S and W <= E") is that I couldn't see a case where you'd want the bounding box to flip either in the horizontal or vertical axis.

Huh. "E <= W".

My mistake. W <= E.

What kind of coordinate system has the X coordinate increasing to the west, anyway? Have been meaning to ask about that.

The LifeViewer coordinate system has 0, 0 at the top left. Somewhat counter-intuitively the X and Y specify the number of cells to shift the pattern right and down in the viewport (which has the effect of panning the camera left and up), rather than how many cells left and up the camera moves. I could easily change this but we'd need to go back and amend any patterns that used Waypoints or the TRACK command, which today is probably quite small.

Assuming a decision on the coordinate system I like the proposal above because it's simple. Initial N, S, E, W position is automatic based on AUTOFIT of T=0 pattern position so no need to specify. User simply defines the dN, dS, dE and dW in cells/generation. To determine these values they could simply run their pattern for a number of generations, AUTOFIT, and these values could be displayed in the help information.

Here's an alternate proposal that allows a lot more interesting cases to be covered -- including the pi ship one that doesn't stick out beyond the LWSSes on the right at all for a while, and then it does.

I'll need to think about this some more. My initial question is how easy would this be to specify?

Tangential thought: might it be possible to have an AUTOFIT version that includes LifeHistory 'blue cells', or the LifeViewer equivalent?

Did you mean just for LifeHistory patterns or in general?
Currently for LifeHistory patterns the bounding box size is never smaller than the initial pattern bounding box defined by all LifeHistory states (which includes state 2).
For non-LifeHistory patterns it just uses the live (and in the case of Generations also decaying) cells.

[dvgrn]

Assuming a decision on the coordinate system I like the proposal above because it's simple. Initial N, S, E, W position is automatic based on AUTOFIT of T=0 pattern position so no need to specify. User simply defines the dN, dS, dE and dW in cells/generation. To determine these values they could simply run their pattern for a number of generations, AUTOFIT, and these values could be displayed in the help information.

Here's an alternate proposal that allows a lot more interesting cases to be covered -- including the pi ship one that doesn't stick out beyond the LWSSes on the right at all for a while, and then it does.

I'll need to think about this some more. My initial question is how easy would this be to specify?

Fairly easy, since the mouse coordinate readout is available. We want to make sure that such-and-such a signal is always on the screen. So we create a POI for it... first time we see it it's at (X1, Y1, T1). Run to the next turning point -- e.g., a Snark, if it's a glider -- point at it, and record (X2, Y2, T2). Do the same for other POIs tracking other gliders traveling in different directions, and that could guarantee that all the interesting signals stayed in view, without having to figure out how to interpolate zoom levels. (Maybe?) I've had a lot more trouble getting zoom levels right, in setting up waypoint animations, than with collecting simple spacetime coordinates.

Anyway, it's quite possible that if you implemented a POI system, no one but me would ever use it. The dN, dS, dE, dW system would be just fine... but might it be possible to specify those numbers as fractions instead of as decimals?

Tangential thought: might it be possible to have an AUTOFIT version that includes LifeHistory 'blue cells', or the LifeViewer equivalent?

Did you mean just for LifeHistory patterns or in general?

I was thinking of patterns in general. A HISTORYFIT option would do a lot to settle down the bumpy auto-fit tracking of sparky oscillators like pentadecathlons, and of sparky spaceships like Corderships -- though in the case of a spaceship, of course you'd end up seeing the whole track from where it started. That's a very different effect but seems as if it might be what's wanted sometimes.

[rowett]

Anyway, it's quite possible that if you implemented a POI system, no one but me would ever use it.

Yes true. Also I think until the TRACK system you and I were a in a very elite club of people who'd ever used the Waypoint system.

The dN, dS, dE, dW system would be just fine... but might it be possible to specify those numbers as fractions instead of as decimals?

Yes it's done and will be in the next build and can be used for any script command that takes a number as an argument. Division by zero becomes zero.

A HISTORYFIT option would do a lot to settle down the bumpy auto-fit tracking of sparky oscillators like pentadecathlons, and of sparky spaceships like Corderships -- though in the case of a spaceship, of course you'd end up seeing the whole track from where it started. That's a very different effect but seems as if it might be what's wanted sometimes.

I don't think it's needed for spaceships since TRACK works well for non-growing spaceships and whichever NSEW/POI system we build will work for growing ones.
I certainly see value for oscillators.

[dvgrn]

... I think until the TRACK system you and I were a in a very elite club of people who'd ever used the Waypoint system.

Now that the LifeViewer has escaped from the forums and is running free on the LifeWiki -- and on my weblog -- I'm hoping that we can induct a few new members into the club. Rich Holmes' four "Gun Show" articles, reposted to the conwaylife.com main page, might almost have been simpler to do if Rich had known about LifeViewer's waypoint system. Illustrations of how synchronized signals travel through circuitry may come in handy in a few upcoming forum discussions also.

Even if I am the only user, I do kind of like the POI idea. There are a lot more opportunities for creative misuse of the system... Only one POI would be needed to track a moving object when the zoom doesn't have to change, and only two would be needed to set up a smooth zoom in or out from one camera viewpoint to another, just by recording two opposite corners of the viewpoint bounds.

The waypoint system can already do that, of course, but it doesn't really guarantee that the intended points of interest are actually visible. The viewport may have changed shape between original WIDTH and HEIGHT settings and the pop-up viewer.