lifeviewer bug

[rowett]

This bug would never occur in LifeViewer homepage or ConwayLife homepage. The only known occurrences happen in the forums or LifeWiki.

Does it occur on embedded Viewers (like the one below) or just on PopUp viewers (when you click Show In Viewer)?

Code: Select all

x=3, y=3, rule=B3/S23
o$obo$2o!

If you go to settings and click Rand All, there's a chance that some buttons in Settings > Display (mostly Shaders and Render Quality) would show despite the settings closed. If not, repeat the process. Reproducible using any devices.

I can't reproduce this either.

[R2INT]

I also seem to get bugs on my touch device. On https://lazyslug.com/lifeviewer, after using the touch screen on it, LifeViewer no longer registers keyboard shortcuts.

Which device and browser are you using?

The browser I am using on my LENOVO_MT_20KK_BU_Think_FM_ThinkPad X1 Tablet Gen 3 is Microsoft Edge.

[b-engine]

This bug would never occur in LifeViewer homepage or ConwayLife homepage. The only known occurrences happen in the forums or LifeWiki.

Does it occur on embedded Viewers (like the one below) or just on PopUp viewers (when you click Show In Viewer)?
[v¡ewer]
x=3, y=3, rule=B3/S23
o$obo$2o!
[/v¡ewer]

(Changed the tags to avoid the large embedded viewer)

I don't observe that in embedded viewers.
Also note that the embedded viewers have empty space (indicated by the scrolling bar below) which takes up the old large size of the viewer.

Screenshot_20250408_060752_com.android.chrome.jpg (126.06 KiB) Viewed 5781 times

[WhiteHawk]

I just lost the ability to paste anything in LV, where when I try to paste the red box, nothing gets pasted. I was working in the rule B38/S23 if that helps

Also, what happened to the feature where I could grab any sized package of empty space and it would paste a de-emptiness version automatically?

[Citation needed]

The "trolls" somehow stopped working.

[b-engine]

I had later observed that this bug could even happen in embedded viewers.
Maybe a problem with forums and LifeWiki.

[confocaloid]

for some reason these don't work anymore????
EDIT: seems like "PASTEMODE COPY" isn't working as it should.

Thou shalt not cause Paradoxes by changing transitions in specific Spacetime points.
Thou shalt rulegolf only by changing the Rules and therefore causing consequences across the entire Spacetime continuum.

[b-engine]

I'm once again asking.

This bug annoys me - every time I'm making a ruletable and decide to draw a pattern, but then LifeViewer just don't let me draw any pattern.

Could backup controls being added (such as joystick) when this happens?
(Note: absolutely never, never use an emulator to reproduce the bug.)

[b-engine]

SMOS:

Code: Select all

x = 6, y = 6, rule = SMOSmore
AB4$5.B$5.A!

@RULE SMOSmore
@TABLE 
n_states:5
neighborhood:Moore
symmetries:rotate4reflect
var a={0,1,2,3,4}
var a1=a
var a2=a
var a3=a
var a4=a
var a5=a
var a6=a
var a7=a
var a8=a

0,2,0,0,0,0,0,0,0,2
0,2,0,2,0,0,0,0,0,3
0,3,1,0,0,0,0,0,0,2
0,1,3,0,0,0,0,0,0,1
3,1,0,1,0,0,0,0,0,0

0,a,a1,a2,a3,a4,a5,a6,a7,0
1,a,a1,a2,a3,a4,a5,a6,a7,0
a,a1,a2,a3,a4,a5,a6,a7,a8,1
@COLORS
1 255 255 255

LifeViewer throws an error that states that B0 is only valid in bounded grid, but the ruletable clearly states that state 0 turns into state 0 unless otherwise specified, before the line that states every cell turns into state 1. When appending a bounded grid specification behind the rule name "SMOSmore", there's no strobing.

[rowett]

LifeViewer throws an error that states that B0 is only valid in bounded grid, but the ruletable clearly states that state 0 turns into state 0 unless otherwise specified, before the line that states every cell turns into state 1.

Fixed in build 1308. Thanks for reporting!

[Antonin Duda]

A wild af replicator in Gaussian Neighborhood...

Code: Select all

x = 3, y = 1, rule = R3,C0,S4-7,24-27,B24,28-31,35,NG
3o!

For some reason, patterns in NG behave differently on Golly vs Lifeviewer.
The survival conditions are simply off by one.

[confocaloid]

A wild af replicator in Gaussian Neighborhood...

Code: Select all

x = 3, y = 1, rule = R3,C0,S4-7,24-27,B24,28-31,35,NG
3o!

For some reason, patterns in NG behave differently on Golly vs Lifeviewer.
The survival conditions are simply off by one.

I tried to rewrite the Gaussian neighbourhood (NG) as a weighted neighbourhood with explicit weights (NW).

• In Golly, both versions are correctly processed as eventually-dying patterns (generation 117 is the last nonempty generation).
• In LifeViewer (build 1308), the explicitly-weighted version appears to work correctly; the "NG" version appears to be bugged.

This means the pattern you posted isn't a replicator, as far as I can tell, it is a consequence of a LifeViewer bug.

Code: Select all

x = 3, y = 1, rule = R3,C0,S4-7,24-27,B24,28-31,35,NG
3o!

Code: Select all

x = 3, y = 1, rule = R3,C0,S4-7,24-27,B24,28-31,35,NW01020304030201020406080604020306090C09060304080C100C08040306090C0906030204060806040201020304030201
3o!

Indeed, changing (actually decrementing) survival conditions gives what is likely to be the intended object (tested in Golly):

Code: Select all

x = 3, y = 1, rule = R3,C0,S3-6,23-26,B24,28-31,35,NG
3o!

Code: Select all

x = 3, y = 1, rule = R3,C0,S3-6,23-26,B24,28-31,35,NW01020304030201020406080604020306090C09060304080C100C08040306090C0906030204060806040201020304030201
3o!

[b-engine]

I do not see any malformations in the rule table. However LifeViewer still throws an error:

Code: Select all

x = 0, y = 0, rule = testet
!
@RULE testet
@TABLE
n_states:4
neighbourhood:vonNeumann
symmetries:none
var a = {0,1,2,3}
var a1=a
var a2=a
var a3=a

[confocaloid]

I do not see any malformations in the rule table. However LifeViewer still throws an error:

Code: Select all

neighbourhood:vonNeumann

Unfortunately Golly and LifeViewer seem to require a particular spelling of the word 'neighbourhood', which differs from how it's spelled in this sentence.

Also, as a matter of principle, I would make the pattern at least 1x1 and add a single cell (even if it's a state-0 cell). (That it currently works either way doesn't mean it doesn't matter.)
Also, the conventions are that the .rule filename should begin with an uppercase letter.

Code: Select all

x = 1, y = 1, rule = Testet
b!

@RULE Testet
@TABLE
n_states:4
neighborhood:vonNeumann
symmetries:none
var a={0,1,2,3}
var a1=a
var a2=a
var a3=a

[Vlev2]

AntiLife not working
when i type in AntiLife or the rulestring of AntiLife in the "rule =" spot in advanced options, instead of actually working, it gives me normal life
how do i fix this?

Code: Select all

x = 1, y = 1, rule = AntiLife
7o$7o$3ob3o$4ob2o$2o3b2o$7o$7o

Code: Select all

x = 1, y = 1, rule = B0123478/S01234678
7o$7o$3ob3o$4ob2o$2o3b2o$7o$7o

[confocaloid]

AntiLife not working [...]

It actually accepts it and interprets it as AntiLife, but it emulates it by converting to the equivalent non-B0 version, and displays emulation (instead of showing nonempty or non-quiescent background).

In particular, a Life-like cellular automaton whose ruleset contains both B0 and S8 is converted into an equivalent CA (with the rule A0 instead of the rule B0), by "inverting" the neighbor counts, and then using S(8-x) for the birth conditions and B(8-x) for the survival conditions.
For example, B0123478/S01234678 (AntiLife) is changed to B3/S23 (Life) via these steps: B0123478/S01234678 -> B56/S5 -> B3/S23.

If you want to see how it would work "actually", you would likely need to define a three-state CA (supported by RuleLoader) where cellstate 1 stands for "dead" and cellstate 2 stands for "alive". This approach allows to see "blinking background" (for the B0/D8 rulesets) and "nonempty background" (for the B0/S8 rulesets). See the link viewtopic.php?p=193317#p193317 (forum thread) for an example of how that could be implemented and how it would look like.

[dvgrn]

AntiLife not working [...]

It actually accepts it and interprets it as AntiLife, but it emulates it by converting to the equivalent non-B0 version, and displays emulation (instead of showing nonempty or non-quiescent background).

Yup. The weird-at-first-sight thing is that the decision was made many years ago that RLE of these types of emulated inverted patterns is considered to encode the interesting "foreground" cells (state 0) rather than the presumed-uninteresting background state-1 cells.

That way the relevant population counts can be shown in anti-rules in LifeViewer and Golly. Otherwise an empty universe of whatever size would jump to infinite population, or to some arbitrary huge number for a bounded universe, after one tick.

For anyone who doesn't know about that old weird decision, it's totally reasonable to expect that LifeViewer would display Vlev2's pattern as a glider instead of an anti-glider, which would then behave the way a glider normally behaves, at least for a tick or two. But that's not how pattern encoding is implemented in the anti-rules -- and as a result, there's no need to specify all the background cells, and the RLE ends up much smaller and less ugly.

Vlev2's pattern RLE was non-standard in a couple of other ways, but even when it's standardized, LifeViewer still runs the pattern as if it were standard Life, all due to this weird "which cells are considered to be the important ones" convention:

Code: Select all

x = 7, y = 7, rule = AntiLife:T7,7
7o$7o$3ob3o$4ob2o$2o3b2o$7o$7o!

Code: Select all

x = 7, y = 7, rule = B0123478/S01234678:T7,7
7o$7o$3ob3o$4ob2o$2o3b2o$7o$7o!

Notice in the above link Macbi was looking for a Life universe with live cells around the border -- didn't really want an AntiLife universe. So it was a slightly different case.

[confocaloid]

[...] Otherwise an empty universe of whatever size would jump to infinite population, or to some arbitrary huge number for a bounded universe, after one tick. [...]

In CA with the "birth on zero alive neighbours" rule, an empty universe (as well as any finite-population pattern) does indeed jump to infinite population after one tick. This is a direct consequence of the rules: every cell whose current condition is "dead with zero alive neighbours" becomes alive in the next generation, so if there are infinitely many such cells, then there are infinitely many births in the next tick.

I think it would be significantly clearer if Golly/LifeViewer reported cell counts separately for each cellstate, rather than lumping them together into a single count. Then it would be indeed possible

• to correctly report something like "∞ state-0 cells, 314 state-1 cells" in even-numbered generations,
• and to correctly report something like "271 state-0 cells, ∞ state-1 cells" in odd-numbered generations.

and the current reporting can be considered misleading in this way: it incorrectly claims a finite population for a pattern that's supposed to have infinite population.

Another good possibility would be to make the emulation explicit, and explicitly convert every CA with the "birth on zero alive neighbours" rule into an equivalent CA without the rule B0, and show the converted rulestring/definition rather than the original one, etc. That would make it clear what is going on.

[pifricted]

Change the rule to “B3-q4q66i/S2-i35i”, pattens will run in rule “B3-q4q6/S2-i35i”, but will save as “B3-q4q6i/S2-i35i”.

Code: Select all

x = 11, y = 9, rule = B3-q4q6i/S2-i35i
4bo2$5bo$b2o5b2o$4o3bob2o$b2o5b2o$5bo2$4bo!

[unname4798]

PiLife/DryLife examples:

Code: Select all

#R B377e/S23|B37/S23
!
DryLife (named as PiLife)|DryLife -> DryLife (named as PiLife)

Code: Select all

#R B377e/S23|B37e/S23
!
DryLife (named as PiLife)|PiLife -> "PiLife|PiLife"

The bug not only happens when changing a rule, but also when defined in the #R section or rule section.

[rowett]

Change the rule to “B3-q4q66i/S2-i35i”, pattens will run in rule “B3-q4q6/S2-i35i”, but will save as “B3-q4q6i/S2-i35i”.

It's not valid to have 6 and then 6i in the rule string. What was your intention?

[Citation needed]

The "trolls" somehow stopped working.

for some reason these don't work anymore????
EDIT: seems like "PASTEMODE COPY" isn't working as it should.

ColorfulGalaxy found a workaround solution by having LifeViewer paste history cells rather than empty cells.

[Citation needed]

The "trolls" somehow stopped working.

for some reason these don't work anymore????
EDIT: seems like "PASTEMODE COPY" isn't working as it should.

ColorfulGalaxy found a workaround solution by having LifeViewer paste history cells rather than empty cells.

[confocaloid]

Can you be a bit more clear? What is supposed to be "a workaround solution" for what, why should I be quoted/pinged in relation to the issue, and why twice in a row?

ColorfulGalaxy found a workaround solution by having LifeViewer paste history cells rather than empty cells.

ColorfulGalaxy found a workaround solution by having LifeViewer paste history cells rather than empty cells.

[Citation needed]

Can you be a bit more clear? What is supposed to be "a workaround solution" for what, why should I be quoted/pinged in relation to the issue, and why twice in a row?

The problem was that "LifeSuper trolls" weren't working.

EDIT by dvgrn: Sent a PM to Citation needed about this post, which ended up in a different thread for some reason.