Golly 3.2

[dvgrn]

Lua's gp.getedges doesn't seem to work properly. Using this:

Code: Select all

g.show(gp.getedges({0, 0, 10, 10}))

Just returns '0'. This is the 32-bit version on Windows 10.

EDIT: In particular, it just returns x. I'm assuming it tries to return a table but can't for some reason.

It's working properly, but when Lua works properly it does fairly strange things sometimes. See #8.1 in Lua Gotchas.

All the return values are there, but if you don't ask for all four of them, Lua cheerfully throws the last three values away and doesn't tell you that it's doing it:

Code: Select all

local g = golly()
local gp = require "gplus"

local left,top,right,bottom = gp.getedges({1, 2, 100, 200})
g.show(left..", "..top..", "..right..", "..bottom)

[muzik]

Is support for the Neumann Binary rulespace supported by MCell planned?

[dvgrn]

Is support for the Neumann Binary rulespace supported by MCell planned?

Not that I know of. It's basically just an uncompressed MAP-type encoding, limited to the von Neumann neighborhood but allowing up to four states instead of just two. Why should it be supported any more than it is already?

For two-state rules there's an easy equivalence to MAP rules.

For three- or four-state rules there's a very simple way to convert the Neumann Binary string to a rule table.

A good first step to support the rulespace in Golly would be to write a Lua script that reads MCell Neumann Binary pattern text from the clipboard (or a file chosen by the user, if you prefer), creates the necessary rule table, and then displays the pattern. Such a script could be mapped to a hotkey, and then you could open these files with one keystroke.

Not much known demand --
The question is, where are these hypothetical Neumann Binary patterns going to come from? Are there any existing collections besides the thirty patterns in the MCell 4.20 pattern collection? (Though Typhoon and Galaxy look like fun, I have to admit.)

For two-state rules it wouldn't make a lot of sense to create new patterns in this Neumann Binary format, when you could just as easily get native Golly support by figuring out the equivalent MAP rule.

-- but there's no native equivalent for multistate Neumann Binary
For multistate Neumann Binary rules... well, it would be nice to be able to extend Golly to support this and lots of other rulespaces -- without having to add new C++ code for each rulespace, and also without having to use a rule generator script to litter your hard drive with a new rule table for every odd corner of one of these "script-supported" rulespaces that you might test out.

To avoid that, some new functionality would have to be added to Golly somewhat along the lines of M.I. Wright's very nice setup for supporting new rule families on Discord. The advantage would be that once it was implemented, instead of helplessly asking whether such-and-such rulespace might be supported someday, people could just go ahead and contribute the necessary Lua script to support the rulespace.

One possible implementation...
Maybe a Scripts folder could be added inside the Rules folder. If a pattern header said "rule = Script:NeumannBinary_xyz", for example, then Golly could check the Scripts subfolder for a script called NeumannBinary.lua. If it finds it, Golly would run that script and feed it the "xyz" part of the rule name to create a temporary rule table. Probably it wouldn't be necessary to save these auto-generated rule tables permanently anywhere -- just regenerate them when they're needed again.

... probably not written by me
At least based on what I've chosen to spend time on in the past decade, I'm very unlikely to successfully contribute this kind of thing to Golly. So if the above spec doesn't catch someone else's imagination, it's probably not going to escape from its current vaporware state.

[muzik]

There's quite a few things I'd like to see in a future version of Golly:

Higher-Range Outer-Totalistic rules: An obvious extension of the outer-totalistic rulespace to larger neighbourhoods. Currently supported by lifelib and lifeviewer. Would support all the neighbourhoods and ranges LtL does.

Code: Select all

x = 1, y = 1, rule = R2,C2,S1,3,5,7,9,11,13,15,17,19,21,23,B1,3,5,7,9,11,13,15,17,19,21,23
o!

Isotropic non-totalistic hexagonal notation: Currently Golly does support these rules, but only in the form of MAP strings. This notation (supported by lifelib) would make them a lot easier to understand and adjust.
http://www.conwaylife.com/wiki/Hexagonal_neighbourhood

Default colour scheme consistency: Currentky, Golly colours Larger than Life rules yellow, which then fade to red when more than two states are present. However, cells are still yellow even when there are only two cell states being used. It would be better if they were white in such a case, to match the range-1 2-state rules. Range-1 Generations also uses a different colour scheme from LtL Generations; it'd look a lot better if the range-1 generations was changed to use the LtL Generations theme by default, except in the case where only two states are specified, in which case the alive cells would be white.

lifelib-supported rulespaces: Currently, lifelib supports deficient rules and Extended Generations natively. It'd be useful to have these be integrated into Golly be default to ease their exploration further, or to at least include a script for their generation.

Range-2 von Neumann isotropic non-totalistic rulespace: I find this rulespace to be quite exciting and to hold quite a lot of potential. At the time of writing, no definitive notation for these rules has been devised; three have been proposed, however. There are 618 different transitions, compared to the millions required for raneg-2 Moore, so this should be easier to implement than that.

Chiral rules: A generalisation of the isotropic non-totalistic rulespace where patterns function the same upon rotation, but not necessarily for reflection. See here for the notation.

More rule names: There's quite a lot of them. (If added, it might be useful to make the selection box containing said rule names to only display the ones which run in the selected algorithm.)

Remove toruses: Some of the supplied LtL patterns are still run on a toroidal bounded grid. It might be useful to remove said bounding from the pattern files by default, since it can be problematic in some cases (e.g. bugs crashing into each other in bug collection).

Cylinder and Möbius strip bounded grids: Acts like an edge of a plane on two opposite sides, and connected on the two other sides (with a twist on the latter).