[Mod] Cellular Automata [0.1.0] [automata]

[bobomb]

A minetest mod for creating, importing and growing various cellular automata, including Conway's Game of Life...



This mod adds two new blocks and a tool:
1. an Active and Inactive Automata Cell
2. a Remote Control tool for triggering activation of cells according to 1D, 2D and 3D cellular automata rules, Importing of Game of Life .LIF files, and pausing resuming patterns.
3. a chat command (//owncells) to follow up WorldEdit commands such as //replace, //set. //mix, //load etc. Used to recover orphaned cells, create random fields, save and load patterns, and convert terrain and in-world objects into cells ready to activate with the remote.

Explanatory video at http://youtu.be/3Ksm1ojMwAo and the readme.md included in the mod is also thorough.

Mod dependencies: worldedit (optional for certain features)
Mod only tested with Minetest v.0.4.12
Author: bobomb
License of code and textures WTFPL
(Included .LIF file collection by Alan Hensel, Game of Life patterns generally attributed to original discoverers)

repository: https://github.com/bobombolo/automata (has a full readme with screenshots)
zip: https://github.com/bobombolo/automata/a ... master.zip (always current)

21july2015: version 0.1.0 released
Development of this mod has stopped (no new features). Bugs will be fixed and efficiency improvements will be made. Request for testing of this mod, especially in multi-player mode. In particular there is a formspec bug that would be nice to squash, one which requries a forced wait to get the form flow to work properly (ya, explain that one...) and a bug where a single cell is not getting set by VM, but must be set_node()ified. Otherwise code reviews from the community are appreciated, especially efficiency improvements. New features will be considered if there is interest (a list of features to be added is in the readme.md)

[cd2]

looks amazing!

[Kilarin]

Wow, cool! I remember writing and playing life back in the 80's! :)

[cd2]

Kilarin : yea, I did that too :D

[Krock]

But... the game of life uses way too many block modification operations, please use the VoxelManipulator to give low-end computers a chance to display it.

[bobomb]

yes i will be learning voxelmanip next. I think it will solve several of my problems.
also game of life entities that enter a steady-state need to be removed from the abm.
there are lots of other optimizations that need to be made, i'm just getting started.

[cd2]

bobomb : try to study paramat`s Mapgen framework/example [noise23]
It helped me a lot!

[bobomb]

cd2:
I will, though this isn't really a mapgen mod. Even the very large patterns grow a layer at a time and watching them grow is most of the appeal. I am reading up on voxelmanip and planning a rewrite this week. see: https://github.com/bobombolo/automata/issues/2

What parts of that mapgen framework are you specifically thinking I should look at?

[paramat]

CA need to use the non-mapgen voxelmanip, which uses different code, see my catacomb mod as an example https://github.com/paramat/catacomb of ABMs triggering the processing of defined volumes.

However ABMs have random timing, perhaps better to just loop the code so it runs as fast as it can.

Reading your post in the LVM thread, it's best to not use metadata because the LVM can only read/process/write content-id, param1 or param2. The fastest method would be to have several different CA nodes and process only content-ids.
For detecting the extent of CA nodes, perhaps better to store the limits of the startng volume and just process this plus 1 node on all sides. Each generation: if a node is placed outside the volume them increase that limit by 1 node. This way you will always know the exact volume of CA nodes you need to process with the LVM

[bobomb]

CA need to use the non-mapgen voxelmanip, which uses different code, see my catacomb mod as an example https://github.com/paramat/catacomb of ABMs triggering the processing of defined volumes.
However ABMs have random timing, perhaps better to just loop the code so it runs as fast as it can.

that is what I am doing in my current rewrite. I have some strategies to mitigate lag, i can't really use ABMs. I think I see what you are doing in catacomb. need to study further

Reading your post in the LVM thread, it's best to not use metadata because the LVM can only read/process/write content-id, param1 or param2. The fastest method would be to have several different CA nodes and process only content-ids.

i tried this already but it means a node type for each combination of rules. I have moved completely away from metadata in the current rewrite except for setting one identifier which i planned to use to persist active patterns to a file. i was under the impression that LVM would deal with meta, so I will find another way. persisting to a file is a secondary objective for me anyway. I have the mod down to two node types and an activator tool.

For detecting the extent of CA nodes, perhaps better to store the limits of the startng volume and just process this plus 1 node on all sides. Each generation: if a node is placed outside the volume them increase that limit by 1 node. This way you will always know the exact volume of CA nodes you need to process with the LVM

Even before I start using LVM I have started to track the pmin and pmax of each pattern at start and each iteration, should make the transition to LVM easy...

you can see my progress at https://github.com/bobombolo/automata/tree/development

thanks for the input

[bobomb]

still haven't started using lvm but latest version 0.0.3 has node, tool and formspec definitions that are much more refined and getting towards a final version. Importing of Life entities finally supported, ships with a large collection of .LIF files to play with. Ability to trigger a single node to current location (ie, in the sky). Still no persistence on game exit / restart.

[bobomb]

version 0.0.4 has some new features, again a much more useful form, management tab, 1D automata, 3D automata, and other new features.

[paramat]

See https://gist.github.com/paramat/389ee65ce9378d9dad25

[bobomb]

See https://gist.github.com/paramat/389ee65ce9378d9dad25

thanks so much, see:
https://forum.minetest.net/viewtopic.php?f=9&t=12666

[bobomb]

But... the game of life uses way too many block modification operations, please use the VoxelManipulator to give low-end computers a chance to display it.

This has now been completed. No Advanced Block Modifier is used and VM has been fully implemented.

Message to all: please test this mod, particularly the multiplayer functionality (manage tab) and how it runs on a server. Also open to any suggestions on improving the efficiency of the growth algorithm.

For version 0.1.0 I plan to have several more features such as persistence, importing / exporting improvements, some form improvements for people used to NKS nomenclature, and possibly an admin tab. Also at this time any rule that uses 0-neighbor birth is inaccurate as 0-neighbor birth is simply ignored. I plan to solve this issue before v.0.1.0.

For those truly interested in cellular automata a recently added feature, stepwise growth (in the manage tab you can add extra generations to any finished pattern, as well as pause/resume) might interest you.

a 3D pattern started from a single cell (18neighbor 0,3,5/1,3,8)



NKS rule 30 in RAINBOW mode... grown in -Y



A 2D pattern finished in mese (8 neighbor, 01234/14) grown in X

[bobomb]

Request for education: Re: voxel areas and indexes:

Is it possible to mathematically convert indexes from one extent to a different extent as long as the nodes to be converted are in both extents (the overlapping area)? My intent is to eliminate a costly conversion from area1 indexes, into positions {x,y,z} and then back into area2 indexes. This is due to the fact that the extent of the pattern changes each iteration. I have eliminated as much of this as possible by storing both indexes and positions in the pattern's cell table but I would like to completely eliminate it if possible.

It occurs to me that learning about the .mts format and importing/exporting to that format might be another way to refactor the growth function more efficiently at the same time as accomplishing the goal of providing better import/export functionality...

[paramat]

Wow, nice. I will think on your question.

[bobomb]

when an extent is created, what is the base index number, which should be 1, but is always in the thousands, based on?

[paramat]

> Is it possible to mathematically convert indexes from one extent to a different extent as long as the nodes to be converted are in both extents

Maybe but it will still be complex, and therefore very slow in lua, it's best to use the c++ voxelarea area.index(p) api as much as possible.

Whenever you work with a particular volume, the actual emerged voxelmanip volume (emin, emax) is the volume of complete mapblocks (16^3 with origin at (0,0,0)) that contains your requested volume.
The voxelmanip index is relative to this volume of complete mapblocks, which is why the index number is large for the first position in your requested volume.

So, the emerged voxelmanip volume only changes it's volume when your structure crosses a mapblock border, so the index for a cell only changes then, you only need too recalculate the index when a border is crossed, not every iteration.
Also, you only need to create a new voxelmanip volume when a border is crossed, because it will be identical until a border is crossed.

[bobomb]

version 0.1.0 released. active development will largely halt now. please report bugs here. Will post a video within next few days.

[bobomb]

http://youtu.be/3Ksm1ojMwAo

[bobomb]

help testing processing time:
my standard patterns for testing efficiency are:
singlenode map, start 3 patterns from single cell in space (obviously), growth: 1, destruct mode on, trail: stone, final: mese
1D pattern, rule 30, main axis: x, growth axis z, 100 generations (should end with 103 cells)
2D pattern, 8 neighbors, rule 01234/14 growth axis y 50 generations (should end with 3776 cells)
3D pattern, 18 neighbors, rule 0,3,5/1,3,8, 30 generations (should end with 36460 cells)
- i start these one after the other not waiting for one to finish before triggering the next

the current total growth times (readable from the manage tab) are:
1D: 25145ms
2D: 46831ms
3D: 19770ms

please let me know your results