Life tag testing

[rowett]

Build 234 is now available on the lazyslug server

Enhancements in this build:

• added support for Hex and von Neumann neighbourhoods with MAP rules
  • Hex neighbourhoods have 22 base 64 characters
  • von Neumann neighbourhoods have 6 base 64 characters

Fixes in this build:

• LifeHistory patterns were not respecting Themes at generation 0
• [[ NOSOURCE ]] now also hides the "CODE: SELECT ALL" line
• copy pattern source (hotkey "c") was not working correctly in the standalone viewer

[dvgrn]

Here's a Chrome bug report I sent to Google this morning, after Saka mentioned last night that there's a new problem with selecting code blocks on the forums -- so I knew it wasn't just me.

Code: Select all

On the conwaylife.com forums, the Select All button no longer creates a selection that can be copied.

See, e.g., http://conwaylife.com/forums/viewtopic.php?f=7&t=1994&start=75#p51150 -- click on "Select All" in the box labeled "CODE", then hit Ctrl+C to copy.

The selection appears to be made correctly, but Ctrl+C now has no effect.  Previous clipboard contents are retained.

If the selection is done manually, visually the selection is exactly the same but Ctrl+C now works.

Just tested this immediately before and after an upgrade from Version 60.0.3112.113 (Official Build) (32-bit) to Version 61.0.3163.100 (Official Build) (32-bit).  The problem definitely is not present in Version 60, but appears in Version 61 immediately after a relaunch.

Luckily my old laptop hadn't quite updated Chrome yet, so I was able to try a really clean before-and-after experiment.

Pretty sure this isn't really LifeViewer related, since LifeViewer is only responsible for adding the Show in Viewer tag. (For example, I'm seeing the problem with Select All in the code block above.) But maybe this is a good place to mention the problem anyway.

[rowett]

Pretty sure this isn't really LifeViewer related, since LifeViewer is only responsible for adding the Show in Viewer tag. (For example, I'm seeing the problem with Select All in the code block above.) But maybe this is a good place to mention the problem anyway.

Correct, it isn't related to LifeViewer. It's a bug (or perhaps new "feature") in Chrome 61.

[rowett]

And for the record I'm having issues with mouse events with Chrome 60+ as well.

[rowett]

And for the record I'm having issues with mouse events with Chrome 60+ as well.

I've finally fixed it. Chrome was firing spurious mouseout events if both mousedown and mouseup were handled between requestionAnimationFrame updates.

As a side note: When I originally planned LifeViewer I decided not to use any third party libraries and wrote all the libraries I needed from scratch. One of the reasons for this was when there was a bug (and there are always bugs) it would most likely be my fault and not in someone else's third party library that I couldn't debug. Unfortunately that strategy didn't account for Chrome itself.

[dvgrn]

As a side note: When I originally planned LifeViewer I decided not to use any third party libraries and wrote all the libraries I needed from scratch. One of the reasons for this was when there was a bug (and there are always bugs) it would most likely be my fault and not in someone else's third party library that I couldn't debug. Unfortunately that strategy didn't account for Chrome itself.

Yes, sorry to hear it and glad you found a workaround.

I'm a little surprised by this new Chrome 61 "feature" of doing a visual selection without actually being able to copy the selected text to the clipboard. Any ideas on whether Chrome 62 will roll this back, or whether it's considered to be a new security feature or some such? It seems like this is a common enough piece of functionality that Google must have broken a lot of phpBB forum functionality with this, not just conwaylife.com/forums ...?

[rowett]

I'm a little surprised by this new Chrome 61 "feature" of doing a visual selection without actually being able to copy the selected text to the clipboard. Any ideas on whether Chrome 62 will roll this back, or whether it's considered to be a new security feature or some such? It seems like this is a common enough piece of functionality that Google must have broken a lot of phpBB forum functionality with this, not just conwaylife.com/forums ...?

Did you raise an issue with Google? The Chrome Platform Status release timeline only shows new features and not bugfixes.
Let's hope it's a bug and not a new "security" feature. If it turns out to be a feature then it may be possible to work round it with the suggestion I made here. Plus for RLE code blocks they can always use the new Ctrl-C hotkey feature in LifeViewer (note there's a bug fix for the popup viewer to make this work that hasn't been released yet).

[dvgrn]

Did you raise an issue with Google? The Chrome Platform Status release timeline only shows new features and not bugfixes.

Yeah, I sent in a couple of versions of a bug report via Help > Report an Issue. Text is in this posting.

Seems to me this should definitely be a bug, and one that should get fixed ASAP. The Select All button still highlights text, in exactly the same way as if you select it manually. If they're not going to allow Select All buttons to select text any more, they need to be honest about it and not do the useless visual selection -- that's just plain false advertising.

[rowett]

Did you raise an issue with Google? The Chrome Platform Status release timeline only shows new features and not bugfixes.

Yeah, I sent in a couple of versions of a bug report via Help > Report an Issue. Text is in this posting.

Seems to me this should definitely be a bug, and one that should get fixed ASAP. The Select All button still highlights text, in exactly the same way as if you select it manually. If they're not going to allow Select All buttons to select text any more, they need to be honest about it and not do the useless visual selection -- that's just plain false advertising.

I re-raised this issue directly on the Chromium Issues site and it's getting some traction. Latest is here.

[rowett]

I re-raised this issue directly on the Chromium Issues site and it's getting some traction. Latest is here.

This was fixed in Chrome 62.

[dvgrn]

I re-raised this issue directly on the Chromium Issues site and it's getting some traction. Latest is here.

This was fixed in Chrome 62.

So it was! Thanks for following up on this, apparently in the right place. People were switching to Firefox left and right...

[dvgrn]

Here's something I've been thinking about, and may possibly dive into lifeviewer.lua code and try to add. (Whether I succeed or not is another matter.)

I'd like to be able to add instant jumps to a waypoint script, similar to the transition that LifeViewer does to TRACK a spaceship, but to arbitrary spacetime locations, maybe with pauses in between to display messages.

For example, I'd like to show a stamp collection of polyominoes, then zoom in on one, show it, run it to stability, back up to T=0, zoom to the next one so it's the only one visible, show a label, run that one, etc., etc.

I'm starting to work on a six-minute talk for Gathering for Gardner 13. Six minutes is not a lot of time, so I'd like to pack in as much action as possible to go along with the narration. I might end up needing a custom Lua script anyway, to load a series of (larger) patterns in succession and zoom in on the areas I'm talking about.

But I think I could probably do almost everything I want with LifeViewer. It just won't be quite as seamless if I have to move down an HTML page and start a new LifeViewer waypoint script every now and then, when the previous pattern has been "used up" and reaches a STOP.

-- All early days yet, just starting to think about what might be possible.

[rowett]

I'd like to be able to add instant jumps to a waypoint script, similar to the transition that LifeViewer does to TRACK a spaceship, but to arbitrary spacetime locations, maybe with pauses in between to display messages.

When generations are specified with the T script command they must be in ascending order:

Code: Select all

[[ T 10 ZOOM 2 X 0 Y 0 ]]
[[ T 20 ZOOM 10 ]]
[[ T 30 ZOOM 3 ]]

Perhaps a T command with an earlier generation than previously specified would reset the generation:

Code: Select all

[[
PAUSE 3
"First interesting pattern"
T 10 ZOOM 2 X 0 Y 0
T 20 ZOOM 10
T 30 ZOOM 3
STOP 40

T 0 ZOOM 12 X 200 Y 15
PAUSE 3
"Second pattern"
T 15 ZOOM 32
STOP 30

T 10 ZOOM 20 X 50 Y -25
PAUSE 3
"Third pattern"
]]

In this case the first set of zooms would run until STOP 40.
Once playback is resumed it would reset to T=0 (ZOOM 12) and continue playback until STOP 30.
Once playback is again resumed it would reset to T=10 (ZOOM 20).

Implementation considerations:

• Would need to handle multiple STOP commands
• Would need to figure out what to do with LOOP
• Non T=0 resets would probably need to create snapshots (for speed) during earlier waypoint playback assuming generations visited
• UI Reset would go back to start of waypoint list
• Graph data would need to reset
• STEPBACK would need attention

[dvgrn]

I'd like to be able to add instant jumps to a waypoint script, similar to the transition that LifeViewer does to TRACK a spaceship, but to arbitrary spacetime locations, maybe with pauses in between to display messages.

When generations are specified with the T script command they must be in ascending order...
Perhaps a T command with an earlier generation than previously specified would reset the generation...
Implementation considerations:

• Would need to handle multiple STOP commands
• Would need to figure out what to do with LOOP
• Non T=0 resets would probably need to create snapshots (for speed) during earlier waypoint playback assuming generations visited
• UI Reset would go back to start of waypoint list
• Graph data would need to reset
• STEPBACK would need attention

The snapshot and STEPBACK items don't seem at all trivial. Which is why I was thinking I maybe ought to try to hack together some rough additions to lifeviewer.lua that work for me for this upcoming talk -- rather than just hoping that you'll do all the work. Not that I would mind if you did, of course.

Multiple STOPs could certainly be useful: I talk about the first animation sequence, then LifeViewer stops, I get caught up, I hit Enter and start talking about the second animation sequence.

I'm not sure STOPs will always be wanted between transitions, though. Maybe more often what will be needed is a PAUSE with a pop-up label, along the lines of the heavy-handed narration experiment I tried a few years ago.

That method will work well for a lot of cases, but not so much where I want an instantaneous transition to a different location, instead of a zoom-and-pan transition taking at least one tick.

For example, I might want to move to a totally different subpattern, as if it was in a different universe. Subpatterns could be stored in different regions of the same RLE, but I'd want to keep the view zoomed in, and make the transfer during a PAUSE with no visible panning, and no time passing on the Life clock. Having a sudden visible transition in some random direction would just be confusing to a viewer.

Resetting the view to 0, or whatever generation might be wanted, could also be done during a pause. In most cases a small additional delay to do the reset wouldn't be a problem, so I don't know how much extra cleverness would really be needed in the snapshot system.

Anyway, short summary: it would be useful (to me, if not anyone else) if the requirement could be removed about T values having to increase, so that I could jump from any spacetime location to any other spacetime location, however I wanted to.

I seem to recall that allowing two T=n waypoints in a row would have done terrible things to the interpolation system, so possibly any zero or negative delta T would always be an instantaneous transition?

Unfortunately I can also imagine a case where I want to jump from one location to another at T=0 -- Zoomed In View #1 to Zoomed Out View to Zoomed In View #2 (with label) to Zoomed Out View again, and so on. In that case, interpolation is still needed for everything except the generation count... but then it's no longer possible to use the GPS setting to figure out how fast LifeViewer has to make the transition.

Seems like that might require a RealTime setting for each waypoint, or something strange like that.

Obviously if these instantaneous transitions are implemented, it will be possible to do arbitrary animations by stacking frames in a grid and insta-zooming to each frame in turn. That could be useful, too -- have one copy of a pattern that's just the pattern, and another copy with circles and arrows and history cells and whatever other labels and annotations, that are helpful in a close-up view but you wouldn't want to see them in the overview.

(I guess that could be done by customizing the colors to hide marked OFF cells, history, etc. -- except when you want two or more different objects to be displayed in the same place in different parts of the animation. That case seems best handled by allowing the "same place" to be two or more different places that just look the same.)

[rowett]

The snapshot and STEPBACK items don't seem at all trivial.

I think snapshot is not too bad. There's already a special case snapshot at T=0 for the reset position. It would simply be a matter of having a list of non-T=0 reset points (that were specified by Waypoints).
If I limit STEPBACK to only going back to T=0 then it's probably trivial. If it needed to wrap to earlier waypoints that would be unpleasant.

Multiple STOPs could certainly be useful: I talk about the first animation sequence, then LifeViewer stops, I get caught up, I hit Enter and start talking about the second animation sequence.

Agreed, that's what I was imagining.

I'm not sure STOPs will always be wanted between transitions, though. Maybe more often what will be needed is a PAUSE with a pop-up label, along the lines of the heavy-handed narration experiment I tried a few years ago.

Yes and as you so well demonstrated, that already works

That method will work well for a lot of cases, but not so much where I want an instantaneous transition to a different location, instead of a zoom-and-pan transition taking at least one tick.

Try PAUSE with a very small value and the target. I could allow PAUSE 0 in the future.

Code: Select all

[[ PAUSE 0.01 X 100 Y 40 ZOOM 3 ]]

I seem to recall that allowing two T=n waypoints in a row would have done terrible things to the interpolation system, so possibly any zero or negative delta T would always be an instantaneous transition?

Yes. So a "T currentgen" waypoint would be the same as a PAUSE 0 waypoint (i.e. instantaneous space transition). Whereas a "T earliergen" waypoint would be an instantaneous time (and possibly space) transition.

Unfortunately I can also imagine a case where I want to jump from one location to another at T=0 -- Zoomed In View #1 to Zoomed Out View to Zoomed In View #2 (with label) to Zoomed Out View again, and so on. In that case, interpolation is still needed for everything except the generation count... but then it's no longer possible to use the GPS setting to figure out how fast LifeViewer has to make the transition.

That's what PAUSE is for.

[rowett]

On a related note there is also the POI (point of interest) command. This can be used to define a set of camera positions that you can then cycle forward or backwards through with hotkeys J and shift-J respectively.
The camera does glide between POIs but I guess I could add a transition time setting.

Code: Select all

#C [[ POI X 33 Y 18 ZOOM 8.5 "1. Interesting" ]]
#C [[ POI X -15 Y 42 ZOOM 12 "2. Curious" ]]
#C [[ POI X -38 Y -6 ZOOM 15.9 "3. Unexpected" ]]
#C [[ POI X 0 Y 0 ZOOM 2 "" ]]
x = 108, y = 131, rule = LifeHistory
28.2A$28.A.A$30.A4.2A$26.4A.2A2.A2.A$26.A2.A.A.A.A.2A$28.BABABA.A$29.
B2ABA.A$30.2B.BA$29.3B$20.2A6.4B$21.A6.B2A3B$21.A.AB3.B2A3B$22.2AB.
10B$24.13B$24.14B$24.15B$26.8B2.4B$26.6B5.4B$25.9B4.4B$24.4B4.2A5.4B$
23.4B5.A7.4B$22.4B7.3A5.4B$21.4B10.A6.4B$20.4B19.4B$19.4B21.4B$18.4B
23.4B$17.4B25.4B$16.4B27.4B$15.4B29.4B$14.4B31.4B$13.5B32.4B$12.8B6.
2A23.4B$10.11B5.A25.4B$8.13B2.BA.A26.4B$7.14B2.B2A28.4B$7.17B31.4B$8.
16B32.4B$10.14B33.4B$11.13B34.4B$11.14B34.4B$11.15B34.4B$8.17B4.2A30.
4B$8.17B3.B2AB30.4B$8.17B3.4B31.4B$6.22B.3B2.B6.2A21.4B$5.31B5.A23.4B
$4.33B.BA.A24.4B7.A$3.34B.B2A26.4B6.3A$2.2A35B29.4B8.A$.A.AB3.31B30.
4B6.A.A$.A8.28B32.4B5.A.AB$2A8.27B34.4B5.A3B$11.2B.10B3.10B35.4B6.4B$
10.2B4.11B.9B36.4B5.6B$9.B2AB3.20B38.4B4.7B$10.2A4.12B.4B42.4B2.8B.4B
.B$17.11B.4B43.17B.B2A$15.4B.4B3DB2.3B44.18B2A$15.2A4.4BD2B3.B45.16B.
2B$16.A4.2B3D2B49.16B$13.3A6.6B49.15B$13.A8.7B46.2AB.12B$22.8B44.A.AB
2.11B$23.8B43.A5.10B$23.8B42.2A5.2B2A6B$22.6B2.B2A46.3B2A6B$22.7B.BA.
A46.10B$23.6B4.A46.8B.B2A.A$23.6B4.2A44.7B3.B2AB3A$23.6B50.6B6.B4.A$
22.8B50.6B4.2E.3E$21.8B51.5B6.E.E$21.9B49.6B4.E$21.9B49.6B4.2E$20.10B
48.7B9.E$20.3B2C5B48.2B3D2B7.3E$19.4B2C5B48.4BD3B5.E$19.11B48.3B3D2B
4.BCE$14.2E.E7BD4B49.8B2.4B$14.E.2E2.4B3DB51.3B2C2B2.4B$21.2B2D2BD2.B
46.5B2C2B.4B$23.5B.BCE45.13B$22.8BCE44.16B$6.2E13.7B.2B5.E38.17B$7.E
5.2B3.10B6.3E15.E23.16B$7.E.EB.14B7.E16.3E11.2E11.15B$8.ECB.14B7.CE
14.E14.E.E11.13B$10.16B4.5B13.B2E15.E12.11B8.E$10.16B3.4B14.4B15.2E7.
15B6.3E$11.16B2.5B12.4B4.B.7B4.B4.20B3.E$12.2B2C11B2.5B11.4B.13B4.25B
3.CE$11.BC4BC16B4.26BD32B$10.8BC5BC10B2.4BD21BD31B$10.2BC5BC4BCBC9B2.
4B3D18B2D33B$11.2B6C4B2C11B.4BDBD15B2C2B2D33B$11.32BD15B2C3BD33B$11.
8B.4B2.21B2.2B3.44B$12.7B3.2B3.17B11.10B2.29B.BCE$10.4B.B11.15B16.6B
4.8B.19B.BE.E$10.EC14.15B19.3B9.23B5.E$11.E14.16B20.B11.13B.7B5.2E$8.
3E15.16B20.2E11.4B3.4B.3B.3B$8.E18.7B3.3B.BCE19.E12.4B4.B3.3B2.2B$28.
5B8.BE.E17.E14.4B6.B2CB.B2CB$28.5B2C9.E17.2E14.4B6.2E3.2E$32.C2BC2.2E
4.2E33.4B$32.CBCB3.E2.2E36.4B$33.C4B.E.E.E37.4B$35.BCE.E2.E39.4B$35.B
EB.E43.4B$33.E4.E45.4B$33.5E47.4B$86.4B$33.2E.2E49.4B$33.2E.2E50.4B$
89.4B$90.4B$91.4B$92.4B$93.4B$94.4B$95.4B$96.4B$97.4B$98.4B$99.4B$
100.4B$101.4B$102.4B$103.4B$104.4B!

[rowett]

On a related note there is also the POI (point of interest) command. This can be used to define a set of camera positions that you can then cycle forward or backwards through with hotkeys J and shift-J respectively.
The camera does glide between POIs but I guess I could add a transition time setting.

... and possibly an option to make each POI transition automatically reset to T=0.
... and even more possibly an option to specify reset on a per-POI basis.

[dvgrn]

On a related note there is also the POI (point of interest) command. This can be used to define a set of camera positions that you can then cycle forward or backwards through with hotkeys J and shift-J respectively.
The camera does glide between POIs but I guess I could add a transition time setting.

... and possibly an option to make each POI transition automatically reset to T=0.
... and even more possibly an option to specify reset on a per-POI basis.

Let me know if I should say anything else. When you get thinking like this it usually has good results --!

[rowett]

Let me know if I should say anything else. When you get thinking like this it usually has good results --!

I'm quite happy to ramble on. If any of it sounds unhelpful let me know.

[dvgrn]

Let me know if I should say anything else. When you get thinking like this it usually has good results --!

I'm quite happy to ramble on. If any of it sounds unhelpful let me know.

A time component to a POI would be handy in some cases, e.g. to get to the various critical points in something like dbell's Collatz 5n+1 simulator. Except that the time between critical points in that particular pattern is probably too long for LifeViewer to handle in any reasonable time.

The basic idea is good, though: maybe the 512x512 metacell is a better example. Zoom and stop at each time a neighbor input is tested, zoom and stop when the ladder circuit is activated, etc., etc.

That would conveniently allow a "reset on per POI basis" -- it would just be a T=0 for the POIs where a reset is wanted, and leave it out otherwise.

[rowett]

I've implemented the enhancements to the POI system. Remember that POIs, unlike Waypoints, are designed to be user interface triggered rather than time or generation triggered. It's like the different between advancing slides in Powerpoint manually via a mouse click or keypress rather than auto advance after 20 seconds.

I'm expecting to also enhance the Waypoint system as discussed above once I've got my head round an awkward design challenge...

What's new in the POI system? Glad you asked...

• there are new script commands that allow you specify actions when switching to a POI
  • [[ POIRESET ]] will reset playback to T=0
  • [[ POIPLAY ]] will start playback (if stopped)
  • [[ POISTOP ]] will stop playback (if playing)
  • if neither [[ POIPLAY ]] or [[ POISTOP ]] are specified then playback status is unaffected
  • both [[ POIRESET]] and one of [[ POIPLAY ]] or [[ POISTOP ]] can be specified per POI
• [[ POITRANS 0..60 ]] specifies transition speed (in frames which are 60ths of a second)
  • 0 means instantaneous transition
  • if not specified then the default is 12
• hotkeys alt-1 to alt-9 will switch to respective POIs (if specified)

I would post an example but I'm 24 hours of flying away from home at the moment and so won't be able to upload the changes until Friday afternoon UK time. Hopefully by then I'll have made more progress on the Waypoint enhancements and the LTL implementation.

[dvgrn]

I've implemented the enhancements to the POI system. Remember that POIs, unlike Waypoints, are designed to be user interface triggered rather than time or generation triggered.

Sounds like fun! I look forward to trying it out.

Coincidentally, I had just started a new thread to try to encourage people to use some of their holiday free time (if any) to put together a few new LifeViewer animations. We'll see if anything comes of that.

I think the one I want to do next is a LOOP with a figure-eight of different spaceships -- seven orthogonal ships with known glider constructions, and gliders connecting from one to the next to complete the '8'. The protagonist of the animation will be a glider that becomes either one of the first or one of the last gliders in a spaceship recipe. Then LifeViewer follows the spaceship for a while, after which it either hits a still life or gets ambushed by gliders, producing a new clean glider at 90 degrees from the old one.

Repeat that seven more times, then LOOP when a glider gets back to the start location. We have plenty of constructible orthogonal spaceships:

LWSS (3 gliders)
MWSS (3)
HWSS (3)
(sidecar? Big A? Coe ship?)
x66 (13)
dart (25)
25P3H1V0.1 (47)
puffership (60)
60P5H2V0 (61)
30P5H2V0 (65)
Pushalong 1 (77)
weekender (79)
30P4H2V0.4 (85)

The only possible problem is that LifeViewer might get kind of slow with all those gliders off in the far corners of the universe, heading in various directions -- or that it will be hard to pack that many constructions into 8192x8192. We'll see. Coincidentally, in checking my memory of the maximum size of a LifeViewer grid, I found that adding [[ DELETERANGE 1 ]] makes LifeViewer throw script errors, when it doesn't otherwise.

Code: Select all

x = 8192, y = 8192, rule = B3/S23
2$8192o8188$8192o!

Code: Select all

x = 8192, y = 8192, rule = B3/S23
2$8192o8188$8192o!
#C [[ DELETERANGE 1 ]]

[rowett]

The only possible problem is that LifeViewer might get kind of slow with all those gliders off in the far corners of the universe, heading in various directions -- or that it will be hard to pack that many constructions into 8192x8192.

If it does fit in 8192x8192 then you can always make it a LifeHistory pattern and enclose it in a state 6 kill box to stop the gliders escaping.

Coincidentally, in checking my memory of the maximum size of a LifeViewer grid, I found that adding [[ DELETERANGE 1 ]] makes LifeViewer throw script errors, when it doesn't otherwise.

It's already fixed in the as yet unreleased build 235.

[rowett]

What's new in the POI system? Glad you asked...

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.

For example:

Code: Select all

POI X 20 Y 50 ZOOM 3
POI X 25 Y 50 ZOOM 3
POI X 25 Y 50 ZOOM 2

Can now be written as:

Code: Select all

POI X 20 Y 50 ZOOM 3
POI X 25
POI ZOOM 2

This only applies to X, Y, ZOOM and ANGLE. POIRESET, POISTART, POISTOP and POITRANS do not inherit previous POI definition.

[rowett]

Build 235 is now available on the lazyslug server

Enhancements in this build:

• whitespace at the beginning of lines is now removed before copying patterns to clipboard (to be nice to Golly)
• enhanced POI (point of interest capability): test
  • there are new script commands that allow you to specify actions when switching to a POI
    • [[ POIRESET ]] will reset playback to T=0
    • [[ POIPLAY ]] will start playback (if paused)
    • [[ POISTOP ]] will stop playback (if playing)
    • if neither [[ POIPLAY ]] or [[ POISTOP ]] are specified then playback status is unaffected
  • [[ POITRANS 0..60 ]] specifies transition speed in 60th of a second
    • 0 means instantaneous transition
    • if not specified then the default is 12
  • hotkeys alt-1 to alt-9 will switch to respective POIs (if specified)
• STOP and LOOP tooltips now show generation

Fixes in this build:

• rules in the format SnnBnn were being decoded with S and B transposed
• error could be generated about [[ XOFFSET ]] and [[ YOFFSET ]] when they weren't specified - test
• updated event handling for UI to handle spurious mouseleave events posted when mouseup and mousedown both happen between frame updates