What I'd like to see in Golly

[Batmanifestdestiny]

it would be nice if the example patterns that aren't Life were organized by CA, not by who made the CA. Also, some more WireWorld patterns would be nice (I could add a couple).

[Axaj]

it would be nice if the example patterns that aren't Life were organized by CA, not by who made the CA. Also, some more WireWorld patterns would be nice (I could add a couple).

The name of many cellular automata is the name of the creator.

[p46beth]

One thing that would be nice is if for rules with more than 2 states, we had more options for "random fill" (e.g. 30% cells in state 2, 60% in state 1, 10% off.) Right now we can just pick the chance a cell will be on.

[ssaamm]

Oh yeah, one thing I'm confused about is, can't you already simulate a hexagonal neighborhood in a Moore neighborhood?
Like so:

Code: Select all

.....___
.___/...\___
/...\_1_/...\
\_6_/...\_2_/
/...\___/...\
\_5_/...\_3_/
....\_4_/

._______
|...|...|
|_1_|_2_|___
|...|...|...|
|_6_|___|_3_|
....|...|...|
....|_5_|_4_|

Is it just a hexagonal grid that you want?

[Axaj]

Oh yeah, one thing I'm confused about is, can't you already simulate a hexagonal neighborhood in a Moore neighborhood?
Like so:

Code: Select all

.....___
.___/...\___
/...\_1_/...\
\_6_/...\_2_/
/...\___/...\
\_5_/...\_3_/
....\_4_/

._______
|...|...|
|_1_|_2_|___
|...|...|...|
|_6_|___|_3_|
....|...|...|
....|_5_|_4_|

Is it just a hexagonal grid that you want?

Yes, exactly. That's why it's the lowest priority.

[calcyman]

Oh yeah, one thing I'm confused about is, can't you already simulate a hexagonal neighborhood in a Moore neighborhood?

That's old news (possibly known even to Gauss), and has been mentioned in a recent blog post:

http://ferkeltongs.livejournal.com/31455.html

[p46beth]

Another thing: in addition to hexagonal grids (which are already in golly) what about triangular grids?

[Andrew]

Another thing: in addition to hexagonal grids (which are already in golly) what about triangular grids?

Triangular grids can also be emulated quite easily -- see http://code.google.com/p/ruletablerepos ... ighborhood.

There's a lot of interesting stuff on that site. You can download the .zip files directly from Golly by going to Help > Online Archives > Rule Table Repository.

[Ntsimp]

I'd like to see support for (various kinds of) symmetry: symmetric random fills, symmetric drawing modes, etc.

[Andrew]

-Support for Torus or Klein Bottle

I'm currently working on this at the moment. You'll be able to specify a bounded grid by appending a suitable suffix to any rule. Here are some examples showing the various topologies Golly will support:

Code: Select all

:P200,100    -- bounded plane of width 200 and height 100
:T200,100    -- simple torus
:T0,100      -- tube of infinite width and height 100
:T30+4,50    -- torus with a shift of +4 on the horizontal edges
:K200*,100   -- Klein bottle with twist on horizontal edges
:C200,100    -- cross-surface (both horizontal and vertical edges are twisted)

The syntax might change slightly, but will look something like the above. I should have a beta version of 2.2 ready for people to try in August some time.

-Multiple rows of states for many-state rules

Not exactly sure what you mean by this. Do you want the "all states" info to wrap over multiple lines if the window is too narrow to show them all? If so I don't really like that idea -- complicated to implement, would look ugly, and take up too much screen real estate. It's easy enough to scroll the states using the edit bar's scroll bar.

[Andrew]

Noticed a glitch: In QuickLife and HashLife (and maybe other modes, I haven't tried), the paste selection (in the red frame before specifying a location) does not flip colors if the rest of the board is flipped in color.

Fixed in version 2.2. Thanks for the report.

[Andrew]

It would also be nice if it didn't show a million consecutive message boxes when you try to load an invalid ruletable file. Put all the errors in one box. And don't irreversibly erase the pattern when that happens.

I can't reproduce either of those problems. Please tell us which version of Golly you're using, which platform, and give an example of a bad .table file that causes those problems.

[Andrew]

I think it would be cool to have a Census function, like WinLife32 has.

I'm unlikely to build such a function into Golly, mainly because it's possible to write a Python/Perl script to do it. I'd love to see a script that would examine the current pattern (or selection, if present) and list all the known objects in a table in the help window (by creating and opening a temporary .html file). Nice also if the script could (optionally?) delete all the known objects. The database of known objects could be stored in the glife module somewhere, possibly by expanding the existing base.py file. Or it might be nicer if the database could be downloaded from some website, or maybe integrated with Nathaniel's soup search database. Lots of interesting possibilities.

[Andrew]

it would be nice if the example patterns that aren't Life were organized by CA, not by who made the CA.

There are tentative plans to reorganize the Patterns folder in a less Life-centric fashion. Probably won't happen in 2.2 -- more likely in the version after that.

Also, some more WireWorld patterns would be nice (I could add a couple).

I've no objections to a few more such patterns, but our aim is to be representative rather than exhaustive. As disk space gets cheaper and the net gets faster there will be less point in worrying about the size of the Golly distribution.

[Andrew]

One thing that would be nice is if for rules with more than 2 states, we had more options for "random fill" (e.g. 30% cells in state 2, 60% in state 1, 10% off.) Right now we can just pick the chance a cell will be on.

It would be pretty easy to write a Python script to do that. If someone does I'll be happy to add it to the Golly Scripts Database.

[Andrew]

I'd like to see support for (various kinds of) symmetry: symmetric random fills, symmetric drawing modes, etc.

Not sure what you mean, but I'm reluctant to add new functions in Golly if they can be achieved by writing a Perl/Python script.

[Axaj]

-Multiple rows of states for many-state rules

Not exactly sure what you mean by this. Do you want the "all states" info to wrap over multiple lines if the window is too narrow to show them all? If so I don't really like that idea -- complicated to implement, would look ugly, and take up too much screen real estate. It's easy enough to scroll the states using the edit bar's scroll bar.

Ah, I never noticed that scroll bar before. But yes, that is what I was talking about.

[winlife32]

I think it would be cool to have a Census function, like WinLife32 has

If anyone wants to undertake writing a script to do this, I'd be happy to make winlife32's source code available. I just don't have the time do it myself these days.

[Nathaniel]

If anyone wants to undertake writing a script to do this, I'd be happy to make winlife32's source code available. I just don't have the time do it myself these days.

I would love to update the Soup search to use your census script if you would be willing to share -- the census script that it uses is quite primitive and requires lots of after-the-fact cleaning up of the database, which I don't have time for so much anymore.

Edit: With that said, if there are any plans to build this into Golly itself, that would of course be preferable for speed reasons, though I then would likely not be the person for the job since I don't know C++ at all

[Lewis]

Doesn't Winlife32 have difficulty with objects made of seperate islands, unless they are already part of the pattern library? Or will the script be altered to fix this when it is added to Golly or the Soup Searcher?

[winlife32]

Doesn't Winlife32 have difficulty with objects made of seperate islands

Indeed it does. It would be possible, given an unstable island, to try it in combination with other nearby islands and see if that makes a stable or oscillating object, but I never got round to trying anything like that. (I wrote all this about 15 years ago). I always expected a small amount of manual involvement, though, in particular to examine apparently unstable new objects and figure out what is going on with them. If anyone wants to try and do more, that would be excellent.

I'm travelling right now and don't have access to the sources. I'll zip them up and put them on a server somewhere when I get a chance, but it'll probably be a week or two.

One thing to note... the census code depends entirely on the "signature" mechanism which is briefly described on the web page. That is computed automatically in Winlife32 by the grow algorithm. In the context of Golly, that will require additional code. It's not especially complicated but it will need to be written.

John

[p46beth]

One thing I'd like to see is the ability to turn off hashing for non-lifelike rules. For quite awhile I've been running highly chaotic patterns in bounded universes, and found that it is much easier for rules like b2s2, where I can switch to quick life, than for multi-state rules, where I am stuck in rule table/tree.

Unfortunately, this might require new algorithms altogether...

[Tropylium]

If there's one thing I miss from the old LifeLab, it's a quick "shift selection" command. Yes, there's a script for this, but really this is so basic that I'd love to have single-key "shift one cell N/E/W/S" commands available.

[Andrew]

Unfortunately, this might require new algorithms altogether...

Not necessarily new algorithms, but certainly a lot of new code. Golly's current support for bounded grids is just a quick hack (all done in the GUI code). I've always seen this as just a temporary solution until someone implements "native" support for bounded grids in one or more algos. Even if this was just for a simple torus (the most useful case) it would boost performance enormously. So, hopefully one day...

[Andrew]

If there's one thing I miss from the old LifeLab, it's a quick "shift selection" command. Yes, there's a script for this, but really this is so basic that I'd love to have single-key "shift one cell N/E/W/S" commands available.

Below is a simplified version of shift.py that moves the selection north. Save it as shift-north.py or whatever. Make the obvious changes and save them in shift-east.py, etc. Go to Prefs > Keyboard, type the key you want to use for shifting north, then use the Choose File button to select shift-north.py. Repeat for the other 3 scripts.

Code: Select all

# Shift current selection north by one cell.
# Author: Andrew Trevorrow (andrew@trevorrow.com), Oct 2011.

import golly as g
from glife import inside

selrect = g.getselrect()
if len(selrect) == 0: g.exit("There is no selection.")

# move 1 cell north (1,0 is east, 0,1 is south, -1,0 is west)
x = 0
y = -1

# set mode (other modes are "copy" or "xor")
mode = "or"

# abort shift if the new selection would be outside a bounded grid
if g.getwidth() > 0:
   gridl = -int(g.getwidth()/2)
   gridr = gridl + g.getwidth() - 1
   newl = selrect[0] + x
   newr = newl + selrect[2] - 1
   if newl < gridl or newr > gridr:
      g.exit("New selection would be outside grid.")
if g.getheight() > 0:
   gridt = -int(g.getheight()/2)
   gridb = gridt + g.getheight() - 1
   newt = selrect[1] + y
   newb = newt + selrect[3] - 1
   if newt < gridt or newb > gridb:
      g.exit("New selection would be outside grid.")

# do the shift by cutting the current selection and pasting it into
# the new position without changing the current clipboard pattern
selcells = g.getcells(selrect)
g.clear(inside)
selrect[0] += x
selrect[1] += y
g.select(selrect)
if mode == "copy":
   g.clear(inside)
g.putcells(selcells, x, y, 1, 0, 0, 1, mode)

if not g.visrect(selrect): g.fitsel()