lifeviewer bug

[I6_I6]

I'm pretty sure this is a known bug (since it happens quite often for me), but I couldn't find it in this thread. If you add bounded grid specifications after an alternating rulestring, it works just fine. But if you go to Settings > Pattern > Change Rule, the bounded grid suffix appears after both rules that are being alternated. Trying to apply the rule makes LifeViewer think the rule is alternating between RuleLoader rules, so it says "Alternating RuleLoader rules are not supported".

For example, when applying the rule "B1/S2|B3/S4:T6,6", it works normally when running it, but when you go to Change Rule, it shows "B1/S2:T6,6|B3/S4:T6,6". The suffix is automatically added to both subrules, which LifeViewer doesn't accept. It raises the error if you press OK in the popup unless you manually remove the first suffix.

Also, if both subrules of an alternating rule are the same, LifeViewer automatically changes it into a non-alternating rule. But if such an alternating rule has a bounded grid suffix, that suffix is applied twice to the autocorrected rule. For example, "B3/S23|B3/S23:T16,16" becomes "B3/S23:T16,16:T16,16". Attempting to use this rule raises "Illegal character in survival specification".

I don't really think this would be that hard to fix, though.

[rowett]

If you add bounded grid specifications after an alternating rulestring, it works just fine. But if you go to Settings > Pattern > Change Rule, the bounded grid suffix appears after both rules that are being alternated.

Thanks for the report. Fixed in build 1384.

[I6_I6]

(This isn't a bug, but rather a suggestion/request. I couldn't find a thread for that, so I'm posting here.)
Is there a way to make autofit smoother? It snaps to fit every generation, which looks very rickety, especially for patterns with rapidly changing bounding boxes.

For example, here's a TL:

Code: Select all

x = 7, y = 7, rule = B3/S23
2b3o2$o5bo$o5bo$o5bo2$2b3o!
[[ AUTOFIT ]]

Pentadecathlon looks even more cursed:

Code: Select all

x = 10, y = 3, rule = B3/S23
2bo4bo$2ob4ob2o$2bo4bo!
[[ AUTOFIT ]]

I can tell it doesn't instantaneously snap right into position every generation...

Code: Select all

x = 1, y = 1, rule = B3/S23
o!
[[ AUTOFIT GRID PASTET 1 PASTE 2o$2o!  0 20 ]]

...but I still think it could be made smoother.

EDIT to avoid doublepost:
Crossposting from Golly Bugs thread:

This is also a problem in LifeViewer.
In @TABLE in a .rule file, if I name a variable "var", and use it at the start of a transition line, it doesn't behave as expected.
For example, this rule should be B2/S012345678:

Code: Select all

x = 0, y = 0, rule = test
!
@RULE test
@TABLE
n_states:2
neighborhood:Moore
symmetries:permute
var var={0,1}
var,1,1,0,0,0,0,0,0,1

But it behaves like B/S012345678 instead.
Simply renaming the variable to something else fixes this:

Code: Select all

x = 0, y = 0, rule = test
!
@RULE test
@TABLE
n_states:2
neighborhood:Moore
symmetries:permute
var a={0,1}
a,1,1,0,0,0,0,0,0,1

I think it's because Golly treats any line in @TABLE that starts with "var" as a variable definition line. I don't know why anyone would name a variable "var", but I think it should still be fixed.

[Citation needed]

The "Symbiosis" rule table crashed.

[rowett]

The "Symbiosis" rule table crashed.

Please post an example pattern that crashes.

[Citation needed]

The "Symbiosis" rule table crashed.

Please post an example pattern that crashes.

That seemed to be just a temporary crash.

[squareroot12621]

The photosensitivity warning in LifeViewer says the display will only update once every 400 milliseconds. However, this can be changed to 200 milliseconds, because:

a flash or rapidly changing image sequence is below the threshold (i.e., content passes) if any of the following are true:

• there are no more than three general flashes and / or no more than three red flashes within any one-second period; […]

where:

• A general flash is defined as a pair of opposing changes in relative luminance of 10% or more of the maximum relative luminance (1.0) where the relative luminance of the darker image is below 0.80; and where "a pair of opposing changes" is an increase followed by a decrease, or a decrease followed by an increase, and
• A red flash is defined as any pair of opposing transitions involving a saturated red

(colored text mine)
In other words, it takes 2 generations—one to turn on a cell, and the other to turn it off—to count as a flash. This means the maximum number of display updates per second is 6 (3 flashes of 2 generations each), so the time between updates is should be at least 167 milliseconds.
Although the minimum time between updates is 167 milliseconds, I’m recommending that it should be changed to 200 milliseconds. 200 is a round number, unlike 167, and it’s a neat halving of the original limit. (I think the limit was set at 400 milliseconds under the assumption that the display could only update 3 times a second, rather than 6.)

Edit: Looks like the relevant code is line 85 of lifeview.js.

[otismo]

something seems a bit "off" with the latest forum build of LV

[COMPARE Trioscillon here in forum with same at cgol art using older build]

Thank You for LV !

<3