Life tag testing

[dvgrn]

Haven't found any new bugs to complain about yet (but just give me a little time).

Okay, how about these?

Code: Select all

#C script order matters as soon as PAUSE is included,
#C  even with no waypoints set with "T" keyword --
#C during PAUSE, the viewer pans from default to chosen setting
x = 244, y = 228, rule = B3/S23
222b2o$222b2o4$242b2o$242b2o4$211b2o$211b2o6$238b2o$238bobo$239bo$231b
2o$231b2o19$206b3o$208bo$207bo18$190b3o$192bo$191bo18$180b2o$181b2o$
180bo18$145b3o$147bo$146bo18$122b2o$123b2o$122bo32$62b2o$61bobo$63bo
10$40b2o$39bobo$41bo25$20b3o$22bo$21bo30$b2o$obo$2bo!
#C [[ PAUSE 2 AUTOSTART STEP 4 ZOOM 6 X -100 Y 100 ]]

Code: Select all

#C Zoom setting before PAUSE (I think) becomes initial setting
#C -- no zooming during PAUSE now
x = 244, y = 228, rule = B3/S23
222b2o$222b2o4$242b2o$242b2o4$211b2o$211b2o6$238b2o$238bobo$239bo$231b
2o$231b2o19$206b3o$208bo$207bo18$190b3o$192bo$191bo18$180b2o$181b2o$
180bo18$145b3o$147bo$146bo18$122b2o$123b2o$122bo32$62b2o$61bobo$63bo
10$40b2o$39bobo$41bo25$20b3o$22bo$21bo30$b2o$obo$2bo!
#C [[ ZOOM 6 X -100 Y 100 PAUSE 2 AUTOSTART STEP 4 ]]

Code: Select all

#C If no X and Y settings,
#C the viewer zooms from default to chosen setting
x = 244, y = 228, rule = B3/S23
222b2o$222b2o4$242b2o$242b2o4$211b2o$211b2o6$238b2o$238bobo$239bo$231b
2o$231b2o19$206b3o$208bo$207bo18$190b3o$192bo$191bo18$180b2o$181b2o$
180bo18$145b3o$147bo$146bo18$122b2o$123b2o$122bo32$62b2o$61bobo$63bo
10$40b2o$39bobo$41bo25$20b3o$22bo$21bo30$b2o$obo$2bo!
#C [[ PAUSE 2 AUTOSTART STEP 4 ZOOM 2 ]]

Code: Select all

#C if double space after double brackets, script is silently ignored
x = 244, y = 228, rule = B3/S23
222b2o$222b2o4$242b2o$242b2o4$211b2o$211b2o6$238b2o$238bobo$239bo$231b
2o$231b2o19$206b3o$208bo$207bo18$190b3o$192bo$191bo18$180b2o$181b2o$
180bo18$145b3o$147bo$146bo18$122b2o$123b2o$122bo32$62b2o$61bobo$63bo
10$40b2o$39bobo$41bo25$20b3o$22bo$21bo30$b2o$obo$2bo!
#C [[  ZOOM 2 PAUSE 2 AUTOSTART STEP 4 ]]

Also, in the absence of a ZOOM setting, the viewer always seems to default to a zoom that's one step in from the "best-fit" zoom (where the pattern fills the viewer but doesn't overrun the boundary.) Is this intentional? I've almost always been adding a ZOOM script command to move the zoom in that one more step, to get slightly better visibility for patterns. This happens with glider guns and LifeHistory diagrams and things like that, mostly, not these slow salvo patterns so much.

Finally, try running the second pattern in the viewer -- the one with "ZOOM 6 X -100 Y 100". (Or run any of them, and then hit 'F' to auto-fit the pattern after the eater2 construction is done.) Then hit the Reset button. Then hit 'F' again. Build 151 seems to jump to the bounds of the pattern before the reset, instead of the bounds of the original pattern -- you can zoom out and see the line of gliders, but the auto-fit function refuses to admit they exist until the pattern is run one step.

-- It's quite amusing to hold down the "F" key while running one of these patterns. That's the effect I was suggesting setting with an AUTOFIT script command, way back whenever that was.

[rowett]

Okay, how about these?

For the first 3 there's one bug and one clarification. Both the PAUSE command and the T command work in the same way. They define a target time (PAUSE) or generation (T) by which a defined camera state is reached. That state is defined after the command.

[[ T 100 ZOOM 4 ]] means "by the time you get to generation 100 be at ZOOM 4"
[[ PAUSE 5 ZOOM 6 ]] means "after 5 seconds with no generations be at ZOOM 6"

Any camera commands before the first T or PAUSE define the initial state. If none are present then the initial state is the default camera state (i.e. autofit on the pattern).

[[ ZOOM 2 PAUSE 5 ZOOM 5 ]] means "initially be at ZOOM 2 and then after 5 seconds be at ZOOM 5"

So your three examples are interpreted as follows:
1. [[ PAUSE 2 AUTOSTART STEP 4 ZOOM 6 X -100 Y 100 ]]

There's no initial state defined before the PAUSE so the default autofit is used (* see below for bug)
Pause generations for 2 seconds by which time be at ZOOM 6 X -100 Y 100

2. [[ ZOOM 6 X -100 Y 100 PAUSE 2 AUTOSTART STEP 4 ]]

The initial state is ZOOM 6 X -100 Y 100
Pause generations for 2 seconds (the camera doesn't move during this pause because there is no new camera state defined after the PAUSE)

3. [[ PAUSE 2 AUTOSTART STEP 4 ZOOM 2 ]]

There's no initial state defined before the PAUSE so the default autofit is used (* see below for bug)
Pause generations for 2 seconds by which time be at ZOOM 2

* The bug is that when no initial state is defined the autofit zoom level is not being used as the initial zoom

if double space after double brackets, script is silently ignored

This was actually caused by a non-breaking space which will be correctly handled in the next build.

Also, in the absence of a ZOOM setting, the viewer always seems to default to a zoom that's one step in from the "best-fit" zoom (where the pattern fills the viewer but doesn't overrun the boundary.) Is this intentional?

The "best-fit" function ensures there is a border around the pattern. I can make it bigger or smaller as you wish. What would you prefer?

Finally, try running the second pattern in the viewer -- the one with "ZOOM 6 X -100 Y 100". (Or run any of them, and then hit 'F' to auto-fit the pattern after the eater2 construction is done.) Then hit the Reset button. Then hit 'F' again. Build 151 seems to jump to the bounds of the pattern before the reset, instead of the bounds of the original pattern -- you can zoom out and see the line of gliders, but the auto-fit function refuses to admit they exist until the pattern is run one step.

This is a bug and will be fixed in the next build.

-- It's quite amusing to hold down the "F" key while running one of these patterns. That's the effect I was suggesting setting with an AUTOFIT script command, way back whenever that was.

Yes I've done so many times It's still on the list of things I haven't got to yet. I'm currently playing with ZOOM and Bezier curves.

[dvgrn]

Also, in the absence of a ZOOM setting, the viewer always seems to default to a zoom that's one step in from the "best-fit" zoom (where the pattern fills the viewer but doesn't overrun the boundary.) Is this intentional?

The "best-fit" function ensures there is a border around the pattern. I can make it bigger or smaller as you wish. What would you prefer?

Well, I'm just one user at this point, so come to think of it maybe I'll start reporting this kind of thing on the public forum thread, and see if anyone else has a competing opinion.

My experience has been that at least 90 percent of the time, I want the pattern to be zoomed in as much as possible without any of it going outside the borders (or behind the tool buttons at the bottom). The only reason I have to set a zoom level is that the viewer defaults to a wider view than I need.

In 90 percent of the remaining cases, I want to do something like zoom in on the construction area for a slow salvo -- so I have to set the zoom level anyway. I very rarely really want the zoom level that the viewer picks by default.

I don't _think_ it will cause too many problems for existing published patterns, if the default zoom level gets a little bit bigger. Maybe just cross fingers and give it a try, this time around...?

[dvgrn]

I wonder if people find it frustrating when I post a perfectly runnable LifeHistory pattern, and I decide that it's more important to be able to see the extra information provided by states 2 through 6, than to be able to run the pattern. With the [[ VIEWONLY ]] tag, anyone who wants to see the pattern running has to copy it into Golly, even though the viewer could do it perfectly well.

Here's a recent example. Really I'd like to be able to show the red and blue cells and leave the option to run the pattern as well.

Since LifeHistory is an unapologetic special case anyway, might it be possible to keep all the regular controls for a LifeHistory pattern, but still show the extra states -- at T=0 only? The trick would be to instantly switch over to the usual two-state conversion of the pattern as soon as the Play button is clicked.

[rowett]

Since LifeHistory is an unapologetic special case anyway, might it be possible to keep all the regular controls for a LifeHistory pattern, but still show the extra states -- at T=0 only? The trick would be to instantly switch over to the usual two-state conversion of the pattern as soon as the Play button is clicked.

Yes, no problem. Would you want it to revert to the multi-state display on every reset or just initially?

[dvgrn]

Would you want it to revert to the multi-state display on every reset or just initially?

I guess I was thinking it would be fine to revert to multi-state on every reset. Unless maybe the first reset would show the initial two-state pattern, and a second click on the Reset button would bring it back to its initial LifeHistory display state.

[rowett]

Build 152 is now available on the lazyslug server.

Enhancements in this build:

• births and deaths are now computed when stats switched from off to on (rather than just population)
• initial population statistics are remembered for faster Reset
• minor (~15%) improvement to start up time
• ZOOM rate of change is now a constant factor
• waypoint interpolation now uses Bezier curves to smooth start and stop of a camera move
• fit zoom (hotkey "F") no longer keeps a border around the pattern and avoids the UI controls
• improved the styling on the standalone Viewer window
• added support for B0 rules via emulation
• improved colour history display at ZOOM < 0.5x
• new script command [[ AUTOFIT ]] which can be used as a target for [[ T ]] and [[ PAUSE ]] waypoint commands
  • it is an error to use AUTOFIT not at a waypoint
  • AUTOFIT overrides any X, Y or ZOOM setting at the waypoint
• when waypoint playback passes the last defined waypoint the help information displays ">" at the last waypoint in the list rather than "*"

Fixes in this build:

• DEPTH was not being read correctly for the initial waypoint
• STEP size was not being respected after the last waypoint or when waypoint playback disabled
• display could sometimes wrap at 1x ZOOM
• correctly handle non-breaking spaces in patterns
• waypoints with no initial ZOOM defined were using a default rather than the fit to zoom value
• fit zoom (hotkey "F"), reset view (hotkey "V") and THEME change (hotkey "C") are now disabled during waypoint playback (but work if waypoint playback is paused)
• standalone Viewer window no longer intrudes on the vertical scrollbar if present
• manual adjustment during waypoint catch up now works correctly

[dvgrn]

Build 152 is now available on the lazyslug server.

Looks good! The only thing I notice on a first pass has to do with the test viewer with the title "B0 no S8 rule with AUTOFIT overrides".

When AUTOFIT is operating on an active pattern, it seems as if there _should_ be a small boundary around the edge -- not as generous as the old build, but a few pixels would be good. Otherwise the pattern that's pushing the boundary is not clearly visible -- you can never quite see what it looks like.

Everything else looks great so far. Looks like it will probably take me a few weeks to find the time to hunt down any subtle exceptions, this time around...!

[rowett]

Build 153 is now available on the lazyslug server.

Enhancements in this build:

• further improved the styling on the standalone Viewer (shadows!)
• widened fit zoom a little
• added some more colour sets

Nathaniel please will you upload this build since we should publish the B0 emulation fix.

[dvgrn]

Build 153 is now available on the lazyslug server.

I did a quick check of the test page. Looks good so far. Next week I may have time for some more thorough tests. In the meantime it looks pretty safe to make this version available on the forums.

[rowett]

Build 154 is now available on the lazyslug server.

Enhancements in this build:

• further minor improvements to start up time

Fixes in this build:

• improved error checking in the Cells decoder
• grid growth had been inadvertently disabled

Nathaniel please will you upload this build when you get a moment.

[dvgrn]

I haven't checked this against the new LifeViewer build yet, but the current build on conwaylife.com does something vaguely mysterious with patterns in this quoted message.

It's nothing particularly bad, just that most ASCII-format patterns show up as selectable but not viewable... there are a few exceptions, but in those cases the viewer still comes up blank for some reason.

[Nathaniel]

Build 154 is now available on the lazyslug server.

Nathaniel please will you upload this build when you get a moment.

Done, sorry for the delay.

[rowett]

I haven't checked this against the new LifeViewer build yet, but the current build on conwaylife.com does something vaguely mysterious with patterns in this quoted message.

It's nothing particularly bad, just that most ASCII-format patterns show up as selectable but not viewable... there are a few exceptions, but in those cases the viewer still comes up blank for some reason.

These weren't recognized because the Viewer didn't have a decoder that understood the simple format.

• The Cells decoder expects '.' and 'O' (rather than '.' and '*')
• The Life 1.05 decoder expects '.' and '*' but also a mandatory '#Life 1.05' header line

In the next build I've "enhanced" the Cells decoder so it's also happy with '.' and '*'.

[rowett]

Build 154 is now available on the lazyslug server.

Nathaniel please will you upload this build when you get a moment.

Done, sorry for the delay.

Not a problem, many thanks!

[dvgrn]

I had thought that mousewheel zooms were changed to not move the pixel under the mouse pointer, as of build 119.

Recent builds seem to be heavily biased toward the center -- it does make a difference where the mouse is, but the invariant point is definitely not the one under the mouse pointer; it's much closer to the center of the viewer. This is true for different-sized embedded viewers and the standalone viewer as well.

[rowett]

I had thought that mousewheel zooms were changed to not move the pixel under the mouse pointer, as of build 119.

Recent builds seem to be heavily biased toward the center -- it does make a difference where the mouse is, but the invariant point is definitely not the one under the mouse pointer; it's much closer to the center of the viewer. This is true for different-sized embedded viewers and the standalone viewer as well.

Thanks for pointing it out, I'll take a look.

[dvgrn]

Also ran into an odd problem on the How Your Username Evolves thread, with zooms mixed with thumbnails and pauses:

Code: Select all

#C [[ PAUSE 2 AUTOSTART THUMBNAIL ZOOM 18 LOOP 120 ]]
x = 29, y = 10, rule = B3/S23
4bo$4bo$4bo15bo$b4obo3bo2b3o2b2obo2bob2o$o3bobo3bobo3bobo3bob2o2bo$o3b
obo3bobo3bobo5bo3bo$o3bo2bobo2bo3bobo5bo3bo$b4o3bo4b4obo5bo3bo$16bo$
12b4o!

A zoom of 18 is the reported autofit zoom level for a full-sized viewer -- see the third version below -- but it only sometimes works for the thumbnail version. A zoom of 5 seems to work better here, for some reason. Without a specific zoom level, the initial zoom is much too far in --

Code: Select all

#C [[ PAUSE 2 AUTOSTART THUMBNAIL LOOP 120 ]]
x = 29, y = 10, rule = B3/S23
4bo$4bo$4bo15bo$b4obo3bo2b3o2b2obo2bob2o$o3bobo3bobo3bobo3bob2o2bo$o3b
obo3bobo3bobo5bo3bo$o3bo2bobo2bo3bobo5bo3bo$b4o3bo4b4obo5bo3bo$16bo$
12b4o!

-- unless you don't have a pause at the beginning, in which case it's fine:

Code: Select all

#C [[ AUTOSTART THUMBNAIL LOOP 120 ]]
x = 29, y = 10, rule = B3/S23
4bo$4bo$4bo15bo$b4obo3bo2b3o2b2obo2bob2o$o3bobo3bobo3bobo3bob2o2bo$o3b
obo3bobo3bobo5bo3bo$o3bo2bobo2bo3bobo5bo3bo$b4o3bo4b4obo5bo3bo$16bo$
12b4o!

I tried setting proper waypoints, but the problem seemed to remain more or less the same.

[rowett]

Also ran into an odd problem on the How Your Username Evolves thread, with zooms mixed with thumbnails and pauses

Fixed in the next build. Thanks for spotting it!

[rowett]

I had thought that mousewheel zooms were changed to not move the pixel under the mouse pointer, as of build 119.

Recent builds seem to be heavily biased toward the center -- it does make a difference where the mouse is, but the invariant point is definitely not the one under the mouse pointer; it's much closer to the center of the viewer. This is true for different-sized embedded viewers and the standalone viewer as well.

Thanks for pointing it out, I'll take a look.

I've just fixed this. I broke it when I changed to a smoother ZOOM. It will be in the next build.

[rowett]

Build 155 is now available on the lazyslug server.

Enhancements in this build:

• added step back one generation (hotkey "b")
• enhanced the pattern decoders to support simple ASCII "." and "*" with no header

Fixes in this build:

• default fit zoom display was not being updated after grid grows
• patterns in extended RLE format but with valid rule definition and two states were being treated as multi-state
• waypoint ZOOM was not working correctly in THUMBNAIL mode
• LOOP generation in waypoint mode was using incorrect ZOOM
• mousewheel ZOOM was broken

Dave - you inspired me with your "dvgrn" entry for the "How Your Username Evolves" thread.
See http://lazyslug.no-ip.biz/lifeview/plugin/name.html for the upcoming "LIFEVIEWER" submission...

[dvgrn]

Build 155 is now available on the lazyslug server.

Maybe it's time to think about moving a post-154 build to the conwaylife.com server? I'd definitely like to have that step-back-by-one feature available.

Found a new bug today: it turns out that if you click on a viewer from a page where a search has been done -- e.g.,

http://conwaylife.com/forums/viewtopic. ... toG#p18516

-- that labels in the viewer can get cluttered up with the extra HTML tags.

[rowett]

Build 155 is now available on the lazyslug server.

Maybe it's time to think about moving a post-154 build to the conwaylife.com server? I'd definitely like to have that step-back-by-one feature available.

Build 156 should be surfacing tomorrow. This will include the fix below and version 2 of the step-back-by-one feature amongst other excitement. Version 1 is horribly slow for large T.

Sorry for the delay. I got sidetracked by work, prime numbers, digit sums and cloud computing. In that order.

Found a new bug today: it turns out that if you click on a viewer from a page where a search has been done -- e.g.,

http://conwaylife.com/forums/viewtopic. ... toG#p18516

-- that labels in the viewer can get cluttered up with the extra HTML tags.

Nice spot. Fixed in build 156.

I believe it was Ken Arnold who said:
""Every program has at least one bug and can be shortened by at least one instruction — from which, by induction, it is evident that every program can be reduced to one instruction that does not work."

[rowett]

Build 156 should be surfacing tomorrow.

OK so the timescale was a little optimistic. It'll actually surface next Wednesday (2nd September) when I'm back from vacation. But it definitely will include the "step back one generation" feature.

[rowett]

Build 156 is now available on the lazyslug server.

Enhancements in this build:

• added hotkey "5" for 0.5x ZOOM
• added hotkey "0" to reset ANGLE to 0
• you can now specify [[ THEME CUSTOM ]] to use the custom theme at a waypoint
• added script command [[ STARS ]] to switch on starfield background
  • hotkey "s" to toggle starfield
  • added script command [[ COLOR STARS R G B ]] to set star color (default is white)
  • toggle thumbnail mode is now hotkey "n"
• step back one generation (hotkey "b") now limited to a maximum of 64 generations with much improved performance

Fixes in this build:

• disabled THUMBNAIL, WIDTH and HEIGHT commands for the standalone viewer
• the Theme UI was not including the custom theme when defined
• removed forum search decoration from pattern definitions
• patterns bigger than their defined width or height were failed with an exception (rather than just ignored)
• hex rules are no longer executable

Here is a map of the hotkeys.

This one is a candidate for release to conwaylife.com. Dave - please can you test it and let Nathaniel know if it's ready!