Life tag testing

[Andrew]

Interesting stuff! A minor suggestion: maybe "cellview" would be more descriptive than "cellmap"?

If you're happy with the approach I'll check in the prototype changes.

Fire away. Also add lifeviewer.lua to Scripts/Lua.

[rowett]

LifeViewer layers!

[rowett]

If you're happy with the approach I'll check in the prototype changes.

Fire away. Also add lifeviewer.lua to Scripts/Lua.

Prototype checked in.

Open a pattern and then open Scripts/Lua/lifeviewer.lua.

The keyboard controls are as follows:

• space - next generation
• enter - toggle play/pause
• esc - close
• [ - zoom out
• ] - zoom in
• < - rotate left
• > - rotate right
• 5 - reset angle to 0
• c - toggle standard colors / LifeViewer theme 1 (works best for 2 state patterns)
• when in LifeViewer theme mode
  • q - increase layers
  • a - decrease layers
  • p - increase layer depth
  • l - decrease layer depth
• r - reset to generation 0, if at generation 0 also reset camera
• 1 - zoom x1
• 2 - zoom x2
• 4 - zoom x4
• 8 - zoom x 8
• 6 - zoom x16
• 3 - zoom x32

Next will be arrows and mouse control for panning. Is there mouse wheel support yet?

[rowett]

Committed updates to lifeviewer.lua (build 2):

• view can now be panned with arrow keys (works with angles too)
• status line shows camera data

[rowett]

Committed updates to lifeviewer.lua (build 3):

• New keyboard commands
  • h - display help
  • shift [ - halve zoom
  • shift ] - double zoom
  • shift < - rotate left 90 degrees
  • shift > - rotate right 90 degrees
  • shift 2 - set -2x zoom
  • shift 4 - set -4x zoom
  • shift 8 - set -8x zoom
  • shift 6 - set -16x zoom
  • shift left - pan north west
  • shift right - pan south east
  • shift up - pan north east
  • shift down - pan south west
• improved status information formatting

[Andrew]

Prototype checked in.

Impressive work! I'm worried about a couple of things though...

I don't like the way cellview memory persists across "create" calls. It's important that DeleteOverlay() deallocates *all* memory used by the current overlay. Scripts won't necessarily call "delete", so sometimes the user might need to clear all the overlay memory (that's why there's a Delete Overlay item in the Layer menu).

The "create" command should also reset all the theme/camera settings to their defaults. This means lifeviewer.lua will need to restore the current theme/camera settings after the "create" call due to a change in the layer size, but that's trivial to do.

I'd also prefer to see all the cellview-specific code that's in wxrender.cpp (ie. PopulateOverlay etc) moved into wxoverlay.cpp. In fact, I think it's a mistake for DrawOverlay to be changing the overlay data. I think it would be nicer to have a new overlay command ("cellupdate" or "viewupdate"?) that would call PopulateOverlay. Basically it would replace the "dirty" command. It would also allow the script to draw buttons, text, etc on top of the resulting overlay. Do you see any problems with that approach? If not, let me know if you'll make the necessary changes or if you'd prefer I did them.

Is there mouse wheel support yet?

Not yet -- hopefully in the next week or so. I'm struggling with some annoying platform differences at the moment. It looks like we'll probably need a g.os() command that returns a "Mac"/"Windows"/"Linux" string so scripts can handle these differences.

[rowett]

I don't like the way cellview memory persists across "create" calls. It's important that DeleteOverlay() deallocates *all* memory used by the current overlay. Scripts won't necessarily call "delete", so sometimes the user might need to clear all the overlay memory (that's why there's a Delete Overlay item in the Layer menu).

Fixed.
There was a reason it did this which is that the "theme" mode for the cell view keeps historic cell data across generations. If you then use "create" (perhaps on a window resize) to create a new overlay it then would also delete and create a new cell view and lose the historic cell data.
I've fixed this by:

1. always deleting the cell view in "create" as you requested.
2. adding an additional command "resize wd ht" which is used to resize an existing overlay, and keep all additional settings and clips, rather than having to use "create" which throws everything away.

The "create" command should also reset all the theme/camera settings to their defaults. This means lifeviewer.lua will need to restore the current theme/camera settings after the "create" call due to a change in the layer size, but that's trivial to do.

Fixed, but you can now also use "resize" instead.

I'd also prefer to see all the cellview-specific code that's in wxrender.cpp (ie. PopulateOverlay etc) moved into wxoverlay.cpp. In fact, I think it's a mistake for DrawOverlay to be changing the overlay data. I think it would be nicer to have a new overlay command ("cellupdate" or "viewupdate"?) that would call PopulateOverlay. Basically it would replace the "dirty" command. It would also allow the script to draw buttons, text, etc on top of the resulting overlay.

Fixed.
I replaced the "dirty" command with two commands:

1. updatecells - this updates the cell view from the universe and should be used after any change to the universe
2. drawcells - this renders the cells onto the overlay and should be used after updatecells or any camera or theme change

You can then follow "drawcells" with other drawing primitives to draw over the resulting overlay.

lifeviewer.lua was also updated to build 4:

• uses new refactored overlay code and lua commands
• adds hotkey shift and 1 to set zoom to the nearest integer

[rowett]

(And we really must try to fix the bug that causes the edit bar buttons to lose their bitmaps.)

I can now reproduce this:

1. 1. Open Golly
   2. Make the Golly window full screen
   3. Zoom in or out -> icons disappear
   4. Restore the Golly window -> icons appear
   5. Zoom in or out -> icons disappear
   6. Repeat 2-5 as often as you like

[Andrew]

There was a reason it did this which is that the "theme" mode for the cell view keeps historic cell data across generations.

Ah, I see.

... adding an additional command "resize wd ht" which is used to resize an existing overlay, and keep all additional settings and clips, rather than having to use "create" which throws everything away.

Nice solution. A useful command for other scripts (eg. hexgrid.lua).

Thanks for doing all those changes. I've removed the dead_alpha and live_alpha stuff -- they are only non-255 when drawing stacked layers or a paste image so should be 255 in all other cases.

Can you please document the new commands in Help/overlay.html? We might also need a new section called something like "Cell views" with a simple example script, or just an "edit:" link to lifeviewer.lua (like the link to pop-plot.lua at the end).

lifeviewer.lua was also updated to build 4

Minor glitch: If I create a small pattern at scale 1:32 and run lifeviewer.lua, the initial pattern is very small. Shouldn't it be roughly the same size?

[Andrew]

I can now reproduce this:

1. 1. Open Golly
   2. Make the Golly window full screen

I assume you meant maximize the window rather than select View > Full Screen? Anyway, yep, I get the same results, but only on Linux -- I've never seen it happen in the Mac/Win versions. It's probably a bug somewhere in wxGTK but I'll see if I can find a way to avoid it.

[rowett]

Can you please document the new commands in Help/overlay.html?

First tranche of documentation committed. More to do...

If I create a small pattern at scale 1:32 and run lifeviewer.lua, the initial pattern is very small. Shouldn't it be roughly the same size?

Good point, build 5 fixes this by making the initial zoom match Golly's current zoom.

[rowett]

More documentation committed.

[rowett]

Golly + lifeviewer.lua 9:

• fit zoom display and basic autofit
• smooth zoom transitions
• multiple themes
• pan with mouse and zoom with mousewheel
• pattern autofit on load
• theme 1 now default
• patterns render better at zooms < 1x

[rowett]

Golly + lifeviewer.lua 13

• improved layer rendering
• implemented first set of LifeViewer script commands:
  • ANGLE <0.0..359.9>
  • AUTOFIT
  • AUTOSTART
  • DEPTH <0.0..10.0>
  • LAYERS <1..10>
  • LOOP <1..>
  • STOP <1..>
  • THEME <0..9>
  • ZOOM <-16.0..32.0>

[dvgrn]

Wow! I seem to have missed builds 14 through 27. The amount of progress in the last month is really impressive.

-- It's a bit overwhelming, in fact. It's hard to even know where to start...

So I tried copying a sample pattern from the forums into Golly via File > Open Clipboard --

Code: Select all

#C [[ THEME 4 HEIGHT 240 AUTOSTART STEP 8 STOP 531 ]]
#C p531+8N and p557+8N bootstrapped glider loops
x = 214, y = 76, rule = B3/S23
177b2o3b2o$175b3obo2b2o$174bo4bo$47b2o3b2o120bo2b2ob4o$45b3obo2b2o119b
2obobobo2bo$44bo4bo124bobobobo$44bo2b2ob4o120bobob2o$43b2obobobo2bo
121bo$44bobobobo$44bobob2o138b2o$45bo133b2o7bo$179b2o5bobo$58b2o126b2o
$49b2o7bo$49b2o5bobo$56b2o4$176b2o$70b2o105bo$70b2o102b3o$46b2o126bo$
47bo$44b3o$44bo7$56b2o$55bobo$55bo153bo$54b2o135b2o14b5o$9bo25b2o11bo
87bo25b2o11bo16bo13bo5bo$9b3o23b2o10bobo86b3o23b2o10bobo15bobo12b3o2bo
$12bo34bobo2b2o3bo81bo34bobo2b2o3bo3bo4b2o15bob2o$11b2o33b2ob2o2bo2bob
o79b2o33b2ob2o2bo2bobo2b3o16b4o2bo$50bobo3bobo118bobo3bobo5bo10b2o3bo
3b2o$46b2obo2b4obo17b2o96b2obo2b4obo5b2o10b2o4b3o$2ob2o41b2obobo3bo19b
o51b2ob2o41b2obobo3bo27bo$2obo46bobo3bo19b3o48b2obo46bobo3bo26bob2o$3b
o47bobo3bo20bo51bo47bobo3bo24b2ob2o$3b3o4b2o40bo3b2o72b3o4b2o40bo3b2o$
b2o3bo3b2o116b2o3bo3b2o$o2b4o120bo2b4o67b2o$2obo15b2o106b2obo15b2o53bo
$bo2b3o12bobo17b2o2b2o83bo2b3o12bobo17b2o2b2o30b3o$bo5bo13bo3b2o11bobo
2b2o83bo5bo13bo3b2o11bobo2b2o32bo$2b5o14b2o2bo2b2o10bo88b5o14b2o2bo2b
2o10bo$4bo21b2o2bo100bo21b2o2bo$29bo126bo$26b3o124b3o46b2o$25bo126bo
49b2o$25b2o13b2o9b2o21b2o76b2o13b2o$40bo9bobo21b2o91bo$41b3o6bo17b2o
98b3o$43bo5b2o17b2o100bo10b2o$180bobo$180bo$70b2o107b2o$15b2o46b2o5b2o
70b2o$14bobo5b2o39b2o76bobo5b2o$14bo7b2o117bo7b2o$13b2o125b2o2$27bo
126bo$23b2obobo121b2obobo$22bobobobo120bobobobo$19bo2bobobob2o116bo2bo
bobob2o$19b4ob2o2bo117b4ob2o2bo$23bo4bo121bo4bo$19b2o2bob3o118b2o2bob
3o33b2o$19b2o3b2o120b2o3b2o35b2o!

-- and ran into a few minor problems. (EDITed out complaint about HEIGHT command, which works now.) The STOP keyword didn't work, apparently because 531 isn't a multiple of the step. It works if I change it to STOP 536.

Then as soon as I dismiss the "STOP reached, Play to continue" message, LifeViewer advances the pattern one more STEP, so I'm not really looking at what I STOPped to see. And when I try to "Play to continue" (Enter key) I get the same message popping up again and again, with no further evolution until I sneak past the STOP point with the space bar.

Any plans to implement B-for-backtracking in Lua LifeViewer (maybe mapped to Z in this case)?

[rowett]

So I tried copying a sample pattern from the forums into Golly via File > Open Clipboard --

Yes it's still very much a work-in-progress. I'm away this week at a conference so little chance for more work. The following week I have a week off work, and I've finished my recent stint with the new overlay, so hoping to make some significant progress on lifeviewer.lua.

Any plans to implement B-for-backtracking in Lua LifeViewer (maybe mapped to Z in this case)?

Possibly though it's more of a pain in Golly than I thought it would be. Stay tuned

[dvgrn]

Any plans to implement B-for-backtracking in Lua LifeViewer (maybe mapped to Z in this case)?

Possibly though it's more of a pain in Golly than I thought it would be. Stay tuned

Staying tuned. No updates to lifeviewer.lua in the golly codebase since November 12th -- but I see the Breakout script just saw a new checkin, so I guess that's a good sign...!

Just tried out the "How Your Username Evolves" LifeViewer animation in lifeviewer.lua, and discovered by experiment how many other script commands (like the all-important "T") aren't supported yet.

That experiment had to do with exporting lifeviewer.lua frames to make animated gifs or videos. Here's the quick trial run I did this morning for an enthusiastic but non-script-savvy artist with the handle 'larrylazardo'.

In that post I tried not to promise anything about what lifeviewer.lua might eventually support. Is it a goal for Golly 2.9/3.0 to get waypoint animations running more or less the same in LifeViewer and in lifeviewer.lua? Makes me think that LifeViewer script commands could be added to quite a few of the smaller patterns in Golly's collection, as a way to label various mechanisms or show off key reactions.

[rowett]

No updates to lifeviewer.lua in the golly codebase since November 12th -- but I see the Breakout script just saw a new checkin, so I guess that's a good sign...!

Yes I'm using breakout.lua to learn how to make lua and the overlay work quickly together, mainly because breakout is a lot simpler than LifeViewer, and the results are fun The recent breakout.lua builds, for example, have finally got text rendering flying...

Just tried out the "How Your Username Evolves" LifeViewer animation in lifeviewer.lua, and discovered by experiment how many other script commands (like the all-important "T") aren't supported yet.

If you look in the LifeViewer help (press key "h" while running lifeviewer.lua) you'll see a table of the currently supported script commands.

That experiment had to do with exporting lifeviewer.lua frames to make animated gifs or videos. Here's the quick trial run I did this morning for an enthusiastic but non-script-savvy artist with the handle 'larrylazardo'.

Looks interesting. Great use of the ov("save") command.

Is it a goal for Golly 2.9/3.0 to get waypoint animations running more or less the same in LifeViewer and in lifeviewer.lua?

Yes that's the goal, though it depends on the actual release date. There's still a lot to do.

Makes me think that LifeViewer script commands could be added to quite a few of the smaller patterns in Golly's collection, as a way to label various mechanisms or show off key reactions.

Yes, that would be fantastic. Andrew also mentioned that you and I should choose some LifeViewer scripts and add them to Golly (perhaps in a new Patterns folder) to show off the capabilities.

[dvgrn]

Makes me think that LifeViewer script commands could be added to quite a few of the smaller patterns in Golly's collection, as a way to label various mechanisms or show off key reactions.

Yes, that would be fantastic. Andrew also mentioned that you and I should choose some LifeViewer scripts and add them to Golly (perhaps in a new Patterns folder) to show off the capabilities.

Well, I haven't started that script-command-adding project yet. Have been doing lots of historical research lately about patterns that belong in the Very Large Patterns archive, instead. But I might get started on this any time now...!

A post asking for, basically, lifeviewer.lua came in yesterday. While I'm thinking of it, there's an example script snippet at the bottom of my reply that doesn't work very well at all -- in lifeviewer.lua, that is -- works fine in LifeViewer proper. Seems to be the ZOOM part (not counting that STOP isn't implemented).

Code: Select all

x = 323, y = 327, rule = B3/S23
79b2o$79b2o7$87b2o$87b2o7$74b2o$73bo2bo13b2o$74b2o14bo2bo$90bo3bo$91b
3o$56bo$56b2o$55bobo30bobo$82b2o3bo3bo$81bo2bo7b2o$82b2o3bo5bo$87bo6bo
$88b2o4bo$94bo$90bo3bo$90bo3bo$91bobo$91b3o$73bobo$66b2o3b2obo$66b5ob
2o3b2o$66bob2obobo3b2o$67b2o4bob2o2bo$40b2o24b3o5bobobo$35bo4b2o24b3o
7bobo40b2o$33bo4bo21b2o57b2o$32bo5bo20b2o$33bo4bo21b2o$35bo25b3o$62bob
o$62bo2bo$65bo$63bobo61b2o$63b3o61b2o5$62b2o$61bo2bo$61b2o51b2o$62b5o
46bo2bo13b2o$66b2o46b2o14bo2bo$23bo39b2o2b2o61bo3bo$21b2o40bo2b2o63b3o
$22b2o40b3o29bo$65bo30b2o$42bo52bobo30bobo$41b3o78b2o3bo3bo$41bob2o10b
2o64bo2bo7b2o$44b3o7bob2o64b2o3bo5bo$44bo3b2o4bo2bob2o66bo6bo$45bo3bo
5bobobobo66b2o4bo$46b4o7bo3b2o71bo$35b3ob2o16b2ob2o68bo3bo$35b2ob3o17b
3o69bo3bo$36b5o18bo71bobo$36b2o93b3o$36bo76bobo$35bobo68b2o3b2obo$35b
2o69b5ob2o3b2o$17bo16bob3o67bob2obobo3b2o$16bobo16bo3bo67b2o4bob2o2bo$
16bobo15bo3bo41b2o24b3o5bobobo$17bo20b3o34bo4b2o24b3o7bobo$36b2o35bo4b
o21b2o$36b2ob2o31bo5bo20b2o$2o36bo34bo4bo21b2o$2o73bo25b3o$25bo76bobo$
24bobo75bo2bo$24bobo78bo$25bo77bobo$103b3o2$8b2o14bob2o$8b2o13bo4bo$
28bo$17b3o3bo6b2o70b2o$17bo2bo3bo7b2o67bo2bo$20bo4bo7bo67b2o$18bobo4b
2o5b2o68b5o$19bo7b5o74b2o$63bo39b2o2b2o$61b2o40bo2b2o$62b2o40b3o$105bo
$82bo$81b3o$81bob2o10b2o$84b3o7bob2o$84bo3b2o4bo2bob2o$85bo3bo5bobobob
o$86b4o7bo3b2o$75b3ob2o16b2ob2o$75b2ob3o17b3o$76b5o18bo$76b2o$76bo$75b
obo$75b2o$57bo16bob3o$56bobo16bo3bo$56bobo15bo3bo$57bo20b3o$76b2o$76b
2ob2o$40b2o36bo$40b2o$65bo$64bobo$64bobo$65bo3$48b2o14bob2o$48b2o13bo
4bo$68bo$57b3o3bo6b2o$57bo2bo3bo7b2o$60bo4bo7bo$58bobo4b2o5b2o$59bo7b
5o48$292b2o$292bobo$294bo4b2o$290b4ob2o2bo2bo$290bo2bobobobob2o$293bob
obobo$294b2obobo$298bo2$284b2o$285bo7b2o$285bobo5b2o$286b2o25bo$311b3o
$310bo$310b2o$285bo$284bobo$285bo32b2o$296b2o21bo$296bo22bob2o$297b3o
11b2o4b3o2bo$299bo11b2o3bo3b2o$316b4o$302b2o15bo$301bobo12b3o$301bo13b
o$300b2o14b5o$320bo$318bo$318b2o7$305bo$304bobo$305bo19$309b2o$309bo$
310b3o$312bo2$289b2o$289bo$290b3o$292bo15$276b2o$276bobo$278bo$278b2o
2$187bo$186bobo$187bo6$267b2o$267bo$268b3o$270bo5$195bo7bo$195b3o4bobo
$198bo4bo$197b2o2$249b2o$189b2o58bobo$189bo61bo$186b2obo61b2o$186bo2b
3o4b2o$187b2o3bo3b2o$189b4o$189bo15b2o$190b3o12bobo$193bo13bo$188b5o
14b2o$188bo24bo$190bo20b3o$189b2o19bo$210b2o$224bo$223bobo$224bo3$244b
2o$200b2o42bobo$199bobo5b2o37bo$199bo7b2o37b2o$198b2o2$212bo$208b2obob
o$207bobobobo$204bo2bobobobob2o$204b4ob2o2bo2bo$208bo4b2o$206bobo$206b
2o!
#C [[ X -175 Y -175 ZOOM 2 STEP 9 AUTOSTART TRACKBOX 1/4 1/4 1/12 1/12 STOP 2800 ]]

I originally wanted to make a shrinking TRACKBOX with a STOP in this case, by the way. Maybe it would be okay to allow W greater than E or N greater than S, after all, and just stop tracking if the zoom level gets mathematically impossible? (Or just start tracking the new growing box, after the inversion point?)

Happy New Year, by the way!

[rowett]

A post asking for, basically, lifeviewer.lua came in yesterday. While I'm thinking of it, there's an example script snippet at the bottom of my reply that doesn't work very well at all -- in lifeviewer.lua, that is -- works fine in LifeViewer proper. Seems to be the ZOOM part (not counting that STOP isn't implemented).

Yes there's still a lot of work to do on lifeviewer.lua. Lots doesn't work properly yet or just plain isn't implemented so you'll continue to see major discrepancies.

I've also stalled on the LifeViewer backlog, I still need to backport the non-totalistic B0 support into LifeViewer that I added to Golly a while back (already had one forum request).
However one new item that's slowly making progress is the ability to play a sound clip at a waypoint. Narrated waypoint animations, anyone?

Unfortunately I'm swamped at work at the moment and that's unlikely to change for the next month or so.
Just back from a week in the US and about to start a 21 day tour of the Asia Pacific region...

Happy New Year, by the way!

Yes, you too!

[dvgrn]

Another thought to record before I forget it:

The interest in Adam's stable megacells has mutated into a minor interest in asymmetric non-totalistic rules -- and LifeViewer is currently the only simulator within reach with a standard syntax for specifying such things. With Golly you still have to write a custom rule table.

I thought a little more about the [[ MAP <decimal-value> ]] syntax, and it seems as if you'd need an awful lot of places after the decimal point to specify one specific target rule out of 2^512 Or a really big fraction, of course (test page). LifeViewer seems to be doing something slightly odd with that fraction -- it's not producing anything simple like all zeroes, but it's not coming up with the correct map either.

Not surprisingly, I see MAP isn't one of lifeviewer.lua's known script commands yet. Think it might make it for Golly 2.9, or is that too tall an order?

[rowett]

I thought a little more about the [[ MAP <decimal-value> ]] syntax

The MAP <decimal-value> syntax allows you to specify a random threshold to create a random map. The only way to create a fixed map is with base64 encoding. See here for more details.

The bit order for a fixed map is explained here.

Not surprisingly, I see MAP isn't one of lifeviewer.lua's known script commands yet. Think it might make it for Golly 2.9, or is that too tall an order?

It's possible. Depends on when Golly 2.9 is released.

[dvgrn]

I thought a little more about the [[ MAP <decimal-value> ]] syntax

The MAP <decimal-value> syntax allows you to specify a random threshold to create a random map. The only way to create a fixed map is with base64 encoding. See here for more details.

Ah, right. Sorry about the temporary loss of understanding there. Have repaired my description of MAP syntax (I think).

I also added a Lua script to generate a base-64 MAP string based on the rule currently set in Golly. It produces the same string for Life as the one you gave. My guess that you're numbering cells like this --

0 1 2
3 4 5
6 7 8

-- seems to be right, since this broken-symmetry Life-rule-plus-one-bit, seems to be broken in the way I expected:

Code: Select all

x = 17, y = 17, rule = B3/S23
6bo2bo$7b3o5$16bo$2o13bo$bo13bo$bo13b2o$o5$7b3o$7bo2bo!
#C [[ MAP BRYXfhZofugWaH7oaIDogBZofuhogOiAaIDogIAAgAAWaH7oaIDogGiA6ICAAIAAaIDogIAAgACAAIAAAAAAAA ]]

[rowett]

My guess that you're numbering cells like this --

0 1 2
3 4 5
6 7 8

Yes as documented here.

For Golly support I can do one of two things:
1) Build MAP support into lifeviewer.lua. For a user to run a pattern in Golly they'll have to load the pattern and then start lifeviewer.lua. LifeViewer will then decode the map and update the rule in Golly to use the map (and probably switch Golly to QuickLife or another 2-state algo).
2) Build native support into Golly for MAP rules. Perhaps enhance the parser to look for "rule = MAP <code>" strings. I could then make "rule = MAP <code>" work in LifeViewer too - promote MAP to a first class rule family.

Before I do either option are "we" happy with the MAP format. If it's going to escape into the wild it might be worth some opinions.

Also note MAP supports alternate generation rules. MAP defines the even generation rule and MAPODD defines the odd generation rule. If there's no MAPODD defined then MAP is used for all generations.

[dvgrn]

Yes as documented here.

Aha - I went back looking for a post like that, but didn't look far enough.

For Golly support I can do one of two things:
1) Build MAP support into lifeviewer.lua. For a user to run a pattern in Golly they'll have to load the pattern and then start lifeviewer.lua. LifeViewer will then decode the map and update the rule in Golly to use the map (and probably switch Golly to QuickLife or another 2-state algo).
2) Build native support into Golly for MAP rules. Perhaps enhance the parser to look for "rule = MAP <code>" strings. I could then make "rule = MAP <code>" work in LifeViewer too - promote MAP to a first class rule family.

Before I do either option are "we" happy with the MAP format. If it's going to escape into the wild it might be worth some opinions.

I like option #2 better -- seems like there's an opportunity to define a standard syntax for non-totalistic rules. Doesn't seem as if there are any serious competitors. Golly's current alternative is a custom rule table, with no hope of a canonical form. I just checked the old MCell file formats page, and there don't seem to be any likely candidates there.

When I was reading the LifeViewer help on MAP syntax, I read it wrong in two ways: first I thought it was allowable to use the non-base64-encoded string of 512 0's and 1's after MAP. Then for a while I thought that the decimal value was the fraction [binary value]/2^512. The second one doesn't make any sense, but maybe the first one could be an option? It's a good bit easier (pun probably intended) to understand and to edit, in my experience.

Another slightly more natural alternative would be encoding the binary string in hex -- not sure if 128 characters vs. 86 will really make a difference to anyone, and this option would avoid adding a case-sensitive native rule type.

With Calcyman's bit numbering for the megacell, a hex encoding would mean the first 64 characters would encode what happens to an OFF cell, and the last 64 would describe what happens to an ON cell. That was kind of nice...

-- But, well, unless someone else really has a strong opinion, on balance I think we should stick with the base64 encoding, just as it is now in LifeViewer. A working example is nine-tenths of the battle.

Also note MAP supports alternate generation rules. MAP defines the even generation rule and MAPODD defines the odd generation rule. If there's no MAPODD defined then MAP is used for all generations.

To me that seems more like a niche experimental rule type, that could safely be left for lifeviewer.lua (or just LifeViewer) to support. I can't think of any reason why it would be a bad idea to include native support for it in Golly, though...?

We don't currently have any rule types that overflow onto two or more header lines. Current rules also generally fit into the arbitrary old 70-something-character width limit, though, so we have to stretch part of the old standards anyway. (MCell did that too, as I recall, for rule-table rules like HIstoricalLife.)