The accessibility problem

[LuveelVoom]

A common complaint of lifenthusasts is the lack of people exploring cellular automata. I think these people are incorrect: there are plenty of people exploring and interested in CA. The thing is, 90% of these people never go further than the “doodle lines in lifeviewer/golly” stage. Why? Because current life tools are very, very obtuse to the general user.

This issue gets worse the more sophisticated the tool is, meaning that it’s very hard to have new people start making major discoveries. Sure, almost anyone can boot up golly and run a few rules, but I bet half of all golly users don’t realize that scripts even exist, nor what to do with them. I had to ask on the discord just to figure out that the identify script is named Oscar. I’m sure it means something, but what user sees “oscar.py” and thinks “oh, that’s how I figure out oscillator periods!” This is not to mention that the controls for golly, at least to me, feel very clunky. I could use lifeviewer, which has better controls, but is much much weaker.

Now, what about searches? Almost every tool requires command line use to install. Virtually none of them have guis. Imagine you are a lifenthusiast who wants to find a c/8o. You have 3 viable options: qfind, ikpx2, and LLSSS. None of them have guis. There is very little information on which is the best for the task. Good luck trying to figure out how to run any of them with no prior computer experience; it will probably take at least 20 minutes of fumbling on the discord (which many lifenthusiasts never even join, much less the forums) and using the tutorials (which are not linked in convenient places!) and many will just give up.

Many, many other things share this problem. The ruletable format is unintuitive (it’s not bad per se, but it just… isn’t really built to be learnt.) Beyond simple viewing tools, guis are pretty much absent. Strange terminology clouds understanding (what’s 0e0p mean? logical width??). I feel this is the main reason why there aren’t more people in the higher levels of CA: too many get stuck just looking at pretty patterns because doing anything more interesting is too hard.

Hopefully you understand my position here. I am very willing to take comments or corrections, please reply with your thoughts.

[confocaloid]

In principle, it's true that many existing tools (and discussions) are unintuitive or inconvenient in some way.
However, it's also true that many existing software tools are powerful. One needs to keep in mind also that it's a huge amount of work, done by enthusiasts, and done for enthusiasts.

Command line interface is less "user friendly", but at the same time much more powerful.
Having a graphical user interface may even become a disadvantage, if there's no choice.
You might want to run a lot of searches with specific parameters as a batch, but that's only possible if you can configure the searches and let them run automatically one after another without any further interactions.
If the user interface forces you to repeatedly click the buttons and press the keys all the time, that very quickly becomes inconvenient once you go beyond very basic stuff.

The ruletable format might be non-obvious at first, but it's quite convenient, flexible and powerful once you grasp the underlying idea (a ruletable is essentially a chain of "if-then-elif-then-else" rules defining a CA). Certainly ruletables are much more user-friendly than ruletrees. (Ruletrees are supposed to be autogenerated, and aren't designed to be read/written manually. Ruletables are readable and writable by humans.)

I agree regarding the local terminology often being confusing, but, well, that was probably already known.

[...]
Many, many other things share this problem. The ruletable format is unintuitive (it’s not bad per se, but it just… isn’t really built to be learnt.) Beyond simple viewing tools, guis are pretty much absent. Strange terminology clouds understanding (what’s 0e0p mean? logical width??). I feel this is the main reason why there aren’t more people in the higher levels of CA: too many get stuck just looking at pretty patterns because doing anything more interesting is too hard.

Hopefully you understand my position here. I am very willing to take comments or corrections, please reply with your thoughts.

[Sokwe]

Almost every tool requires command line use to install. Virtually none of them have guis. Imagine you are a lifenthusiast who wants to find a c/8o. You have 3 viable options: qfind, ikpx2, and LLSSS. None of them have guis.

I don't see how qfind, or ikpx2 could even benefit from a GUI, and writing a GUI for LLSSS would probably be an unreasonable amount of work. I think we're better off making more tutorials for compiling and running these programs, and making those tutorials easier to find. I've begun writing a tutorial for LLSSS specifically to make it more accessible.

One of the most difficult things is explaining how to compile these programs. Since qfind is so simple, I've been able to provide a pre-compiled Windows binary of the latest versions, but pre-compilation may mean that the program is not optimized for the end-user's machine. Unfortunately, I have no experience with macOS, and as I understand it, you need to compile qfind under Homebrew, because the C compiler that comes with macOS doesn't support OpenMP (I'm not sure if this has changed in the years since I last discussed this), which qfind relies on for multi-threading. I would love to find a way to pre-compile for macOS without access to an Apple computer, if anyone has suggestions in that regard.

Pre-compiling doesn't work with ikpx2, because it optimizes the program during compilation based on the given rule. All pre-compiled ikpx2 binaries would therefore only work for a specific rule.

I don't know about distributing pre-compiled LLSSS binaries, except that they would be very large, and I'm not sure if anything needs to be done to make the binary portable.

I still don't know the best way to make these programs accessible, so I'd like to hear more suggestions.

[LuveelVoom]

Almost every tool requires command line use to install. Virtually none of them have guis. Imagine you are a lifenthusiast who wants to find a c/8o. You have 3 viable options: qfind, ikpx2, and LLSSS. None of them have guis.

{...}
One of the most difficult things is explaining how to compile these programs. Since qfind is so simple, I've been able to provide a pre-compiled Windows binary of the latest versions, but pre-compilation may mean that the program is not optimized for the end-users machine. {...}
Pre-compiling doesn't work with ikpx2, because it optimizes the program during compilation based on the given rule. All pre-compiled ikpx2 binaries would therefore only work for a specific rule.
I don't know about distributing pre-compiled LLSSS binaries, except that they would be very large, and I'm not sure if anything needs to be done to make the binary portable.
{...}

Ah, I almost forgot about the compiling issue (which made me unable to install LLSSS!) I would not doubt that many people who are interested in life don't even know what compiling is, which would make installing these programs without a tutorial very difficult.
For ikpx2, have you considered distributing a pre-compiled file for B3/S23? This would allow a lot more people to search for life specifically. (you could also host a remote web interface but that has many problems)

[Sokwe]

For ikpx2, have you considered distributing a pre-compiled file for B3/S23?

It's currently very difficult to find anything new in Life, even with these powerful programs. I think it's good - almost essential - to be able to search with them in other CA that aren't so well explored. While I could pre-compile ikpx2 for B3/S23 on Windows, I specifically choose not to, and instead encourage people to learn how to compile the code themselves. At least on Windows, you can do this fairly easily under WSL, and this is my suggested method for Windows. However, I also wrote a tutorial explaining how to compile ikpx2 on Windows without WSL or Cygwin, for those rare cases where someone would want to do that.

I kind of expect people using Linux to be able to figure it out for themselves, and I unfortunately can't give advice for macOS, due to having no familiarity with that operating system.

What I would be interested to learn is exactly what difficulties people tend to have when compiling these programs, so that those difficulties can be addressed, hopefully publicly, and other users who have the same problems can use previous solutions as a guide.

[hkoenig]

You are correct in that the appearance of tools for the Game of Life, from a beginner point of view, vary from "not very good" to "unintuitive" to "command line."

Until my Permanent Vacation started a few years ago, I was in the business of writing applications for the iPhone/iPad, some of which had downloads in the tens of millions of copies. I have some experience with this subject, including how to do it wrong.

The problem is that to write a good application or tool takes time and effort will little relationship with the final product until much of it has been done. And you will need to add all the features and support your users have come to expect from a real application for your platform. Cross-platform tools do a poor to terrible job of supporting native platform features beyond the most basic, and it shows. Usually they are based on a particular platform with modifications that grudging support the conventions of other platforms or operating systems, and lagged a generation behind os updates. All that's going to confuse and frustrate naive users who expect behavior like all the other apps on their device. (Golly, for example, doesn't look like a native app, and does not support various MacOS touchpad gestures for scrolling and zooming that I expect use with all my native MacOS applications. Little thing can make a difference.)

Command line is usable if you have the technical background, but most people don't, and will want something more graphical, and something forgiving when making mistakes (and documentation beyond "--h") For example, if you want to encourage people to work with Herschel tracks, being able to manipulate the various components as single entities is needed, along with validation and immediate user feedback. Think of an application that emulates Snap Circuits or LEGO, which would build patterns at a higher level above individual bits.

What's needed is for a group of people to put together some interface toolboxes for various platforms. Standard ways to display objects and patterns and database records in a library that can be used by an app so all Life apps look and behave similarly.

I just did a quick look again at the lifelib page (not the one for actuaries) and to be honest, it looks like one of those packages that claim to work on the Mac, but based on experience, are difficult to impossible to actually use. (It's hard enough to get compatibility with Objective C, C++, C and Swift all in the same app (I've done it), but I have no idea how Python would get in there, or if Apple would allow it.)

"macOS doesn't support OpenMP"

Years ago (the last update to the project file was in 2018) I was able to get apgnano to run under macOS as a commandline tool, so it could run in the Terminal app. To do that I added some conditional compiling to enable apgnano to use Grand Central Dispatch (GCD) on MacOS and supported multiple threads. As far as I know, GCD is still going to be supported, despite Apple's push toward other multitasking models.

What I wanted to do next was see if I could wrap the command-line tool with a rudimentary interface. One that would display my "interesting" results in a log window, along with statistics, instead of having me dig around in text files or web pages and copy/paste the results into a GOL app. Unfortunately, I never never actually got that far as submissions require an account with Evil Software, Inc., which I don't and won't have.

An "exercise for the student" might be for someone to do that and actually get it to the point where it could be submitted and accepted in an Apple app-store. Or write a simple Game of Life application and publish it as "sample code", showing what it takes to get a simple app up and running, and how to fix some of the potential problems. (Yes, Apple is restrictive, but they also insure that you've done things right. When I had to interview job candidates, I always considered a app-store visible app a major positive, because it showed that the candidate actually understood how to meet outside requirements and specifications.)

[confocaloid]

Maybe create a subforum titled "Help / Support", and very directly clearly tell in the visible description that it's specifically created as the place to help new forum members?

In some places, there is a separate board/subforum titled along the lines of "Help" or "Support". That could also include help/support with existing software tools, with solving CGoL/CA-related problems, different sorts of basic questions / advanced questions / etc.

The existing "General Discussion" is not entirely right for that purpose. It's not specifically for helping newcomers. Instead, it's just, well, general on-topic discussion.

Maybe one problem is simply that there's no single obvious place where a newcomer could go to get help/support.

[...] and using the tutorials (which are not linked in convenient places!) [...]

[...] What I would be interested to learn is exactly what difficulties people tend to have when compiling these programs, so that those difficulties can be addressed, hopefully publicly, and other users who have the same problems can use previous solutions as a guide.

"From the viewpoint of an imaginary newcomer"

I can imagine a newcomer looking through the forums for the first time, trying to find a place where to ask for help / support:

• "Website Discussion"? That doesn't sound right, I don't really want to request any changes to how the forums or home page function, I'm just looking for a place to get some help.
• "LifeWiki Discussion"? That doesn't sound right, I'm not even sure if I already know what LifeWiki is.
• "Bugs & Errors"? That doesn't sound right, I don't have any bug reports yet, I don't even know much about what's the existing software and how to use it.
• "General Discussion"? Maybe, not sure... but it doesn't appear to be specifically for helping newcomers, seems like it's just for any on-topic general discussion of interest to people? Maybe there's a better place to ask for help?
• "Other Cellular Automata"? Doesn't sound right, I'm currently interested in Conway's Life, and looking inside it feels a bit cluttered to the point of being frightening.
• "Scripts"? That doesn't sound right, I'm not looking for a place to share scripts. (And why it's named "Scripts" anyway, looking inside it seems to be about CA software tools in general, and not just scripts? To a newcomer with some technical background from other fields, it sounds awkward to describe a compiled program as a "script".)
• "Patterns"? That doesn't sound right, I don't currently have much to contribute to discussion of specific patterns or specific families of patterns. (And why it's named "Patterns" anyway, looking inside it seems to be CGoL-specific but that's not explicitly mentioned in the description? Aren't patterns in other cellular automata patterns too? And why the focus on patterns? Patterns are supposed to behave; that's what makes them interesting. The word 'patterns' sounds like the wrong word to use here.)
• "The Sandbox"? Well... sounds like my topic doesn't fit elsewhere, so maybe I should go and ask for help in the Sandbox. Except that, looking inside, it feels more than a little bit more cluttered compared to viewforum.php?f=11 and well, I didn't really want to get stuck meaninglessly playing/chatting in the Sandbox! I was told elsewhere that you people here are doing some cool stuff and I just wanted to get some help so that I can contribute too.

[Nathaniel]

Maybe create a subforum titled "Help / Support", and very directly clearly tell in the visible description that it's specifically created as the place to help new forum members?

I like this. Done!

[dvgrn]

Now comes the interesting part! What additional threads should we create (and maybe pin) on the new board?

Just for example: we had a "FAQ" thread for a while in 2023, but that was targeted toward the LifeWiki rather than the forums. We ended up with both LifeWiki:FAQ and also User:Dvgrn/Readme/FAQ, which is linked to from User:Dvgrn/Readme/Main -- neither of which probably need to be in my userspace any longer.

Does it make sense for someone to start a "Frequently Asked Questions" thread in the new board on the forums? ... maybe with a first post that's intended to be continually edited to include questions and answers that show up farther down in the thread?

[LuveelVoom]

Now comes the interesting part! What additional threads should we create (and maybe pin) on the new board?

I think a thread for terminology- life lexicon does exist, but not in a convenient location, and not with embedded lifeviewer sims.
Also, maybe a collection of tutorials? A comparison of sim and search programs?

[confocaloid]

Maybe create a subforum titled "Help / Support", and very directly clearly tell in the visible description that it's specifically created as the place to help new forum members?

I like this. Done!

Now comes the interesting part! What additional threads should we create (and maybe pin) on the new board?

I think a thread for terminology- life lexicon does exist, but not in a convenient location, and not with embedded lifeviewer sims.
Also, maybe a collection of tutorials? A comparison of sim and search programs?

Maybe it would be better to keep relatively few topics initially (i.e. not create too many topics upfront).
Over time, some answers to further questions by newcomers might naturally become new topics.
Some tutorials could become separate topics (allowing people to discuss the tutorial). The wiki does have tutorials, and the wiki is good for the purpose of presenting existing knowledge, however the wiki is inconvenient for the purpose of having a related discussion. Maybe forum-based "tutorial" threads could be an improvement on that.

EDIT: Some existing forum threads, possible candidates for moving:

viewtopic.php?f=12&t=530 Introductions
viewtopic.php?f=2&t=5922 Construction Challenges and Ideas
viewtopic.php?f=2&t=1827 Thread For Requesting Help
viewtopic.php?f=2&t=2316 Construction practice
viewtopic.php?f=12&t=6781 Practical uses for cellular automata?
viewtopic.php?f=12&t=6745 Interesting math stuff
viewtopic.php?f=12&t=942 how and when you discovered the game of life?
viewtopic.php?f=7&t=1375 Videos about Conway's game of life
viewtopic.php?f=7&t=4875 A guide for new Life enthusiasts
viewtopic.php?f=12&t=2333 Help with names
viewtopic.php?f=12&t=3813 Tutorials
viewtopic.php?f=2&t=6066 Life has been proven omniperiodic. What next?

[WhiteHawk]

EDIT: Some existing forum threads, possible candidates for moving:

viewtopic.php?f=7&t=6765 Thread For Advanced Questions

not necessarily a newcomer's thread, but fits the bill for Help/Support

viewtopic.php?f=2&t=576 Thread for unsure discoveries

Perhaps would help to reduce clutter, though keeping it close to Accidental Discoveries might be better.

Also, maybe a collection of tutorials? A comparison of sim and search programs?

What sort of tutorials would there be on this new thread?

[confocaloid]

[...] Also this thread could be moved, or it could stay. [...]

No, this forum thread is "meta". This thread isn't by a newcomer trying to learn the basics. Further, I think this thread will not be directly useful to newcomers. It's just part of discussion about the current environment, state of art, etc. For this reason, I think this forum thread should stay; it would be offtopic in "Help/Support".

The idea of "Help/Support" is just to provide a single obvious place where a newcomer could go to ask about something (or find something already explained, over time there could be some "tutorial threads", "frequently asked questions" threads for some wide areas within CGoL/CA, etc. hopefully helping newcomers to understand ideas better.)

[...]
Maybe it would be better to keep relatively few topics initially (i.e. not create too many topics upfront).
Over time, some answers to further questions by newcomers might naturally become new topics.
[...]

[dvgrn]

Maybe it would be better to keep relatively few topics initially (i.e. not create too many topics upfront).

Yup, makes sense to me. Let's not be in a big rush to move a lot of threads right away, at least.

Actually I wasn't even entirely sure about Nathaniel's initial move of "Thread for basic questions". Is a thread with 212 pages containing a lot of technical detail really going to be all that helpful for newcomers? Or is the knowledge that that thread exists really the key fact that would be most helpful?

Maybe we should move the basic-questions thread back to where it was, add a link to it from the "Help for Newcomers" thread, and maybe also create a new "Questions from newcomers" thread or some such. (?)

If we stack a lot of existing threads into "Help / Support" that contain lots of posts, none of which were really written with newcomers in mind ... doesn't that get us right back to the problem of "Newcomers Aren't Going To Be Able To Find Anything They Can Understand"?

Maybe what's needed is is a relatively small number of pinned threads, with some fairly careful editing in the first post of each thread -- so that an exploration of "Help / Support" won't send anybody off into the weeds too quickly ... at least not without giving them a sense of what resources are available, and where to find them.

Some existing forum threads, possible candidates for moving:

viewtopic.php?f=12&t=530 Introductions
viewtopic.php?f=2&t=5922 Construction Challenges and Ideas
viewtopic.php?f=2&t=1827 Thread For Requesting Help
viewtopic.php?f=2&t=2316 Construction practice
viewtopic.php?f=12&t=6781 Practical uses for cellular automata?
viewtopic.php?f=12&t=6745 Interesting math stuff
viewtopic.php?f=12&t=942 how and when you discovered the game of life?
viewtopic.php?f=7&t=1375 Videos about Conway's game of life
viewtopic.php?f=12&t=2333 Help with names
viewtopic.php?f=12&t=3813 Tutorials
viewtopic.php?f=2&t=6066 Life has been proven omniperiodic. What next?

I've tried putting these into the first post of the "Help for Newcomers" thread.

If we end up with a new thread that fits this topic better, maybe we can move these links there. Like, how about a "Must-See" thread, where the idea is to compile a lot of short simple descriptions with links, so that people can decide what sounds interesting to explore?

(I stole that idea from MCell's pattern collection, from way back. At one point we tried to figure out how to add a similarly named folder to Golly, but it was too hard to decide what did and didn't count as a "Must-See". I don't know, maybe we'll end up with the same problem with a Must-See thread. But forum threads can run onto many pages, with just the most irresistible items getting edited up into the top post -- maybe that will work better.)

[confocaloid]

The "Thread for basic questions" definitely belongs to "Help / Support" much better than in "General discussion". I agree with that move. It becomes "the main thread of the subforum", with the common purpose of being a place where beginners can ask questions. There's no need to move it back.

Merely adding a network of back-and-forth links won't really help much, long lists of links aren't too helpful in practice.

[...]
Actually I wasn't even entirely sure about Nathaniel's initial move of "Thread for basic questions". Is a thread with 212 pages containing a lot of technical detail really going to be all that helpful for newcomers? Or is the knowledge that that thread exists really the key fact that would be most helpful?

Maybe we should move the basic-questions thread back to where it was, add a link to it from the "Help for Newcomers" thread, and maybe also create a new "Questions from newcomers" thread or some such. (?)
[...]

[H. H. P. M. P. Cole]

We should have a "Thread for your unsure discoveries" but for OCA.

The reason why I propose this is that despite the staggering variety of OCA objects and cellular automata, some will most likely be rediscovered in time to come. There seem to be enough OCA objects and cellular automata by now that at least something would be rediscovered already.

Open (and very silly) question: What is the "cyclic" of OCA?

[unname4798]

We should have a "Thread for your unsure discoveries" but for OCA.

RLE copy/paste thread exists for that purpose.

[b-engine]

We should have a "Thread for your unsure discoveries" but for OCA.

RLE copy/paste thread exists for that purpose.

But it's in Sandbox; we need the unsure discoveries threads in OCA subforum.

If there's nothing wrong, I'll create the thread.

[Sokwe]

We should have a "Thread for your unsure discoveries" but for OCA.

RLE copy/paste thread exists for that purpose.

But it's in Sandbox; we need the unsure discoveries threads in OCA subforum.

If there's nothing wrong, I'll create the thread.

I think this should already be covered by the miscellaneous discoveries thread.

[confocaloid]

[...]
Command line is usable if you have the technical background, but most people don't, and will want something more graphical, and something forgiving when making mistakes (and documentation beyond "--h")
[...]

There is another interesting possibiity for interactivity, namely read-eval-print loop. Interpreters for many popular languages work in this mode.

Comparing with other possibilities, a REPL is simple to implement (no need to deal with the pain of creating meaningful cross-platform GUIs), while still providing a surprising amount of interactivity (compared to having the user build a string of command-line arguments all at once). It is possible to keep the state and let the user build a request incrementally. A REPL can be substantially more "forgiving" than bare CLI.

I believe this possibility deserves more attention than it got so far, for tools to explore Conway's Life and other cellular automata. Although it still remains nontrivial to make a helpful intuitive UI with a read-eval-print loop, but not nearly as hard compared to making a full-scale GUI with windows and buttons and menus and so on.)

See also earlier forum threads:
viewtopic.php?f=9&t=5378 "Should we create a domain-specific language for CA searches?"
viewtopic.php?f=9&t=6597 "A script to write cellular automata as arithmetic expressions"

[dvgrn]

REPL could be an interesting option to think about, especially for cases where new search programs are being written from the ground up.

That said... it seems like the great majority of the difficulties that I've heard about, related to getting search engines up and running, have to do less with command-line inputs than with the basic problem of successfully compiling executables from source code.

Command-line programs do take some getting used to, for sure! However, most of our commonly used search software includes at least some documentation that gives examples of how to pass in command-line parameters to a functional executable program. A few examples like that can really help flatten the learning curve... but a functional compiled executable is absolutely necessary, before examples will be any help!

Compiling is really hard for beginners
Our search-software documentation very rarely manages to cover even a tiny fraction of the problems that people can run into in the process of trying to get search code to compile.

It's awesome whenever someone takes the time to write a section of a tutorial that gives good pointers in the right direction. But there are so many possible pitfalls across all of the possible platforms people might be trying to use, that it seems like there's just no way to cover them all adequately.

Pre-compiled executables
People sometimes request pre-compiled executables, but those run into their own compatibility problems between systems an awful lot. In some ways they end up adding more things that can go wrong, to an already very long list.

There might be a way of doing pre-compiled executables that is more likely to solve more problems for more people, though.

The last time that I can find this topic coming up was 2018.

... ideas for how to put together a cross-platform library of search utilities intended to travel with Golly (and compile with it, possibly?) -- without running aground on too many support headaches.  Several of the classic utilities like gencols, ptbsearch, and dr seem to have changed so little in the last decade that they'd be unlikely to create a lot of new support issues -- it would be more the kind of thing that LifeWiki tutorials would be written about, if some standard cross-platform way of accessing them was provided, say via Golly Lua scripts.

(I admit that more recent additions like Bellman, CatForce, apgluxe, and the [nt]zfinds could be a lot more trouble.)

Last but maybe not least, and along somewhat the same lines, there's the possibility of a minisat / retrolife code base that doesn't include instructions like "might need some minor changes to get it to compile".  I can generally get through minor troubles like that eventually, but it usually takes me an embarrassing number of hours to sort out even simple things, so generally I tiptoe away and find something else to work on.

Yeah, I still think I want to get some search programs or functionality available.  It's possible the right way to do this is to simply make another project and "take over" maintenance/packaging/porting of some of these programs.

Putting it under the general umbrella of "Golly" might be a loss of focus.  If it were just my project, I would probably just lump them into the same codebase (but separate executables) but I'm not the one doing most of the work these days . . .

If we could manage it, it would be really nice to set up a standardized repo that new search-program code could be contributed to. The idea could be that on a fairly regular schedule -- in conjunction with each new release of Golly, let's say -- someone compiles all the code available in the repo, on each platform that Golly supports ... hopefully using the same compiler that's used to build Golly on that platform.

Basically that would mean that anyone who jumps through the necessary hoops to be able to build Golly, will get a fairly large number of working executables for search programs, more or less "for free".

GUIs could be "easy"...
If we ever get to the point of having a centralized repo like that in working order, then we might really have an incentive to build GUIs for each search program, using Golly's Lua overlay. It seems like the community has really missed an opportunity here so far, to get GUI versions of search-program interfaces running fairly easily, in a standardized cross-platform way -- from inside Golly.

The Lua overlay was implemented over seven years ago already, and it's enormously powerful and has lots of really helpful sample code by Chris Rowett -- but I can still count on one hand the number of people who have done anything with it (and I don't even have to use the majority of my fingers).

[confocaloid]

GUIs could be "easy"...

There comes the problem of having the parts interact correctly. There's the Lua script running within Golly. There's a compiled search program behind the scenes. One will need to reliably invoke the searcher through the script (or have the user manually doing that, which undermines half of the idea).

Then there are programs like Logic Life Search, which are already a script (Python in that case) invoking a solver (e.g. kissat). Your idea seems to amount to adding Lua on top of that. Lots of things can and probably will go wrong.

Of course I'm not really opposed to Lua overlay, it's cool and powerful, but I doubt re: user-friendliness of Golly/Lua as an interface to a compiled program. A REPL might happen to be more user-friendly than that.

[get_Snacked]

Open (and very silly) question: What is the "cyclic" of OCA?

in my opinion, it's this replicator:

Code: Select all

x = 3, y = 2, rule = B3/S235e6c
bo$3o!

[confocaloid]

Open (and very silly) question: What is the "cyclic" of OCA?

in my opinion, it's this replicator:

Code: Select all

x = 3, y = 2, rule = B3/S235e6c
bo$3o!

Actually, I think it might be the 'bowtie pasta' replicator from HighLife:

Code: Select all

x = 4, y = 4, rule = B36/S23
3o$bobo$2b2o$3bo!
#C [[ THEME MCell GRID ZOOM 6 ]]

(In Conway's Life, cyclic is "famous" because many people rediscovered it. I assume that here the above question was about what would be an "alien" equivalent of that, "the most rediscovered" alien object or reaction)

[CARuler]

if you're talking about the type of object, it would be this

Code: Select all

x = 29, y = 30, rule = 356/23/6
2.ABCDE18.EDCB$.ABCDE20.EDC$ABCDE22.ED$BCDE11.2A11.E$CDE11.A2BA$DE11.
2A2C2A$E11.ABA2DABA$11.2ACA2EBCBA$10.ABADB2.CDC2A$9.ABCBEC2.DEDABA$8.
ABCDC.D2.E.EAC2A$7.ABCDED.E5.BDABA$6.ABCDE.E7.CEC2BA$5.ABCDE10.D.2C3A
$4.3ABCDE10.C.EDCBA$3.ABCDE14.DCB4A$2.4ABCDE15.EDCB$.ABCDE19.EDCB$ABC
DE17.EDCB3A$2ABCDE9.2AC.D3.EDCBA$CDE11.AB2ADED.EDCBA$CDE11.ABA2D2.BC3A
$3ABCDE8.A2BC2ECABA$ABCDE11.ABA2DABA$.3ABCDE9.2A2C2A$2.ABCDE11.A2BA$3.
ABCDE11.2A$4.ABCDE$5.ABCDE$6.ABCDE!

taken from https://conwaylife.com/wiki/List_of_Generations_rules