Pattern viewer for forum threads

[rowett]

I've noticed that a few higher-range patterns have been interacting oddly with bounded grids, causing cells to be visibly born outside of the boundary.

Fixed, thanks!

[muzik]

When identifying this oscillator, the strict volatility value seemed to conflict with the period map it provided, since the vast majority of the cells are at full period. Indeed, checking the table out reveals that the percentages don't even come close to adding up to 100:

Code: Select all

x = 482, y = 396, rule = B3aeiq4-aijn5cy6cik7/S2cen3-ajr4ceiq5eijkq6-a7c8
199bo$198b3o$197b5o$196b7o$195b4o2b3o$194b4o4b3o$193b4o2bobob3o$192b5o
3bo2b4o$191b3o8bob4o$190b5o10b4o$189b6o10b5o$188b6o10b3ob3o$187b7o11bo
3b3o$186b3o2b2o17b3o$185b4o3b2o17b3o$184b4o24b3o$183b5o23bob3o$182b5o
23bo2b4o$181b5o28b4o$180b5o32b2o$180b4o33b3o$182bo33bo2b2o$219b3o$220b
3o$221b3o$222b3o$223b3o$224b3o$222bob4o$222b2o2bo$223b3obo$225bobo37$
219bo$218b3o$217b5o$216b3o2b2o$215b3o3b3o$214b4o4b3o$213b4obo4b3o$212b
3o2b2o5b3o$211b5o10b2o$211bo9bo4b3o$212bo13b4o$227b4o$227b5o$228b5o$
231b3o$232b3o$234b2o$233bob2o$233bob3o$237bo$237bobo$236b3o12$146bo$
147bo$144bo3bo$143b3o$142b5o$141b5o$140b3o$139b3o$138b2o$137b3o$136b6o
$135b2o2b2o$134b6o$133b4o2bo$132b5obo$131b6obo$130b5o2bo$129b5o3bo$
128b5o$127b4o$126b3o$125b4ob2o$124b3obobo$123b3o2b3o$122b2o2b2o2bo3bo$
121b2obo2b2ob2o2b2o$120b4o3b2obo3bo$119b4o$118b4o$117b2o$116b3o$115b3o
bo$114b3obo$113b5o$112b2o2b2o$111b3o2bo$110b4o$109b4o$108b4o226bo$109b
3o225bo$110b3o223bo3bo$111b3o225b3o$112b3o223b5o$113b3o223b5o$114b2obo
222bob3o$115b3o225b3o$116bo222bo2b3o$343bo32$199bo$198b3o$197b5o$64bo
131b7o$63b3o129b2o2bo2b2o$62b5o127b3o2bo2b3o$61b7o127b2o5b4o$60b4o3b2o
126b2o6b4o$61bo5b3o133bob3o$58bo3b3obob3o136b2o$60bobo4b5o131b2o2b3o$
205bo3b2o$70bo2bo131b2o2b3o$209b4o$210b4o$52bo160b2o$51b3o158bob2o$50b
4o159bob2o$49b2obo162b3o$48b3o163bob3o$47b5o163bo2b2o$46b3o169b3o23bo$
45b5o169b3o21b3o$44b5o170b4o19b5o$43b5o151bo19b5o17b3ob3o$42b3o153b3o
15bo5bo17b4ob4o$41b2o154b5o15bo21b6o2b3o$40b3o153b7o35b4o5b4o$39b3o45b
o107b9o33b4o8b3o$38b3obo43b3o105b4obo2b3o31b4o11b2o$37b3obo43b5o103b4o
bo2b5o29b4o12b3o$36b3o45b3obo103b4o7b4o27b2o13b6o$35b4o44b3o2b2o101b3o
10b4o25b2obo13bo2b3o$34b3obo43b5o103b3o12b4o23b3o17b5o$33b4obo42b5o
103b3o14b4o21b3o21b3o$32b2o4b2o40b5o103b5o14b4o19b3o24b2o$31b3o45b3o
105b7o13b5o17b4o22b5o$30b3o45b3o105b7o17b3o15b4o2bo20b6o$29b4o44b4o
104b7o17b5o15b3o3bo20bo2b3o$28b3o45b3o105b7o21b3o15b3o3bo21b5o$27b3o
45b5o103b7o22b4o15b2o24b7o$26b3o45b5obo101b3ob3o24b4o15b3o23b7o$25b3o
45b4o104b7o24bo2b3o15bo25bo4b2o$24b3o45b4o104b2o31bob4o45b3o$23b2obo
44b4o104b3o35b3o45b3o$22b2obo44b5o103b5o2bo32b3o44b4o$21b3o45b4ob2o
101b6o36b3o43b5o$20b5o43b7o101b5o3bo35b3o42b6o$19b2o2b2o42b4ob2o101b5o
19bo21b3o44b4o$18b3o45b3o3bobo99b4o20b3o21b3o45b3o$17b4o44b3o5bo99b9o
15b5o21b3o45b3o$16b5o43b4o104b9o15b3o2b2o20b4o44b4o$15b3o3bo3bo37b3o2b
o102b4ob4o15b3o3b3o20b4o43bob3o$14b3o4bobo2bo35b2o106b5ob3o15b4ob3ob2o
21b3o42b6o$13b4o3bo40b3o3bo101b4o3b2o15b4obo4b3o21b3o45b3o$12b4o4bob3o
35b4o104b3o5bo15b3o3bob2o2b3o21b3o45b3o$11b3o9bo35b5o103b3o21b4obo7b4o
22b2o46b2o$10b4o44b5o103b4o20b4o12b3o21b3o44bob2o$9b2o2b2o42b5o19b2o
84b3o19b2o12bo3b3o20b4o45b3o$8b3o2bo42b5o22bo80bo3bo19b3o18b2o21b3o45b
3o$7b3o45b5o19bo3bo81bo21b3o9bo3bo5b3o22b2o42bo2b3o$6b4o44b5o19b3o85bo
19b3o9b3o8b4o21b3o45b3o$5b3o45b4o20b2o106b3o9b5o8b4o18b6o45b3o$4b2o46b
3o21b2obo104b4o8b3ob3o7b5o17bo2b4o43bob3o$3b3o45b3o21b3o105b5o7b3o3b3o
7b5o22b2o46b2o$2b2o46b3o21b3o105b5o7b3o3bob3o7b5o21b3o42bo2b3o$b3o45b
3o21b2o106b3obo7b3o6b4o8b4o18b6o42bo2b3o$6o42b4o20b3o105b4o8b4o2bo3b5o
7b5o18b6o46b2o$b3o7bo37b3obo19b3obo103b3obo7b3ob2ob2o3b3o6b6o18b2ob3o
45b3o$2b2o7b2o37b4o4bo15b5o2b2o99b4o8b5o5bob3o9b3o17b7o44b4o$3b3o5b3o
37b3o21b3o4b2o99b3o9b3o9b3o8b4o19b5o43b5o$4b2o2bo3b3o37b2o2b2o18b4o3bo
100b2o2bo7bo9b3o7b5o18bob4o44b4o$5b4o3b4o37b5o19b4obo102b3obo11b2o3b2o
7b5o20b4o45b3o$6b3ob2o42b5o3bo15b4o104b3o11b2o2b3o8b4o14bo5b4o37bo7b3o
$7b5o43b5o2b2o15b4o104b2o12bob3o9b3o14bo5b4o37b2o5bob2o$8b3o3bo41b5ob
3o15b4o104b3o10b4o9b3o14bo6b3o37b3o6b2o$9b3o45b4o3bo16b3o105b3o9b3o8b
4o19bo2b2o37b3o3b5o$10b3o45b4obo18b3o105b4o7b2o8b4o19b5o39b2o3b4o$11b
2obo3bo40b3o21b2obo104b4o3b4o6bob4o21b3o41bo3b3o$12b4o2bo41b3o21b2o
106b3o2b4o9b3o22b2o41bob5o$13b3ob4o40b3o21b3o105b7o8b4o20b4o44b4o$14b
3o4b2o39b4o20b3o105b5o7b5o20b4o43bob3o$15b6o42b3obo19b2o106b3o7b5o21b
3o45b3o$16b5o43b5o19b3o105bo7b5o18b2o2b2o43b5o$17b5o43b5o19bo2bo94bo
15b5o21b3o44b4o199bo$18b5o3bo39b5o115bo15b5o19b5o44b4o201bo$19b5o2bo
40b3o3bo17bo99bo10b4o20b4o42b2ob3o199bo3bo$20b5o43b3ob3o113b3o11b3o15b
o3bob3o44bob2o200b2o$21b4o44b5o115b3obo7b3o15b2o3b4o44b4o201b3o$22b3o
45b3o117b4o5b4o15b3ob5o45b3o200bob2o$23b3o45b3o117b5ob5o15b4ob4o42bo3b
2o202b2o$24b2o46b3o117b3o3b3o16bob6o44b4o201b3o$25b3o45b3o117b7o18bob
4o45b3o203bo$26b3o45b3obo115b5o20b4o45b3o$27b3o45b3o117b3o20b4o45b3o$
28b3o45b3o117bo20b4o45b3o$29b2o2bo43b3o137b3o39bo4bob2o$30b3o45b2obo
133b4o39bo6b2o$31b2o46b2o133b4o19b2o14b2o8b3o$32b3o45b4o128bob3o19bo
15b3o4bob4o$33b5o43b4o124b2o2b3o19bobo14b4o5b3o$34b5o43b5o122bo3b2o19b
3o17b2o4b3o$35b5o43b3o33bo91b3o19b5o17bo4b2o$36b4o44b2obo2bo116bo3b2o
19b5o17bob5o$37b3o45b2o4bo25bo2bo88b3o20b4o18bob4o$38b3o45b3o27b2ob3o
85b4o21b3o18bo2b3o$39b2obo44b3obo23b3ob2o62bo21bob3o20bob2o22b2o$40b2o
46b4o10b3o9b4ob3o64bo18b4o22b2o20b4o$41b3o45b5o7bobobo7b5obo65b5o14b4o
21b3o11b3o5b5o$42b2obo44b3o3bo7bo9b6obo64b3o15b3o19bo2b2o11b3o6b4o$43b
2obo44b3ob3o17b3o69b3obo11b3o15bo5b3o13b2o5b4o$44b2obo44b5o7b2o10b2o
70b3obo9b3o15b2o5b2o16bobob4o$45b2o46b3o6b2o13b3o69b4o8b3o15b3o3b3o18b
ob4o$46b5o43b3obo19b2o70b4o6b3o15b4ob4o20b4o$47b4obo42b4o92b3o5b3o15b
9o21b3o$48b4o4bo39b3o2b2o89b3o3b3o15b9o19bob3o$49b6o42b2o3bo90b7o20b4o
20b4o$50b9o39b3o73b2o18b5o19b5o20b4o37b2o$51b4o3b2o39b2o72b3o19b3o19b
5o18b6o$52b3o45b3o69b4o20bo19b5o19b5o39bo2bo$53b3o45b3o69b3o2bo36b5o
19bob3o41b2obo$54b3o45b3o69b2o2b2o34b5o20bob2o42b2o2bo$55b3o45b3o69b6o
32b5o22b2o40bo2b5o$56b3ob2o42b3obo67b3o34b4o20b4o42b6o$57b6o42b4o68b2o
30b2o2b3o20b4o44b4o$58b6o42b4o68b3o28bo3b2o21b3o44b4o$59b4o2bo41b3o4bo
64b3o29b3o19b2ob2o44b4o$60b3obo43b2obob3o64b2obo27b2o18b2o2b2o45b3o$
61b3o45b2obo68b2o26b3o17bob5o45b3o$62b3o45b4obo66b3o21b5o21b3o44bob2o$
63b3o45b3o2bo66b3o19b5o17bo3b3o46b2o$64b2obo44b4o2bo65b2obo17b4o18bo3b
2o45b3o$65b3o45b3o2bo66b2o18b3o18b2ob3o43bob3o$66bo47b2obob2o65b4o13b
4o18b2o2b2o43b2ob2o$115b2o2bo67b5o10b4o18b6o45b3o$116b6o66b3o11b3o18b
6o37bo7b3o$117b3obobo65b5o7b3o18bob4o46b2o$118b3o69b4o5bob2o18bo2b3o
39b2o3b4o$119b3o4bo64b3obo4b2o19bob3o45b3o$120b3o3bo46bo18b9o19b5o45b
3o$121b3ob3o43bo21b7o20bob2o44b4o$122b3o45b3o4bo16b5o21b3o43b5o$123b3o
45b3ob2o18b3o16bo2bo2b2o43b5o$124b4o44b3o21bo21b3o44b4o$125b4o44b2o2bo
37b5o45b3o$126b3o45b5o36b4o43bob3o$127b3o45b5o31b2o2b3o42b2o2b2o$128b
5o43b4o34b3o43b5o$129b5o3bo39b3o32b4o43b5o$130b5ob3o39b2o31bob2o44b4o$
131b3o45b3obo24bob4o39b2o4b3o$132b3o45b4obo22bo2b2o39b2ob2o2b2o$133bo
47b5o23b3o42b6o$182b4o20bob3o43b5o$183b3o20b4o43b5o$184b3o18b4o43b5o$
185b3o17b3o44b4o$140bo45b4o2bo11b3o45b3o$139bo47b6o10b3o44bob2o$142b2o
44b3o11b3o36bobo2bo4b2o$141b4o44b2o10b3o37b2o5b4o$142b4o3b2o39b3o6b4o
38b4o3b3o$143b4obob2o39b3o3bob3o42bo2b3o$144b4ob4o39b9o42b2ob3o$145b9o
39b7o43b5o$146b9o39b5o41bo2b4o$147b5o2b2obo37b3o43bob3o$148b4o2b3o39bo
43b5o$149b3o2bo83b6o$150b5o80b3o2b3o$151b4o85b2o$152b4o78b2ob4o$153b3o
77b7o$154b2o78b2ob2o$155b3o2bo73b4o$156b2o2b2o70b5o$157b4o72b3o$158b3o
71b3o$159b4o69b2o$160b4o2bo61b5o$161b5o61b5o$162b4obo58b5o$163b3ob3o
55b5o$164b5o53bo3b3o$165b4o52b3ob3o$166b3obo51b5o$167b3o52b4o$168b3obo
49b3o$169b3o49b3o$170b2o45b6o$171b4o44b3o$172b3o42b4o$173b4o38bob3o$
174b4o38b3o$175b3o37b3o$176b3o35b3o$177b3o33b3o$178b4o2bo26bob2o$179b
5o28b2o$180b4o26b3o$181b4o23bob2o$182b3o24b2o$183b4o14bo3b5o$184b5o14b
6o$185b3o2b2o11b5o$186b3o15b3o$187b4o10bo2b2o$188b4o8b5o$189b5o2b3ob4o
$190b2obobo3b4o$191b3o5b3o$192b2o2b5o$193b7o$194b5o$195b3o$196bo!

The "Active Cells" value, which I assume to be correct, is also much, much larger than the sum of all cell period types present in the period counts table, which is without a doubt linked to this issue. Indeed, 37572/103432 gives a value that appears to match the strict volatility output and the sum of the two percentages in the counts table.

I'm not sure what's even going on here - is the pattern too big for all of the periodic cells to be properly counted, are cells outside of the oscillator but within the bounding box being counted as well, or something else entirely? It'd certainly be interesting to see a "percentage of cells inside of the oscillator's bounding box which actually belong to the oscillator itself" value added to the Identify table, but that's a whole different suggestion.

[rowett]

When identifying this oscillator, the strict volatility value seemed to conflict with the period map it provided, since the vast majority of the cells are at full period.

Fixed, thanks!

[rowett]

Would it be possible to be able to individually show and hide the values for "Alive", "Births" and "Deaths" in the population graph?

Yes, there are now buttons and hotkeys to toggle what you want displayed.

Also, is it intended that bounded grids don't display births or deaths in the graph? I know they're omitted from the T menu, but even at that it seems strange to render them absent outright.

Yes since births and deaths are not calculated for Bounded Grids. It's been on the backlog for a long time. The T menu shows Density instead.

[muzik]

births and deaths are not calculated for Bounded Grids. The T menu shows Density instead.

Could density per generation be tracked on the graph for bounded grids, with 0% being the bottom of the graph and 100% being the top of it?

Code: Select all

x = 1, y = 1, rule = B1357/S02468:T128,129
o!
[[ GRAPH STEP 64 NOTHROTTLE STARTFROM 47 ]]

For non-bounded grids, I'd also be interested in seeing Heat tracked on graphs.

For default line colors, Density could be DeepSkyBlue and Heat could be Orange.

[muzik]

Instead of a NR neighbourhood, could some sort of suffix be added to the HROT rulestring that controls determinicity as to allow for non-deterministic rules with any supported neighbourhood?

You can now add ",P" to any valid HROT rule string to enable non-deterministic births and survivals.

What exactly is it that makes rules non-deterministic anyway - is it just that each birth and death has a pseudorandom 50% chance of happening, rather than an assured 100%? I definitely think that there would be more interest in such rules if the randomness was more customizable, even just the ability to set a percentage value for birth success likelihood and death success likelihood. Two values from 0 to 100 after the P, separated by a comma, could be used to notate this.

In addition, it might be advisable to disable Identify for non-deterministic rules, since periodicity in such rules can effectively only be coincidental.

It may also be advisable to deprecate the "NR" neighbourhood, as it's now redundant to the Moore neighbourhood with P at the end. This would free up NR for another neighbourhood in future if needed. As far as I'm aware, this is the only post in the forums to use NR (attempting to find any more by searching "NR" on the forums crashes the search after a while), so it just needs to be edited to use the Moore neighbourhood with ,P at the end.

[rowett]

What exactly is it that makes rules non-deterministic anyway - is it just that each birth and death has a pseudorandom 50% chance of happening, rather than an assured 100%?

A first random chance is picked for births and a second for survivals. These chances are then used during evolution.

In addition, it might be advisable to disable Identify for non-deterministic rules, since periodicity in such rules can effectively only be coincidental.

Done in the next build.

It may also be advisable to deprecate the "NR" neighbourhood, as it's now redundant to the Moore neighbourhood with P at the end.

This was done a while back - and that referenced post doesn't use NR.

[muzik]

It may also be advisable to deprecate the "NR" neighbourhood, as it's now redundant to the Moore neighbourhood with P at the end.

This was done a while back - and that referenced post doesn't use NR.

Seems I had a tab open for far too long. My mistake!

[muzik]

Something random I tested a couple of days ago: if the bounding box of a given oscillator exceeds 2048, no period map will be generated at all, just like what happened previously with the greater than one cell per pixel case.

Code: Select all

x = 223, y = 221, rule = B3/S23
3o2040$2040b3o!
[[ THEME Catagolue ]]

Code: Select all

x = 223, y = 221, rule = B3/S23
3o2050$2050b3o!
[[ THEME Catagolue ]]

This could possibly be fixed, but I doubt anyone will be able to identify any actually interesting oscillators with bounding boxes of this size, so it may be worth just graying out the map button for anything too big. The periods table still works fine, so it can remain accessible.

[rowett]

if the bounding box of a given oscillator exceeds 2048, no period map will be generated at all

This appears to be a limitation of mobile devices (at least I can reproduce on the iPhone). On the desktop it works fine.

[rowett]

Could density per generation be tracked on the graph for bounded grids, with 0% being the bottom of the graph and 100% being the top of it?

No because it's no different than population.

For non-bounded grids, I'd also be interested in seeing Heat tracked on graphs.

This is only calculated during Identify so not available for the Population Graph.

[rowett]

... given the fact it's a rather large pattern in terms of bounding box, takes 23 whole seconds

Code: Select all

x = 156, y = 75, rule = B3/S23
146b2o5b2o$146b2o5b2o16$145b2obo3bob2o$145bo2bo3bo2bo$146b3o3b3o3$31b
2o$33bo$18b2o10b2o2bo$18b2o11bo2bo$32bobo$32b2o119b2o$153b2o$32b2o$32b
obo$18b2o11bo2bo10b2o30b2o$18b2o10b2o2bo10b2o30b2o$b2o4b3o23bo$b2o3bo
3bo20b2o$6b2ob2o$7bobo67bo$53bo2bo19bobo66bo2bo$7bobo21b4o22bo17b2ob2o
69bo$6b2ob2o19bo3bo18bo3bo16bobob3o64bo3bo$6bo3bo4b2o17bo19b4o14bob2o
2b2o66b4o$7b3o4b2o14bo2bo38bobo77b2o$16bo135bobo$154bo$86b2o34bo31b2o$
69b2o15bobo7b2o24b2o$51bo3b3o11b2o17bo7b2o23bobo$36b2o12bobo2b5o26b3o$
36b2o12bo3b2o3b2o$51bo2bo3b2o$3o5b3o41b3o3bo$o2b2ob2o2bo16bo58b3o$b3o
3b3o16b2o24b3o3bo10b2o17bo7b2o$2bo5bo17bobo22bo2bo3b2o9b2o15bobo7b2o$
36b2o12bo3b2o3b2o2b2o21b2o$36b2o12bobo2b5o3b2o$51bo3b3o52b2o$111b2o$
92bo17bo$50b2o38bo2bo$b2o5b2o42bo25b2o10b5o$b2o5b2o39b2o2bo10b2o12b2o
10b3ob2o$31bo18bo2bo10b2o25b2obo15bo3bo$30bo2bo4b2o11bobo38b2o15bo5bo
9b2o$17b2o10b5o3b2o12b2o56bo15b2o$17b2o9b2ob3o5bo52b2o15b2o3bo$29bob2o
18b2o38b2obo16b3o$30b2o19bobo24b2o10b3ob2o$50bo2bo10b2o12b2o10b5o16b3o
$30b2o17b2o2bo10b2o24bo2bo15b2o3bo$29bob2o19bo39bo16bo15b2o$17b2o9b2ob
3o16b2o57bo5bo9b2o$17b2o10b5o76bo3bo$30bo2bo$31bo!

Identify is now faster for 2-state patterns.

[muzik]

The Theme section of Help > Info contains several values for things which are not actually tied to themes at all. Would it be possible to move these into more fitting categories? For example, Text, Error and Help might fit better in the UI category since they control UI elements.

[rowett]

The Theme section of Help > Info contains several values for things which are not actually tied to themes at all. Would it be possible to move these into more fitting categories? For example, Text, Error and Help might fit better in the UI category since they control UI elements.

Done.

[muzik]

The Theme section of Help > Info contains several values for things which are not actually tied to themes at all. Would it be possible to move these into more fitting categories? For example, Text, Error and Help might fit better in the UI category since they control UI elements.

Done.

Since grid settings are theme dependent, would it be possible to either merge the Gridlines section into the Theme section, or move it directly under it?

Another random suggestion: could these be made to display their respective name used for customization in scripts when moused over? The UI select color and cell selection color are both named "Select", and there's also two things described as "Background" nearby - it'd probably be a good idea to make sure the cell selection displays "SELECT" when moused over in that menu, the UI selection value "UISELECT", and so on for all other customizable colors. I know that there is a separate help section for this, but having it here as a mouseover-only clarification would be useful as well.

[rowett]

Since grid settings are theme dependent, would it be possible to either merge the Gridlines section into the Theme section, or move it directly under it?

It's now under the Theme section.

Another random suggestion: could these be made to display their respective name used for customization in scripts when moused over?

No, but I did make some adjustments to some of the item names.

[muzik]

Certain types of cells, particularly [R]History cells, [R]Super cells as well as cells from custom rules, aren't theme dependent, yet are still listed under the "Theme" section. The same is true for the "unbounded" boundary color and bounded grid border color.

Would it be possible to either make these cells theme-dependent (in which case, here's a post from 2020 containing color proposals for what was changeable at the time, and here's my proposal for how Themes could be made to support rule tables which I'm still very proud of and strongly stand by today), or relocate these to a new, closeby section?

A related sighting which may be a bug: for certain pattern errors, the "Theme" section in Help displays far less theme-related data that expected, which appears to vary depending on the rulespace even for the same type of error:

Code: Select all

x = 10, y = 10, rule = B3/S23:T10000,10000
5bo2$19bo$2bo$bo6b6o$7b8o$6b10o$o4b11o$5b2ob5ob2o$5b11o$5b2ob8o$5b2ob
o3b3o$6b3obob2o6bo$7b6o$o18bo$bo$17bo$3bo9b2o$5bo4b4o!

Code: Select all

x = 21, y = 19, rule = R6,C2,M1,S49..93,B21..25,NM:T10000,10000
5bo2$19bo$2bo$bo6b6o$7b8o$6b10o$o4b11o$5b2ob5ob2o$5b11o$5b2ob8o$5b2ob
o3b3o$6b3obob2o6bo$7b6o$o18bo$bo$17bo$3bo9b2o$5bo4b4o!

Code: Select all

x = 10, y = 10, rule = MargSingRot:T10000,10000
5bo2$19bo$2bo$bo6b6o$7b8o$6b10o$o4b11o$5b2ob5ob2o$5b11o$5b2ob8o$5b2ob
o3b3o$6b3obob2o6bo$7b6o$o18bo$bo$17bo$3bo9b2o$5bo4b4o!

Code: Select all

x = 10, y = 10, rule = MarBlocks7-OT-2x2-minimal:T10000,10000
5bo2$19bo$2bo$bo6b6o$7b8o$6b10o$o4b11o$5b2ob5ob2o$5b11o$5b2ob8o$5b2ob
o3b3o$6b3obob2o6bo$7b6o$o18bo$bo$17bo$3bo9b2o$5bo4b4o!

Code: Select all

x = 10, y = 10, rule = LifeHistory:T10000,10000
5bo2$19bo$2bo$bo6b6o$7b8o$6b10o$o4b11o$5b2ob5ob2o$5b11o$5b2ob8o$5b2ob
o3b3o$6b3obob2o6bo$7b6o$o18bo$bo$17bo$3bo9b2o$5bo4b4o!

Code: Select all

x = 10, y = 10, rule = LifeSuper:T10000,10000
5bo2$19bo$2bo$bo6b6o$7b8o$6b10o$o4b11o$5b2ob5ob2o$5b11o$5b2ob8o$5b2ob
o3b3o$6b3obob2o6bo$7b6o$o18bo$bo$17bo$3bo9b2o$5bo4b4o!

For Generations, we even get a completely unexpected state number, whose color isn't even mentioned in the Theme section even though several non-present states (which could exist in a valid pattern) are:

Code: Select all

x = 10, y = 10, rule = /2/3:T10000,10000
5bo2$19bo$2bo$bo6b6o$7b8o$6b10o$o4b11o$5b2ob5ob2o$5b11o$5b2ob8o$5b2ob
o3b3o$6b3obob2o6bo$7b6o$o18bo$bo$17bo$3bo9b2o$5bo4b4o!

Code: Select all

x = 10, y = 10, rule = Fire rule:T10000,10000
5bo2$19bo$2bo$bo6b6o$7b8o$6b10o$o4b11o$5b2ob5ob2o$5b11o$5b2ob8o$5b2ob
o3b3o$6b3obob2o6bo$7b6o$o18bo$bo$17bo$3bo9b2o$5bo4b4o!

And in PCA, that state goes completely unnamed:

Code: Select all

x = 10, y = 10, rule = PCA_4:T10000,10000
5bo2$19bo$2bo$bo6b6o$7b8o$6b10o$o4b11o$5b2ob5ob2o$5b11o$5b2ob8o$5b2ob
o3b3o$6b3obob2o6bo$7b6o$o18bo$bo$17bo$3bo9b2o$5bo4b4o!

I don't know how valid this report is given that it depends on another error to happen to see this, and is also likely simply revealing ultimately inconsequential differences regarding rule processing.

[rowett]

Certain types of cells, particularly [R]History cells, [R]Super cells as well as cells from custom rules, aren't theme dependent, yet are still listed under the "Theme" section. The same is true for the "unbounded" boundary color and bounded grid border color.

In the next build the "Theme" section is optional (depending on the rule) and only covers the theme name, number of age and history states.
Under it is a new "Cells" section that contains the colours of the cells (including Bounded Grid and Boundary) and also whether cell borders are displayed.

Would it be possible to either make these cells theme-dependent (in which case, here's a post from 2020 containing color proposals for what was changeable at the time, and here's my proposal for how Themes could be made to support rule tables which I'm still very proud of and strongly stand by today), or relocate these to a new, closeby section?

Extending the Themes is interesting but has never made it to the top of the backlog. I've always got something higher priority to do (for example Cell Period Map for Identify, @ICONS support, Progress Bar for Identify, etc.).

A related sighting which may be a bug: for certain pattern errors, the "Theme" section in Help displays far less theme-related data that expected, which appears to vary depending on the rulespace even for the same type of error...

I don't know how valid this report is given that it depends on another error to happen to see this, and is also likely simply revealing ultimately inconsequential differences regarding rule processing.

I'm not going to fix these for the reason you stated.

[muzik]

It's been mentioned before that history and age fading is handled internally via the use of extra cell states. Would it be possible to view the exact color assigned to each state somewhere, since we can already do this for the fading cells from Generations, as well as the state used internally for each age?

[muzik]

Hexagonal Selections

Can anyone point me at a tool or paper that describes a good way of making selections on a hexagonal grid?

I'm not sure if this would be of any use.

I have, however, been wondering if it'd be worth implementing one of those "draw a closed loop and everything inside of it will be selected"-type selections, since those would work regardless of the type of grid used.

[muzik]

When the Settings and Help menus are opened, a dark gray background is applied to the viewer. This appears to be hardcoded. Could the color of this background be made customizable as to fit in with the ability to customize all other UI elements?

[rowett]

When the Settings and Help menus are opened, a dark gray background is applied to the viewer. This appears to be hardcoded. Could the color of this background be made customizable as to fit in with the ability to customize all other UI elements?

The UI background colour is now used in these cases.

Code: Select all

x = 3, y = 1, rule = B3/S23
3o!
[[ COLOR UIBACKGROUND DarkBlue ]]

[muzik]

One of the few things remaining that doesn't have a customizable color is the red flashing of the playback speed slider. Can this be made changeable?

On the topic of colors: for Help > Info > Identify, I'd like it if the positions of the values for "Back" and "Grid" were switched. "Back" describes a type of cell, just like the different periods are, so I personally think it should be listed closer to them.

[rowett]

One of the few things remaining that doesn't have a customizable color is the red flashing of the playback speed slider. Can this be made changeable?

This now uses the Error colour.

On the topic of colors: for Help > Info > Identify, I'd like it if the positions of the values for "Back" and "Grid" were switched. "Back" describes a type of cell, just like the different periods are, so I personally think it should be listed closer to them.

Done.

[muzik]

I've noticed a small inconsistency: if we set the UI background to white, the disabled script indicators directly to the right of the zoom bar have a white shadow, but disabled buttons on the bottom have shadows colored identically to themselves.

Code: Select all

x = 19, y = 16, rule = B3/S23
17bo$17bo2$17bo$16bobo$2bo6bo$b2o6b2o5b3o$3o6b3o$b2o6b2o$2bo6bo6b3o2$
16bobo$17bo2$17bo$17bo!
[[ COLOR UIBACKGROUND White ]]

If we set the UI foreground color to something, the extent of this becomes more obvious: text in buttons has a UIBACKGROUND shadow, whereas pictographic elements have a UIFOREGROUND shadow.

Code: Select all

x = 19, y = 16, rule = B3/S23
17bo$17bo2$17bo$16bobo$2bo6bo$b2o6b2o5b3o$3o6b3o$b2o6b2o$2bo6bo6b3o2$
16bobo$17bo2$17bo$17bo!
[[ COLOR UIFOREGROUND Aqua COLOR UIBACKGROUND White ]]

The default settings, as well as only changing UIFOREGROUND, does not seem to result in any visible such effects.

Code: Select all

x = 19, y = 16, rule = B3/S23
17bo$17bo2$17bo$16bobo$2bo6bo$b2o6b2o5b3o$3o6b3o$b2o6b2o$2bo6bo6b3o2$
16bobo$17bo2$17bo$17bo!

Code: Select all

x = 19, y = 16, rule = B3/S23
17bo$17bo2$17bo$16bobo$2bo6bo$b2o6b2o5b3o$3o6b3o$b2o6b2o$2bo6bo6b3o2$
16bobo$17bo2$17bo$17bo!
[[ COLOR UIFOREGROUND Aqua ]]

This issue may be directly linked to white itself; using other colors results in consistent shadows.

Code: Select all

x = 19, y = 16, rule = B3/S23
17bo$17bo2$17bo$16bobo$2bo6bo$b2o6b2o5b3o$3o6b3o$b2o6b2o$2bo6bo6b3o2$
16bobo$17bo2$17bo$17bo!
[[ COLOR UIBACKGROUND Pink ]]

Code: Select all

x = 19, y = 16, rule = B3/S23
17bo$17bo2$17bo$16bobo$2bo6bo$b2o6b2o5b3o$3o6b3o$b2o6b2o$2bo6bo6b3o2$
16bobo$17bo2$17bo$17bo!
[[ COLOR UIFOREGROUND Aqua COLOR UIBACKGROUND Pink ]]

Side note: I'd be interested in seeing shadow colors be configurable individually from the UI background color. This could be done via something like "COLOR UISHADOW". If UIBACKGROUND is specified in a script but UISHADOW is not, then shadows would use the UIBACKGROUND color, as to retain backwards compatibility, but if UISHADOW is specified, shadows will use that color instead.