rowett wrote:Updated the [[ LABELT ]] command to take three parameters <t1>, <t2>, and <fade>...
Looks good! And that rated a new build number, I see. I've copied it out to try making labels for the timeline animation -- here's hoping I can avoid being distracted by anything else for a while.
But speaking of distractions: emailing back and forth with Will Cavendish last night, we ran into a LifeViewer limitation where the best current workaround seems to be to create multiple animations and then string them together outside of LifeViewer.
The problem is a simple one -- but I've asked you about it before, so I'm guessing it might be a headache to implement a fix for it. At the very beginning of the animation, I've put in a random scattering of polyominoes as placeholders, because that's what Conway's group was testing. They worked their way up to the R-pentomino and discovered the glider (and found themselves in the special level of Hell reserved for people who try to simulate 1103-tick methuselahs with nothing but graph paper and tile floors.)
Ideally I could focus on a single dot, show that it dies, focus on a domino spark, show that it dies, move to the two tetrominoes, show that they survive, and then jump to a nice organized set of 12 pentominoes and show how they all do boring things except for the R. But I can't jump backwards in time in a waypoint script, and I can't jump to T=0 in a new pattern which would also work fine.
There are two in-viewer tricks I could use. One would be to find multi-tick predecessor patterns for the tetrominoes and pentominoes, so that they're just getting to the pentomino stage when I get around to looking at them. But that seems a little silly.
Instead of that, I'll try using PAUSE 0 instant-jumps with different labels in different locations, to switch to each frame of the movie I want to show. Then the actual simulation only has to start when I get to the pentominoes.
-- Not that I'd mind having the option of jumping instantly to any spacetime location (disregarding some calculation time for getting to new time T from the nearest earlier saved state). But it doesn't look like I really need it in this case after all...!
rowett wrote:LifeViewer has a maximum grid size of 8192x8192. I set it to that mostly to conserve memory in the browser but also because I suspected it was unlikely that displayed larger patterns in the browser would be common, and even if they were, animating patterns that large might be slow in Javascript.
Now you're building bigger and better animations do you see a need for 16384x16384 grids? I've tested LifeViewer and it works fine - it just uses more memory (around 800Mb). Because of the resource requirement if it was needed I'd probably have it enabled by a script command.
I certainly don't mind LifeViewer having the option to use a larger grid. People do bump up against the current boundaries now and again. Did you see the latest
Amazing Minstrel Remover and Detector, for example?
