Life tag testing

[rowett]

Nathaniel please will you release build 274.

Or better still, please release build 275.

[dvgrn]

Or better still, please release build 275.

Ran into something that might be considered a fixworthy bug, having to do with label coordinates.

I tried collecting locations for labels by pointing with the mouse and collecting the reported X, Y values in the lower left corner. But those are Golly coordinates, measured from (0,0) in the upper left corner of the pattern, whereas the coordinates you need for labels, and that you get when you hit 'i', are LifeViewer coordinates measured with (0,0) in the center of the pattern.

I tried adding a coordinate adjustment #CXRLE -1905 -1656 so that the mouse-pointer coordinates and the info-readout coordinates would agree. That worked great -- but the labels still showed up at their original location, (+1905, +1956) from where I want them.

I'll take out the #CXRLE line for now and recompute all my collected label locations. But along with making LifeViewer pay attention to #CXRLE coordinate offsets for labels, maybe there could be a hotkey to toggle between Golly coordinates and LifeViewer coordinates for that mouse position readout in the lower left corner? Or possibly script commands for [[GOLLYCOORDS]] vs. [[LVCOORDS]]?

[rowett]

Build 276 is now available on the lazyslug server

Enhancements in this build:

• Label coordinates are now relative to pattern coordinates and respect CXRLE Pos
  • labels will be horizontally centred on the specified coordinates
  • use the XY coordinates from the lower left corner
  • note that [[ LABELT ]] coordinates are still screen relative (use the InfoBar)
• range 1 HROT rules are now allowed

Fixes in this build:

• Wolfram W0 is now allowed
• fixed an issue with decoding hex format HROT rules
• fixed an issue with canonical form of HROT rules
• LABELT fading was going one step too far

This build is a Release Candidate.

[rowett]

Regarding this discussion on History supports for Generations (and perhaps LtL and HROT) rules:
I'm debating whether have the support work explicitly or automatically:

• Explicitly would require specifying the rule with a History postix (3/23/12History) and would allow the additional history state to be used in the RLE so patterns could differentiate between dead cells and unoccupied cells
• Automatically would require no rule change and would not allow an extra state to be specified in the RLE

So the trade off is minor functionality over portability. Thoughts?

[dvgrn]

Regarding this discussion on History supports for Generations (and perhaps LtL and HROT) rules:
I'm debating whether have the support work explicitly or automatically:

• Explicitly would require specifying the rule with a History postix (3/23/12History) and would allow the additional history state to be used in the RLE so patterns could differentiate between dead cells and unoccupied cells
• Automatically would require no rule change and would not allow an extra state to be specified in the RLE

So the trade off is minor functionality over portability. Thoughts?

In CGOL there's definitely a use case for posting pre-existing LifeHistory cells to show signal tracks.

There are a few isotropic rules where people are working on universal constructors and such, but I don't know of any similar demand in the Generations/LtL/HROT space at the moment.

I think as long as you're not going for full LifeHistory support with marked cells and so forth, the "automatic" option would make a lot of sense for now. Wouldn't need any adjustments in Golly to support the same patterns LifeViewer can support -- though I guess existing [R]History LifeViewer patterns for [R]!="Life" are already in that boat.

[Nathaniel]

Build 276 is now live.

[rowett]

Thank you!

[dvgrn]

The problem with unpredictable playback speed seems to have resurfaced in Build 276 (or maybe a few builds before it). It was rock solid all the time I was previewing this sample waypoint script, but as soon as I posted it, the first run went at triple speed through the middle part of the animation, for some reason.

I've since had it work at the correct speed sometimes immediately after a refresh, and other times it doesn't. Is this something that can be seen anywhere other than on my system?

EDIT: Guess so, if you can reproduce it.

Something that came up while I was building that sample was that I still wanted Labels With A Velocity Vector. It didn't help in the Butch-and-Sundance sample script to have FIXED gliders vs TRACK/TRACKLOOP gliders, because the track direction would have to change at the end of the script.

[rowett]

The problem with unpredictable playback speed seems to have resurfaced in Build 276 (or maybe a few builds before it).

Try this build and let me know if it's more consistent on your machine.

Something that came up while I was building that sample was that I still wanted Labels With A Velocity Vector. It didn't help in the Butch-and-Sundance sample script to have FIXED gliders vs TRACK/TRACKLOOP gliders, because the track direction would have to change at the end of the script.

Noted.

[dvgrn]

The problem with unpredictable playback speed seems to have resurfaced in Build 276 (or maybe a few builds before it).

Try this build and let me know if it's more consistent on your machine.

I've run the Butch-and-Sundance sequence multiple times via labelanim.html, and am not seeing any of the sudden acceleration that showed up in Build 276.

-- Then again, the acceleration didn't show up in a single one of my dozen or more previews, either. I'll try some more testing later, but until further notice it looks good!

[rowett]

Build 277 is now available on the lazyslug server

Enhancements in this build:

• multi-state Generations patterns now display history if they have less than 256 states - test

Fixes in this build:

• fixed rare incorrect B0 error report when decoding multi-state patterns
• more consistent timing for animation

[dvgrn]

Build 277 is now available on the lazyslug server

Animation timing still looks good -- no new troubles to report so far. I haven't checked out the 256-state Generations history edge case yet. One of these days.

With my new obsession with labeling it's hard for me to imagine this, but it seems possible that someone might want to toggle the labels off with a hotkey sometimes, to see the actual pattern (!).

I'm also getting the sense that larger labels than the current maximum of 32 would be useful sometimes. I've been maxing out the LABELSIZE fairly regularly in my labeled patterns so far, but haven't gone near the lower edge of the range yet.

The second labeled pattern in the Sir Robin article shows some kind of developing semi-standard: labels are just at the edge of visibility, so you know you can zoom in closer to look at the details. And then if you zoom in close enough that you can only see one of the labels, you probably know what you're looking at by then and don't need the label in the way... and it has conveniently gotten out of its zoom range around then so it fades back out.

[rowett]

... it seems possible that someone might want to toggle the labels off with a hotkey sometimes, to see the actual pattern (!).

I was thinking of repurposing hotkey shift L for this and moving toggle loop to shift P.

I'm also getting the sense that larger labels than the current maximum of 32 would be useful sometimes.

What new maximum would be sufficient?

The second labeled pattern in the Sir Robin article shows some kind of developing semi-standard: labels are just at the edge of visibility, so you know you can zoom in closer to look at the details. And then if you zoom in close enough that you can only see one of the labels, you probably know what you're looking at by then and don't need the label in the way... and it has conveniently gotten out of its zoom range around then so it fades back out.

I really like this. Labels have turned out better than I expected and especially the zoom fading.

[dvgrn]

I'm also getting the sense that larger labels than the current maximum of 32 would be useful sometimes.

What new maximum would be sufficient?

Don't really know without trying to put a too-big label in a viewer. How about whatever size a makes a single capital letter W fit exactly in the LifeWiki popup viewport? Or Word and WordPad give 72 as the largest dropdown option (though bigger numbers can be typed in).

Labels have turned out better than I expected and especially the zoom fading.

Zoom fading should go especially well with waypoint animations that zoom in and out, I think -- haven't done one of those yet.

I wouldn't mind being able to set the minimum and maximum zoom levels -- i.e., specify the two zoom levels at which the label is invisible, but visible for any intermediate value. I suppose the other possible variable is the fraction of that interval where the label is fading in or out... pretty much the equivalent of the third parameter in a LABELT.

If bigger labels become an option, it might also become more important for them to fade out of the way more quickly, to make room for lower-level labels.

[rowett]

Build 278 is now available on the lazyslug server

Enhancements in this build:

• new script command [[ LABELTRACK DX DY|FIXED ]] - test
  • sets movement vector for subsequent label definitions (DX and DY can be from -2 to +2)
  • [[ LABELTRACK FIXED ]] turns off movement for subsequent label definitions
• increased maximum LABELSIZE to 128
• hotkey shift and "l" is now toggle labels
  • hotkey shift and "p" is toggle loop mode
• close button in bottom right menu is available in PopUp viewers when help or errors are displayed
• fps toggle in bottom right menu is available when help or errors are displayed

Fixes in this build:

• bounded grid border colour no longer overwrites state colour for 256 state patterns
• MAXGRIDSIZE was only allowing patterns to grow to the specified size rather than start at the specified size - test

The updated hotkey map detailing the LifeViewer keyboard controls is here.

[dvgrn]

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

Ooh, more new labeling options! I'll have to try updating my Butch-and-Sundance-Loafer waypoint script with these and see what can be done.

... The Butch and Sundance animation is probably a good example of a standard use case for traveling labels. The things that we want to label -- the traveling gliders, with "YEE-HAW!" -- don't exist at T=0, so I think maybe the only way to do this would be to calculate where "YEE-HAW!" should start at T=0, so that it doesn't appear in the waypoint-script viewport until the appropriate time.

In signal circuitry this will quickly get messy enough that it won't be workable -- the label might even have to start outside the maximum grid size sometimes (not sure if that will throw an error or not) and it will be visible in places where it doesn't make any sense.

That makes it seem like a LABELT is more like what's wanted. Really the information I'll usually want to feed to LifeViewer is either (StartX, StartY, StartZoom, EndX, EndY, EndZoom), or just (StartX, StartY, Zoom, DX, DY).

The first set of parameters would be needed for hypothetical cases where we're following and labeling a signal that is also being followed by a waypoint script where the zoom level is changing. To fit it in with the current way LifeViewer is collecting parameters, maybe something like ENDPOINTLABELT EndX EndY Zoom and ENDPOINTLABELT OFF ? That's a bit awkwardnessful, but maybe better than needing to call LABELT with X Y Z X Y Z all the time when the labels aren't supposed to move.

The second set is for use cases that I'm getting more interested in -- where the person watching isn't being dragged through any particular sequence of views, but instead is free to explore around and watch the action anywhere they want. Labels on specific gliders or Herschels or whatever saying "Test for Zero", "IS-ZERO signal", "IS-NOT-ZERO signal", "Self-Destruct", or what have you, could be very helpful in understanding some complicated constructions.

-- Not that there's a very large pool of people willing to make labels for complicated constructions yet. But we do have a few people starting to pick them up already on the LifeWiki. Or, well, Entity Valkyrie anyway!

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

... Looks like you made the following design decision on purpose, and it works as advertised:

Code: Select all

#C Standard label will be relative to TRACK if ON
#C [[ LABEL 4 4 16 "Normal" ]]

I'm not sure what the use case is for a label that's either attached to a specific point in the pattern OR attached to a specific point in the viewport, depending on if TRACK is ON. Seems like any such labels are going to look broken in one of the two TRACK settings. "I always want to be able to read this" viewport-tracking labels are somewhat duplicated by pop-up messages.

Would it work better if standard labels behaved like Fixed instead of like Tracking Normal? Or is there some situation I'm not thinking of where things look just as broken that way too?

[rowett]

Build 279 is now available on the lazyslug server

Enhancements in this build:

• LABELTRACK positions are relative to T1 if defined by LABELT - test

[rowett]

The things that we want to label -- the traveling gliders, with "YEE-HAW!" -- don't exist at T=0, so I think maybe the only way to do this would be to calculate where "YEE-HAW!" should start at T=0, so that it doesn't appear in the waypoint-script viewport until the appropriate time.

I've solved this by making a moving label's position relative to its start time as defined by LABELT. See the test case in the build above. Three gliders appear at different generations and have labels that track their movement for their life time.

[rowett]

Build 280 is now available on the lazyslug server

Enhancements in this build:

• rule names now support slash after generations prefix and G in generations postfix - test
  • prefix: G3/B3/S23
  • postfix: B3/S23/G3 or MAPFEABCD/G3
• multi-state LtL and HROT patterns now display history - test

[dvgrn]

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

Looks good! Might this be a Release Candidate, or do you have other items on your immediate to-do list?

[rowett]

Build 281 is now available on the lazyslug server

Enhancements in this build:

• moved Shrink button from top left to bottom right
• added support for C in generations postfix e.g. B3/S23/C3 - test

Fixes in this build:

• cell under mouse display now correctly ignores bounded grid border cells

This build is a Release Candidate.

[rowett]

Build 282 is now available on the lazyslug server

Fixes in this build:

• survival counts in canonical HROT form were off by 1
• improved rule validation for non-totalistic rules

This build is a Release Candidate.

[Nathaniel]

Build 282 is now live.

[rowett]

Great, many thanks!

[rowett]

Build 283 is now available on the lazyslug server

Enhancements in this build:

• added many new rule aliases
• secret function prototype available on hotkey F1 - test

Fixes in this build:

• better error reporting when invalid characters in RLE
• Generations rules were not displaying Life ended messagear neighborhoods