A while ago, I wrote:In terms of further rule families, the next one I intend to implement is outer-totalistic rules up to range 5.

Higher-range outer-totalistic (HROT) rules are implemented as of

v4.63 (in apgsearch) and

ll2.0.17 (in lifelib).

The syntax is

rXbXXX...XsXXX...X[z]where the range can be either 2, 3, 4, or 5, and the 'b' and 's' must each be followed by exactly r(r+1) hexadecimal characters. For instance, the LtL rule r2b4t4s10t19 has the outer-totalistic rulestring r2b000008s03ff00, where:

- 000008 = 0000 0000 0000 0000 0000 1000 because we have birth only on 4 neighbours, and the 4th-from-last bit is 1 (the others are 0).
- 03ff00 = 0000 0011 1111 1111 0000 0000 because we have survival from 9 to 18 neighbours, and those bits are 1.

IMPORTANT: the middle cell is

included in LtL (for consistency with Kellie Evans' original notation), but

excluded in HROT (for consistency with the usual outer-totalistic B/S notation).

If you want survival on zero neighbours, stick a 'z' on the end of the rule. For instance, if we were allowed r1 (which we're not, because that pointlessly duplicates the outer-totalistic rulespace), then B3/S02456 would have the rulestring r1b04s3az:

- 04 = 0000 0100 because we have birth only on 3 neighbours, and the 3rd-from-last bit is 1 (the others are 0).
- 3a = 0011 1010 because we have survival on 2, 4, 5 and 6 neighbours.
- z because we have survival on zero neighbours.

A maximum range of 5 is supported (in which case each of the birth and survival conditions have exactly 30 hex chars), because due to extremely technical reasons* the

HROT code can't support neighbourhoods of area greater than 127.

* The easiest way to explain it is that PSHUFB allows me to index into a lookup table of at most 16 bytes, and I can (with some effort) use that as a 128-bit lookup table. I have separate 'birth' and 'survival' lookup tables, PSHUFB each of them, and combine the results using the result of PCMPEQB-ing the centre cell with zero. This extracts the relevant

byte; to extract the specific

bit, I PSHUFB a 'powers of 2' lookup table and take the bitwise AND with the vector of bytes.

Also, I haven't combined this with Generations yet (it's 3:58 am here and I want to have food and sleep soon!), but the changes to do so would be utterly trivial.