Life tag testing

For scripts to aid with computation or simulation in cellular automata.
Locked
User avatar
rowett
Moderator
Posts: 4597
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: Life tag testing

Post by rowett »

Build 265 is now available on the lazyslug server

Enhancements is this build:
  • new script command [[ LABEL X Y ZOOM "<string>" ]]
    • displays a static label at the given cell position and zoom
    • Help information contains label definitions
  • new script command [[ LABELALPHA <0.0..0.1> ]]
    • sets opacity for following label definitions from 0 (transparent) to 1 (opaque - the default)
  • new script command [[ LABELSIZE <4..32> ]]
    • sets the label font size for following label definitions (default is 18)
  • new script command [[ COLOR LABEL <colourname>|R G B ]]
    • sets the label text colour (default is 240 255 255)
  • HROT rule parser now validates von Neumann and Circular neighborhoods (though runtime isn't implemented yet)
Fixes in this build:
  • fixed canonical HROT rule decoder
  • fixed broken Torus
  • fixed LtL and HROT patterns not clearing correctly on right-hand boundary
User avatar
rowett
Moderator
Posts: 4597
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: Life tag testing

Post by rowett »

Build 266 is now available on the lazyslug server

Enhancements is this build:
  • new script command [[ LABELT <t1> <t2> <fade> ]]
    • sets a range of generations from <t1> to <t2> for subsequent labels to be visible
    • <fade> specifies generations to fade label in/out
    • use [[ LABELT ALL ]] to specify all generations
User avatar
rowett
Moderator
Posts: 4597
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: Life tag testing

Post by rowett »

Build 267 is now available on the lazyslug server

Enhancements is this build:
  • new script command [[ MAXGRIDSIZE <10..14> ]]
    • specifies the maximum grid size 2^n
    • if not specified the grid size starts at 2^10 (1024) and automatically grows as needed up to 2^13 (8192)
    • 2^14 (16384) is only available if specified with this command
  • Labels now work wth [[ TRACK ]] and [[ TRACKLOOP ]] - test
  • Label shadow offset is now based on label size
User avatar
dvgrn
Moderator
Posts: 12053
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: Life tag testing

Post by dvgrn »

rowett wrote:
dvgrn wrote:-- Not that I'd mind having the option of jumping instantly to any spacetime location (disregarding some calculation time for getting to new time T from the nearest earlier saved state). But it doesn't look like I really need it in this case after all...!
I think that means I don't need to do anything :)
Certainly not. Instant spacetime jumps are a nice-to-have, mostly only mentioned in case it turned out to be easy to implement after all. About the worst effect of their absence is that sometimes it will be necessary to duplicate (or more) a whole large pattern to do the narration I want to do, and that might be a little puzzling to someone copying out the RLE and expecting just a single copy.

Sometimes I'll just need two or more LifeViewers. If I want to show the evolution of multiple Garden of Eden patterns one after another, there's only one sneaky workaround available to keep things in one LifeViewer. I used that workaround in the JvN replicator animation at G4G, but for things like GoE evolution it would make the actual RLE pattern fairly huge and confusing to look at.

... For that matter, I wasn't making any demands even for the labeling feature -- but the labels are turning out really nice! Did you consider my other crazy labeling ideas?
-- label only visible if viewpoint is within distance d (Manhattan? Cartesian?) of a specified point
-- label only visible if mouse cursor is within distance d of a specified point
-- moving label, same parameters as TRACK presumably;
specified initial label position is the T1 position for LABELT cases.

(The "specified point" would not be the labeling point necessarily, but rather a separate coordinate probably at the center of the object being labeled.

... And how painful is the ANGLE !=0 problem, by the way? Or shouldn't I even ask?
User avatar
rowett
Moderator
Posts: 4597
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: Life tag testing

Post by rowett »

dvgrn wrote:Did you consider my other crazy labeling ideas?
-- label only visible if viewpoint is within distance d (Manhattan? Cartesian?) of a specified point
-- label only visible if mouse cursor is within distance d of a specified point
-- moving label, same parameters as TRACK presumably;
specified initial label position is the T1 position for LABELT cases.

(The "specified point" would not be the labeling point necessarily, but rather a separate coordinate probably at the center of the object being labeled.
All being considered.
dvgrn wrote:... And how painful is the ANGLE !=0 problem, by the way? Or shouldn't I even ask?
Not painful at all it turned out. Rotate one of these.
At the moment it's just the position of the label I move. Did you want the text (optionally) rotated?
User avatar
dvgrn
Moderator
Posts: 12053
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: Life tag testing

Post by dvgrn »

rowett wrote:At the moment it's just the position of the label I move. Did you want the text (optionally) rotated?
Ideally, yes. There's no point in allowing text to turn upside down in the default case, but if there's a command to lock down the text angle, it will work better for some circuit labeling situations where the text extends a good distance, marking a long signal path.
User avatar
rowett
Moderator
Posts: 4597
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: Life tag testing

Post by rowett »

dvgrn wrote:
rowett wrote:At the moment it's just the position of the label I move. Did you want the text (optionally) rotated?
Ideally, yes. There's no point in allowing text to turn upside down in the default case, but if there's a command to lock down the text angle, it will work better for some circuit labeling situations where the text extends a good distance, marking a long signal path.
I think there are two separate cases:
  1. wanting a rotated label
  2. wanting labels to rotate with the camera angle
Both are valid. Agree?
User avatar
dvgrn
Moderator
Posts: 12053
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: Life tag testing

Post by dvgrn »

rowett wrote:I think there are two separate cases:
  1. wanting a rotated label
  2. wanting labels to rotate with the camera angle
Both are valid. Agree?
Ah, definitely. When the first is needed, the second is also usually a good idea.
User avatar
rowett
Moderator
Posts: 4597
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: Life tag testing

Post by rowett »

Build 268 is now available on the lazyslug server

Enhancements is this build:
  • Labels work with non-zero angle
  • Labels work in hex display mode
  • new script command [[ LABELANGLE <0..359> (FIXED) ]]
    • sets the label angle for subsequent label definitions
    • optional keyword FIXED means label will not rotate when camera rotates
The second test here shows the new LABELANGLE features.
User avatar
dvgrn
Moderator
Posts: 12053
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: Life tag testing

Post by dvgrn »

rowett wrote:Build 268 is now available on the lazyslug server...
Looks really good! I've borrowed Build 268 to start tackling the timeline labeling problem with. Will let you know if anything interesting turns up when I try to mix waypoint animations with labels.

I'm a little uncertain about that first test viewer, with the glider TRACKLOOP... though really plain TRACK might be more of an issue sometimes. What you've done is clearly what is wanted if the pattern is just a spaceship, but not if you were trying to put a label on a stationary structure that was being left behind by the tracked object.

Anyway, thank you again! Once the timeline labeling is done, I'll see if I can collect a big pile of object data from somewhere, and produce a really big explorable labeled stamp collection as a sample "interactive feature".

This is something I've been thinking about in a LifeWiki context. So far, use of LifeViewer waypoint scripting for simple LifeWiki animations seems to have worked out pretty well: if you're just showing a reflector repeatedly reflecting a glider, all the action is over in a few seconds and nobody is going to get impatient. With a few of Entity Vakyrie's more ambitious recent additions, I start to worry a little that not everyone might really want to see what the waypoint script is trying to show off, at the speed that it's showing it.

If you know enough to hit the leftmost left-arrow you can reset the pattern _and_ turn off the animation -- but then if a message is supposed to pop up at T=1000 when the waypoint script is passing by some remarkable subpattern, you couldn't have that and control over LifeViewer at the same time. With labels at different zoom levels, I think it will be a lot easier to do "self-guided tours" of large patterns, let users handle their own zooming and panning, and stop trying to drag everyone along at a fixed speed in such cases.

(That's right, no new feature requests in any of this!)
User avatar
rowett
Moderator
Posts: 4597
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: Life tag testing

Post by rowett »

dvgrn wrote:I'm a little uncertain about that first test viewer, with the glider TRACKLOOP... though really plain TRACK might be more of an issue sometimes. What you've done is clearly what is wanted if the pattern is just a spaceship, but not if you were trying to put a label on a stationary structure that was being left behind by the tracked object.
You make a good point. It might be worth having Label TRACK mode an option (rather than your earlier suggestion of random tracks per Label). If you're watching a TRACK pattern I'll probably default to TRACK mode and reuse the FIXED keyword to let you specify labels that you don't want to move.
dvgrn wrote:Once the timeline labeling is done, I'll see if I can collect a big pile of object data from somewhere, and produce a really big explorable labeled stamp collection as a sample "interactive feature".
Yes I was imagining something like this when you asked the question about how many labels could be managed. So far, so good.
dvgrn wrote:With labels at different zoom levels, I think it will be a lot easier to do "self-guided tours" of large patterns, let users handle their own zooming and panning, and stop trying to drag everyone along at a fixed speed in such cases.
Yes it almost, but not quite, obsoletes Waypoint (and also POI) messages. But I still see cases where they are valid.
User avatar
rowett
Moderator
Posts: 4597
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: Life tag testing

Post by rowett »

Build 269 is now available on the lazyslug server

Enhancements is this build:
  • updated script command: [[ LABEL X Y ZOOM (FIXED) "<string>" ]]
    • optional FIXED argument makes the position static when TRACK mode is on
  • cell under mouse display now works at any ANGLE
Fixes in this build:
  • cell under mouse display was incorrect when TRACK mode is on
The first test here shows the new FIXED position feature.
User avatar
rowett
Moderator
Posts: 4597
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: Life tag testing

Post by rowett »

Build 270 is now available on the lazyslug server

Enhancements is this build:
  • Labels now use non-integer font point sizes
  • Labels now work with [[ TRACKBOX ]] - test
  • Grid Lines now work at all angles - test
Fixes in this build:
  • fixed an issue with custom Themes
User avatar
rowett
Moderator
Posts: 4597
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: Life tag testing

Post by rowett »

Build 271 is now available on the lazyslug server

Enhancements is this build:
  • new script command [[ LABELTARGET X Y D ]] or [[ LABELTARGET OFF ]] - test
    • sets the target point and distance for subsequent label definitions
    • the center viewpoint must be within the defined distance of the target point for the label to be displayed
    • the target point is independent from the label position
    • [[ LABELTARGET OFF ]] turns off the target for subsequent label definitions
  • new menu button to toggle population graph
User avatar
rowett
Moderator
Posts: 4597
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: Life tag testing

Post by rowett »

The [[ LABELTARGET ]] command takes a distance in cells. I was thinking it might also be helpful to allow specification of a distance in screen pixels (maybe 5 means five cells, and 50px means fifty screen pixels). That way for some labels the distance wouldn't be dependent on zoom level. Thoughts?
User avatar
dvgrn
Moderator
Posts: 12053
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: Life tag testing

Post by dvgrn »

rowett wrote:The [[ LABELTARGET ]] command takes a distance in cells. I was thinking it might also be helpful to allow specification of a distance in screen pixels (maybe 5 means five cells, and 50px means fifty screen pixels). That way for some labels the distance wouldn't be dependent on zoom level. Thoughts?
I was actually worried about something a little different, but along these same lines.

Your test case is way up at maximum zoom level. A test case at moderate zoom levels -- labeling the parts of a line crosser, for example -- might make it clear that there's a piece missing somewhere.

Regular labels have an X, Y, Z coordinate, so that they can appear at more or less the right zoom level. Completely different labels might be appropriate at the same location for different zoom levels -- right?

I haven't played around with these things long enough yet to be able to tell whether a distance measured in screen pixels would be more useful in some cases. Seems like there's a limited zoom range in which that option would work: if you zoom too far out, then the pixel distance might say that the label should be visible, but it will be out of zoom range and faded to invisibility anyway. Zoomed too far in, maybe a similar but different problem -- a label that takes up most of the viewport will suddenly appear or disappear as you cross an arbitrary pixel distance boundary.

So I _think_ that adding a Z parameter to LABELTARGET would probably handle a lot of the cases you're thinking about for distances measured in pixels. But I might just be imagining different a different use case from the one you have in mind, so I certainly wouldn't object to the "px" suffix option you suggested...!
User avatar
rowett
Moderator
Posts: 4597
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: Life tag testing

Post by rowett »

dvgrn wrote:Regular labels have an X, Y, Z coordinate, so that they can appear at more or less the right zoom level. Completely different labels might be appropriate at the same location for different zoom levels -- right?
Yes and you make the key point to why I'm now thinking we may not need a px or a Z.

We can specify a LABELTARGET per label. So just pick an appropriate distance based on the Z of each label.

Try this test which has 5 labels at the same location but different zoom levels. I specify appropriate distance LABELTARGETs so they always appear at a similar distance from the viewport center.

My only thought is the default zoom range that labels are visible might be a bit generous.
User avatar
dvgrn
Moderator
Posts: 12053
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: Life tag testing

Post by dvgrn »

rowett wrote:My only thought is the default zoom range that labels are visible might be a bit generous.
Offhand it looks about right to me. A too-big label isn't much of a problem as long as it's starting to go transparent -- you may not be able to read it, but it tells you there's a higher-level feature you _could_ read about if you zoomed out a little.

Too-small labels generally aren't much of a problem anyway, because they don't take up too much space.

Start with the current default zoom range, and provide a way to change those settings, just in case anyone turns out to need that?
User avatar
rowett
Moderator
Posts: 4597
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: Life tag testing

Post by rowett »

Build 272 is now available on the lazyslug server

Enhancements is this build:
  • HROT rules now support von Neumann and Circular neighbourhoods - test
    • new optional neighbourhood postfix: Rr,Cc,Slist,Blist(,Nm)
  • 2-state Generations rules now use standard Themes - test
Fixes in this build:
  • graph close button was not updating graph toggle button
This build is a Release Candidate since it contains some needed fixes.
User avatar
rowett
Moderator
Posts: 4597
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: Life tag testing

Post by rowett »

Build 273 is now available on the lazyslug server

Enhancements is this build:
  • 2-state LtL and HROT rules now use standard Themes
This build is a Release Candidate since it contains some needed fixes.
User avatar
rowett
Moderator
Posts: 4597
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: Life tag testing

Post by rowett »

rowett wrote:This build is a Release Candidate since it contains some needed fixes.
Actually it's not it's just failed some tests...
User avatar
rowett
Moderator
Posts: 4597
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: Life tag testing

Post by rowett »

Build 274 is now available on the lazyslug server

Fixes in this build:
  • fixed an issue with 2 state LtL or HROT rules and Planes
This build is a Release Candidate since it contains some needed fixes.
User avatar
dvgrn
Moderator
Posts: 12053
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: Life tag testing

Post by dvgrn »

rowett wrote:Build 274 is now available on the lazyslug server...
Looks good. I ran through the Official Unofficial Test Suite starting with images.html, and added a random label in the POI test and it worked great, and got through to the end without finding anything particular to complain about -- except that test.html ought to be removed, it's a duplicate of something in lifeviewer.html.

I haven't looked at A through H yet, and of course I might possibly have missed something in I through Z -- a few of the cases are maybe somewhat in need of little essays about what to expect, now that memory of the original problem has faded. I might put together some kind of one-page regression test library at some point, to give a slightly better chance of catching new things going wrong without checking all of these pages. The bugs tested on some of these pages seem fairly unlikely to recur.

Then again, going through the whole collection doesn't take that long. Maybe it would work to ask for volunteer beta testers from the forums or Discord now and then, just to get some fresh eyes on the subject.

Anyway, the new Candidate 274 has my provisional okay for release into the wild -- !
User avatar
rowett
Moderator
Posts: 4597
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: Life tag testing

Post by rowett »

dvgrn wrote:Anyway, the new Candidate 274 has my provisional okay for release into the wild -- !
Nathaniel please will you release build 274.
User avatar
rowett
Moderator
Posts: 4597
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: Life tag testing

Post by rowett »

Build 275 is now available on the lazyslug server

Enhancements in this build:
  • 2 state LtL and HROT rules are faster especially at higher range
Fixes in this build:
  • fixed layer rendering for 2 state generations, LtL and HROT rules
This build is a Release Candidate.
Locked