Life tag testing

[rowett]

enhanced POI (point of interest capability)

At the moment at each POI you can set:

• X
• Y
• ZOOM
• ANGLE
• POITRANS
• POIRESET
• POISTART or POISTOP

Would it also be helpful to be able to set:

• THEME
• DEPTH
• LAYER
• STOP value
• LOOP value

[rowett]

I'm now thinking about adding support for TRACK, TRACKBOX and TRACKLOOP per POI.
I did briefly consider Waypoints per POI but it hurt my brain.

Additionally GRID and GRIDMAJOR might make the cut.

[rowett]

POI definitions now inherit the current position, zoom and angle so you only have to specify what is different than the previous POI. This is now in line with how Waypoint definitions work.

I changed my mind on this.

POI definitions will no longer inherit information from the previous defined POI. This was valid for Waypoints since they are a connected journey of the camera through space and time. POIs are just spatial so have no logical connection to each other.

Items not defined at a POI default to the initial camera position (which can be defined by X, Y, ZOOM, THEME etc commands before the first POI script command, or will default to the AUTOFIT position).

For example:

Code: Select all

[[ ZOOM 3
POI X 25 Y 22 ZOOM 10
POI X -10 ]]

The default camera position will be X 0 Y 0 at ZOOM 3.

The first POI will be X 25 Y 22 ZOOM 10

The second POI will be X -10 Y 0 ZOOM 3

Likewise I'll probably have a POI with POIRESET defined respect AUTOSTART unless POISTOP or POISTART are specified.

[dvgrn]

Likewise I'll probably have a POI with POIRESET defined respect AUTOSTART unless POISTOP or POISTART are specified.

Happy New Year! And it all looks good so far. The only detail I can see to make any noise about is that POISTOP and POITRANS run for one tick if LifeViewer is already stopped -- e.g., press Alt+2 and/or Alt+8 twice in a row each.

The slow transition doesn't seem very slow when POIs are far away from each other. Maybe it would be okay to have a higher maximum value for that? I don't really have a use case for that, though -- probably slow transitions would usually be kind of annoying in practice.

I tried adding an unsupported parameter to a POI, and got no errors but also no POIPLAY functionality any more:

#C [[ POI X -448 Y -262 T 100 ZOOM 3 "Play Action" POIPLAY ]]

Would it also be helpful to be able to set:
THEME
DEPTH
LAYER
STOP value
LOOP value

Different THEMEs per POI would be nice to have, certainly, but that's not really high priority.

STOP and LOOP values are the ones that stand out -- along with TRACK/TRACKBOX/TRACKLOOP, I suppose, if we're going to use this to show off spaceships or puffers or what have you. *

But if you have a STOP value, maybe you also need a POI GPS setting to say how fast to play until the stopping point? Seems like it might make sense to allow POIRESET + POIPLAY + STOP (not POISTOP), so that every time you hit Alt+whatever you see a replay of whatever the local Important Reaction is.

My attempt to add T=100, above, was based on the vague idea that sometimes the POIPLAY timeslice that you want to show off will start at some significantly later time than T=0.

At some point I start wanting to add so many options to POI locations that it amounts to your momentary, frightening idea of a separate waypoint script for each POI. That does seem like an implementation (and testing) nightmare... so maybe there's a happy medium somewhere short of that?

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

* Speaking of TRACKBOX, I think the error checking isn't really necessary, that enforces E >=W, S<=N, etc. Especially with a STOP value, it makes perfect sense sometimes to define a TRACKBOX that shrinks and then grows. A simple example might be

Code: Select all

x = 13, y = 23, rule = B3/S23
bo$2bo$3o18$10b3o$10bo$11bo!
#C [[ TRACKBOX -1/4 -1/4 1/4 1/4 ]]

Yes, there's a Division By Zero moment that you have to check for -- or maybe a larger Worry Zone where the TRACKBOX specifies a very small area, like a single-digit number of cells? -- but it seems as if it would be okay to keep the same zoom and center as the previous frame, for those few cases. Soon enough the TRACKBOX will invert and start growing again, and then the math will still make sense... if you're following passing spaceships similar to the above case.

For cases where you want to track something like a spaceship synthesis recipe, I suppose it might make sense to be able to specify a T value after which the TRACKBOX stops tracking. But here again things are getting complicated, and maybe the waypoint system is a better general solution.

[rowett]

Happy New Year! And it all looks good so far. The only detail I can see to make any noise about is that POISTOP and POITRANS run for one tick if LifeViewer is already stopped -- e.g., press Alt+2 and/or Alt+8 twice in a row each.

Fixed. It was calling the Stop UI function which steps if already paused.

The slow transition doesn't seem very slow when POIs are far away from each other. Maybe it would be okay to have a higher maximum value for that?

Will do. I'll make it 200 for now.

I tried adding an unsupported parameter to a POI, and got no errors but also no POIPLAY functionality any more:
#C [[ POI X -448 Y -262 T 100 ZOOM 3 "Play Action" POIPLAY ]]

The T command created a new Waypoint and so everything after it was specific to the Waypoint, and not the original POI. Two things here:

1. I should throw an error or warning if you try to add POI actions to a Waypoint (rather than a POI)
2. I haven't given any thought to Waypoints mixed with POIs other than it'll probably be unpleasant

Different THEMEs per POI would be nice to have, certainly, but that's not really high priority.

It's not a high priority but it was trivial so I've already implemented it, along with DEPTH and LAYERS.

STOP and LOOP values are the ones that stand out -- along with TRACK/TRACKBOX/TRACKLOOP, I suppose, if we're going to use this to show off spaceships or puffers or what have you.

Currently working in STOP and LOOP and then the TRACK family are next.

But if you have a STOP value, maybe you also need a POI GPS setting to say how fast to play until the stopping point?

Yes I'll add GPS and also STEP per POI.

Seems like it might make sense to allow POIRESET + POIPLAY + STOP (not POISTOP), so that every time you hit Alt+whatever you see a replay of whatever the local Important Reaction is.

Exactly. Plus POIPLAY would be redundant if AUTOSTART was specified before the first POI definition since that would be the default on POIRESET.

My attempt to add T=100, above, was based on the vague idea that sometimes the POIPLAY timeslice that you want to show off will start at some significantly later time than T=0.

I could probably add a POIT command which would quickly play to the defined generation (probably without updating the display) on POIRESET.

Speaking of TRACKBOX, I think the error checking isn't really necessary, that enforces E >=W, S<=N, etc.

OK I'll take a look.

For cases where you want to track something like a spaceship synthesis recipe, I suppose it might make sense to be able to specify a T value after which the TRACKBOX stops tracking. But here again things are getting complicated, and maybe the waypoint system is a better general solution.

Yes this occurred to me while I was originally testing the TRACKBOX code. There's also an argument for not starting TRACKBOX until a specified T. I'll cross this bridge when I come back to it.

As ever the simple POI enhancement requirement gained a Life of its own (pun intended). Ironic really, given I started thinking about it as way to avoid improving the Waypoint system...

Which reminds me: must finish LTL implementation

[dvgrn]

As ever the simple POI enhancement requirement gained a Life of its own (pun intended). Ironic really, given I started thinking about it as way to avoid improving the Waypoint system...

Which reminds me: must finish LTL implementation

Heh, don't make me laugh just when I'm drinking from a water bottle... In terms of the Not Getting Things Done competition, I've been slow working through my own To-Do list lately. Lots of updates still not made to Golly's pattern collection and glife/gplus and so on. And the quadratic replicator and the HashLife-friendly metacell are just sitting there un-worked-on.

However, I might possibly have gotten through to the final version of Release 28 of the Life Lexicon as of the end of 2017. Almost. I probably ought to read it all again from the top and see how many typos I can find, and how many links I can add in passing, to new definitions that weren't there before. But I'm afraid to do that, because it will make me think of more new definitions that are desperately needed.

Anyway, I like the way the POI system is turning out -- kind of a multi-point Waypoint Lite system. I had a couple other ideas about possible new POI-related features, but when I looked again it turned out you had already implemented them. (That was quick work!)

The only remaining vague idea is some way of cueing the user that there are POIs defined (besides hitting I and scrolling down to the POI section). But the only screen real estate that I could see making available is during mouse-is-hovering time when it's showing "Click to control". Could possibly say "POIs defined: 9" then -- or even "POIs: 1 2 3 4 5 6 7 8 9" and a click on the number would take you there.

That last wouldn't work when there are more than nine POIs, but that's just the same as the Alt+{digit} trick keyboard shortcut not working (except on Babylonian keyboards). Can still get there with J and Shift+J.

[rowett]

When you specify a POI you can define the camera position (X, Y, ZOOM and ANGLE), playback speed (GPS and STEP), pseudo 3D display (LAYERS and DEPTH), transition speed (POITRANS) and various actions (POISTART, POISTOP and POIRESET).

If you omit any of the values above when specifying a POI then it defaults the missing values to the pattern load values, which are either the AUTOFIT defaults or can be specified before the first POI command.

I'm now thinking there is another use case where you may wish a POI to leave an unspecified value unchanged (i.e. whatever the current camera position is) rather than default it to the initial camera position.

For example, you might want to define POIs which leave everything unchanged except:

• set ZOOM to 2 and ANGLE to 0
• set GPS to 60 and STEP to 4
• set THEME to 6, LAYERS to 6 and DEPTH to 0.5
• set just X to 0

In these cases I need a way of specifying the difference between "use pattern load defaults for omitted values" and "use current camera position for omitted values".

Perhaps the best way would be that the default is anything unspecified uses the current value. To set something explicitly to the initial camera position you would use [[ INITIAL ]] as the command value e.g. [[ ZOOM INITIAL ]].

I could have a POI which sets ZOOM to 3 and THEME to 1:
[[ POI ZOOM 3 THEME 1 ]]

Or I could have a POI which sets ZOOM to 3 and keeps whatever the current THEME is:
[[ POI ZOOM 3 ]]

Or finally I could have a POI which sets ZOOM to 3 and sets the THEME to the pattern load theme:
[[ POI ZOOM 3 THEME INITIAL ]]

Thoughts?

[dvgrn]

I'm now thinking there is another use case where you may wish a POI to leave an unspecified value unchanged (i.e. whatever the current camera position is) rather than default it to the initial camera position.

It sounds like you're stretching the definition of POI a little bit. For example, if POI #N just sets the GPS to 60 and STEP to 4 as you suggest, then that's not really a "point" any more, exactly. I can definitely see how it could be useful, though.

I'm thinking in terms of my upcoming talk here, where I might want to run a pattern slowly at first, then pick up the speed, then faster yet, and then -- hmm, run to a specified T value and then stop? That's closer to waypoint STOP functionality, I guess.

And then jump to the next POI, which maybe actually has a position. Probably all with the J key, so as not to have to memorize Alt+digit shortcuts -- and there will probably be too many POIs for them all to be mapped to shortcuts anyway.

In these cases I need a way of specifying the difference between "use pattern load defaults for omitted values" and "use current camera position for omitted values".

Perhaps the best way would be that the default is anything unspecified uses the current value. To set something explicitly to the initial camera position you would use [[ INITIAL ]] as the command value e.g. [[ ZOOM INITIAL ]].
...
Thoughts?

I should probably try writing a sample series of POIs and see how some of this works in practice. One oddity would be that running through partly-specified POIs with Shift+J might have very different effects than running through them in the standard order. I don't think that's necessarily a bad thing, though. Having same-as-last defaults is likely to make these POI scripts a bit easier to write.

This POI implementation does seem to have gotten away from one of the earlier ideas for using LifeViewer as a lecture visual aid. There's nothing set up yet for doing multiple STOPs, or for controlling in the script where the STOP happens -- right? So if I wanted POI #2 to stop at exactly T=100, I'd have to hit the shortcut at just the right time, or adjust manually somehow.

Are there any multi-STOP / spacetime-coordinate POI ideas still in the works?

[rowett]

It sounds like you're stretching the definition of POI a little bit. For example, if POI #N just sets the GPS to 60 and STEP to 4 as you suggest, then that's not really a "point" any more, exactly. I can definitely see how it could be useful, though.

Yes it has generalised into more of a macro on a hotkey.

Are there any multi-STOP / spacetime-coordinate POI ideas still in the works?

Yes it's all coming. It just wasn't required to describe the question above.

[rowett]

Are there any multi-STOP / spacetime-coordinate POI ideas still in the works?

Yes it's all coming. It just wasn't required to describe the question above.

Here's the current implementation plan for [[ STOP ]] and [[ LOOP ]] in the new POI system:

• You can specify STOP and/or LOOP for each POI
• If not specified at a POI then the current STOP and LOOP settings are unchanged
• You can choose to use at a POI the STOP and/or LOOP that were defined at pattern load with [[ STOP INITIAL ]] and/or [[ LOOP INITIAL ]] commands
• You can explicitly turn off STOP and/or LOOP at a POI with [[ STOP OFF ]] and/or [[ LOOP OFF ]]

I'm still thinking about a [[ POIT <generation> ]] command which would set the start generation for a specific POI.

[rowett]

Making some progress on the new POI implementation. Currently "working" are:

• POI actions: POIRESET, POISTOP and POISTART
• Camera transition speed: POITRANS
• POI start generation: POIT
• Camera positioning: X, Y, ZOOM, ANGLE
• Display settings: LAYERS, DEPTH
• Playback speed: GPS, STEP
• Colour theme: THEME
• Playback control: STOP, LOOP including OFF
• Text message display
• Hotkeys: Alt 1-9, j and Shift j
• Improved POI Help information

To do:

• Camera tracking: TRACK, TRACKLOOP, TRACKBOX
• Defaulting parameters: INITIAL
  • Default single parameters: X INITIAL THEME INITIAL
  • Default all parameters and override specifics: ALL INITIAL ZOOM 4
• Ability to define a DEFAULT POI to be automatically applied on pattern load

Dave is there anything I'm not tracking that you're expecting?

[dvgrn]

Making some progress on the new POI implementation...
Dave is there anything I'm not tracking that you're expecting?

Wow -- no, I think that's everything. Random clarification: you have a separate keyword for POIT, but not for POIX, POIY, POIZOOM, etc., because the T keyword is what you use to signal a new waypoint -- right?

Will this still make sense if waypoints also eventually get the functionality of being able to jump backwards in time, with different types of transitions? Or will waypoints now accidentally turn out to be just a series of POIs strung together with a new AUTOPLAYPOI command?

[rowett]

Random clarification: you have a separate keyword for POIT, but not for POIX, POIY, POIZOOM, etc., because the T keyword is what you use to signal a new waypoint -- right?

Yes and I'm assuming that at some stage in the future I may allow POIs and Waypoints to peacefully co-exist.

Will this still make sense if waypoints also eventually get the functionality of being able to jump backwards in time, with different types of transitions? Or will waypoints now accidentally turn out to be just a series of POIs strung together with a new AUTOPLAYPOI command?

My working theory is that I'll just allow the T command to have an earlier generation than the previous Waypoint.

[dvgrn]

My working theory is that I'll just allow the T command to have an earlier generation than the previous Waypoint.

... But with an option for an instantaneous transition, I hope? I could do some very entertaing things with instantaneous transitions. Especially on April Fool's Day, I suppose.

[rowett]

• Ability to define a DEFAULT POI to be automatically applied on pattern load

This is done by specifying [[ INITIAL ]] straight after the [[ POI ]] command followed by the POI settings.
Example:
[[ POI INITIAL X 20 ZOOM 3 ]]

[rowett]

Hopefully release an update this weekend. Been sidetracked with bounded grids and CXRLE POS.

[dvgrn]

Hopefully release an update this weekend. Been sidetracked with bounded grids and CXRLE POS.

Looking forward to it! I might have a little time this weekend for regression testing.

Slow progress continues on using LifeViewer more on the LifeWiki. It really has gotten a lot easier to include an animated illustration in an article, without needing an admin to upload an RLE file. We're currently working through new Life Lexicon entries, and producing articles in a fairly standard format along these lines.

A question came up recently about what happens to the (not very many) people who might not have Javascript enabled in their browser. I don't think we need to do anything much about that case, but wondered if you might have suggestions what a reasonable and easy failover would be.

I just tried turning off scripting in IE, and of course ended up with just an empty box where LifeViewer is supposed to be. Might it make sense to include some boilerplate text somehow. for the failover case -- "To enable LifeViewer, please use a browser with Javascript capability"...?

[rowett]

A question came up recently about what happens to the (not very many) people who might not have Javascript enabled in their browser. I don't think we need to do anything much about that case, but wondered if you might have suggestions what a reasonable and easy failover would be.

I just tried turning off scripting in IE, and of course ended up with just an empty box where LifeViewer is supposed to be. Might it make sense to include some boilerplate text somehow. for the failover case -- "To enable LifeViewer, please use a browser with Javascript capability"...?

Looks like some kind soul (perhaps you) already did this on the Wiki.

[rowett]

Build 236 - "Othello 2" is now available on the lazyslug server

Enhancements in this build:

• improved POI capability - test
  • you can now specify any of the following settings at each POI
    • [[ X Y ZOOM ANGLE LAYERS DEPTH GPS STEP THEME LOOP STOP ]]
  • you can also specify actions at each POI
    • [[ POIRESET ]] - reset playback to T = 0
    • [[ POIPLAY ]] - continue playback from current generation
    • [[ POISTOP ]] - pause playback
    • [[ POIT <generation> ]] - skip to defined generation
  • [[ POITRANS 0..200 ]] specifies the transition speed to the POI
  • a POI will only change the settings that are defined and other settings are left unmodified
  • the initial settings are the default settings for LifeViewer and can be overridden with script commands before any POI definition
  • added script keyword [[ INITIAL ]] that can be used in a POI definition
    • [[ ALL INITIAL ]] makes all settings for the POI the same as the initial settings
      • the required settings can then be overridden e.g. [[ POI ALL INITIAL ZOOM 4 ]] copies all and overrides ZOOM
    • [[ X|Y|ZOOM|ANGLE|LAYERS|DEPTH|GPS|STEP|THEME|LOOP|STOP INITIAL ]] copies the initial setting of the defined parameter into the POI
      • [[ POI X INITIAL Y INITIAL ]] sets X and Y from the initial and leaves everything else unchanged
    • [[ POI INITIAL ]] makes the defined POI the default on pattern load rather than the initial settings (note this does not change the initial settings for copying)
• [[ STOP ]] and [[ LOOP ]] can now take the parameter [[ OFF ]] to disable them (useful for POI definitions)
• MAP rules now allow base64 padding
• hotkey shift and "c" now cycles backwards through colour themes
• hotkey alt and "c" now selects the default theme
• panning with the cursor keys is now faster when zoomed out
• hotkey shift and "l" will toggle LOOP mode if defined
• Life 1.05 format patterns now support all rules including bounded grids

Fixes in this build:

• bounded grids now work correctly with CXRLE POS
• non-totalistic rules with repeated neighbour counts were decoded incorrectly
• LOOP was performing a camera reset when LOOP enabled after the LOOP generation
• Waypoint error messages were showing incorrect sign when overwriting X or Y camera positions
• if there were more script errors than could fit on the viewer then the last error could not be scrolled to

[dvgrn]

Build 236 - "Othello 2" is now available on the lazyslug server...

Going from POI 8 to POI 6 or POI 2 on the test page gives kind of an odd result -- a quick flicker.

More tomorrow, probably --

EDIT: Yes, it looks like the odd result is the correct consequence of the rule that settings not specified by a POI are left unchanged. The unexpected flicker can be fixed by setting a step size in each POI, etc., etc.

The other item that I've been meaning to report for a while also turns out not to be a bug. I keep hitting "+" to increase the step size, and having LifeViewer jump instantly to 50. Turns out I should be hitting "=" without the shift to get the behavior I want.

Might it make sense to make "+" do the same thing as "=", just to match what Golly does? Or increase the step by maybe 5 instead of 1, anyway? That way you only have to hold the key down briefly to get to 50, if that's what you want -- but if you just hit the key once with the intention of doing a Golly-like single speed increase, you'd actually get a near-Golly-sized speed increase.

[rowett]

Might it make sense to make "+" do the same thing as "=", just to match what Golly does?

In Golly the step size is decreased with both "-" and "_", and increased with both "=" and "+" (i.e. the "shift" key makes no difference). So LifeViewer already matches Golly, assuming you can train yourself NOT to press the "shift" key when you press "="

I like the LifeViewer functionality because I get decrease and increase on "-" and "=", and then "shift" modifies those to perform "minimum speed" on "_" ("shift -") and "maximum speed" on "+" ("shift ="), which Golly doesn't have.

[rowett]

Next I need to clip CXRLE POS patterns to their bounded grids and then I may have to finish LTL.

[dvgrn]

Next I need to clip CXRLE POS patterns to their bounded grids and then I may have to finish LTL.

Oh, there's always something else that you could find to be distracted by instead. Check the LifeWiki Tiki Bar if you need ideas...

I'm supposed to be building illustrations for the Gathering for Gardner talk, but I keep ending up building Demonoids and writing tricky isotropic-rule-modifying scripts for other people. Getting back to illustrations now --

[rowett]

Yes, it looks like the odd result is the correct consequence of the rule that settings not specified by a POI are left unchanged. The unexpected flicker can be fixed by setting a step size in each POI, etc., etc.

You could use the [[ ALL INITIAL ]] feature to make this easier:

1. Define a baseline setting for your POIs before the first POI definition
2. Use [[ POI ALL INITIAL ]] at each POI and then specifically override the settings you want
3. Tell LifeViewer which POI you want to be set on pattern load with [[ POI INITIAL ]]
   • If you don't specify a default POI then LifeViewer will use the default settings on pattern load

Example (this won't work on the forum yet since the new build is not uploaded):

Code: Select all

#C Default settings for all POIs
#C [[ STEP 1 GPS 60 THEME 1 ]]
#C First POI inherits STEP, GPS and THEME and sets X, Y and ZOOM
#C [[ POI ALL INITIAL X 20 Y 30 ZOOM 4 ]]
#C Second POI inherits GPS and THEME, sets ZOOM and ANGLE and overrides STEP
#C [[ POI ALL INITIAL ZOOM 12 ANGLE 30 STEP 20 ]]
#C Third POI inherits STEP and GPS, sets ZOOM and overrides THEME and is the default on load
#C [[ POI INITIAL ALL INITIAL ZOOM 10 THEME 4 ]]
#C Fourth POI only inherits GPS, sets STEP, THEME (and everything else) will be unchanged
#C [[ POI GPS INITIAL STEP 35 ]]
x = 37, y = 5, rule = B3/S23
o3bo3b5o3bo7bo8b3o$o3bo3bo7bo7bo7bo3bo$5o3b4o4bo7bo7bo3bo$o3bo3bo7bo7b
o7bo3bo$o3bo3b5o3b5o3b5o4b3o!

The example is slightly artificial in that [[ STEP 1 GPS 60 THEME 1 ]] are the LifeViewer defaults so don't actually need to be specified.

[rowett]

Build 237 - "1st3x∈7" is now available on the lazyslug server

Fixes in this build:

• POI definitions were always inheriting X, Y, ZOOM and ANGLE
• [[ POI INITIAL ]] was not making the default POI the current POI (for next and previous POI hotkeys)
• [[ POI INITIAL ]] was not setting ANGLE or STEP