Fixed.
It's on the backlog but low priority so not sure when it will get done.
No since it's possible to draw extra cells and keep playing. Also the [[ PASTET ]] command can add new cells at a later generation than the initial set of cells died.
Fixed.
It's on the backlog but low priority so not sure when it will get done.
No since it's possible to draw extra cells and keep playing. Also the [[ PASTET ]] command can add new cells at a later generation than the initial set of cells died.
Fixed, thanks for reporting!
Fixed, thanks!muzik wrote: ↑April 20th, 2021, 6:46 amIdentify on this gives both a period and mod of 67292. However, running this to generation 16823 (67292/4) and rotating it accordingly gives a figure identical to the starting one. This also works for 33646 (67292/2) and 50469 (3(67292)/2), so the expected mod here would be 16823.
Done.
I don't see this. Did you mean "Major Gridlines"? If so then it should be on and greyed out until you switch "Use Rectangles" on.
Both fixed, thanks!muzik wrote: ↑April 21st, 2021, 2:50 pmWhen moving forward purely by using the step forward button, natural deaths or all cells show the message as expected, but those resulting from KILLGLIDERS do not:
EDIT: I've also noticed that the values in the T menu don't account for it properly either, so perhaps due to there being a nonzero amount of births it assumes the pattern can't have died out?
Fixed, thanks!
Noted.
Code: Select all
x = 31, y = 32, rule = B3/S23
2o$2o$o12$12bo$10bobo$11b2o13$29b2o$29b2o$29bo!
[[ KILLGLIDERS AUTOSTART STOP 3 ]]
In this case your nitpick is invalid since you're trying to apply "normal rules" to KILLGLIDERS which isn't normal since it can kill things that were created in the same generation. Hence the calculation is correct. In that generation 2 cells were created (as the glider moved) and then got killed by KILLGLIDERS.muzik wrote: ↑April 23rd, 2021, 10:51 amsomething illogical can be seen to happen in generation 4: a primordial dead cell immediately becomes a freshly dead cell, which is something that can obviously never happen through normal rules. T statistics confirm this, showing 2 births despite there being 0 alive cells.
Code: Select all
x = 4, y = 3, rule = SemiFelineLife
obo$o2bo$obo!
Due to how the keyboard works on an iPad and probably other landscape touchscreen devices, clicking View with the keyboard still brought up results in an extremely thin viewer window. It has to be quit out of to get a reasonably usable window size back.rowett wrote: ↑August 5th, 2020, 1:51 amNew resizeable LifeViewer is here. Would much appreciate any feedback!
I'm aware there's an issue with menu controls overlapping if the window is made too narrow and the Settings button not appearing if the initial window height is too small. I'll fix in due course.
Copying the rule doesn’t work for me, as it pasted nothing.(copy rule button)muzik wrote: ↑April 23rd, 2021, 2:31 pmCode: Select all
x = 4, y = 3, rule = SemiFelineLife obo$o2bo$obo!
Please let me know which platform and browser you are using.yujh wrote: ↑April 23rd, 2021, 8:15 pmCopying the rule doesn’t work for me, as it pasted nothing.(copy rule button)muzik wrote: ↑April 23rd, 2021, 2:31 pmCode: Select all
x = 4, y = 3, rule = SemiFelineLife obo$o2bo$obo!
iPad, safari.rowett wrote: ↑April 24th, 2021, 4:35 amPlease let me know which platform and browser you are using.yujh wrote: ↑April 23rd, 2021, 8:15 pmCopying the rule doesn’t work for me, as it pasted nothing.(copy rule button)muzik wrote: ↑April 23rd, 2021, 2:31 pmCode: Select all
x = 4, y = 3, rule = SemiFelineLife obo$o2bo$obo!
Likewise, some oscillators have transformations that could equivalently be considered either RotCW or RotCCW (it seems to default to the latter):
Code: Select all
x = 5, y = 7, rule = B2in3/S123a
o2bo$o2bo$b2o2$2b2o$bo2bo$bo2bo!
Code: Select all
x = 5, y = 7, rule = B2in3/S123a
bo2bo$bo2bo$2b2o2$b2o$o2bo$o2bo!
This should be fixed now. Please let me know.muzik wrote: ↑April 22nd, 2021, 1:51 pmSpecifically, this is the issue where clicking on a button in the viewer can occasionally not cause the button press to be registered until clicking on somewhere in the viewer again. If that click happens on the same button, it will register as the button having been pressed twice.
A couple minutes messing about with the Select tool in the new build has failed to trigger it. While I'm yet to see if other functions are fixed as well (although I do strongly expect that they will be), in the meantime please accept my gratitude for once and for all putting a well-deserved end to LifeViewer's most long-standing, annoying bug.rowett wrote: ↑April 24th, 2021, 2:40 pmThis should be fixed now. Please let me know.muzik wrote: ↑April 22nd, 2021, 1:51 pmSpecifically, this is the issue where clicking on a button in the viewer can occasionally not cause the button press to be registered until clicking on somewhere in the viewer again. If that click happens on the same button, it will register as the button having been pressed twice.